<tpb>
Title: ecp5: Fix placement of DCCs to guarantee routeability by daveshah1 · Pull Request #454 · YosysHQ/nextpnr · GitHub (at github.com)
vidbina has quit [Ping timeout: 264 seconds]
llee454 has joined #yosys
<llee454>
Good morning. Is anyone free to answer a question I have about using Yosys to generate BLIF files for arachne-pnr? I'm getting the following error from arachne: "kami32.blif:11: fatal error: invalid .names entry: both gates must be 1 here"
<daveshah>
How are you generating the BLIF?
<llee454>
I used the interactive shell to enter the following sequence of commands: read_verilog "kami32.v"; hierarchy -check -top _design; proc; memory; techmap; abc; write_blif "kami.blif"
<llee454>
Also thanks for offering to help.
<daveshah>
you need to use synth_ice40
<daveshah>
arachne-pnr doesn't support generic primitives, it places and routes for iCE40 so needs the iCE40 specific primitives
<daveshah>
which gives some extra arguments to write_blif to make it arachne-pnr compatibke
<daveshah>
*compatible
<llee454>
Thanks daveshah I'm going to try this now.
craigo has quit [Quit: Leaving]
kraiskil has quit [Ping timeout: 256 seconds]
az0re has joined #yosys
<llee454>
daveshah, I tried to run "synth_ice40," but ran out of RAM during the peepopt pass. I then copied the commands listed here (http://www.clifford.at/yosys/cmd_synth_ice40.html) into a script file, commented out the peepopt pass, and ran the script. This generated a blif file. But, arachne-pnr returned the following error message for it:
<llee454>
"kami32.blif:88146: fatal error: unknown model `$__ICE40_CARRY_WRAPPER'" Any ideas?
<tpb>
Title: Yosys Open SYnthesis Suite :: Command Reference :: synth_ice40 (at www.clifford.at)
<daveshah>
There shouldn't be $__ICE40_CARRY_WRAPPERs in the output but this is possibly an issue with whiteboxes
<daveshah>
The running out of RAM issue is probably more serious, assuming your system has a reasonable amount of free RAM
<daveshah>
the `only if relut` comment might be out of date, try re-enabling ice40_unlut
<llee454>
yosys was consuming 14GB when it died running peepopt. Is this normal for a large design?
<llee454>
ok
<daveshah>
not for any design that fits on an iCE40 or ECP5
<daveshah>
(for perspective, a Rocket design that maxes out a Versa peaks at around 1GB)
<whitequark>
do you maybe have a RAM that got legalized into FFs?
<ZipCPU>
Or some multiplies that didn't get placed into DSPs?
<llee454>
rerunning with "ice40_unlut; opt_lut -dlogic SB_CARRY:I0=1:I1=2:CI=3"
<tnt>
Yeah, non-inferred bram would be my guess.
<ZipCPU>
It might also help to run on the yosys on the various components of your design. Chances are there's one component that's using way too many resources
<ZipCPU>
Just doing that component would likely fit in memory
<llee454>
I see.
<daveshah>
If other commands run fine, then it isn't a design problem but a peepopt problem
<llee454>
I will try to run yosys on the various components and see how much RAM it consumes.
<llee454>
daveshah the other commands appear to run fine.
<mwk>
llee454: I'd be interested in having a look at that design
kraiskil has joined #yosys
<llee454>
The documentation for the synth_ice40 pass is out of date. The documentation says that the pass calls ice40_unlut, but ice40_unlut no longer exists. There is a pass named "ice40_wrapcarry" however. The shell documentation says that this pass accepts a flag named "-unwrap," which looks like it might resolve the error returned by Arachne. I'm
<llee454>
recommenting out the ice40_unlut pass and adding a call to wrapcarry.
<llee454>
@mwk sure. One moment.
<mwk>
llee454: FWIW for a current list of commands executed by the pass, you can always run yosys -p 'help synth_ice40'
<mwk>
this applies to most yosys script passes
<llee454>
@mwk thanks. I see that this includes a call to unwrap. I will use that and comment out peepopt.
<mwk>
... would be nice to know which of the three peepopt sub-passes causes the problem
<mwk>
but uh, seems we don't even have a way at the moment to execute a subset of thoser
<ross_s>
daveshah: thanks for following up, I just re-broke my design and verified that it failed to route on my current version / succeeds to route on nextpnr master, so patch seems good!
<llee454>
@mwk note: that the verilog is generated by compiling a model written in Kami. The Kami model is divided into a set of files in the ProcKami directory. Somewhat confusingly both verilog and Kami use the same file extension - ".v"
<mwk>
hmm
<mwk>
how do I trigger the issue? "yosys -p synth_ice40 kami32.v"?
<mwk>
otoh, it gets stuck soon afterwards in the `share` pass and ate 16GB of memory so far
Nazara has joined #yosys
<mwk>
yeah, OOM-killed in share at 27GB memory usage
<mwk>
peepopt worked just fine though, and semi-instantly as well
<llee454>
@mwk Yes. I just noticed that I misattributed the point of failure.
<llee454>
@mwk apparently it was the share pass that consumed the excess memory.
<tnt>
The RAM have resets.
<tnt>
Although removing it doesn't really help either.
<whitequark>
what if you mark the RAM as (*ram_block*)?
<llee454>
@tnt I thought that the hierarchy pass strips out the two memory devices.
<tnt>
llee454: mmm maybe, I didn't try the full synth, I figured if it was in the verilog, it'd be used ...
<llee454>
I see. I'll try removing them explicitly if my current run fails.
<tnt>
So the top level is _design and not _system ?
<tnt>
did you select that as the top level ?
<mwk>
... what exactly emitted this thing?
<llee454>
@tnt yes. I only care about _design right now. My goal was just to confirm that the build system would work and that the processor core would fit.
<mwk>
because uh I'm not convinced it's actually valid verilog
<mwk>
yosys emits craploads of lines like "kami32.v:58620: Warning: Identifier `\tmp$818.valid' is implicitly declared."
<llee454>
@mwk './doGenerate.sh --verilog-sim --xlen 32' This command compiles the Kami code and generates System Verilog. Then I used sv2v to convert the System Verilog into Verilog. The kami32.v file is the result of this build process.
<mwk>
and, indeed, I have no idea what that is supposed to be — a bitfield of tmp$818 perhaps? but tmp$818 is just a plain 34-bit wire...
<mwk>
... well, then it seems that sv2v is emitting bullshit
<mwk>
looks like a not-quite-converted SV structure to me
<mwk>
I mean, the OOM in `share` is still worrying and I'll try to investigate it, but it seems you have bigger problems
<llee454>
@mwk hmm. Do you know of a better utility for converting System Verilog to Verilog? Yosys's System Verilog frontend chocked on the arrays in the original file.
<mwk>
not really
<tnt>
Although really to answer you question ... pretty sure it won't fit in any ice40 :p
<daveshah>
yeah the 7.9MB kind of gives that away already
<tnt>
:)
<llee454>
@daveshah what size range would the Verilog file have to fit in to be viable?
<llee454>
Also are there plans to expand support for System Verilog arrays?
<daveshah>
there's no exact range, it's just a feeling
<llee454>
I might be willing to help add that support. What would be involved?
<daveshah>
maps to 17k LUT4s at the end with share commented out so it's over 2x too big for an ice40 anyway
<daveshah>
that's because you have more pins than the device has
<daveshah>
but the number of logic cells/LUTs is a bigger problem
<tnt>
LCs 22737 / 7680
<tnt>
lol
<llee454>
I used: https://hastebin.com/usohaforen.cs, where I just commented out the share pass (as well as other passes controlled by flags).
<tpb>
Title: hastebin (at hastebin.com)
<tnt>
BRAMs 0 / 32
<tnt>
That's worrying.
<tnt>
sv2v probably screwed up inferrence.
<llee454>
I see.
<llee454>
Well, the only reason I used sv2v was because Yosys couldn't handle the arrays in my system verilog file. Perhaps it would be wiser for me to add support for arrays. Can anyone tell me (at a high level of abstraction) what this would entail?
<mwk>
so... not an array, just a multi-dimensional wire
<tnt>
Ah yeah, arrays in ports, yeah that's not going to work.
<llee454>
Is there anything I can do to add support? Is there a conversion I can apply to the Verilog file to work with Yosys?
<tnt>
yeah you can flatten it ... change it to a [31:0]
<tnt>
(obviously you need to change it everywhere it's used ...)
<llee454>
Thanks
<llee454>
I assume that I need to do the same for packed structs?
<llee454>
Yosys doesn't appear to like line 7 either.
<tnt>
All of that is in the "System" which you don't care about so maybe focus on fixing "Design" ...
<llee454>
Thanks to everyone who offered me assistance. I'm going to revise the Kami compiler/design to avoid outputing packed structs and multidimensional wires. Hopefully that will result in parsable System Verilog code (even if the design remains too large to fit in an ice40 board).
llee454 has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
emeb_mac has joined #yosys
jfcaron has quit [Ping timeout: 256 seconds]
jeanthom has quit [Ping timeout: 246 seconds]
Asu has quit [Quit: Konversation terminated!]
futarisIRCcloud has joined #yosys
az0re has quit [Remote host closed the connection]