USB ACM FIFO and RISCV core demo


#1

I’ve managed to split the USB ACM device into a standalone Verilog module with a simple FIFO interface for reuse. I also separated the physical layer into a 48 MHz clock domain and have clock-crossing logic to interface with slower logic for the USB endpoints. This works on the iCE40lp8k as well as the smaller, slower FPGAs like the up5k in the Tomu: https://github.com/osresearch/up5k/tree/master/usb

As a test case, I’ve replaced the icicle RISCV serial UART with the ACM device so that the softcore on the TinyFPGA BX can communicate with the /dev/ttyACM device on the host machine it is plugged into (no more FTDI cables!): https://github.com/osresearch/icicle/tree/tinyfpga


Bootloader resources
#2

Very impressive. I mentioned you work on this thread - USB Communication. It is geat to see that you have made so much progress with the TinyFPGA version.

Several of us have had USB communication over /dev/ttyACM0 with a uart-like interface working for a while but without your separation of clock domains. Your implementation looks as if it will be a lot more reliable.

I have also been working on a Risc-V application that uses our version but mine uses Clifford Wolf’s picorv32 and picoSoC rather than icicle.

What I have been doing is a proof-of-concept of programming the TinyFPGA using the Arduino IDE, based on work by @uXe and others on the mystorm BlackIce device - see https://forum.mystorm.uk/t/soft-arduino-and-accelerated-libraries/517/22.

So the uart I have replaced is Clifford’s simpleuart that is used with PicoSoc. I have the system mostly running but receiving data is not quite working yet - see https://github.com/lawrie/tiny_usb_examples/tree/master/arduino


#3

Hi,

thanks for sharing. This is really awesome work.


#4

Hello,

I am trying to compile/run the code that can be found in the repository. but it ain’t fully working for me
https://github.com/osresearch/icicle/tree/tinyfpga

So far I made a few changes to get the code compiling

  • In the makefile I replace the compiler from iscv64-unknown-elf to riscv32-unknown-elf
  • In the makefile I replace the default target to be tinyfpga-bx
  • In current version of icestorm (git) I am getting a crash on pcf files that contain the -nowarn flag. (I removed them) but might post a patch to icestorm.
  • make flash does’t work as it tries to use dfu hence I used tinyprop -p top.bin

I am now stuck in the program compilation

(.text+0x4): relocation truncated to fit: R_RISCV_PCREL_LO12_I against `.L0 ’


#5

I just tried it and did not get the -nowarn problem, but hit the same issue as you.

I did:

git clone -b tinyfpga https://github.com/osresearch/icicle
cd iclicle

I replaced the TARGET variable in the Makefile with:

TARGET = /opt/riscv/bin/riscv64-unknown-elf

As I had the riscv64 version of the compiler in /opt/riscv because I have run icicle before on the BlackIce II board and had built the risc64 version of the compler for that. I have both the risc32i and risc64 versions installed.

I then ran:

make BOARD=tinyfpga-bx

and got the (.text+0x4): relocation truncated to fit: R_RISCV_PCREL_LO12_I against `.L0 ’ error.

Looks like this issue - https://github.com/riscv/riscv-gcc/issues/120


#6

Indeed. (changing the load address does remove this issue)
a temporary fix is therefore probably to change the load address (and also on flash to) 0x00000008
and manually insert nop (0x13 00 00 00 , 0x13 00 00 00) at the start of the file

When I just change the load address things start to look good … I am getting world# out of the serial


#7

When I accidentally got the BOARD parameter wrong, I did not get that error, so it worked for the default board. The relevant difference is that the ice40hx8k-b-evn board has PROGMEM = flash, so I wonder if the flash version needs changing.

It is working for me now, but what has happened to “Hello, w”?

orld!
orld!
orld!
orld!
orld!
orld!

If I add some spaces to to

uart_puts(" Hello, world!\r\n");

I start getting

!Helmo, worle!

So there seems to be something wrong with the USB output.


#8

The USB stack seems quite stable in other applications (like my 16x2 character OLED video display and the Tomu USB bootloader), but I also see weirdness like that from the icicle core that makes me wonder if there is something wrong in the CPU logic.

If I replace uart_puts() with a series of uart_putc() calls, it does the right thing and outputs the full string. There are also some oddities on more complex test programs that make function calls; functions that are inlined seem correct, but jumps don’t always go right.


#9

FPGAs seem to be Rick-rolling a lot of LED and LCD output devices.:grinning: