FleaOhm support possible?

[NeuerUser]

Hi

I've seen that you also have some experience with the Flea Ohm board, as you are also using the FleaOhm JTAG tool (https://github.com/emard/FleaFPGA-JTAG). Is it possible to make ujprog also compatible with the FleaOhm? That way a fully open source tool chain could be used with it. Currently Diamond is still necessary as Flea-Ohm-JTAG only flashes vme files. I have tried to adapt the cable section by inserting:

    {
        .cable_hw =     CABLE_HW_USB,
        .usb_vid =  0x0403,
        .usb_pid =  0x6015,
        .cable_path =   "FleaFPGA v2.5",
        .tck =          0x08,
        .tms =          0x04,
        .tdi =          0x01,
        .tdo =          0x02,
        .cbus_led = 0x00
    },

The board is then detected, but the JTAG chain does not seem to work:

$ ./ujprog -d -b115200 ../../../../FleaFPGA-Ohm/FleaFPGA_Ohm_test/impl1/Blinky_impl1.bit 
ULX2S / ULX3S JTAG programmer v 3.0.92 (built Mar 13 2019 11:20:51)
Using USB cable: FleaFPGA v2.5
1: STATE IDLE;
2: STATE RESET;
3: STATE IDLE;

4: SIR  8       TDI     (E0);
5: SDR  32      TDI     (00000000)
6:      TDO     (41111043)
7:      MASK    (FFFFFFFF);

Found unknown (00000000) device, but the bitstream is for LFE5U-25E.

Failed.

[XarkLabs]

Hello,

Yes, I ported the ancient Lattice VME DOS example software (using PC parallel port) to work with FleaFPGA FTDI part (working with Valentin on the FleaFPGA boards development).

FleaFPGA needed to have a "clever" connection setup to get reasonable bitstream download speed with non MPSSE-FTDI part (constantly switching between two FTDI comm modes).

So the FTDI API is needed to be operated in an unusual way. My guess is ujprog doesn't behave this way. No promises, but maybe I will have time to take a look at ujprog next weekend or so.

However, not too complicated if you know C. There are basically two functions to send and recieve bits that would need to be added as a "mode" in ujprog. Also, "depending" it could be very very slow (if it needs to switch between read/write often).

-Xark

On Wed, Mar 13, 2019, 4:15 AM NeuerUser notifications@github.com wrote:

Hi

I've seen that you also have some experience with the Flea Ohm board, as you are also using the FleaOhm JTAG tool ( https://github.com/emard/FleaFPGA-JTAG). Is it possible to make ujprog also compatible with the FleaOhm? That way a fully open source tool chain could be used with it. Currently Diamond is still necessary as Flea-Ohm-JTAG only flashes vme files. I have tried to adapt the cable section by inserting:

{ .cable_hw = CABLE_HW_USB, .usb_vid = 0x0403, .usb_pid = 0x6015, .cable_path = "FleaFPGA v2.5", .tck = 0x08, .tms = 0x04, .tdi = 0x01, .tdo = 0x02, .cbus_led = 0x00 },

The board is then detected, but the JTAG chain does not seem to work:

$ ./ujprog -d -b115200 ../../../../FleaFPGA-Ohm/FleaFPGA_Ohm_test/impl1/Blinky_impl1.bit ULX2S / ULX3S JTAG programmer v 3.0.92 (built Mar 13 2019 11:20:51) Using USB cable: FleaFPGA v2.5 1: STATE IDLE; 2: STATE RESET; 3: STATE IDLE;

4: SIR 8 TDI (E0); 5: SDR 32 TDI (00000000) 6: TDO (41111043) 7: MASK (FFFFFFFF);

Found unknown (00000000) device, but the bitstream is for LFE5U-25E.

Failed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/f32c/tools/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AIhN9ME2RvHzGyCpLUcHiVtOFZV4zhJmks5vWN3ggaJpZM4bs-e2 .

[NeuerUser]

Hey, that would really be awesome. I just got my FleaOhm and am starting to learn everything around it. It would be great if I could start with an open toolchain, instead of relying on the Diamond moloch.

Concerning speed: There is also the Flea-Ohm-JTAG tool (which, however, does not understand bitfiles. But it is pretty fast. (about 14 sec for SRAM config, 40 sec for SPI flash). But it needs Diamond to convert the bitfile first, which ujprog doesn't need.

[XarkLabs]

Right, I understand. I believe Flea-Ohm-JTAG is basically the same code as FleaFPGA-JTAG (with perhaps some different settings for the newer Flea board).

[NeuerUser]

Let's just say that this tool https://github.com/emard/FleaFPGA-JTAG/ seems to have been forked from the original to include support for ULX3S boards. It still works in full speed with the Flea Ohm.

That's why I think there might be a good chance to include support also in ujprog.

[emard]

ujprog should be possible to be modified to run on FleaFPGA ohm board and it's always good to expand scope of usage...

Difference is not big but also it's not plain simple as changing bit register numbers in ujprog because FleaFPGA boards connects JTAG pins to a mixture of CBUS pins and RS232 pins of FT230X.

When connected so, bitbanging software must switch FT230X chip from CBUS mode to RS232 mode and back on demand.

At ULX2S and ULX3S boards we intentionally avoided this situation by using only RS232 pins of FT231X for JTAG (because 231X has more pins than 230X :) so the adequate swiching code is missing in ujprog but it could be probably "borrowed" from FleaFPGA-JTAG :)

On 3/13/19, NeuerUser notifications@github.com wrote:

Let's just say that this tool https://github.com/emard/FleaFPGA-JTAG/ seems to have been forked from the original to include support for ULX3S boards. It still works in full speed with the Flea Ohm.

That's why I think there might be a good chance to include support also in ujprog.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-472501666

[emard]

Xark, it would be great if you can take a look how to include CBUS bitbanging for fleafpga into the "slightly messy" ujprog Davor

[NeuerUser]

Hey, that would really be awesome. I just got my FleaOhm and am starting to learn everything around it. It would be great if I could start with an open toolchain, instead of relying on the Diamond moloch.

Concerning speed: There is also the Flea-Ohm-JTAG tool (which, however, does not understand bitfiles. But it is pretty fast. (about 14 sec for SRAM config, 40 sec for SPI flash). But it needs Diamond to convert the bitfile first, which ujprog doesn't need.

[emard]

Yea, I'm also not fond of depending on diamond's binaries to generate VME when we have opensource toolchain.

FleaFPGA-JTAG on ulx3s does 300kbit/s and ujprog does 500kbit/s on ULX3S so ujprog is even faster than Flea JTAG tool on our boards.

I don't say that speed advantage can be kept for Ohm board because FT230X must be switched between CBUS and RS232 bitbang mode.

On 3/18/19, NeuerUser notifications@github.com wrote:

Hey, that would really be awesome. I just got my FleaOhm and am starting to learn everything around it. It would be great if I could start with an open toolchain, instead of relying on the Diamond moloch.

Concerning speed: There is also the Flea-Ohm-JTAG tool (which, however, does not understand bitfiles. But it is pretty fast. (about 14 sec for SRAM config, 40 sec for SPI flash). But it needs Diamond to convert the bitfile first, which ujprog doesn't need.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-474013995

[XarkLabs]

Hello, Just wanted to mention that I am starting to look into supporting FleaFPGA Ohm in ujprog (slowly, in my limited time). I have ujprog compiling and running for me under Win-10 with mingw32-64 (which was a minor pain, as expected, but the first hurdle :) ). I am using vendor FTDI libs first (since that what I got compiling), but I will add Linux/libusb changes once it is working. From a first pass over things, the changes seem reasonable and are making some sense to me (and code makes it fairly easy for me to change things). I didn't find ujprog "too messy" but my changes may not "help" any mess (but I will try to keep them "clean" and hopefully not too invasive). I am also concerned about FT230X speed, but we will see (I am hoping it is a "usable" speed for downloading bitstreams, but hard for me to really know until I try it [and see read/write switching frequency]). P.S. What tab settings should I be using for this utility (4 w/hard tabs doesn't seem right)? Trying to resist urge to "clang-format" it. :)

[emard]

HI

I welcome your every possible effort around ujprog! :)

It only matters to get this cbus mode switching to make it running for flea boards. Normally it is expected to be somewhat slower for this additional switch mode commands.

Also don't care about tab width (it has some outdated "vi" editor style), just use any setting for which you find useful to edit the code.

On 3/23/19, Xark notifications@github.com wrote:

Hello, Just wanted to mention that I am starting to look into supporting FleaFPGA Ohm in ujprog (slowly, in my limited time). I have ujprog compiling and running for me under Win-10 with mingw32-64 (which was a minor pain, as expected, but the first hurdle :) ). I am using vendor FTDI libs first (since that what I got compiling), but I will add Linux/libusb changes once it is working. From a first pass over things, the changes seem reasonable and are making some sense to me (and code makes it fairly easy for me to change things). I didn't find ujprog "too messy" but my changes may not "help" any mess (but I will try to keep them "clean" and hopefully not too invasive). I am also concerned about FT230X speed, but we will see (I am hoping it is a "usable" speed for downloading bitstreams, but hard for me to really know until I try it [and see read/write switching frequency]). P.S. What tab settings should I be using for this utility (4 w/hard tabs doesn't seem right)? Trying to resist urge to "clang-format" it. :)

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-475904304

[Speccery]

It seems that this discussion was a while ago, but I have now successfully ported the ujprog to support FleaFPGA Ohm board. The code is available at my fork https://github.com/Speccery/tools. I don't have other boards with ECP5, so don't know if after my changes the code still works with ULX3S for instance.

[emard]

HI Erik!

Great work, I can review your changes and test on boards ULX3S, ULX2S, FleaOhm and FleaUno If everything works, let's merge :)

On 11/16/19, Erik Piehl notifications@github.com wrote:

It seems that this discussion was a while ago, but I have now successfully ported the ujprog to support FleaFPGA Ohm board. The code is available at my fork https://github.com/Speccery/tools. I don't have other boards with ECP5, so don't know if after my changes the code still works with ULX3S for instance.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-554609890

[emard]

hmm it doesn't work for ULX3S

guest@brix4:/tmp/tools/ujprog$ ujprog /tmp/blink.bit ULX2S / ULX3S JTAG programmer v 3.0.92 (built Nov 16 2019 08:52:59) Using USB cable: ULX3S FPGA 25K v2.1.2

Found unknown (82222087) device, but the bitstream is for LFE5U-25F.

Failed.

On 11/16/19, D EMARD vordah@gmail.com wrote:

HI Erik!

Great work, I can review your changes and test on boards ULX3S, ULX2S, FleaOhm and FleaUno If everything works, let's merge :)

On 11/16/19, Erik Piehl notifications@github.com wrote:

It seems that this discussion was a while ago, but I have now successfully ported the ujprog to support FleaFPGA Ohm board. The code is available at my fork https://github.com/Speccery/tools. I don't have other boards with ECP5, so don't know if after my changes the code still works with ULX3S for instance.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-554609890

[Speccery]

Thanks for testing! I am not surprised, let me review and clean the code a bit.

[Speccery]

@emard Is it working for you with Flea ohm?

[emard]

Yes it is working for FleaFPGA-Ohm. If you can a bit cleanup the code, maybe revew did some change related to Ohm has leaked out into ULX3S code...

On 11/16/19, Erik Piehl notifications@github.com wrote:

@emard Is it working for you with Flea ohm?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-554628167

[Speccery]

Sure, I will do that. I also heard some good news that I should be getting a ULX3S from the next batch, so will be hopefully soonish able to test myself. The code has debugging prints etc so it is by no means final, but I wanted to share the version as soon as it started to work.

[emard]

yes in fact ujprog "community" is kinda sensitive on updates, patch must be as clean and minimal as possible

On 11/16/19, Erik Piehl notifications@github.com wrote:

Sure, I will do that. I also heard some good news that I should be getting a ULX3S from the next batch, so will be hopefully soonish able to test myself. The code has debugging prints etc so it is by no means final, but I wanted to share the version as soon as it started to work.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-554632784

[Speccery]

Right. I appreciate you taking the time to test the patch. I forked off the code to be able to play with it in the context of FleaFPGA Ohm, it took me while to get it working even if the code changes are small. The CBUS context switch seems to cause the clock signal to float, which is why it must be driven low before mode change. This in turn means that command bits in txbuf now occupy three bytes instead of two, and that it turn has an implication in the received data decoding. I may create a separate much simpler programmer for the Ohm, without all the features of the ujprog. I learned from pnr about your ESP32 micropython programmer, perhaps that could be a source of inspiration. I have some ESP32 breakout boards lying around. Anyway, when I get my own ULX3S I will modify my forked version to make sure it works on that too. For ujprog I was thinking it might make sense to modularize the code a little, and take the operating system dependent parts into separate modules rather than having #ifdefs around.

[emard]

Absolutely you can take my esp32ecp5 micropython as inspiration besides you can even keep it in python, using python-libusb

I think also it is the best that you have both ulx3s and ohm to make it properly.

I'm just a low-bandwidth maintainer of ujprog, getting cbus to work is difficult and I appreciate your efforts!

ujprog internally converts bit to svf and svf back to bit, so why don't we take a shortcut. 600 lines of python code may be better, readable and faster :)

On 11/16/19, Erik Piehl notifications@github.com wrote:

Right. I appreciate you taking the time to test the patch. I forked off the code to be able to play with it in the context of FleaFPGA Ohm, it took me while to get it working even if the code changes are small. The CBUS context switch seems to cause the clock signal to float, which is why it must be driven low before mode change. This in turn means that command bits in txbuf now occupy three bytes instead of two, and that it turn has an implication in the received data decoding. I may create a separate much simpler programmer for the Ohm, without all the features of the ujprog. I learned from pnr about your ESP32 micropython programmer, perhaps that could be a source of inspiration. I have some ESP32 breakout boards lying around. Anyway, when I get my own ULX3S I will modify my forked version to make sure it works on that too. For ujprog I was thinking it might make sense to modularize the code a little, and take the operating system dependent parts into separate modules rather than having #ifdefs around.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-554634540

[XarkLabs]

Hello Speccery, Thanks for doing this work. I never got my changes fully working - and never could quite figure out the last problems (that floating CBUS pin sounds interesting...). I am glad there is now a fully open path now for FleaFPGA Ohm.

[emard]

Yes Speccery has the ball rolling, now we need just a bit of peaceful coexistence for the both code.

Maybe it's off topic a bit but I have ft4232 board and someone made ft2232 (similar chip) port for ujprog. I changed usb ids to recognize the chip and everything goes well, it detects ID, it uploads bitstream and intermediate TDO responses are all ok but last SVF command to start the last TDO check fails and bitstream doesn't work :(

On 11/19/19, Xark notifications@github.com wrote:

Hello Speccery, Thanks for doing this work. I never got my changes fully working - and never could quite figure out the last problems (that floating CBUS pin sounds interesting...). I am glad there is now a fully open path now for FleaFPGA Ohm.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/issues/14#issuecomment-555263916

[gornjas]

This in turn means that command bits in txbuf now occupy three bytes instead of two, and that it turn has an implication in the received data decoding.

Using three bytes instead of two per clock pulse means the effective programming speed would become reduced by 33%, which should be avoided, as the main goal of ujprog was and still is maintaining reasonable programming speed using low-cost FT232 and FT231X devices.

Perhaps the problems with CBUS context switching for your application could be avoided by simply operate the device in the synchronous mode all the time, but this would likely sacrifice the effective programming speed even further.

I'm wondering if a different workaround for the floating CBUS pin could be devised?

[Speccery]

Thanks for the comments! Like I mentioned, I don't have currently any other boards to test with than the FleaFPGA Ohm. However, I have on order an ULX3S and when I get it (we have here a post strike so fingers crossed) I will be able to test. I have to say that I am not 100% convinced the pins float, but in my oscilloscope setup that sure is how it looked like. It could have been a problem with poor ground connectivity too, but I doubt it. On my side I was happy to see this working with the Flea Ohm in the first place, as now I am able to use the open source tool chain with the Flea Ohm. It is possible there are other workarounds, need to test more. With the Flea Ohm the CBUS is not floating, it is used in input mode to capture the TDO signal. The problem is that TCLK seems to be floating, it is driven by one of the serial port pins, not CBUS. One alternative I have in mind is to just develop a simple standalone loader for the the FleaOhm, without all the features of ujprog.