Thorn has quit [Remote host closed the connection]
kraiskil has quit [Ping timeout: 264 seconds]
<promach3>
Could yosys actually do gate-level simulation ?
<Sarayan>
it's pretty much what cxxrtl does
jakobwenzel has quit [Ping timeout: 240 seconds]
jakobwenzel has joined #yosys
proteusguy has quit [Remote host closed the connection]
jakobwenzel has quit [Quit: jakobwenzel]
vidbina has quit [Ping timeout: 240 seconds]
emeb has quit [Quit: Leaving.]
jakobwenzel has joined #yosys
jakobwenzel has quit [Ping timeout: 260 seconds]
<thoughtpolice>
Has anyone happened to write any kind of "seed search" tool/script for nextpnr, by chance? Rather self evident but just anything that can do parallel runs and give me the fMAX for a given seed (let's keep it simple: single clock domain.) I figure I'd ask if anyone had anything nice before I go write a bad one myself.
vidbina has joined #yosys
kraiskil has joined #yosys
emeb_mac has joined #yosys
<cr1901_modern>
thoughtpolice: Yes. Gimme a moment
<cr1901_modern>
to find it
<cr1901_modern>
I didn't write it- the person who did isn't in here
<agg>
It's quite hacked together but I've been using it a bunch recently and it's working well for me
<cr1901_modern>
That's what I get for relying on autocomplete and not checking the list
<thoughtpolice>
Great, thanks! I was thinking about using the python API, but close enough ;)
<thoughtpolice>
And yes, mine would have been worse certainly
<cr1901_modern>
You can hook the python API from the command-line, but not sure you can run nextpnr in a loop like that?
<agg>
I think using the python api would be a bit tricky to parallelise
<agg>
This is obviously gross and also could benefit from even short documentation... but it does handle multiple clocks lol
<thoughtpolice>
I was thinking a combination of an outer parallel wrapper (gnu parallel, perhaps) with a python script for the --run phase
<thoughtpolice>
Though I didn't see much documentation or examples of how to approximate the default flow with a script
<thoughtpolice>
(maybe I missed something)
<cr1901_modern>
ctx.pack() ctx.place() ctx.route(), and maybe "assign timing info" somewhere in between :P?
<thoughtpolice>
Yeah, something like that. Lots of 'dir' in the REPL too
<cr1901_modern>
haha
<agg>
I couldn't figure out how to get timing information from the context in a post-routing context
<thoughtpolice>
In theory gnu parallel would let you trivially use multiple machines or whatever though. I actually had the absurd idea to abuse this with GitHub actions to do something a seed search for builds as a part of the CI system, in a way.
<agg>
So long as you remember to cite gnu parallel in your research paper :p
<agg>
So far just running like 300 seeds on my 8c16t desktop has worked well but otherwise I just spin up a huge server in a cloud or whatever :p
<agg>
You'll probably quickly observe two things I've noticed so far, one is that the seeds can make a huge difference to fmax but the other is that tiny changes to your design can make huge differences to synthesis that aren't explored by npnr seeds
<agg>
eg I had a small design that got like 60+-10MHz when trying 300 seeds, then I added an extra output that just toggles 0/1 and the distribution shifted to 68+-8MHz or so
<agg>
Half those spreads, I mean total spread 10 and 8 not +-
<agg>
Ah yep basically that comment indeed
<agg>
I wish for a way to perturb abc somehow
<cr1901_modern>
agg: This might be worthwhile to spin into a package so the setup.py machinery can handle creating a windows binary to simulate shebang
<cr1901_modern>
your script I mean*
<cr1901_modern>
in the interim, I'm just using it from a bash prompt
<thoughtpolice>
Yeah, I've noticed that simulation is quite sensitive to small changes already. ¯\_(ツ)_/¯
<thoughtpolice>
Err, synthesis
<agg>
I wanted to just implement it inside nextpnr but then I remembered that c++ is hard
<agg>
And I spent all week(s) working really late instead so...
<agg>
Thankfully I'm probably back doing hands on things at work for a few weeks and thus not working on work gateware all evening and thus maybe doing more other things in the evenings :p
<cr1901_modern>
The Ethernet switch gateware?
<agg>
Different (not yet open source) work project
<agg>
Though a lot of nice nmigen things in it I hope to open source soonish, we'll see
<agg>
Well one thing anyway
<agg>
Anyway it seems like implementing it inside nextpnr would be more useful and correct rather than trying to wrap the output like my python script does
<cr1901_modern>
There's an issue about this I think on nextpnr... maybe you created it?
<agg>
Wasn't me
<agg>
But I assume everyone who's used --seed has wanted it at some point
<cr1901_modern>
Hmm it's not printing anything for me