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

DrTrigon,

take any ice40 project you already can compiled with arache-pnr and just replace my sources verilogs *.v and firmware.c firmware.hex, that should all it takes. You don't need to strictly follow my build path for ECP5 when you have ICE40

For me at ECP5 it executed something, jumps to address but blink example doesn't blink led. CPU picorv32 seems to run uploaded code, different binaries result in different types of crash, but something still needs additional work on how to prepared the correct binary executable from arduino to picorv32 (files boards.txt and platform.txt) so please help by experimenting on there

I mailed Clifford Wolf to help but got no response yet...

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

@emard: ;) ...ok - thanks! Was not aware of such a obvious replacement. Added.

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... (cuurently it ran until and finished step 6.28 - then make complains about finding no rule for creating empty_lfe5u-85f.config).

@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.)?

-- 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-453989139

emard commented 5 years ago

Hi Dr3Gon!

I have good news 4U.

Suppose that you manage to compile my prjtrellis-picorv32 sources for your ICE40, then in our FPGArduino quickly edit ~/.arduino15/packages/FPGArduino/hardware/f32c/1.0.0/cores/f32c around line 46, comment out f32c specific initialization (the picorv32 soc crashed because of this) // f32c_specific_initialization(); after this change, I hope the famous blinkled from this thread should happily run on your Alhambra board with picorv32 loaded.

If you'd ever decide to obtain one of our ECP5 ULX3S boards which does full featured f32c, check this out:

http://radiona.org/ulx3s

Best regards, Davor

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

DrTrigon,

take any ice40 project you already can compiled with arache-pnr and just replace my sources verilogs *.v and firmware.c firmware.hex, that should all it takes. You don't need to strictly follow my build path for ECP5 when you have ICE40

For me at ECP5 it executed something, jumps to address but blink example doesn't blink led. CPU picorv32 seems to run uploaded code, different binaries result in different types of crash, but something still needs additional work on how to prepared the correct binary executable from arduino to picorv32 (files boards.txt and platform.txt) so please help by experimenting on there

I mailed Clifford Wolf to help but got no response yet...

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

@emard: ;) ...ok - thanks! Was not aware of such a obvious replacement. Added.

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... (cuurently it ran until and finished step 6.28 - then make complains about finding no rule for creating empty_lfe5u-85f.config).

@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.)?

-- 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-453989139

uXeBoy commented 5 years ago

Have made a fork, and have it close to working with iCE40 on the 'myStorm BlackIce II':

https://github.com/uXeBoy/prjtrellis-picorv32

When I hit enter, instead of 'rv32>' I get five garbage characters back, so maybe just COM port settings / parity etc need adjusting on the PC side?

emard commented 5 years ago

Check this serial port speed divider I have something like 412/2 for 25MHz, correct this factor for your clock and let it be 115200

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

Have made a fork, and have it close to working with iCE40 on the 'myStorm BlackIce II':

https://github.com/uXeBoy/prjtrellis-picorv32

When I hit enter, instead of 'rv32>' I get five garbage characters back, so maybe just COM port settings / parity etc need adjusting on the PC side?

-- 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-454281309

uXeBoy commented 5 years ago

Working now! Was definitely something to do with the built-in serial, but not sure what exactly? Switched to using one of these instead and it's all good:

https://raw.githubusercontent.com/uXeBoy/prjtrellis-picorv32/master/blink.gif

emard commented 5 years ago

Yes, not all serial cables are reliable and HEX protocol has no checksum so it must be 100% reliable.

If that works next step would be to take our f32c binary bootloader protocol, it will make it longer but such will retry transfer so any bad cable will become useful

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

Working now! Was definitely something to do with the built-in serial, but not sure what exactly? Switched to using one of these instead and it's all good:

https://raw.githubusercontent.com/uXeBoy/prjtrellis-picorv32/master/blink.gif

-- 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-454340166

emard commented 5 years ago

HI dr3Gon!

Get new FPGArduino, it will be slightly more friendly to the picorv32. See README.md in my https://github.com/emard/prjtrellis-picorv32

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

Yes, not all serial cables are reliable and HEX protocol has no checksum so it must be 100% reliable.

If that works next step would be to take our f32c binary bootloader protocol, it will make it longer but such will retry transfer so any bad cable will become useful

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

Working now! Was definitely something to do with the built-in serial, but not sure what exactly? Switched to using one of these instead and it's all good:

https://raw.githubusercontent.com/uXeBoy/prjtrellis-picorv32/master/blink.gif

-- 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-454340166

drtrigon commented 5 years ago

Thanks for all the hints so far! Now I had a bit more time to look into it. I started a new Makefile https://github.com/drtrigon/prjtrellis-picorv32/commit/dd55eb30205ece8b66d44a28465ced763f637841 and now I use blif instead of json backend, so the yosys step passes properly. However the arachne-pnr step throws: fatal error: failed to place: placed 32 RAMs of 68 / 32 so it does not fit into the available BRAM. From manpage http://manpages.org/arachne-pnr I do not see any parameters that allow optimization, so what to remove or disable? Other question is how to connect the clock signal properly, I see clk_25mhz but the Alhambra 2 has a 12 MHz clock signal, see https://github.com/drtrigon/prjtrellis-picorv32/commit/f028af7b09b60cf591558b0f1e9086c0b5901255.

I add here the output of the failing step:

arachne-pnr -d 8k -P tq144:4k -o top.asc -p demo.pcf top.blif
seed: 1
device: 8k
read_chipdb +/share/arachne-pnr/chipdb-8k.bin...
  supported packages: cb132, cb132:4k, cm121, cm121:4k, cm225, cm225:4k, cm81, cm81:4k, ct256, tq144:4k
read_blif top.blif...
prune...
read_pcf demo.pcf...
demo.pcf:21: warning: no port `clk' in top-level module `top', constraint ignored.
demo.pcf:24: warning: no port `flash_csb' in top-level module `top', constraint ignored.
demo.pcf:25: warning: no port `flash_miso' in top-level module `top', constraint ignored.
demo.pcf:26: warning: no port `flash_mosi' in top-level module `top', constraint ignored.
demo.pcf:27: warning: no port `flash_clk' in top-level module `top', constraint ignored.
instantiate_io...
pack...

After packing:
IOs          19 / 107
GBs          0 / 8
  GB_IOs     0 / 8
LCs          2852 / 7680
  DFF        647
  CARRY      433
  CARRY, DFF 126
  DFF PASS   224
  CARRY PASS 17
BRAMs        68 / 32
WARMBOOTs    0 / 1
PLLs         0 / 2

place_constraints...
promote_globals...
  promoted clk_25mhz$2, 909 / 909
  promoted $abc$27963$n5, 435 / 435
  promoted $abc$27963$n2173, 66 / 66
  promoted $abc$27963$n2227, 64 / 64
  promoted $abc$27963$n2163, 52 / 53
  promoted $abc$27963$n2161, 49 / 49
  promoted $abc$27963$n3, 31 / 31
  promoted $abc$27963$n1, 6 / 6
  promoted 8 nets
    3 sr/we
    4 cen/wclke
    1 clk
  8 globals
    3 sr/we
    4 cen/wclke
    1 clk
realize_constants...
  realized 1
place...
fatal error: failed to place: placed 32 RAMs of 68 / 32
drtrigon commented 5 years ago

Btw.: I would also like to test it with https://github.com/f32c/f32c but when I looked into it I was a bit overwhelmed by the options and variants that are in there. Do I understand correct, it only exists in VHDL but not in Verilog? Thus I would first have to setup the yosys plugin (and by that next-pnr too according to http://www.clifford.at/icestorm/) or better the whole icestorm toolchain as icestudio contains a yosys w/o plugin support (and w/o json output).

drtrigon commented 5 years ago

@emard: OK, managed to make it synthesize by reducing memory usage in attosoc.vwith MEM_WORDS = 2048 see https://github.com/drtrigon/prjtrellis-picorv32/commit/557f71a5da9eb6f4d5882aa9cf2028efbc7455db. Now it takes 20 of 32 BRAM blocks. However I have no idea whether that's ok? As soon as you can give me feedback about MEM_WORDS, the clock signal and the baudrate setting I'll upload and test it!

uXeBoy commented 5 years ago

@drtrigon - to use the 12MHz clock you will need to change reg_uart_clkdiv = 416/2 in firmware.c to reg_uart_clkdiv = 104 (12,000,000 / 115200 = 104.166666667)

@emard - the reason for my issue with serial has been found, reg_uart_clkdiv should be 217 to use with 25MHz, not 208 (416/2)

drtrigon commented 5 years ago

Ok, changed the setting as suggested (thanks for the hint @uXeBoy) and just connected clk with clk_25mhz, see https://github.com/drtrigon/prjtrellis-picorv32/commit/41b7980cb1180c3c95450619d8c589d3effacb5c. Uploaded it, but no blinking leds (yet)... have tried to set https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 to 1 in order to enable it, but no change... suggestions? ideas?

emard commented 5 years ago

My apologies, this baud rate math was slightly off, but yes you got it right For start you can feed 12 MHz to picorv32 just to make sure it works, later rise the clock until it stops working and back off 10-15% to be safe for normal use

when memory is shorter: 2 things need to be changed:

  1. in firmware.c set lower the stack address 7FF0 means 16 bytes below 32K. change it similar for your smaller mem "li s0, 0x00007FF0;" / stack address /

  2. in sections.lds also you should lower the length similar RAM (xrw) : ORIGIN = 0x00000000, LENGTH = 0x008000 / 32 KB /

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

Ok, changed the setting as suggested and just connected clk with clk_25mhz, see https://github.com/drtrigon/prjtrellis-picorv32/commit/41b7980cb1180c3c95450619d8c589d3effacb5c. Uploaded it, but no blinking leds (yet)... have tried to set https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 to 1 in order to enable it, but no change... suggestions? ideas?

-- 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-455319286

drtrigon commented 5 years ago

@emard: Thanks for the hints. If I got the math right, I have for 1/4 of the memory size (8K) to set hex(2048*4-16) = 1FF0 instead of 7FF0 and hex(2048*4) = 0x002000 instead of 0x008000 as done in https://github.com/drtrigon/prjtrellis-picorv32/commit/623c3a6cfb72f7679171b736a32358003e6ef2ce but still no reaction...

I don't understand your comment about rising the clock. At the moment I just connected the 12MHz to your clk_25mhz signal. Do I have to adopt dividers for that also?

emard commented 5 years ago

HI

Great, seems you calculated 8K RAM constants well I have rewritten readme with intention to solve FAQ around here. It's working on my board and latest FPGArduino

I can change RAM to see if it works or my README is maybe not telling the complete truth

No reaction, no rv32> boot prompt on serial console? check that you have correctly connected TX/RX

In my example I'm connecting RX of FPGA to TX of USB-SERIAL and vice versa TX of FPGA to RX of USB-SERIAL

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

@emard: Thanks for the hints. If I got the math right, I have for 1/4 of the memory size (8K) to set hex(2048*4-16) = 1FF0 instead of 7FF0 and hex(2048*4) = 0x002000 instead of 0x008000 as done in https://github.com/drtrigon/prjtrellis-picorv32/commit/623c3a6cfb72f7679171b736a32358003e6ef2ce but still no reaction...

I don't understand your comment about rising the clock. At the moment I just connected the 12MHz to your clk_25mhz signal. Do I have to adopt dividers for that also?

-- 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-455375629

emard commented 5 years ago

In my latest git there's firmware.c with proper integer math for the divisor. Just change the clock 12 MHz = 12000000 Hz compile, it will calculate divisor automatically

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

HI

Great, seems you calculated 8K RAM constants well I have rewritten readme with intention to solve FAQ around here. It's working on my board and latest FPGArduino

I can change RAM to see if it works or my README is maybe not telling the complete truth

No reaction, no rv32> boot prompt on serial console? check that you have correctly connected TX/RX

In my example I'm connecting RX of FPGA to TX of USB-SERIAL and vice versa TX of FPGA to RX of USB-SERIAL

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

@emard: Thanks for the hints. If I got the math right, I have for 1/4 of the memory size (8K) to set hex(2048*4-16) = 1FF0 instead of 7FF0 and hex(2048*4) = 0x002000 instead of 0x008000 as done in https://github.com/drtrigon/prjtrellis-picorv32/commit/623c3a6cfb72f7679171b736a32358003e6ef2ce but still no reaction...

I don't understand your comment about rising the clock. At the moment I just connected the 12MHz to your clk_25mhz signal. Do I have to adopt dividers for that also?

-- 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-455375629

drtrigon commented 5 years ago

@emard: Thanks again for your hints and efforts. Currently I am stuck as I must be doing something fundamentally wrong. I double checked the RX, TX connections, swapped them several times, there is no prompt appearing. What happens is when I swap RX/TX I get some leds on like 0b10101010. When I enable the stuff on line 62 https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 I get a led pattern like 0b00001111. Adding LED = 0xFF; in firmware.c right before prompt label does not change anything. I never get serial output. Summary; something happens but I have no clue what currently...

Do I need to use an additional USB-SERIAL adapter? I want to use the one (ftdi chip) on the board that is used to upload fpga bitstreams etc.

emard commented 5 years ago

Well your thing seems to work, don't enable this stuff #if 0 it was just for debugging but led pattern you discribed is OK so at least you compiled successfully your code

I think you are close, Either serial port or pinout is wrong or baudrate or clock rate, something simple

0b10101010 is normal startup pattern that's good. and 0b00001111 from #if 1 enabled is indication that bootloader is executing C compiled code, great.

when this #if 0 stuff is not enabled, any key press on the prompt should show on the LED the binary form of the ascii letter you pressed

Im no expert on ICE40 field, but I know picorv32 was initially developed for ICE40 so it should work there.

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

@emard: Thanks again for your hints and efforts. Currently I am stuck as I must be doing something fundamentally wrong. I double checked the RX, TX connections, swapped them several times, there is no prompt appearing. What happens is when I swap RX/TX I get some leds on like 0b10101010. When I enable the stuff on line 62 https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 I get an led pattern like 0b00001111. Adding LED = 0xFF; in firmware.c right before prompt label does not change anything. I never get serial output. Summary something happens but I have no clue what currently...

-- 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-455482455

drtrigon commented 5 years ago

@emard: Thanks a lot for the feedback - I did not find where in code these LED patterns are set - if you say that's a indication of running code, that's a very good sign. Thanks!

I have several icestudio projects using the same picorv32 and they work - that is where the idea for this feature request comes from. I can provide them also later e.g. as I have implemented GPIO (read and write) including tri-state port etc. - that's a nice topic for later.

Coming back to the current problem; by using LED = 0xFF; as "breakpoint" replacement I am trying to track down where my code hangs. What I found is that is does not pass beyond https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L78 (does not leave the do while after the loop label). To me it looks like serial issue. The divider (104) is ok, I used the same in the other mentioned projects successfully. The thing is I double checked the TX/RX signals again and am 99% sure that they are wrong now - but if I swap them, no C code gets executed at all (LED = 0xFF; in very first line does nothing)... ideas?

emard commented 5 years ago

HI

This is strange, maybe a bad compilation or too congested design for small ICE40. I can ask somebody who has ICE40 to try it too

To verify tx and rx I woulld do in toplevel something like assign tx = rx; so if I connect with serial console, whatever I type should be echoed back, that is the test that tx and rx and serial port are working.

There is also "helloworld.c" example that you can copy over firmware.c and see what happens.

I have further updated my project by adding serial break detection to the simpleuart.v and I it works (FPGArduino sends serial break to reset CPU back to bootloader)

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

@emard: Thanks a lot for the feedback - I did not find where in code these LED patterns are set - if you say that's a indication of running code, that's a very good sign. Thanks!

I have several icestudio projects using the same picorv32 and they work - that is where the idea for this feature request comes from. I can provide them also later e.g. as I have implemented GPIO (read and write) including tri-state port etc. - that's a nice topic for later.

Coming back to the current problem; by using LED = 0xFF; as "breakpoint" replacement I am trying to track down where my code hangs. What I found is that is does not pass beyond https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L78 (does not leave the do while after the loop label). To me it looks like serial issue. The divider (104) is ok, I used the same in the other mentioned projects successfully. The thing is I double checked the TX/RX signals again and am 99% sure that they are wrong now - but if I swap them, no C code gets executed at all (LED = 0xFF; in very first line does nothing)... ideas?

-- 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-455643015

drtrigon commented 5 years ago

@emard: Ok following improvement; I pulled your latest code and merged. Now I see a rv32> prompt after reset! What puzzles me is that the leds do not react to or show the value of the last byte sent.

drtrigon commented 5 years ago

@emard: Testting the helloworld.c now ... sending from FPGA to PC works but it seems the back path does not ... have to investigate that...

emard commented 5 years ago

rv32> prompt is good, if LEDs don't follow typing I would suspect bad FPGA synthesys, upgrade your ICE40 tools.

Also when you have rv32> prompt, you can immediately try sending a binary from FPGArduino. Follow my README.md and upload the blink

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

@emard: Testting the helloworld.c now ... sending from FPGA to PC works but it seems the back path does not ... have to investigate that...

-- 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-455661742

emard commented 5 years ago

rv32> should appear each time you press ENTER not only at reset, also if you send BREAK the prompt will reappear suppose you use terminal screen /dev/ttyUSB0 115200 break is sent by ctrl-a ctrl-b

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

rv32> prompt is good, if LEDs don't follow typing I would suspect bad FPGA synthesys, upgrade your ICE40 tools.

Also when you have rv32> prompt, you can immediately try sending a binary from FPGArduino. Follow my README.md and upload the blink

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

@emard: Testting the helloworld.c now ... sending from FPGA to PC works but it seems the back path does not ... have to investigate that...

-- 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-455661742

drtrigon commented 5 years ago

rv32> prompt is good, if LEDs don't follow typing I would suspect bad FPGA synthesys, upgrade your ICE40 tools.

Either this or something is wrong with my RISCV32-GCC toolchain. Could you may be point me to the proper one?

In any case I can honestly say that I currently have no clue what's going on... I tested with this file https://github.com/drtrigon/prjtrellis-picorv32/blob/master/helloworld.c. What works are line 45+46 and if everything else is commented as in the current version also line 53. But that's all... e.g. the while loop does not work - the leds blink once and then stay off. I changed the delay loop and once the output text was printed a few times (so it looped) but then stopped also. So to summarize; something works but there are various strange artifacts.

Also when you have rv32> prompt, you can immediately try sending a binary from FPGArduino. Follow my README.md and upload the blink

I would love to go forward and try this, but currently I don't think it makes sense... wrong? (currently it does not react on S or ENTER)

emard commented 5 years ago

Proper gcc toolchain is the same gcc which comes in binary form when you automatically install FPGArduino support using boards-manager method. In the makefile this gcc will appear in the path ~/.arduino15/bla..

My both bootloader and arduino blink examples successfuly compile with this gcc

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

rv32> prompt is good, if LEDs don't follow typing I would suspect bad FPGA synthesys, upgrade your ICE40 tools.

Either this or something is wrong with my RISCV32-GCC toolchain. Could you may be point me to the proper one?

In any case I can honestly say that I currently have no clue what's going on... I tested with this file https://github.com/drtrigon/prjtrellis-picorv32/blob/master/helloworld.c. What works are line 45+46 and if everything else is commented as in the current version also line 53. But that's all... e.g. the while loop does not work - the leds blink once and then stay off. I changed the delay loop and once the output text was printed a few times (so it looped) but then stopped also. So to summarize; something works but there are strange artifacts.

Also when you have rv32> prompt, you can immediately try sending a binary from FPGArduino. Follow my README.md and upload the blink

I would love to go forward and try this, but currently I don't think it makes sense... wrong?

-- 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-455708817

drtrigon commented 5 years ago

Had some time to give it a try. Installed the fpgarduino toolchain successfully using the boards-manager method. Now the newest arachne-pnr refuses to route:

$ make
arachne-pnr -d 8k -P tq144:4k -o top.asc -p demo.pcf top.blif
seed: 1
device: 8k
read_chipdb +/share/arachne-pnr/chipdb-8k.bin...
  supported packages: bg121, bg121:4k, cb132, cb132:4k, cm121, cm121:4k, cm225, cm225:4k, cm81, cm81:4k, ct256, tq144:4k
read_blif top.blif...
prune...
read_pcf demo.pcf...
note: no set_io constraints for pins `btn[0..6]'
note: no set_io constraints for pin `wifi_gpio0'
demo.pcf:32: fatal error: Missing 8 set_io constraints
make: *** [top.asc] Error 1

where the older one just did this:

promote_globals...
  promoted clk_25mhz$2, 811 / 811
  promoted $abc$27162$n7, 287 / 287
  promoted $abc$27162$n5, 147 / 147
  promoted $abc$27162$n2040, 66 / 66
  promoted $abc$27162$n2095, 64 / 64
  promoted $abc$27162$n2030, 52 / 53
  promoted $abc$27162$n2028, 59 / 59
  promoted $abc$27162$n3, 31 / 31
  promoted 8 nets

have to figure that out now ...

emard commented 5 years ago

note: no set_io constraints for pins btn[0..6]' note: no set_io constraints for pinwifi_gpio0'

what are you trying to compile? wifi_gpio0 is board specific for ULX3S and I guess it has no sense to be tried on picorv32 Just remove it

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

Had some time to give it a try. Installed the fpgarduino toolchain successfully using the boards-manager method. Now the newest arachne-pnr refuses to route:

$ make
arachne-pnr -d 8k -P tq144:4k -o top.asc -p demo.pcf top.blif
seed: 1
device: 8k
read_chipdb +/share/arachne-pnr/chipdb-8k.bin...
  supported packages: bg121, bg121:4k, cb132, cb132:4k, cm121, cm121:4k,
cm225, cm225:4k, cm81, cm81:4k, ct256, tq144:4k
read_blif top.blif...
prune...
read_pcf demo.pcf...
note: no set_io constraints for pins `btn[0..6]'
note: no set_io constraints for pin `wifi_gpio0'
demo.pcf:32: fatal error: Missing 8 set_io constraints
make: *** [top.asc] Error 1

where the older one just did this:

promote_globals...
  promoted clk_25mhz$2, 811 / 811
  promoted $abc$27162$n7, 287 / 287
  promoted $abc$27162$n5, 147 / 147
  promoted $abc$27162$n2040, 66 / 66
  promoted $abc$27162$n2095, 64 / 64
  promoted $abc$27162$n2030, 52 / 53
  promoted $abc$27162$n2028, 59 / 59
  promoted $abc$27162$n3, 31 / 31
  promoted 8 nets

have to figure that out now ...

-- 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-473714694

drtrigon commented 5 years ago

Still your prjtrellis-picorv32 sources.

emard commented 5 years ago

Yes yes, my sources are tested on ULX3S board that I have. ESP32 wifi will reset the board if wifi_gpio0 is held 0 too long.

otherwise you can remove/ignore it when porting to ICE40 board

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

Still your prjtrellis-picorv32 sources.

-- 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-473819812

drtrigon commented 5 years ago

So I did this to your top.v:

module top(
    input clk_25mhz,
//    input [6:0] btn,
    output [7:0] led,
    output ftdi_rxd,
    input ftdi_txd,
//    output wifi_gpio0
);

//assign wifi_gpio0 = btn[0]; // hold btn0 -> escape to ESP32/OLED control

attosoc soc(
    .clk(clk_25mhz),
//    .reset_n(btn[0]),
    .reset_n(reset_n),
    .led(led),
    .uart_tx(ftdi_rxd),
    .uart_rx(ftdi_txd)
);

endmodule

This synthesizes now - I'll report back after testing...

Basically I just want to get fpgarduino to run on Alhambra. Meanwhile I installed the icestorm toolchain including vhdl support and fpgarduino as you mentioned. So if It would be more useful to test the f32c sources tell me how to do.

emard commented 5 years ago

HI

Yes your changes seem ok to me!

As far as I'm informed, open source tools don't have yet sufficiently advanced VHDL support to compile f32c out of the box. Best results are done with vhdl2vl converter, but it is not good enough for f32c as packages and functions are not supported.

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

So I did this to your top.v:

module top(
    input clk_25mhz,
//    input [6:0] btn,
    output [7:0] led,
    output ftdi_rxd,
    input ftdi_txd,
//    output wifi_gpio0
);

//assign wifi_gpio0 = btn[0]; // hold btn0 -> escape to ESP32/OLED control

attosoc soc(
    .clk(clk_25mhz),
//    .reset_n(btn[0]),
    .reset_n(reset_n),
    .led(led),
    .uart_tx(ftdi_rxd),
    .uart_rx(ftdi_txd)
);

endmodule

This synthesizes now - I'll report back after testing...

Basically I just want to get fpgarduino to run on Alhambra. Meanwhile I installed the icestorm toolchain including vhdl support and fpgarduino as you mentioned. So if It would be more useful to test the f32c sources tell me how to do.

-- 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-473835214

drtrigon commented 5 years ago

@q3k reported success with f32c and Yosys+Verific (for VHDL support).

So I think I'm giving up on this... Now with the new 2 toolchains (recent icestorm and fpgarduino via boards-manager) I am again further away than I was before. It synthesises but that's all. The LED do not light up, no rv32> prompt anymore... To me it looks like either there is still something wrong with (a) the verilog code, (b) my toolchain has issues or (c) I am just doing very stupid stuff. I am quite sure it is not (b) and as for (a) and (c) I tried my best. As others report they can make it work (@q3k, @uXeBoy, @emard) it is most probably (c). So I'll have to wait until somebody figures out how to get fpgarduino work on Alhambra II and write a fool-prove how to. A pitty as I think icestudio and fpgarduino could really profit and boost each other. My goal would have been a f32c core that can be modified from icestudio (e.g. pin assignments, peripherals, etc.) and at the same time be programmed from arduino ide. What a dream... (I really hate it to give up in such things!)

emard commented 5 years ago

I wish that is really true, given the wide ICE40 community there should be many capable developers able to recompile my my bootloader for ICE40. I suggest you leave that job for them.

Until this I can only recommend you ULX3S for f32c contact Goran at http://radiona.org/ulx3s to get your ULX3S board

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

@q3k reported success with f32c and Yosys+Verific (for VHDL support).

So I think I'm giving up on this... Now with the new 2 toolchains (recent icestorm and fpgarduino via boards-manager) I am again further away than I was before. It synthesises but that's all. The LED do not light up, no rv32> prompt anymore... To me it looks like either there is still something wrong with (a) the verilog code, (b) my toolchain has issues or (c) I am just doing very stupid stuff. I am quite sure it is not (b) and as for (a) and (c) I tried my best. As others report they can make it work (@q3k, @uXeBoy, @emard) it is most probably (c). So I'll have to wait until somebody figures out how to get fpgarduino work on Alhambra II and write a fool-prove how to. A pitty as I think icestudio and fpgarduino could really profit and boost each other. My goal would have been a f32c core that can be modified from icestudio (e.g. pin assignments, peripherals, etc.) and at the same time be programmed from arduino ide. What a dream...

-- 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-473860377

drtrigon commented 5 years ago

A (last) thought; as mentioned in the very first post I actually do already have a working picorv implementation. Do you have an idea how hard it is to make your firmware.c run on it? As I understand this should do the trick and work with fpgarduino, correct?

emard commented 5 years ago

Of course!

If you already have working picorv32 with serial port on 115200 just change firmware.hex and run it, it's as simple as that.

when you see prompt rv32> then go to fpgarduino and try to upload some examples etc.

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

A (last) thought; as mentioned in the very first post I actually do already have a working picorv implementation. Do you have an idea how hard it is to make your firmware.c run on it? As I understand this should do the trick and work with fpgarduino, correct?

-- 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-474050992

drtrigon commented 5 years ago

Ok. Used my picorv examples together with your firmware.c. Got the rv32> prompt went to Arduino IDE and uploaded the example blinky you provided with your picorv. Upload works! :+1: :))

The example however does not blink yet which is caused by a mismatch in memory mappings. My picorv32 uses:

#define reg_spictrl (*(volatile uint32_t*)0x02000000)
#define reg_uart_clkdiv (*(volatile uint32_t*)0x02000004)
#define reg_uart_data (*(volatile uint32_t*)0x02000008)
#define reg_leds (*(volatile uint32_t*)0x03000000)

which conflicts or mismatches with

#define LED (*(volatile uint32_t*)0x02000000)

in your Blinky example. Can I just change it in your firmware.c and Blinky examples or does this cause further issues?

emard commented 5 years ago

Congratulations, you have succeeded to compile and get prompt.

There are no issues, just change LED addresses to match your memory mapping so you probably just need to replace 2->3 change

define LED ((volatile uint32_t)0x02000000)

to

define LED ((volatile uint32_t)0x03000000)

recompile and upload, does it blink now?

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

Ok. Used my picorv examples together with your firmware.c. Got the rv32> prompt went to Arduino IDE and uploaded the example blinky you provided with your picorv. Upload works! :+1: :))

The example however does not blink yet which is caused by a mismatch in memory mappings. My picorv32 uses:

#define reg_spictrl (*(volatile uint32_t*)0x02000000)
#define reg_uart_clkdiv (*(volatile uint32_t*)0x02000004)
#define reg_uart_data (*(volatile uint32_t*)0x02000008)
#define reg_leds (*(volatile uint32_t*)0x03000000)

which conflicts or mismatches with

#define LED (*(volatile uint32_t*)0x02000000)

in your Blinky example. Can I just change it in your firmware.c and Blinky examples or does this cause further issues?

-- 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-474082989

drtrigon commented 5 years ago

I changed it in your firmware.c and the blinky example. The change in the firmware.c makes all led going on during start, upload still works. Changing it in the blinky example does not help the example does nothing. I have the impression it does not run at all. Any chance that the start vector is set wrong?

emard commented 5 years ago

yes probably, use any fpgarduino board in BRAM mode or the generic and depending on your compiled bootloader size it could be larger than 1K so you have to select start vector past the bootloader now it is 0x400 and it will overwrite itself before having a chance to survive so use start address or 0x800 by editing boards.txt

for example of your bootloader is longer than 1K but shorter than 2K then use generic board selected as having ramsize 8K BRAM replace fpga_generic.menu.ramsize.8.compiler.ld.extra_flags=--section-start=.init=0x400 with fpga_generic.menu.ramsize.8.compiler.ld.extra_flags=--section-start=.init=0x800

in the future, Bootloader can be hand-optimized with assembly parts to become shorter than 1K

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

I changed it in your firmware.c and the blinky example. The change in the firmware.c makes all led going on during start, upload still works. Changing it in the blinky example does not help the example does nothing. I have the impression it does not run at all. Any chance that the start vector is set wrong?

-- 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-474086089

drtrigon commented 5 years ago

firmware.bin is 1020 bytes. What else could it be?

drtrigon commented 5 years ago

Have to stop for now. Don't know what happens, but just recognized that it outputs 0xff over serial all the time. Any idea and help is welcome...

drtrigon commented 5 years ago

May be my sections.lds is causing the issue, it starts like:

MEMORY
{
    FLASH (rx)      : ORIGIN = 0x00100000, LENGTH = 0x400000 /* entire flash, 4 MiB */
    RAM (xrw)       : ORIGIN = 0x00000000, LENGTH = 0x000400 /* 1 KB */
}
emard commented 5 years ago

bootloader size is <1K, that's OK then

Have you tried my blinkled example with changed adress 300000 source from my prjtrellis-picorv32 example?

have you selected generic board 8K? Does -DF32C=0 appear in compiler logs?

one important fact to check is that your picorv32 mapped RAM with firmware.c starts at address 0x0 and that this firmware is read/writeable (not read-only ROM).

If you have ram at different address you can change it in boards.txt replacing 0x400 with something else

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

firmware.bin is 1020 bytes. What else could it be?

-- 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-474093619

emard commented 5 years ago

I'm not expert at picorv32 but let's speculate that bootloader firmware is running off flash and 1K of RAM is mapped at 0x0 and that picorv32 can JUMP to RAM and execute. Not all CPUs SOCs can do so, sometimes RAM is only for data and flash is only for instructions, this setup is not useable by fpgarduino.

In case it can jump to RAM then: Im not sure will it work but you can try:

fpga_generic.menu.ramsize.8.compiler.ld.extra_flags=--section-start=.init=0x0

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

bootloader size is <1K, that's OK then

Have you tried my blinkled example with changed adress 300000 source from my prjtrellis-picorv32 example?

have you selected generic board 8K? Does -DF32C=0 appear in compiler logs?

one important fact to check is that your picorv32 mapped RAM with firmware.c starts at address 0x0 and that this firmware is read/writeable (not read-only ROM).

If you have ram at different address you can change it in boards.txt replacing 0x400 with something else

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

firmware.bin is 1020 bytes. What else could it be?

-- 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-474093619

emard commented 5 years ago

we have additional "problem" as this ram size is probably too small average blinkled could be larger than 1K, you may need to increase this RAM length in SOC if possible

MEMORY { FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x400000 / entire flash, 4 MiB / RAM (xrw) : ORIGIN = 0x00000000, LENGTH = 0x000400 / 1 KB / }

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

I'm not expert at picorv32 but let's speculate that bootloader firmware is running off flash and 1K of RAM is mapped at 0x0 and that picorv32 can JUMP to RAM and execute. Not all CPUs SOCs can do so, sometimes RAM is only for data and flash is only for instructions, this setup is not useable by fpgarduino.

In case it can jump to RAM then: Im not sure will it work but you can try:

fpga_generic.menu.ramsize.8.compiler.ld.extra_flags=--section-start=.init=0x0

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

bootloader size is <1K, that's OK then

Have you tried my blinkled example with changed adress 300000 source from my prjtrellis-picorv32 example?

have you selected generic board 8K? Does -DF32C=0 appear in compiler logs?

one important fact to check is that your picorv32 mapped RAM with firmware.c starts at address 0x0 and that this firmware is read/writeable (not read-only ROM).

If you have ram at different address you can change it in boards.txt replacing 0x400 with something else

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

firmware.bin is 1020 bytes. What else could it be?

-- 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-474093619

drtrigon commented 5 years ago

I will again look into this as soon as I have time. I think we are quite close now, just the mem mapping. Some of your suggetion have be checked alteady (select 8K board, F32C flag, ) - except the mapping, so I think/hope its that. Btw some info about the core I use - may be helpful: https://github.com/cliffordwolf/picorv32/blob/master/README.md (however not too much about mapping) The increased RAM mapping you posted has no changes...

emard commented 5 years ago

The core itself is OK, just we need to know particular configuration address of RAM, size of RAM and can CPU execute code from the RAM

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

I will again look into this as soon as I have time. I think we are quite close now, just the mem mapping. Some of your suggetion habe be checked alteady (select 8K board, F32C flag, ) - except the mapping, so I think/hope its that. Btw some info about the core I use - may be helpful: https://github.com/cliffordwolf/picorv32/blob/master/README.md (however not too much aboutmapping)

-- 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-474221793

drtrigon commented 5 years ago

I can follow your speculations and they seem reasonable to me. I just checked, the compiled blinky is 200 bytes - so that's fine. I tested with --section-start=.init=0x0 but no change. I can confirm that firmware is in flash as the command to upload it is $(ICESTORM)/iceprog -o 1M $(FIRMWARE).bin so to a offset of 1M - thus that must be flash. May be https://github.com/cliffordwolf/picorv32/tree/master/picosoc answers most of the questions: "The flash is mapped to the memory regions starting at 0x00000000 and 0x01000000, with the SRAM overlayed for the mapping at 0x00000000. The SRAM is just a small scratchpad memory (default 256 words, i.e. 1 kB). The reset vector is set to 0x00100000, i.e. at 1MB into in the flash memory." If not, a look into the source could help: https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc .

edit: Just came to my mind... what about this in firmware.c - might this be our issue:

//          "li s0, 0x00008000;"    /* 32K RAM top = stack address */
            "li s0, 0x00002000;"    /* 8K RAM top = stack address */
emard commented 5 years ago

We need picorv32 expert now. I'm not sure can thic picorv32 jump to code in RAM from 0x0

This system setup is different than my ECP5 where bootloader is in BRAM, size 32K I think.

Maybe we can do a trick to test: Upload blink.ino.bin using ICE40 flashing tool to some higher flash address not to touch bootloader, say 0x200000 and set same adress .init=0x200000 then try to "upload" blink. It will upload over ROM flash (actually nothing will happen) and jump to the code which is already there! if that blinks and 0x0 doesn't blink then we know, picorv32 on ice40 is not configured that it can execute from RAM

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

I can follow your speculations and they seem reasonable to me. I just checked, the compiled blinky is 200 bytes - so that's fine. I tested with --section-start=.init=0x0 but no change. I can confirm that firmware is in flash as the command to upload it is $(ICESTORM)/iceprog -o 1M $(FIRMWARE).bin so to a offset of 1M - thus that must be flash. May be https://github.com/cliffordwolf/picorv32/tree/master/picosoc answers most of the questions: "The flash is mapped to the memory regions starting at 0x00000000 and 0x01000000, with the SRAM overlayed for the mapping at 0x00000000. The SRAM is just a small scratchpad memory (default 256 words, i.e. 1 kB). The reset vector is set to 0x00100000, i.e. at 1MB into in the flash memory." If not, a look into the source could help: https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc .

-- 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-474536634