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

No, The IceStudio is for new implementations.
The adventage of this IDE is that you don't need to know any HDL Language to use it

@benitoss:
I've looked into IceStudio, but in my honest opinion I think that LiteX is more then sufficient for creating the firmware. Within LiteX-CNC I've tried to make a stepgen-component both in Litex and with IceStudio. The benefit of creating it with Litex is that the created Verilog code is human readable and you can easily debug the code. The code created with IceStudio has random names, which means that tying in to variables and modules is more difficult, or impossible to mix both methods.

Maybe my knowledge is too limited on this subject, so please prove me wrong.

Update:
For my re-write of ColorCNC to the more generic LiteX-CNC I have created a new step generator. This one is a drop in replacement for the standard stepgen supplied with LinuxCNC. The card can easily sustain a 400 kHz step-frequency (tested) with correct timings for steplen, dir setup and dir hold. Improvement over the Plutostep is the more correct timing when dir changes between two steps. The firmware I've tested, now working on the driver.

@Inga: I noticed in the firmware that values in both the read and write messages are being converted with htobe32(...). The FPGA is big-endian, this means that reading from the card will be erroneous I think when the CPU is little-endian (such as x86). Should reading from the card not use be32toh()?

Hello
enjoy-digital provided a bugfix that should address the disconnection problem in litex in case of packet collisions.
I tested it on a simplified testbench and seem effective, but I still didnt verify it on actual linuxcnc on raspi.
see
github.com/enjoy-digital/litex/issues/1268
github.com/enjoy-digital/litex/commit/ed...938fe0a2435375f96a80

Fabio

TOLP2, would you say, the RV901T board is the one to get, from all the other options? Want to order one of the boards and wait till the stable release.

@NickXX: I did not receive my RV901T yet, so I do not have a preference yet for a specific card. With both the RV901T and the 5A-75E you have to change some components. With 5A-75E all buffers are setup as inputs, so some of the buffers have to be removed, modified or replaced. With the RV901T, some 60+ pin are configurable as input or output, but they can only be switched as one group, so modification is still required. The only benefit of the RV901T  is the more sane position of the headers, which makes it possible to create a HAT-board with some components...

Update:
After some vigorous testing I finally published the stepgen component for LitexCNC. I explicitly chose to create my own firmware to be able understand its working and be able to expand it in the future. The design of the firmware is very similar to the design of the stepgen component of LinuxCNC, only then implemented on a FPGA. 

One thing I encountered during testing is that things go (horribly) wrong with re-starting LinuxCNC, without power-cycling the FPGA. When LinixCNC is restarted the position in the PC is set to 0, while the FPGA reminds the old position. When enabling the machine this will lead to uncommanded movement. When setting up the connection to the card, all registers have to be set to their original values with a reset mechanism. This mechanism is not yet present in the firmware. As far as I can see, this is also a problem with the original ColorCNC.

Because this is a safety issue, this will be the first thing which I will attend to after the school holiday. Until this problem is solved, I would not recommend to use this code on an actual machine, but only for desktop testing.
 

Back from a nice holiday and now solved the above problem. Implemented a start-up procedure:

• Check whether the data on the FPGA on address 0x0 is equal to 0x18052022. This indicates that we are talking to a FPGA which is configured for LitexCNC;
• Check the fingerprint of the config-file on the PC and as used for programming the FPGA. When these configurations are not equal, LinuxCNC will not proceed, as the pin-out might be changed. As fingerprint the CRC-checksum of the file is used. This is well-defined in both Python (for LiteX) and C (for the driver).
• Reset the FPGA, this will stop all movement on any stepgen present and resets the counters to their starting positions. Because the reset is very important, the reset-bit is first written and then read back from the card. Only when the value which is read back equals the reset-state, the driver set the reset-bit to 0 and the FPGA will go to the normal state.

Also started to work on the encoder and received finally the RV901T to try that one as well. Keep you all posted!

Such amazing progress!

I've been distracted with other projects but plan to pivot back to testing this soon. Excited to get tons more inputs on my machine and go from software stepgen to hardware :-D

These all are the great news!
With RV901T, ISE 13.7 failed to build the firmware. (I've chosen this ancient version of ISE to be able also to build hostmot2 firmware).
And with the latest version of LiteX, for Colorlight 5A-75 v. 8.0 and liteeth in 32-bit mode, timing issues are not met.

@romanetz: if I understand you correctly you are trying to install the orginal MESA firmware on a re-purposed card such as the RV901T? Can you elaborate on the timing issues of the latest version of Litex, would that affect the LitexCNC project, or does it only affect the installation of the MESA firmware?

Update: Sending the wrong data to the card can lead to dangerous situations (worst case; uncommanded movement) or hard to debug problems. To solve this I already added checking the fingerprint of the configuration used for the card and driver; checking whether we talk to the same configuration. Now I also added firmware version in the header. The driver now checks whether the version is compatible with the firmware: when the communication protocol has changed (for example due to adding a new component), the version number is increased and the user is informed to update the firmware and/or driver (depending which one he upgraded first).