USB-to-UART core desirable

[dalnefre]

https://workshop.fomu.im/en/latest/hdl.html says, "Ideally, a USB-to-UART core would be provided for users to instantiate in their HDL designs."

Is this still a desirable goal? I don't have much HDL experience, but I'm interested in trying to get this working.

Is the goal to make something like a FT232 USB-to-TTL-serial interface, so there is TTL-serial TX/RX on the user pins?

I was thinking that something supporting DFU would be valuable, so an uploaded design could carry support for upgrading itself.

[umarcor]

Hi @dalnefre! Yes, it is still desirable. Have a look at greatscottgadgets/luna#80. Any other design would also be acceptable. However, dealing with USB in HDL is non-trivial, and meeting timing requirements on the Fomu (UP5K) makes it really challenging.

Is the goal to make something like a FT232 USB-to-TTL-serial interface, so there is TTL-serial TX/RX on the user pins?

That's how I envision it. I think having a /dev/ttyS* on GNU/Linux and a COM* on Windows would be the easiest solution. Nevertheless, any solution would be acceptable which allows communicating a Python script on the workstation/laptop with an HDL design in the Fomu. I don't think performance is critical for now.

I was thinking that something supporting DFU would be valuable, so an uploaded design could carry support for upgrading itself.

I think this is a different feature. UP5K devices have the so called warm-boot feature, which allows booting one of up to 4 different bitstreams. Currently, 2 of those slots are used only (one for the bootloader and another one for the user design). It'd be interesting to write other two designs into the unused slots, and then allow up to 3 designs to switch between them or to the bootloader.

Providing documentation about how to let an HDL design switch back to the bootloader would be interesting for allowing easier programming of consecutive tests. Currently, when an HDL design is loaded, the board is dead for the workstation/laptop. Therefore, it needs to be unplugged and plugged again for the bootloader to kick in.

After these features are tested, mechanisms for an HDL design to request an specific bitstream to the workstation/laptop would be very interesting.

[mithro]

This is currently desired and @tcal-x was looking into doing this with LUNA recently if I understand correctly.

The goal here is to enable people to use the Fomu in serial applications without having to understand how USB works, not to add additional hardware.

[umarcor]

The goal here is to enable people to use the Fomu in serial applications without having to understand how USB works, not to add additional hardware.

What I understood is whether the desired HDL code should provide a feature equivalent to what you achieve when using FT232; not that the FTDI chip should be required! That is, exactly what LUNA provides.

[mithro]

The goal here is to enable people to use the Fomu in serial applications without having to understand how USB works, not to add additional hardware.

What I understood is whether the desired HDL code should provide a feature equivalent to what you achieve when using FT232; not that the FTDI chip should be required! That is, exactly what LUNA provides.

Correct!

[umarcor]

Kate assigned herself a few days ago: https://github.com/greatscottgadgets/luna/pull/80. We should have something to play with soonish, as the idea is to pre-generate a verilog black box from LUNA's usb/acm_serial example.

[dalnefre]

I wasn't suggesting adding any new hardware, just trying to understand the desired behavior. Thanks for the clarifications!

I'll check out the LUNA work as well.

[tcal-x]

Hi @dalnefre ,

Let me relate my experience as a consumer of UART on Fomu. Since the Fomu's IOs are rather limited, I felt the need for a usable UART as the main IO channel in an effort to put TensorFlow Lite for Microcontrollers on Fomu for demonstration.

• Micropython provided a working example of providing a UART interface; however, I was advised that pulling out the related code for my own use was not a good idea, since that code was somewhat quick-and-dirty.
• The workshop does mention as "Further Experiments" that you can clone "TinyUSB" and build the cdc_msc example. It doesn't mention that this example provides BOTH a mass storage interface, and also a UART interface on /dev/ttyACM0 that just echos keystrokes back to the user. TinyUSB provides just the single-character read/write, and is not connected to the usual printf() stack, so it would be more work to make it generally useful to bare-metal C programs, starting from that example.
• The LiteX Fomu target now provides ACM UART interface by default: https://twitter.com/enjoy_digital/status/1313788215409684481 . You can interact with the typical LiteX BIOS commands over UART. This uses ValentyUSB.
• And building on LiteX, I have also gotten the bare-metal demo working on Fomu (with spinning donut!). It is loaded via LiteX' serial boot mechanism, over the UART, and then interacts with the user over UART. This would be the best starting point if you want to write your own bare-metal program that uses UART. NOTE: getting this working requires a little hacking to load the program into Fomu's SPRAM using the serialboot mechanism. I'm happy to provide more details if you want. ALSO: The demo could /probably/ also be flashed using dfu-util, but I haven't tested that.

[dalnefre]

I have some experience with bare-metal programming, however I got the Fomu primarily to explore HDL programming without a CPU, possibly leading to novel soft-core implementations. So the USB support I'm looking for is, ideally, an instantiable Verilog module. I realize this is non-trivial.

If we're only looking for serial access from external devices, wouldn't it be easier to instantiate a simple serial UART connected to the USER pins? What's the recommended practice for making such a connection? Alligator clips? I have a couple of USB-to-Serial converter cables/dongles that could be part of an alternate access path into the Fomu. Pardon me if this is an ignorant suggestion. I'm just trying to learn.

[umarcor]

however I got the Fomu primarily to explore HDL programming without a CPU

@dalnefre, the Fomu is probably not the best choice for this task on Jan 2021. Don't take me wrong. That's my background, and that's what I want to use Fomu's for. However, the conception of *omus was a system-level approach, for software people to get their hands dirty with "embedded" programming/design. That's why this workshop is written top to bottom; and most of the examples do involve some SoC. Given the physical constraints in the device, it's also the most sensible approach for delivering a product useful for the majority. There are other similarly priced UP5K boards with more I/O which are friendlier for HDL only designs.

Given said that, we can and should provide an instantiable HDL module, conceptually similar to the default wrapper in google/efabless/skywater's shuttle. Any of the solutions mentioned in this issue might be suitable if we can release them as a black box.

If we're only looking for serial access from external devices, wouldn't it be easier to instantiate a simple serial UART connected to the USER pins? What's the recommended practice for making such a connection? Alligator clips? I have a couple of USB-to-Serial converter cables/dongles that could be part of an alternate access path into the Fomu. Pardon me if this is an ignorant suggestion. I'm just trying to learn.

I don't think there is a recommended procedure for doing so, because the idea is that we should be able to deliver a programmable solution. That's why Tim mentioned that additional hardware should not be required.

I think that using alligator clips connected to the USER pins would work. You might also use the two data pins of the USB, and use a regular female USB connector. The data pins of the USB are connected through a 220 ohm resistor: https://raw.githubusercontent.com/im-tomu/fomu-hardware/master/archive/pvt/releases/pvt1/tomu-fpga-pvt1.pdf. However, using the USB connector would require plugging the Fomu to different places for programming and/or for testing, and maybe tweaking the loading so it boots the user design.

[smunaut]

I would suggest to try https://github.com/no2fpga/no2muacm . Don't clone the repo but rather download the latest release (which is pre-built). It's pretty much meant to look like "a FT232 USB-to-TTL-serial interface" and also supports DFU Run Time to reboot into the bootloader bitstream.

The release .tar.bz2 contains the pre-built core and an example/skeleton how to use and integrate it in your own design and includes fomu PCF already.

[possibly-not]

If we're only looking for serial access from external devices, wouldn't it be easier to instantiate a simple serial UART connected to the USER pins? What's the recommended practice for making such a connection? Alligator clips? I have a couple of USB-to-Serial converter cables/dongles that could be part of an alternate access path into the Fomu. Pardon me if this is an ignorant suggestion. I'm just trying to learn.

I used a "Dupont thread Male to Alligator Clip" on my Fomu to connect to pad 2 (user_2) for UART Tx. You might be able to also get a Rx onto the third pad but it seems like a pain. Just having Tx was enough for me. I wanted to implement my own UART for the learning experience. It works alright actually!

You can also consider looking at https://github.com/stef/nb-fomu-hw but I didn't manage to get it working. You'll need to replace the pcf file.

[dalnefre]

I've soldered a 4-pin female header onto the Fomu touchpads to make it easier to attach test-leads.

Unfortunately, my work on the Fomu has been temporarily superseded by paying projects.

[ulixxe]

I would suggest trying https://github.com/ulixxe/usb_cdc. It should be small enough to leave room for other stuff on FOMU.