$ iverilog -Wall picorv32.v
picorv32.v:1298: warning: @* is sensitive to all 32 words in array 'cpuregs'.
picorv32.v:1299: warning: @* is sensitive to all 32 words in array 'cpuregs'.
picorv32.v:1298: warning: @* is sensitive to all 32 words in array 'cpuregs'.
picorv32.v:1299: warning: @* is sensitive to all 32 words in array 'cpuregs'.
Quartus complains thus:
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(301)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(372)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1080)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1210)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1210)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1227)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1227)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1268)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1398)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1398)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1410)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1496)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1540)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1540)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1648)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1679)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1749)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1749)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1757)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1757)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1772)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1772)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1797)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1797)
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(1814)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(1814)
Info (12021): Found 7 design units, including 7 entities, in source file rtl/picorv32.v
Info (12023): Found entity 1: picorv32
Info (12023): Found entity 2: picorv32_pcpi_mul
Info (12023): Found entity 3: picorv32_pcpi_fast_mul
Info (12023): Found entity 4: picorv32_pcpi_div
Info (12023): Found entity 5: picorv32_axi
Info (12023): Found entity 6: picorv32_axi_adapter
Info (12023): Found entity 7: picorv32_wb
Info (12021): Found 1 design units, including 1 entities, in source file rtl/memory.v
Info (12023): Found entity 1: memory
Info (12021): Found 1 design units, including 1 entities, in source file rtl/gpio.v
Info (12023): Found entity 1: gpio
Info (12021): Found 1 design units, including 1 entities, in source file rtl/address_decoder.v
Info (12023): Found entity 1: address_decoder
Info (12127): Elaborating entity "xoro_top" for the top level hierarchy
Warning (10858): Verilog HDL warning at xoro_top.v(50): object CLOCK_100_SHIFTED used but never assigned
Warning (10858): Verilog HDL warning at xoro_top.v(51): object CLOCK_10 used but never assigned
Warning (10858): Verilog HDL warning at xoro_top.v(52): object CLOCK_LOCKED used but never assigned
Warning (10230): Verilog HDL assignment warning at xoro_top.v(56): truncated value with size 32 to match size of target (8)
Warning (10030): Net "pcpi_rd" at xoro_top.v(31) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "irq" at xoro_top.v(36) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_wr" at xoro_top.v(30) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_wait" at xoro_top.v(32) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_ready" at xoro_top.v(33) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "CLOCK_100_SHIFTED" at xoro_top.v(50) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "CLOCK_10" at xoro_top.v(51) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "CLOCK_LOCKED" at xoro_top.v(52) has no driver or initial value, using a default initial value '0'
Info (12128): Elaborating entity "memory" for hierarchy "memory:mem"
Info (12128): Elaborating entity "gpio" for hierarchy "gpio:gpio"
Warning (10230): Verilog HDL assignment warning at gpio.v(46): truncated value with size 32 to match size of target (8)
Info (12128): Elaborating entity "prng" for hierarchy "prng:prng"
Warning (10230): Verilog HDL assignment warning at prng.v(42): truncated value with size 64 to match size of target (1)
Info (12128): Elaborating entity "xoroshiro128plus" for hierarchy "prng:prng|xoroshiro128plus:prng"
...
...
...
Those warnings are typical. Synthesizers will notice things that simulators won't. e.g. those pragmas parallel_case and full_case are comments are far as a simulator is concerned. It's good to understand these - if there are any in your code that you can't figure out let me know and I'll take a look.
I know it's not your code, but there are papers about the dangers of those pragmas:
Warning (10335): Unrecognized synthesis attribute "parallel_case" at rtl/picorv32.v(301)
Warning (10335): Unrecognized synthesis attribute "full_case" at rtl/picorv32.v(372)
Warning (10030): Net "pcpi_rd" at xoro_top.v(31) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "irq" at xoro_top.v(36) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_wr" at xoro_top.v(30) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_wait" at xoro_top.v(32) has no driver or initial value, using a default initial value '0'
Warning (10030): Net "pcpi_ready" at xoro_top.v(33) has no driver or initial value, using a default initial value '0'
Lattice seems fine with synthesis attribute "parallel_case" - I think he targets a Lattice variant like HX8X ?
but does give these warnings around those Nets
@W: CL279 :"C:\Lattice\PicoRV\picorv32.v":826:1:826:6|Pruning register bits 31 to 21 of decoded_imm_uj[31:1]. If this is not the intended behavior, drive the inputs with valid values, or inputs from the top level.
@N: CL159 :"C:\Lattice\PicoRV\picorv32.v":101:19:101:25|Input pcpi_wr is unused.
@N: CL159 :"C:\Lattice\PicoRV\picorv32.v":102:19:102:25|Input pcpi_rd is unused.
@N: CL159 :"C:\Lattice\PicoRV\picorv32.v":103:19:103:27|Input pcpi_wait is unused.
@N: CL159 :"C:\Lattice\PicoRV\picorv32.v":104:19:104:28|Input pcpi_ready is unused.
@N: CL159 :"C:\Lattice\PicoRV\picorv32.v":107:19:107:21|Input irq is unused.
This is a cheapy RIGOL DS1054Z 50MHz 1GSa/s scope.
But I hacked it to unlock 100MHz bandwidth and all the options it has in it's firmware.
Below are the notes I made about my RIGOL hacking. The unlocking part starts at "Unlock procedure:" Of course the id's and keys I have there are specific to my scope. Pursue at you own risk. A google search will reveal hacking procedures for other Rigol scopes.
Rigol DS1054Z Hacking
---------------------
My scopes identity (Before unlock):
RIGOL TECHNOLOGIES,DS1054Z,DS1ZA180501319,00.04.03.SP2
Links:
Latest firmware:
http://int.rigol.com/File/ProductSoftWare/20160914/DS1000Z(ARM)update.rar
or perhaps try here:
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0
S/W Version 00.04.04.01.01
Board Version 0.1.1
Boot 0.0.1.2
F/W Version 0.2.3.11
CPLD 1.1
Scope control and visualize for Linux:
http://www.teuniz.net/DSRemote/
and:
http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/screenshots.htm
Unlock video:
https://www.youtube.com/watch?v=AnxOGl27GjE
Latest Rigol Firmware:
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0
EEVBlog New Rigol DS1054Z oscilloscope
http://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/
EEVBlog Telnet unlocking and other commands:
http://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1028052/#msg1028052
http://www.eevblog.com/forum/testgear/is-ds1054z-with-firmware-00-04-02-04-07-hackable/msg715684/#msg715684
gotroot online RIGOL privatekey generator:
http://gotroot.ca/rigol/riglol/
Rigol privatekey generator archive
http://gotroot.ca/rigol/riglol/riglol.zip
Telnet command manual
http://int.rigol.com/File/TechDoc/20151218/MSO1000Z&DS1000Z_ProgrammingGuide_EN.pdf
Note: Do use socket.setNoDelay(true) for high speed.
Telnet to your Rigol
--------------------
Be sure the scope has a LAN connection and can get an address from a DHCP server.
Go to your instrument front panel. Press button for System or Utility - you will see I/O or LAN menu
buttons: these allow you to see the IP address given to your instrument
The telnet to the scope on port 5555 like so:
$ telnet 192.168.1.126 5555
Trying 192.168.1.126...
Connected to 192.168.1.126.
Escape character is '^]'.
*IDN?
Rigol Technologies,DS1104Z,.....
DHCP server.
Unlock procedure:
-----------------
1) Upgrade the firmware, see above
2) Fetch serial number via telnet with *IDN? command, see above
*IDN?
RIGOL TECHNOLOGIES,DS1054Z,DS1ZA180501319,00.04.03.SP2
3) Visit gotroot.ca key generator page above and enter:
Serial number: DS1ZA180501319
(A Privatekey will now show: 6F1106DDA994DA)
Otions: DSER
The unlock code will now be shown:
RDJ9JBB-N3SWWUS-VE3ELVP-4257RNA
4) Unlock scope over telnet with command:
:SYST:OPT:INST RDJ9JBBN3SWWUSVE3ELVP4257RNA
A notification should pop up on the scope briefly indicating success.
5) Check the unlock worked:
*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA180501319,00.04.03.SP2
Note: "DS1054Z" became "DS1104Z"
6) Reversing the unlock can be done with the command:
:SYST:OPT:UNINST
:SYSTem:OPTion:UNINSTall
In case the scope needs to go for repair.
To check installed options:
utility > options > installed
Should see all marked as "official"
To display the full version information:
- In the trigger area on the front panel, press MENU > MENU > FORCE > MENU <<< press this sequence very quickly
- In the menu area, press UTILITY > SYSTEM > SYSTEM INFO
Possible user names and password:
username: test
password: 111111
username: rigollan
password: 111111
The build including P&R, static timing analysis, bitstream generation, ...? What the heck are you running it on?
Sorry I missed your question earlier.
That is one minute from hitting "Start compilation" button in Quartus to getting an "xoro.sof" file that can be sent to the DE0 Nano.
I'm running this on a Microsoft Surface Pro 4. With an i5 2.5GHz processor and 8GB RAM.
Actually, I'm not sure if you are surprised that this is fast or slow!
I found that paper about the Evil Twins of Verilog Synthesis when I googled for the warnings Quartus produces. Looks like when they are noticed in synthesis they break things. Or at least what you are synthesizing is no longer the same as what you have been simulating.
Kind of worrying...I wish they were not there.
However Clifford Wolf is some kind of genius so I don't like to question what he has produced.
I wouldn't modify Clifford Wolf's Verilog for this since he probably knows what he's doing. But the author of the paper is also an expert. It may just be something along the lines of old habits die hard.
Your synthesis time just seemed amazingly fast. I'm used to much larger parts with designs that barely fit. (ASIC emulation) It would take say 4+ hours, and we had to run multiple jobs in parallel with different seeds in the hopes that we would have a good run that met timing. It's cool that you still use the simulator - maybe you can convince Chip that simulations are worth the effort. I find them far quicker to debug than FPGA builds.
The last design I played with was in a Cyclone V (DE0-Nano-SOC which is cool because it has dual ARM cores in it. Nice board but it gets surprisingly hot) and it also took a little while. I can't remember but it was definitely over a minute. It did have an HMAC IP core in it though. I ended up finding a bug in the IP core, and was able to get an update by delivering waveforms demonstrating the issue to the vendor.
An interesting tool for you to explore might be Verilog mode for emacs. It makes wiring things together really easy. Maybe not an issue for you but I know some heavy users of it. There's a way to treat it as a batch process if you don't want to hang out in emacs. https://www.veripool.org/wiki/verilog-mode
I'm going to see if I can simulate your design on a Raspberry Pi. Just for the heck of it.
Edited to add: Thanks for the scope hacking notes. I knew about the 100 MHz stuff but never bothered with it. I'll have to look into this again now that you mentioned the other capabilities.
Heater - maybe I'll figure this out shortly, but what do you do to build a simulation? When I try "make test" then I get "make: *** No rule to make target 'testbench.v', needed by 'testbench.vvp'. Stop."
Also did you update iverilog due to this statement in the picorv32 github?
Note: The test bench is using Icarus Verilog. However, Icarus Verilog 0.9.7 (the latest release at the time of writing) has a few bugs that prevent the test bench from running. Upgrade to the latest github master of Icarus Verilog to run the test bench.
Edited to add:
Another script of potential interest (if it works on these designs - e.g. doesn't get confused by the code):
I started trying to build this on my own, and found an extraneous semicolon on line 53 of uartTx.v - this confuses iverilog. Maybe some updates didn't make it into github? (I've never used it before, but I guess I'll try to learn how to push things soon...)
48 end else begin
49 if (mem_valid & enable) begin
50 if ((mem_wstrb[0] == 1) && (bufferEmpty == 1)) begin
51 buffer <= mem_wdata;
52 bufferEmpty <= 0;
53 end;
If I run a script like the following from a subdirectory with iverilog 0.9.7 then I have some issues with those previously mentioned pragmas in pcirv32.v. Maybe I need to update iverilog or set some additional command line options?
I am using Icarus version version 11.0. I built it from source. Clifford says somewhere that
some recent version is required.
Sorry the Makefile is a mess. I just copied Clifford's and started hacking to my liking. Probably
nothing works except:
make firmware/firmware.hex
I have been running all the test benches directly from the command line. The commands get stuck in my BASH history so I never got around to putting them in the Makefile.
The top level "xoro_top_tb.v" produces a ton of output which is probably meaningless unless you
know what the firmware it is running looks like:
I'll have a look at that semi-colon. Looks like I have some tidying up to do in the project...
Nooo...I'm not going anywhere near emacs. I found the Atom editor has great Verilog syntax
highlighting and uses icarus for linting. It does something of a job for auto-completion as well.
Thanks for the "x" link Chip. So much to learn here....
By the way. Is my tri-state bus between CPU and peripherals a sensible thing?
The only other thing I could think to do is use a ton of mux's but that seems rather wasteful.
I should probably be using a standardized bus like the Wishbone spec. but that is over complicating things for me right now.
I think tri-state busses are never actually implemented in ASIC's. Instead, everything is built from driven logic, since there can be no contention that way. I usually build AND-OR busses when I need to bring things together. See 'jump9':
This AND-OR mux can be done with busses, as well as single bits. I like it better than a priority mux made from ternary operators, or a mux that uses indexing, because it allows the tools more freedom to prioritize higher-latency signals. You just have to be sure that all your AND cases are exclusive.
Oh yeah, David, sounds like you are all fired up to do some FPGA hacking. Go for it.
I'm wondering how to integrate Chip's P1 verilog into this....
I need to spend some more time trying to get Icarus Verilog working on my Mac. I made an attempt but it seems I need to install one of the non-Apple package managers to get it to work and the last time I did that I ended up in a mess. Maybe I should just run iverilog under Linux. Or maybe I'll get a Surface Pro 4 like you have! :-)
There are instructions in the repo for building on Mac.
Oh, yeah, go for the Pro. Mine is doing a decent enough job pretending to be Linux. What with Cygwin and the Linux Subsystem for Windows.
Oddly I could not build the GCC for RISC V with either of those. Cygwin seems to not have recent enough libs or something. The Linux Subsystem for Windows just hangs at some point during the build. On the other hand it does run the riscv tool chain I built on my Debian PC.
...seems I need to install one of the non-Apple package managers...
You mean like git?
No, I have git installed. I tried to build from sources but needed some other packages that require me to install something like Brew or MacPorts. I've had trouble with both in the past and would rather not go that route.
There are instructions in the repo for building on Mac.
Oh, yeah, go for the Pro. Mine is doing a decent enough job pretending to be Linux. What with Cygwin and the Linux Subsystem for Windows.
Oddly I could not build the GCC for RISC V with either of those. Cygwin seems to not have recent enough libs or something. The Linux Subsystem for Windows just hangs at some point during the build. On the other hand it does run the riscv tool chain I built on my Debian PC.
Have you tried VirtualBox on your Pro? Also, how usable is the SD card? Can you put your source files on it and do builds and edits there or do you really need to have often accessed stuff on the internal flash drive?
>By the way. Is my tri-state bus between CPU and peripherals a sensible thing?
It used to be more common for designs to use tristate logic, but I don't think it's common any more. It could cause difficulty in static timing analysis, you can't buffer long wires as easily, you need to worry about bus contention (even in test modes),...
If I remember correctly the move generation logic in DeepBlue (chess ASIC) used tristate logic to find the Most Valuable Victim - Least Valuable Aggressor. It's been a while since I looked at that.
>I have been running all the test benches directly from the command line. The commands get stuck in my BASH history so I never got around to putting them in the Makefile.
Can you paste the command that you're using? Not sure if what I pasted is equivalent.
You can run emacs as a batch process to get verilog mode for emacs so you never need to suffer. It's quite useful - if I'm motivated then I'll try to get it going. There are some presentations that show what it can do here - https://www.veripool.org/projects/verilog-mode/wiki/Documentation
Things are looking better with the development version of icarus. (I used the command that a pasted a few posts above.) I just did a "git clone https://github.com/steveicarus/iverilog". Is that what you did, or were you more specific in requesting a particular revision?
Now to get the RISC V firmware build going so something interesting happens.
Cool! I just found instructions for installing autotools on the Mac and that let me build iverilog. Do you have a github repository with your RISC-V work? It would be fun to try it.
Comments
The build including P&R, static timing analysis, bitstream generation, ...? What the heck are you running it on?
Icarus complains thus: Quartus complains thus:
I know it's not your code, but there are papers about the dangers of those pragmas:
http://www.sunburst-design.com/papers/
"full_case parallel_case", the Evil Twins of Verilog Synthesis
Lattice seems fine with synthesis attribute "parallel_case" - I think he targets a Lattice variant like HX8X ?
but does give these warnings around those Nets
http://quartushelp.altera.com/15.0/mergedProjects/hdl/vlog/vlog_file_dir.htm
This is a cheapy RIGOL DS1054Z 50MHz 1GSa/s scope.
But I hacked it to unlock 100MHz bandwidth and all the options it has in it's firmware.
Below are the notes I made about my RIGOL hacking. The unlocking part starts at "Unlock procedure:" Of course the id's and keys I have there are specific to my scope. Pursue at you own risk. A google search will reveal hacking procedures for other Rigol scopes.
That is one minute from hitting "Start compilation" button in Quartus to getting an "xoro.sof" file that can be sent to the DE0 Nano.
I'm running this on a Microsoft Surface Pro 4. With an i5 2.5GHz processor and 8GB RAM.
Actually, I'm not sure if you are surprised that this is fast or slow!
I found that paper about the Evil Twins of Verilog Synthesis when I googled for the warnings Quartus produces. Looks like when they are noticed in synthesis they break things. Or at least what you are synthesizing is no longer the same as what you have been simulating.
Kind of worrying...I wish they were not there.
However Clifford Wolf is some kind of genius so I don't like to question what he has produced.
http://infocenter.arm.com/help/topic/com.arm.doc.arp0009a/Verilog_X_Bugs.pdf
Your synthesis time just seemed amazingly fast. I'm used to much larger parts with designs that barely fit. (ASIC emulation) It would take say 4+ hours, and we had to run multiple jobs in parallel with different seeds in the hopes that we would have a good run that met timing. It's cool that you still use the simulator - maybe you can convince Chip that simulations are worth the effort. I find them far quicker to debug than FPGA builds.
The last design I played with was in a Cyclone V (DE0-Nano-SOC which is cool because it has dual ARM cores in it. Nice board but it gets surprisingly hot) and it also took a little while. I can't remember but it was definitely over a minute. It did have an HMAC IP core in it though. I ended up finding a bug in the IP core, and was able to get an update by delivering waveforms demonstrating the issue to the vendor.
An interesting tool for you to explore might be Verilog mode for emacs. It makes wiring things together really easy. Maybe not an issue for you but I know some heavy users of it. There's a way to treat it as a batch process if you don't want to hang out in emacs. https://www.veripool.org/wiki/verilog-mode
I'm going to see if I can simulate your design on a Raspberry Pi. Just for the heck of it.
Edited to add: Thanks for the scope hacking notes. I knew about the 100 MHz stuff but never bothered with it. I'll have to look into this again now that you mentioned the other capabilities.
Also did you update iverilog due to this statement in the picorv32 github?
Edited to add:
Another script of potential interest (if it works on these designs - e.g. doesn't get confused by the code):
http://www.burbleland.com/v2html/v2html.html
It lets you browse around the design. (Verdi can do this sort of thing better)
I am using Icarus version version 11.0. I built it from source. Clifford says somewhere that
some recent version is required.
Sorry the Makefile is a mess. I just copied Clifford's and started hacking to my liking. Probably
nothing works except: I have been running all the test benches directly from the command line. The commands get stuck in my BASH history so I never got around to putting them in the Makefile.
The top level "xoro_top_tb.v" produces a ton of output which is probably meaningless unless you
know what the firmware it is running looks like: and can then trace it through.
I'll have a look at that semi-colon. Looks like I have some tidying up to do in the project...
Nooo...I'm not going anywhere near emacs. I found the Atom editor has great Verilog syntax
highlighting and uses icarus for linting. It does something of a job for auto-completion as well.
By the way. Is my tri-state bus between CPU and peripherals a sensible thing?
The only other thing I could think to do is use a ton of mux's but that seems rather wasteful.
I should probably be using a standardized bus like the Wishbone spec. but that is over complicating things for me right now.
I think tri-state busses are never actually implemented in ASIC's. Instead, everything is built from driven logic, since there can be no contention that way. I usually build AND-OR busses when I need to bring things together. See 'jump9':
This AND-OR mux can be done with busses, as well as single bits. I like it better than a priority mux made from ternary operators, or a mux that uses indexing, because it allows the tools more freedom to prioritize higher-latency signals. You just have to be sure that all your AND cases are exclusive.
I was wondering about that contention issue. I could not imagine they would actually allow multiple outputs to drive a wire in the FPGA or ASIC.
I notice Quartus puts a TRI-BUS block in the circuit for all my tri-state connections. Whatever that does.
git clone git://github.com/steveicarus/iverilog.git
There are instructions in the repo for building on Mac.
Oh, yeah, go for the Pro. Mine is doing a decent enough job pretending to be Linux. What with Cygwin and the Linux Subsystem for Windows.
Oddly I could not build the GCC for RISC V with either of those. Cygwin seems to not have recent enough libs or something. The Linux Subsystem for Windows just hangs at some point during the build. On the other hand it does run the riscv tool chain I built on my Debian PC.
Never really played with the SD card. In have no idea if it's speedy enough to be comfortable.
It used to be more common for designs to use tristate logic, but I don't think it's common any more. It could cause difficulty in static timing analysis, you can't buffer long wires as easily, you need to worry about bus contention (even in test modes),...
If I remember correctly the move generation logic in DeepBlue (chess ASIC) used tristate logic to find the Most Valuable Victim - Least Valuable Aggressor. It's been a while since I looked at that.
Can you paste the command that you're using? Not sure if what I pasted is equivalent.
You can run emacs as a batch process to get verilog mode for emacs so you never need to suffer. It's quite useful - if I'm motivated then I'll try to get it going. There are some presentations that show what it can do here - https://www.veripool.org/projects/verilog-mode/wiki/Documentation
I'll try and remember to give it a go. See if it uses more or less logic elements.
Thanks.
Now to get the RISC V firmware build going so something interesting happens.
Is there a git guide for dumb cvs/svn users?
My icarus is whatever you get when you "git clone" from the repo.
The risc v tools were installed following Clifford Wolf's instruction on his picorv32 github repo's README file.