ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

The honest answer is: it has grown this way. The first version by Romanetz was a combination of PlutoStep stepgen with (I think) own implementation of gpio, pwm and encoders. That has been my starting point.

The goal for me was to make the design more flexible, i.e. the end user should be able to choose which pins have which function, regardless which supported card they choose. Also, I strive to mimic the Hal pinout of the normal Linuxcnc components which you use with the parport (which it will replace in my machine). The latter did not completely work out for the stepgen however.

For using the bit-file for Mesa cards, I think that is only possible for the Rv901t, however I'm not 100% sure. Both Mesa and the Rv901t use the Spartan chipset. The 5a-series uses ECP chipsets.

Your more then welcome to try out the LitexCNC drivers. I would like to recommend to try it first with 5A-75B, as that tool chain is fully open source and the easiest. For the Rv901t we discovered that the Verilog generated by Litex requires some hand work to get it work. Also the Xilinx software is very large and I found it hard to obtain.

The branch with the latest version is 'stepgen_improvement'. As we speak I get a Joint following error due to a refactoring I did. I have to revert the last commit, that will restore it in a working order.

Thanks for the explanation. I wasn't talking about using the mesa bitfiles, but parts of the source code. I was in the process of porting the hostmot2 code to colorlight when I discovered this project. Using Litex as a basis is a great idea to cover a broad range of cards. I really like that, although I have no experience with Litex, but some experience with nmigen/amaranth.
Although the hostmod code is vhdl, I think it should still be possible to port the stepgen etc implementations (the "hostmot2" module) into the litex framework. That way, we could make use of the existing host driver as well as having a tried and tested implementation for stepgen etc. Having this as a starting point would enable me to quickly move away from LPT (new Servos and 3d touch probe just arrived . Going from there, we could gradually improve or replace existing components, as well as switching to a different protocol.
But these are just my first thoughts. First I have to get your project to run. I managed to install xilinx ISE on my arch, as well as the yosys/nextpnr-ecp5 toolchain. Next step is to get a good understanding of litex.

Why can't I use stepgen_improvement and main to compile into firmware, only the encoder can be used to compile successfully
The picture above shows the result， I don't know what's wrong, I've reverted countless times with virtual machine snapshots, still the same problem, I installed it according to DePrutser's instructions

5A-75E builds, but it fails timing:

Warning: Max frequency for clock '$glbnet$crg_clkout0': 42.97 MHz (FAIL at 50.00 MHz)
Warning: Max frequency for clock '$glbnet$eth_clocks_rx$TRELLIS_IO_IN': 107.31 MHz (FAIL at 125.00 MHz)

Please use Python 3.8 or later. That will solve the import error.

About timing: this happened with the last commit on stepgen_improvement. Have to revert that commit (or you can try to pull using the commit hash of the commit before). Try to solve that tonight. 

Okay, I think I see what you're doing here. To be able to use the MESA-protocol it would be necessary to replace etherbone by our own Ethernet/WB controller, which is not very attractive. Also the memory would need remapping.
Another question that popped up in my mind while reading through the sources ... why not bake the json-config into the firmware and make it available to the host? This way we would get a completely self-identifying card, only the IP address would have to be known to the host.
Regarding timing: is it imperative that the general clock stays at 50MHz? Why not reduce it to 25MHz to relax the timing requirements? Ethernet clock has to stay at 125MHz, of course, but with the right setting I have been able to meet that.

sensille wrote:

Another question that popped up in my mind while reading through the sources ... why not bake the json-config into the firmware and make it available to the host? This way we would get a completely self-identifying card, only the IP address would have to be known to the host.
Regarding timing: is it imperative that the general clock stays at 50MHz? Why not reduce it to 25MHz to relax the timing requirements?
​​​​​
 

Hi, about the self identification, this is what I'm working on right now on my version of the driver (github.com/faeboli/Lcnc).
The idea is to report in a pair of registers the firmware contents in the form of Number of each peripheral, and make the driver adapt to It.
My firmware Is also failing the timing closure on 50MHz, but my board (5a75e) seem to be working ok. I think the clock can be lowered to 40MHz or less without issues.

Fabio

I'm not sure yet about self identification, because the config file also allows a user to create names for pins. This might make the HAL a little bit more accessible then the numbers. Another thing which is in the configuration is the IP-address of the card, which is required to start. However, one can always set the IP-address ass a parameter for the component. For now I see the JSON a part of the HAL-structure of LinuxCNC, just as the ini-file and the hal-files.

For slowing down the clock if timing issues are not met: in the JSON-file you can set the parameter "clock_frequency" to a lower value when necessary. Please note, you need to pull the latest version to be able to do this.

Made a chance in the steogen-config in order to make it more flexible (adding more stepper types such as differential, unipolar, etc.). When pulling the latest, please note that the format of the JSON has changed. Please refer to the stepgen example for the correct format.

I also think the names of the pins can be useful. My proposal for self-identification was to make the (possibly compressed) json file accesible to the host by some means, either by memory mapping it or by storing it in the flash and let the host read it from there. So only the IP address remains to be configured.

Not sure if the capability to reduce the clock via json is a useful feature. Either a high clock is not necessary, then we can always go with a low clock, or a minimum frequency is needed, in that case it should be allowed to go below that. Why not just pick a low value that's easy to implement for all?

I already went through the config change yesterday, my day ended with a ping reply from my rv901t As you already hinted at I had to change the constraint file manually. I filed an issue for that, github.com/enjoy-digital/litex/issues/1502

About the clock frequency: it is still the 125 MHz clock which is the limiting factor (error in timing). Whether it is useful to have a user configurable clock frequency: I think so. There will be always users wanting to tweak it; for the normal users they can just let it be the default setting. A sensible value for that we have of course to determine.

At this moment I shift focus to create some HUB75 breakout boards for the different functions. All boards have standard dimension of 85 x 56 mm (equal to a Raspberry Pi, although mounting holes are not aligned). At this moment I have designed:

• HUB-75 -> Stepgen differential
  Breakout board which converts 2HUB-75 connectors to 3 stepgen outputs using differential pairs (5V) for high speed operation up to 400 kHz. The enable signal for the stepper drivers is shared. Per channel the ENA can be selected as either active HIGH or active LOW using a DIP-switch. On the board is also a HUB-75 connector for ALARM input, which can also be selected as active HIGH or active LOW with a DIP-switch. Two boards can share 1 HUB-75 input connector (total 6 inputs, for each ALARM one).
• GPIO -> HUB-75 (sinking input)
  Break-out board which supplies 12 sinking inputs, requires 2 HUB-75 input connectors. The inputs are 5-24 Volt tolerant and are isolated from the FPGA using opto-couplers (LTV827). All inputs have indicator LED's to show which input is active. Designed for PNP limit switches and buttons which switch to VField. Each input is a JST connector with three pins, supplying VField, GND and Signal, so limit switches can be easily connected. Can also be used for encoders, but is limited to approximately 1~10 kHz; for faster encoders a different breakout board will be developed.
• HUB-75 -> GPIO (sourcing output)
  Break-out board which supplies 12 sourcing outputs, requires 2 HUB-75 output connectors. Field power can be in the range of 5-24 Volts. Isolated from the FPGA with opto-couplers (LTV827). High side switching using P-channel MOSFETs, which can deliver up to 300 mA per channel.  All outputs have indicator LED's to show which output is active. Each output is a 2-pin JST connector positive and negative (GND) terminal. Designed for a frequency of 1 kHz, but will most-likely support a higher frequency.

My TODO-list:

• Add reverse polarity protection on field power and maybe also a power-indicator;
• Create a board for fast encoders using a RSS-422 chipset for accepting differential input;
• Put the boards on GITHub with a nice description

I try to finish these boards this week so I can order prototypes