Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FleaOhm support possible? #14

Open
NeuerUser opened this issue Mar 13, 2019 · 24 comments
Open

FleaOhm support possible? #14

NeuerUser opened this issue Mar 13, 2019 · 24 comments

Comments

@NeuerUser
Copy link

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
Copy link

XarkLabs commented Mar 13, 2019 via email

@NeuerUser
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Member

emard commented Mar 14, 2019 via email

@emard
Copy link
Member

emard commented Mar 14, 2019

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
Copy link
Author

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
Copy link
Member

emard commented Mar 18, 2019 via email

@XarkLabs
Copy link

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
Copy link
Member

emard commented Mar 24, 2019 via email

@Speccery
Copy link

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
Copy link
Member

emard commented Nov 16, 2019 via email

@emard
Copy link
Member

emard commented Nov 16, 2019 via email

@Speccery
Copy link

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

@Speccery
Copy link

@emard Is it working for you with Flea ohm?

@emard
Copy link
Member

emard commented Nov 16, 2019 via email

@Speccery
Copy link

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
Copy link
Member

emard commented Nov 16, 2019 via email

@Speccery
Copy link

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
Copy link
Member

emard commented Nov 16, 2019 via email

@XarkLabs
Copy link

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
Copy link
Member

emard commented Nov 19, 2019 via email

@gornjas
Copy link
Contributor

gornjas commented Nov 19, 2019

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@NeuerUser @XarkLabs @gornjas @emard @Speccery