search

f32c / arduino

FPGArduino source
http://www.nxlab.fer.hr/fpgarduino
68 stars 44 forks source link

Add picorv32 support for Alhambra board #32

Closed drtrigon closed 5 years ago

drtrigon commented 5 years ago

According to https://github.com/cliffordwolf/picorv32/issues/92 picorv32 RISC soft core runs on Alhambra board. Is it possible to add support for this to FPGArduino?

emard commented 5 years ago

If picorv32 core can use the same gcc that works for our f32c-rv32 and approximately have the SOC (mmaped io, leds, spi, timers) also same or similar to f32c soc and are mapped preferrably to the same memory addresses then I'd be happy to add some board names, strings and compiler options to boards.txt and/or platform.txt

Can somebody try our rv32 binaries on picorv32 and report if they work at least to make a led blinky?

On 10/22/18, drtrigon notifications@github.com wrote:

According to https://github.com/cliffordwolf/picorv32/issues/92 picorv32 RISC soft core runs on Alhambra board. Is it possible to add support for this to FPGArduino?

-- 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/arduino/issues/32

drtrigon commented 5 years ago

I try to help with whatever I can. The toolchain I used successfully is "RISC-V GNU toolchain and libraries for a pure RV32I target" as mentioned in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain. It uses riscv32-unknown-elf-gcc, riscv32-unknown-elf-objcopy and from icestorm/icestudio toolchain iceprog (see https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile).

emard commented 5 years ago

Can you try to use our f32c-rv32 compiled binary to get LED blinky on picorv32? In the meantime I probably should get picorv32 for ulx3s, I think it's already done at prjtrellis but haven't tried to download and compile

I'm currently busy with new boards ULX3S and some hardware support around it

On 10/23/18, drtrigon notifications@github.com wrote:

I try to help with whatever I can. The toolchain I used successfully is "RISC-V GNU toolchain and libraries for a pure RV32I target" as mentioned in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain. It uses riscv32-unknown-elf-gcc, riscv32-unknown-elf-objcopy and from icestorm/icestudio toolchain iceprog.

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

drtrigon commented 5 years ago

Can you try to use our f32c-rv32 compiled binary to get LED blinky on picorv32?

I tried, but not with much success... I used code from a working project and just tried to replace the toolchain with yours, see attached Makefile.txt (the commented parts are the ones from the working toolchain for reference).

Running it results in (the .elf file has a size of 0 bytes):

$ make prog ../../fpgarduino/f32c/bin/riscv-elf-gcc -std=gnu11 -DHX8KDEMO -march=RV32I -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc4XMh7D.o: ABI is incompatible with that of the selected emulation $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc4XMh7D.o $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc39QdcM.o: ABI is incompatible with that of the selected emulation $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc39QdcM.o make: *** [firmware.elf] Fehler 1

So my questions:

emard commented 5 years ago

Aiieeee segmentation fault in riscv linker :) Our riscv support is obviously not too functional no more testing from you needed, we must refresh this riscv support.

Maybe better for alhambra board is to use another more stable riscv toolchain that you know works for your hardware

It is no problem for integrate from licensing point of view but we lack of ing-hours to assemble all parts into stuff that works. I can package another riscv compiler and all required programming tools and libs, if you succeed with anything that leads to a blink led

On 10/26/18, drtrigon notifications@github.com wrote:

Can you try to use our f32c-rv32 compiled binary to get LED blinky on picorv32?

I tried, but not with much success... I used code from a working project and just tried to replace the toolchain with yours, see attached Makefile.txt (the commented parts are the ones from the working toolchain for reference).

Running it results in (the .elf file has a size of 0 bytes):

$ make prog ../../fpgarduino/f32c/bin/riscv-elf-gcc -std=gnu11 -DHX8KDEMO -march=RV32I -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc4XMh7D.o: ABI is incompatible with that of the selected emulation $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc4XMh7D.o $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc39QdcM.o: ABI is incompatible with that of the selected emulation $HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc39QdcM.o make: *** [firmware.elf] Fehler 1

So my questions:

  • Can you be more specific what I should test exactly (source files, commands for compiling, etc.)?
  • Would it be possible to integrate the picorv32 icestorm/icestudio toolchain as it is open source too (e.g. the programmer could be needed)?

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

gornjas commented 5 years ago

Our current riscv toolchain is exactly the same as the mips version, i.e. is gcc-7.2 based and should be perfectly fine. The question is why the OP has fetched the long obsoleted 4.9.2 toolchain - could that be a bug in our Arduino json / packaging?

emard commented 5 years ago

Yes, that's true we should package 7.2 into arduino....

On 10/27/18, Marko Zec notifications@github.com wrote:

Our current riscv toolchain is exactly the same as the mips version, i.e. is gcc-7.2 based and should be perfectly fine. The question is why the OP has fetched the long obsoleted 4.9.2 toolchain - could that be a bug in our Arduino json / packaging?

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

gornjas commented 5 years ago

How did that regression happen? I thought we already switched over to 7.2 a year ago, and were using gcc-6 based toolchains prior to that. The bm/package_fpga_index.json is clearly referencing 7.2 based toolchains.

I'm inclined to wipe out all the pre-7.2 .zip archives from the web, otherwise we'll be getting into this again and again...

emard commented 5 years ago

There were no regression, we only upgraded mips to 7.2 and riscv 7.2 I forgot :)

On 10/27/18, Marko Zec notifications@github.com wrote:

How did that regression happen? I thought we already switched over to 7.2 a year ago, and were using gcc-6 based toolchains prior to that. The bm/package_fpga_index.json is clearly referencing 7.2 based toolchains.

I'm inclined to wipe out all the pre-7.2 .zip archives from the web, otherwise we'll be getting into this again and again...

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

gornjas commented 5 years ago

How's that possible? There's a single integrated toolchain archive for both mips + riscv toolchains per OS/architecture (win32, osx, lin32, lin64)? I.e. they are not downloaded separately, and there's no way to separate them in the json?

gornjas commented 5 years ago

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

emard commented 5 years ago

If zip toolchain is just removed this from bm installation directory without any other fix, fpgarduino board manager will no longer be installable effectively breaking everything :)

On 10/27/18, Marko Zec notifications@github.com wrote:

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

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

emard commented 5 years ago

When I look better, we should have 7.2 toolchain for both mips+riscv in boards manager for bsd linux win osx so gcc 4.9 probably remained from some old installation?

On 10/27/18, The EMARD vordah@gmail.com wrote:

If zip toolchain is just removed this from bm installation directory without any other fix, fpgarduino board manager will no longer be installable effectively breaking everything :)

On 10/27/18, Marko Zec notifications@github.com wrote:

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

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

emard commented 5 years ago

OK I found it linux 32-bit is really old toolchain from 2015 because Marko provided only linux-64 bit 7.2 and I had no better idea than to keep old toolchain for 32-bit systems otherwise they would compiletely break without any toolchain

On 10/27/18, The EMARD vordah@gmail.com wrote:

When I look better, we should have 7.2 toolchain for both mips+riscv in boards manager for bsd linux win osx so gcc 4.9 probably remained from some old installation?

On 10/27/18, The EMARD vordah@gmail.com wrote:

If zip toolchain is just removed this from bm installation directory without any other fix, fpgarduino board manager will no longer be installable effectively breaking everything :)

On 10/27/18, Marko Zec notifications@github.com wrote:

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

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

drtrigon commented 5 years ago

I got the toolchain from http://www.nxlab.fer.hr/fpgarduino/ and it was 64-bit:

gornjas commented 5 years ago

The 7.2-based toolchain for 32-bit linux was built at the same time the 64-bit version was. We have 5 different toolchains based on gcc-7.2 since 2017 so there's no reason to use anything else:

login% ls -l tool -r--r--r-- 1 marko fpgasvn 68284749 Nov 15 2017 f32c-fbsd64-toolchain-7_2.tar.gz -r--r--r-- 1 marko fpgasvn 79048039 Nov 15 2017 f32c-lin32-toolchain-7_2.tar.gz -r--r--r-- 1 marko fpgasvn 72986821 Nov 14 2017 f32c-lin64-toolchain-7_2.tar.gz -rw-r--r-- 1 marko fpgasvn 82335149 Nov 24 2017 f32c-osx-toolchain-7_2.tgz -r--r--r-- 1 marko fpgasvn 93959677 Nov 9 2017 f32c-win32-toolchain-7_2.zip

drtrigon commented 5 years ago

Ok a lot of links on http://www.nxlab.fer.hr/fpgarduino/ are broken now but I figured the name of the new one to be www.nxlab.fer.hr/fpgarduino/bm/f32c-lin64-toolchain-7_2.tar.gz now, using that I got following result:

$ make prog ../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c cc1: error: requested ABI requires -march to subsume the 'D' extension make: *** [firmware.elf] Fehler 1

drtrigon commented 5 years ago

It is no problem for integrate from licensing point of view but we lack of ing-hours to assemble all parts into stuff that works. I can package another riscv compiler and all required programming tools and libs, if you succeed with anything that leads to a blink led

As explained in https://github.com/cliffordwolf/picorv32/issues/92 you can find a working example in https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc (see e.g. https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile). The toolchain used can be found in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain (risc-v gcc) and https://github.com/FPGAwars/toolchain-icestorm/releases/ (iceprog). Do you need more info? More specific details? What I do not have are includes to make it compatible with Arduino source code.

gornjas commented 5 years ago

$ make prog ../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c cc1: error: requested ABI requires -march to subsume the 'D' extension make: *** [firmware.elf] Fehler 1

Hi drtrigon,

pls. try adding -mabi=ilp32 to riscv32-elf-gcc invocation options.

drtrigon commented 5 years ago

Works! The created .elf file differs by one byte from the one the original toolchain generated a few days before. Nice! Uploaded using iceprog.

drtrigon commented 5 years ago

Do you need more info from my side?

emard commented 5 years ago

HI

I think that's ok for now, I'm preparing to update arduino release with riscv 7.2 compiler for linux-32bit, I'm preparing some additional files there too

On 10/28/18, drtrigon notifications@github.com wrote:

Do you need more info from my side?

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

drtrigon commented 5 years ago

Oh, by the way the links on http://www.nxlab.fer.hr/fpgarduino/ are still broken, quite some confusion with "_", "-" and "." going on there, e.g.:

drtrigon commented 5 years ago

Any news?

emard commented 5 years ago

HI

I'm still fixing the flash/sd bootloader to make the f32c load at power-on the user-compiled sketch (*.bin from arduino).

I have some positive results on ulx3s and papilio-pro but in the meantime ulx2s stopped working so I'm fixing it now.

On 11/9/18, drtrigon notifications@github.com wrote:

Any news?

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

drtrigon commented 5 years ago

Sorry to hear that but thanks a lot for your work! (I'm eager to test it on Alhambra... ;)

drtrigon commented 5 years ago

What is the current status? Do you have an estimate by when I can start using it on the Alhambra?

emard commented 5 years ago

HI

q3k managed to compile f32c on ice40, maybe you can try the same: http://www.twipu.com/RadionaOrg/tweet/1068227927773536256

Although fpgarduino can run on bare-bones risc-v for blink, using f32c is good for it has rich SOC which would provide you a lot of additional soft-core hardware.

On 12/4/18, drtrigon notifications@github.com wrote:

What is the current status? Do you have an estimate by when I can start using it on the Alhambra?

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

drtrigon commented 5 years ago

Do you have any more info about it? Link to a logfile e.g.?

emard commented 5 years ago

I haven't tried to compile this, you can contact q3k he could have log file https://github.com/q3k

On 12/9/18, drtrigon notifications@github.com wrote:

Do you have any more info about it? Link to a logfile e.g.?

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

drtrigon commented 5 years ago

Tryed to contact @q3k but was not able due to a flaw in my mail prog. May be he can comment here on the details of how he "compile[d] f32c on ice40"?

emard commented 5 years ago

I know, sometimes q3k just doesn't read mails but the fact that f32c is possible on ICE40 is worth enough to try

The big thing about FPGA Arduino is the SOC coming with f32c. Many projects around offer free risc-v core and a minimalistic SOC with a serial port and pins to blink LED

No HDMI video, FPU, DMA audio, advanced timers, SDR radio, SPI etc...

On 12/23/18, drtrigon notifications@github.com wrote:

Tryed to contact @q3k but was not able due to a flaw in my mail prog. May be he can comment here on the details of how he "compile[d] f32c on ice40"?

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

q3k commented 5 years ago

I got f32c to synthesize on iCE40 by hacking on the VHDL source until it synthesized via Yosys with built-in Verific support (a commercial VHDL elaboration frontend), then P&Rd it using NextPNR. I haven't tested it on HW though, as I didn't have an iCE40 devboard handy at the time. I can dig up my VHDL changes if you're curious.

And, contrary to popular belief, I do read all of my email, just don't have the willpower to act upon all of them :/.

emard commented 5 years ago

Great work q3k, it would be great if you could clone the f32c and on the cloned f32c commit your changes that allow it to compile.

On 12/23/18, Serge Bazanski notifications@github.com wrote:

I got f32c to synthesize on iCE40 by hacking on the VHDL source until it synthesized via Yosys with built-in Verific support (a commercial VHDL elaboration frontend), then P&Rd it using NextPNR. I haven't tested it on HW though, as I didn't have an iCE40 devboard handy at the time. I can dig up my VHDL changes if you're curious.

And, contrary to popular belief, I do read all of my email, just don't have the willpower to act upon all of them :/.

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

drtrigon commented 5 years ago

Thanks a lot @q3k for commenting here! I can do tests on my hardware as I own a https://github.com/FPGAwars/Alhambra-II-FPGA

drtrigon commented 5 years ago

@q3k: If you don't commit your changes it would be great if you "can dig up [my/your] VHDL changes if you're curious" and post them. I'll try to "commit your changes that allow it to compile" then. Thanks a lot in advance!

drtrigon commented 5 years ago

ping @q3k: what's the status? can I help you with anything?

gornjas commented 5 years ago

We'd be happy to accept patches, but until that materializes there's no point in reopening this issue. We do not have access to the Alhambra board, and even if we did, we (at least I) wouldn't have time to port picorv32 to a new board, prepare bootloaders etc. If you did the porting work, test the core with the GNU tools we provide with FPGArduino, and provide at least some crude patches, we would be happy to consider merging it to FPGArduino.

drtrigon commented 5 years ago

?? ... I am very puzzeled by your action. As stated in the beginning I am willing to invest my time but need your support. I do have the hardware for tests.

I only closed the issue by accident. We had progress here - I am just waiting for an example by @q3k.

Given the popularity the iCE40 platform has at the moment (Alhambra, TinyFPGA, iCEBreaker, Fomu, etc) I consider supporting it as an important step.

If you prefer to trash these efforts I guess FPGArduino will die at some point in the future anyway. The first sign was that the download links stopped working for weeks recently...

emard commented 5 years ago

HI

I'm supporting FPGArduino and keep your picorv32 efforts as normal. We have simple serial bootloader protocol which if you happen to get running on picorv32 it should be enough to get the board load and run any other FPGArduino code.

In the meantime I'm also trying to add usb-serial from opencores as f32c soc which would enable 10Mbit USB 1.1 serial port with a minimum hardware (2 fpga pins, only cable and few resistors and diodes, no ftdi chips no usb transcievers)

On 12/31/18, drtrigon notifications@github.com wrote:

?? ... I am very puzzeled by your action. As stated in the beginning I am willing to invest my time but need your support. I do have the hardware for tests.

I only closed the issue by accident. We had progress here - I am just waiting for an example by @q3k.

Given the popularity the iCE40 platform has at the moment (Alhambra, TinyFPGA, iCEBreaker, Fomu, etc) I consider supporting it as an important step.

If you prefer to trash these efforts I guess FPGArduino will die at some point in the future anyway. The first sign was that the download links stopped working for weeks recently...

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

emard commented 5 years ago

We have ECP5 board which also supports opensource tools and picorv32 is supposed to compile on this, I prefer to develop on this and results will be compatible with ICE40 boards too

So I'd like to call for efforts that someone prepares picorv32 for ECP5 preferrably with SDRAM support (if won't work then BRAM only) and get our sime C bootloader here

https://github.com/f32c/f32c/tree/master/src/boot/sio

It should print "rv32>" prompt at terminal on ULX3S or similar ECP5 board using some usb-serial hardware like ft232r, ft231x or my latest usb core

https://github.com/emard/fpga-usbserial

I will make FPGArduino adaptation to use picorv32 for blinkled at least

On 12/31/18, D EMARD vordah@gmail.com wrote:

HI

I'm supporting FPGArduino and keep your picorv32 efforts as normal. We have simple serial bootloader protocol which if you happen to get running on picorv32 it should be enough to get the board load and run any other FPGArduino code.

In the meantime I'm also trying to add usb-serial from opencores as f32c soc which would enable 10Mbit USB 1.1 serial port with a minimum hardware (2 fpga pins, only cable and few resistors and diodes, no ftdi chips no usb transcievers)

On 12/31/18, drtrigon notifications@github.com wrote:

?? ... I am very puzzeled by your action. As stated in the beginning I am willing to invest my time but need your support. I do have the hardware for tests.

I only closed the issue by accident. We had progress here - I am just waiting for an example by @q3k.

Given the popularity the iCE40 platform has at the moment (Alhambra, TinyFPGA, iCEBreaker, Fomu, etc) I consider supporting it as an important step.

If you prefer to trash these efforts I guess FPGArduino will die at some point in the future anyway. The first sign was that the download links stopped working for weeks recently...

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

gornjas commented 5 years ago

@drtrigon: all of the open source projects I'm aware of are based on the principle of submitting, reviewing, polishing and finally committing patches. So far in this lengthy thread we have seen none. OTOH we have been subjected to repeated demands to produce support for feature XYZ. If you could point me to a single open source project which works that way I'd feel enlightened.

I'm agree with you that adding support for iCE40 would be nice, but repeating demands that this should happen (or else the project would die) seems quite unproductive to me.

drtrigon commented 5 years ago

@emard: Thanks for your info. As soon as I get some sources I can start testing with, I'll do so. I have to say I don't understand the differences between picorv32 and your f32c-rv32 (SOC). To me it is not important which soft-core/soc is used as long as it works with FPGArduino. (picorv32 is just the thing I am familiar with) Do I understand correct that ECP5 board code should work one iCE40 boards also? If you can point me into the right direction I'll happy to test this! (do we need the picorv32 if that works?)

One thing to keep in mind is that it would be nice if the soft-core/soc could later be implemented in icestudio also and by that allow to add additional logic easily. From my understanding that should be no big deal. Also breaking the soc down into parts in icestudio would allow to gain more insight and result in more ways to modify it according to user wishes.

emard commented 5 years ago

The ECP5 code, if written in portable way, using only generic constructs and avoiding use of features that ECP5 has and ICE40 doesn't have then ECP5 code should be reusable for ICE40 with a minimum effort (only clock generator and pin names would differ)

picorv32 should be such case

On 1/1/19, drtrigon notifications@github.com wrote:

@emard: Thanks for your info. As soon as I get some sources I can start testing with, I'll do so. I have to say I don't understand the differences between picorv32 and your f32c-rv32 (SOC). To me it is not important which soft-core/soc is used as long as it works with FPGArduino. (picorv32 is just the thing I am familiar with) Do I understand correct that ECP5 board code should work one iCE40 boards also? If you can point me into the right direction I'll happy to test this! (do we need the picorv32 if that works?)

One thing to keep in mind is that it would be nice if the soft-core/soc could later be implemented in icestudio also and by that allow to add additional logic easily. From my understanding that should be no big deal. Breaking the soc down into it's parts in icestudio would allow to gain more insight and result in more ways to modify it according to user wishes.

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

emard commented 5 years ago

HI dr3gon

Can you help or get this running on your ICE40 board? Bootloader works but arduino's code won't execute.

I have compiled picorv32 with opensource tools for my ECP5 board and replaced its firmware with f32c bootloader (HEX mode only) that shows rv32> prompt and blinks its leds during upload with

ujprog -P/dev/ttyUSB0 -ra /tmp/arduino_build_668623/BlinkPicoRV32.ino.hex

Blink is arduino sketch:

define LED ((volatile uint32_t)0x02000000)

int ledState = 0; int previousMillis = 0; const long interval = 100000; void setup() { LED = 0xFF; } void loop() { static int currentMillis = 0; currentMillis++; if (currentMillis - previousMillis >= interval) { previousMillis = currentMillis; if (ledState == 0) ledState = 0xFF; else ledState = 0; LED = ledState; } }

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

The ECP5 code, if written in portable way, using only generic constructs and avoiding use of features that ECP5 has and ICE40 doesn't have then ECP5 code should be reusable for ICE40 with a minimum effort (only clock generator and pin names would differ)

picorv32 should be such case

On 1/1/19, drtrigon notifications@github.com wrote:

@emard: Thanks for your info. As soon as I get some sources I can start testing with, I'll do so. I have to say I don't understand the differences between picorv32 and your f32c-rv32 (SOC). To me it is not important which soft-core/soc is used as long as it works with FPGArduino. (picorv32 is just the thing I am familiar with) Do I understand correct that ECP5 board code should work one iCE40 boards also? If you can point me into the right direction I'll happy to test this! (do we need the picorv32 if that works?)

One thing to keep in mind is that it would be nice if the soft-core/soc could later be implemented in icestudio also and by that allow to add additional logic easily. From my understanding that should be no big deal. Breaking the soc down into it's parts in icestudio would allow to gain more insight and result in more ways to modify it according to user wishes.

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

emard commented 5 years ago

The picorv32 and bootloader is here https://github.com/emard/prjtrellis-picorv32

On 1/9/19, D EMARD vordah@gmail.com wrote:

HI dr3gon

Can you help or get this running on your ICE40 board? Bootloader works but arduino's code won't execute.

I have compiled picorv32 with opensource tools for my ECP5 board and replaced its firmware with f32c bootloader (HEX mode only) that shows rv32> prompt and blinks its leds during upload with

ujprog -P/dev/ttyUSB0 -ra /tmp/arduino_build_668623/BlinkPicoRV32.ino.hex

Blink is arduino sketch:

define LED ((volatile uint32_t)0x02000000)

int ledState = 0; int previousMillis = 0; const long interval = 100000; void setup() { LED = 0xFF; } void loop() { static int currentMillis = 0; currentMillis++; if (currentMillis - previousMillis >= interval) { previousMillis = currentMillis; if (ledState == 0) ledState = 0xFF; else ledState = 0; LED = ledState; } }

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

The ECP5 code, if written in portable way, using only generic constructs and avoiding use of features that ECP5 has and ICE40 doesn't have then ECP5 code should be reusable for ICE40 with a minimum effort (only clock generator and pin names would differ)

picorv32 should be such case

On 1/1/19, drtrigon notifications@github.com wrote:

@emard: Thanks for your info. As soon as I get some sources I can start testing with, I'll do so. I have to say I don't understand the differences between picorv32 and your f32c-rv32 (SOC). To me it is not important which soft-core/soc is used as long as it works with FPGArduino. (picorv32 is just the thing I am familiar with) Do I understand correct that ECP5 board code should work one iCE40 boards also? If you can point me into the right direction I'll happy to test this! (do we need the picorv32 if that works?)

One thing to keep in mind is that it would be nice if the soft-core/soc could later be implemented in icestudio also and by that allow to add additional logic easily. From my understanding that should be no big deal. Breaking the soc down into it's parts in icestudio would allow to gain more insight and result in more ways to modify it according to user wishes.

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

q3k commented 5 years ago

I will get you all I know about how to get f32c to synthesize&pr under verific+yosys+nextpnr for ice40 - I just haven't had time to get to it yet :(.

drtrigon commented 5 years ago

Thanks a lot @emard this is great news! Took the code from your repo and modified makefile and scripts/ulx3s_trellis.mk in order to point to my toolchain:

F32C-COMPILER-PATH=../toolchain-fpgarduino/f32c/bin

and

YOSYS ?= $(HOME)/.icestudio/apio/packages/toolchain-icestorm/bin/yosys

finally running make all yields this:

~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$ make all
$HOME/.icestudio/apio/packages/toolchain-icestorm/bin/yosys \
        -p "hierarchy -top top" \
        -p "synth_ecp5 -noccu2 -json dvi.json" \
        top.v attosoc.v picorv32.v simpleuart.v 

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2016  Clifford Wolf <clifford@clifford.at>           |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.7 (Apio build) (git sha1 8c071a2, gcc 4.8.4-2ubuntu1~14.04.3 -fPIC -Os)

-- Parsing `top.v' using frontend `verilog' --

1. Executing Verilog-2005 frontend.
Parsing Verilog input from `top.v' to AST representation.
Generating RTLIL representation for module `\top'.
Successfully finished Verilog frontend.

-- Parsing `attosoc.v' using frontend `verilog' --

2. Executing Verilog-2005 frontend.
Parsing Verilog input from `attosoc.v' to AST representation.
Generating RTLIL representation for module `\attosoc'.
Generating RTLIL representation for module `\picosoc_regs'.
Successfully finished Verilog frontend.

-- Parsing `picorv32.v' using frontend `verilog' --

3. Executing Verilog-2005 frontend.
Parsing Verilog input from `picorv32.v' to AST representation.
Generating RTLIL representation for module `\picorv32'.
Generating RTLIL representation for module `\picorv32_regs'.
Generating RTLIL representation for module `\picorv32_pcpi_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_fast_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_div'.
Generating RTLIL representation for module `\picorv32_axi'.
Generating RTLIL representation for module `\picorv32_axi_adapter'.
Generating RTLIL representation for module `\picorv32_wb'.
Successfully finished Verilog frontend.

-- Parsing `simpleuart.v' using frontend `verilog' --

4. Executing Verilog-2005 frontend.
Parsing Verilog input from `simpleuart.v' to AST representation.
Generating RTLIL representation for module `\simpleuart'.
Successfully finished Verilog frontend.

-- Running command `hierarchy -top top' --

5. Executing HIERARCHY pass (managing design hierarchy).

5.1. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         \picorv32

5.2. Executing AST frontend in derive mode using pre-parsed AST for module `\picorv32'.
Parameter \BARREL_SHIFTER = 0
Parameter \COMPRESSED_ISA = 0
Parameter \ENABLE_MUL = 1
Parameter \ENABLE_DIV = 0
Parameter \ENABLE_IRQ = 0
Parameter \ENABLE_IRQ_QREGS = 0
Parameter \PROGADDR_RESET = 0
Parameter \PROGADDR_IRQ = 0
Parameter \STACKADDR = 32768
Generating RTLIL representation for module `$paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32'.

5.3. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         $paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul

5.4. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         $paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul
Removing unused module `\picorv32_wb'.
Removing unused module `\picorv32_axi_adapter'.
Removing unused module `\picorv32_axi'.
Removing unused module `\picorv32_pcpi_div'.
Removing unused module `\picorv32_pcpi_fast_mul'.
Removing unused module `\picorv32_regs'.
Removing unused module `\picorv32'.
Removing unused module `\picosoc_regs'.
Removed 8 unused modules.

-- Running command `synth_ecp5 -noccu2 -json dvi.json' --
ERROR: No such command: synth_ecp5 (type 'help' for a command overview)
make: *** [dvi.json] Fehler 1
~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$

...so what is the proper substitute for synth_ecp5 ?

@q3k: Would be great to get you hints - looking forward to this...

emard commented 5 years ago

HI synth_ecp5 you should replace by synth_ice40 or similar ECP5 is my FPGA, ICE40 is yours

On 1/13/19, drtrigon notifications@github.com wrote:

Thanks a lot emard this is great news! Took the code from your repo and modified makefile and scripts/ulx3s_trellis.mk in order to point to my toolchain:

F32C-COMPILER-PATH=../toolchain-fpgarduino/f32c/bin

and

YOSYS ?= $(HOME)/.icestudio/apio/packages/toolchain-icestorm/bin/yosys

finally running make all yields this:

~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$
make all
$HOME/.icestudio/apio/packages/toolchain-icestorm/bin/yosys \
        -p "hierarchy -top top" \
        -p "synth_ecp5 -noccu2 -json dvi.json" \
        top.v attosoc.v picorv32.v simpleuart.v

/----------------------------------------------------------------------------\
 |
 |
 |  yosys -- Yosys Open SYnthesis Suite
 |
 |
 |
 |  Copyright (C) 2012 - 2016  Clifford Wolf <clifford@clifford.at>
 |
 |
 |
 |  Permission to use, copy, modify, and/or distribute this software for any
 |
 |  purpose with or without fee is hereby granted, provided that the above
 |
 |  copyright notice and this permission notice appear in all copies.
 |
 |
 |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 |
 |
 |
\----------------------------------------------------------------------------/

 Yosys 0.7 (Apio build) (git sha1 8c071a2, gcc 4.8.4-2ubuntu1~14.04.3 -fPIC
-Os)

-- Parsing `top.v' using frontend `verilog' --

1. Executing Verilog-2005 frontend.
Parsing Verilog input from `top.v' to AST representation.
Generating RTLIL representation for module `\top'.
Successfully finished Verilog frontend.

-- Parsing `attosoc.v' using frontend `verilog' --

2. Executing Verilog-2005 frontend.
Parsing Verilog input from `attosoc.v' to AST representation.
Generating RTLIL representation for module `\attosoc'.
Generating RTLIL representation for module `\picosoc_regs'.
Successfully finished Verilog frontend.

-- Parsing `picorv32.v' using frontend `verilog' --

3. Executing Verilog-2005 frontend.
Parsing Verilog input from `picorv32.v' to AST representation.
Generating RTLIL representation for module `\picorv32'.
Generating RTLIL representation for module `\picorv32_regs'.
Generating RTLIL representation for module `\picorv32_pcpi_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_fast_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_div'.
Generating RTLIL representation for module `\picorv32_axi'.
Generating RTLIL representation for module `\picorv32_axi_adapter'.
Generating RTLIL representation for module `\picorv32_wb'.
Successfully finished Verilog frontend.

-- Parsing `simpleuart.v' using frontend `verilog' --

4. Executing Verilog-2005 frontend.
Parsing Verilog input from `simpleuart.v' to AST representation.
Generating RTLIL representation for module `\simpleuart'.
Successfully finished Verilog frontend.

-- Running command `hierarchy -top top' --

5. Executing HIERARCHY pass (managing design hierarchy).

5.1. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         \picorv32

5.2. Executing AST frontend in derive mode using pre-parsed AST for module
`\picorv32'.
Parameter \BARREL_SHIFTER = 0
Parameter \COMPRESSED_ISA = 0
Parameter \ENABLE_MUL = 1
Parameter \ENABLE_DIV = 0
Parameter \ENABLE_IRQ = 0
Parameter \ENABLE_IRQ_QREGS = 0
Parameter \PROGADDR_RESET = 0
Parameter \PROGADDR_IRQ = 0
Parameter \STACKADDR = 32768
Generating RTLIL representation for module
`$paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32'.

5.3. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:
$paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul

5.4. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:
$paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul
Removing unused module `\picorv32_wb'.
Removing unused module `\picorv32_axi_adapter'.
Removing unused module `\picorv32_axi'.
Removing unused module `\picorv32_pcpi_div'.
Removing unused module `\picorv32_pcpi_fast_mul'.
Removing unused module `\picorv32_regs'.
Removing unused module `\picorv32'.
Removing unused module `\picosoc_regs'.
Removed 8 unused modules.

-- Running command `synth_ecp5 -noccu2 -json dvi.json' --
ERROR: No such command: synth_ecp5 (type 'help' for a command overview)
make: *** [dvi.json] Fehler 1
~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$

...so what is the proper substitute for synth_ecp5 ?

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

drtrigon commented 5 years ago

@emard: ;) ...ok - thanks! Was not aware of such a obvious replacement. Added and did a fast/short test.

My current synth_ice40 (came with icestudio) seems to be old as it does not have the -json option. Is it possible to generate the bitstream etc. w/o using the json output? If not, I'll need some time to get a current toolchain... currently it ran until and finished step 6.28 - then make complains about finding no rule for creating empty_lfe5u-85f.config. This is strange because the rule $(BOARD)_$(FPGA_SIZE)f_$(PROJECT).config is still existing (I did not remove it).

@q3k: As the ice40 toolchain comming with icestudio contains arachne-pnr I'll go and use this until something forces me to change (errors/incompatibilities, size of final design, etc.). Do you remember why you used nextpnr? Was there a reason that forced you to use it? Or was it just by accident (because you had it installed already, you where familiar with it, etc.)?