cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #yosys
filt3r has joined #yosys
kraiskil has quit [Ping timeout: 256 seconds]
az0re has quit [Remote host closed the connection]
kraiskil has joined #yosys
<lf>
Hi i want to take a look at an ecp5 bitstream. is there a way to convert it back into a json file? ecpunpack gives me an .config that is hard to read. ideally i would like to get a verilog file with the SB_ instances to make easer to change things.
<daveshah>
No that's not possible
<daveshah>
for iCE40 there is a tool icebox_vlog but I never got round to doing similar for ECP5
jordigw has joined #yosys
<lf>
ah ok was hopeing i could just load it into nextpnr and get an json out.
<lf>
i will read up on the config format
az0re has joined #yosys
TalS has joined #yosys
craigo has quit [Ping timeout: 256 seconds]
dormito has quit [Ping timeout: 256 seconds]
Asu has quit [Remote host closed the connection]
tpearson-mobile has joined #yosys
<tpearson-mobile>
Is there a way to get yosys to spit out resource usage per module?
<tpearson-mobile>
I'm trying to determine why a very complex design is using a tremendous amount of resources vs. the proprietary tooling, and being able to isolate the offending module(s) would help
<daveshah>
Add -noflatten to synth_ecp5 or whatever
m4ssi has joined #yosys
<tpearson-mobile>
Thanks, I'll give that a go!
<daveshah>
Oh, incidentally, for ECP5 the nextpnr SLICE usage isn't necessarily representative of actual LUT usage, due to the fairly sparse packing at the moment to ease routing
<daveshah>
The current packer will actually 'stick' at around 95% of SLICEs for quite varied LUT and FF usages
<tpearson-mobile>
Good to know, that actually explains a lot
<daveshah>
This is something that is being improved over the next few months
<tpearson-mobile>
however, I still need to track down an inordinate amount of FFs being generated, so the noflatten option is what I'm looking for
<daveshah>
Something that the ECP5 flow doesn't do yet is pack FFs into DSPs
<tpearson-mobile>
hmmm...yeah, that could be related (the resource hog is a CPU)
<daveshah>
Sounds unlikely then if its a big difference
<tpearson-mobile>
OK
<daveshah>
That mostly affects signal processing pipelines with lots of multipliers and FFs
<tpearson-mobile>
yeah I was wondering if maybe the FPU was balooning out
<daveshah>
Whereas for a typical CPU I would expect that to be <<1k FFs
<daveshah>
Oh, could be that yeah
<tpearson-mobile>
I've got a bunch of stats to dig through now, so I'll spend a bit of time doing that and see where the problem actually resuldes
<tpearson-mobile>
*resides
<daveshah>
Out of curiosity, what are you comparing against? Synplify or LSE?
<tpearson-mobile>
To be honest I'm not the one running the proprietary tooling, that's another group. I believe they're checking against the Lattice tooling
<tpearson-mobile>
but they're indicating that the resource usage on the open flow is *way* out of line, like 3x higher
<daveshah>
That sounds a lot like BRAM inference issues
<tpearson-mobile>
It does, yeah
<tpearson-mobile>
hence why I want to go module by module and check for the high consumption one
<Lofty>
Check what the memory_bram pass says
<tpearson-mobile>
hm, whole bunch of " No acceptable bram resources found."
<tpearson-mobile>
that explains the I/D cache resource explosions, but I was already expecting that to be honest
<tpearson-mobile>
and have the caches cut back to bare minimums as a result
<tpearson-mobile>
5000 cells seems a bit large for a two line D cache ;)
<tpearson-mobile>
it's odd because it's inferring some BRAMs but obviously not all of them
<daveshah>
Are they TDP RAMs?
<tpearson-mobile>
I'd expect so, yes
<tpearson-mobile>
the ECP5 does have TDP resources though as far as I know?
<daveshah>
Yes but Yosys doesn't support them
<tpearson-mobile>
oh. ouch.
<tpearson-mobile>
that'd explain it
<tpearson-mobile>
nearly 7k cells just for the I cache
<tpearson-mobile>
Rule #1 for bram type $__ECP5_PDPW16KD (variant 1) accepted. Mapping to bram type $__ECP5_PDPW16KD (variant 1): Shuffle bit order to accommodate enable buckets of size 9.. Results of bit order shuffling: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
<tpearson-mobile>
46 47 48 4$ Write port #0 is in clock domain \clk. Mapped to bram port A1. Read port #0 is in clock domain !~async~. Bram port B1.1 has incompatible clock type. Failed to map read port #0. Mapping to bram type $__ECP5_PDPW16KD failed.
<tpearson-mobile>
Is there a roadmap / timing for TDP support?