<pepijndevos>
ZirconiumX, my script has an assert, so I don't think I need grep. What I ended up doing is specifying everything except -modules
<pepijndevos>
ZirconiumX, What exactly are you doing with test/arch/common? I made them work for gowin recently, so maybe I know _something_
<ZirconiumX>
pepijndevos: you'll still need grep :P
<pepijndevos>
Hmmm, question of my own: how do I implement a Nextpnr constraint for the generic target in Python? Some of my slices in a tile don't have a DFF.
<pepijndevos>
ZirconiumX, to do what? That only limits what is considered a crash, any my assert perfectly describes the crash I want.
<ZirconiumX>
Great, and what if you find a Yosys bug in the process?
<ZirconiumX>
That's a crash
<pepijndevos>
sure...
<ZirconiumX>
And now bugpoint is going off to minimise something entirely different to your target
<ZirconiumX>
In fact, I bet that's why you needed to ignore modules; because pruning the top-level module produced a different error, no?
kraiskil has quit [Ping timeout: 265 seconds]
<ZirconiumX>
Anyway.
<pepijndevos>
Oh... you're saying it deleted *everything* and decided that was the most minimal case... yea ok...
<ZirconiumX>
Honestly I think -grep should be required
<daveshah>
pepijndevos: in a real arch it would be a simple validity check problem
<daveshah>
But that isn't exposed to Python, and Python code in the placer hot path wouldn't be great in any case
<daveshah>
imo, just ignore those cells for now
<pepijndevos>
Right haha
<pepijndevos>
I'll just have 6 slices
<ZirconiumX>
pepijndevos: I just pushed the broken test to the better-flow branch of prjmistral
<pepijndevos>
link?
<ZirconiumX>
Make sure to clone it in your home directory, because I don't yet have the luxury of the + path, so put it in ~ instead :P
<ZirconiumX>
Here's the vendor model I'm trying to replicate
<daveshah>
I don't think the async clear is gated by the enable at all?
<daveshah>
So just have the enable as an if statement in the clocked 'else' part
<ZirconiumX>
I must have gotten it confused with synchronous clear then
<ZirconiumX>
Okay, so now proc_arst doesn't complain
<ZirconiumX>
It fails to prove equivalence though
<ZirconiumX>
Which is annoying.
<ZirconiumX>
On the other hand
<ZirconiumX>
Warning: No SAT model available for cell $techmap$auto$simplemap.cc:420:simplemap_dff$56.$procdff$167_gate ($adff)
<ZirconiumX>
I should probably find/fix this
<daveshah>
You probably need a techmap and clk2fflogic or sync2async in there
<ZirconiumX>
I'm basing this off the iCE40 script
<ZirconiumX>
5.45. Executing EQUIV_STATUS pass.
<ZirconiumX>
Found 8 $equiv cells in equiv:
<ZirconiumX>
Of those cells 8 are proven and 0 are unproven.
<ZirconiumX>
Equivalence successfully proven!
<ZirconiumX>
Woo!
craigo has joined #yosys
<pepijndevos>
Niiice
<pepijndevos>
ZirconiumX, Micko recommended I based mine of the Efinix tests because they don't have any arch-specific tests in them yet
<pepijndevos>
Curious if fsm.ys works for you... I'm stuck on that one with a weird equivalence bug.
<ZirconiumX>
First I've got to get my LUTs in order
<pepijndevos>
(which seems unrelated to my techmap, rather wreduce just deletes a few too many bits)
wifasoi has joined #yosys
<ZirconiumX>
I mean, that's indicative of a bug if anything
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
<pepijndevos>
Probably, maybe.
<pepijndevos>
Hmmmmmmmmm, do cell port names have to map to bel port names? I'm currently just using Gowin bel port names, but it's not happy about that.
<pepijndevos>
And the generic packer does a weird thing where the Q is either the LUT F or the DFF Q, while on Gowin they are different things. So maybe I just need to bit the bullet and make my own Python packer.
<ZirconiumX>
daveshah: I have a really stupid idea. Quartus accepts a Routing Constraints File that lets you map signal paths, and the Quartus Settings File lets you place cells in exact positions. So nextpnr would produce a solution that constrains Quartus to the point where nextpnr's solution is the only valid solution for PnR, and then it can produce a bitstream from there.
rohitksingh has quit [Ping timeout: 245 seconds]
<mwk>
tbh that seems to be the obvious correct way to use quartus as bitgen-only
<mwk>
not pretty, but Should Work™
vidbina_ has joined #yosys
<ZirconiumX>
mwk: it's a stupid idea, you're not meant to *agree* with me :P
<mwk>
ZirconiumX: it's what I would actually do :p
<mwk>
we work with the tools we're given
<mwk>
or well
<ZirconiumX>
The main question is how long it will take Quartus to realise I've given it the solution
<mwk>
what I'd really do is use the same path, but to build a lot of fuzzers
<ZirconiumX>
Indeed, but I'm not as smart as you, mwk :P
<mwk>
you're severely overestimating the complexity of a routing fuzzer, given device map and control over routing :p
kraiskil has joined #yosys
<ZirconiumX>
No, I'm not :P
<pepijndevos>
If you know all the wires that exist, and have control over them, you can just fuzz them like any other feature, no? Turn wire off, collect bits, turn wire on, collect bits, compare.
<ZirconiumX>
*If* you know all the wires that exist
<mwk>
pepijndevos: correct
<pepijndevos>
Uh, you have control over them, but you can't observe them?
<ZirconiumX>
I have little knowledge of the internal routing
<daveshah>
I'm also not sure if Quartus can just turn arbitrary wires on and off
<mwk>
ZirconiumX: this is also a requirement for getting P&R working, though
<daveshah>
I think it still needs a full routed path
<mwk>
so if you can do a nextpnr backend, you can also do a fuzzer
<daveshah>
And I presume will create one around constraints if an rcf isn't complete
<ZirconiumX>
Yep
<ZirconiumX>
So I can observe them, but control is questionable
<daveshah>
The simple correlation approach that xray does would probably suffice
<ZirconiumX>
mwk has automated fuzzers for these bits and I calculated them all by hand
<ZirconiumX>
Well, by manual binary diffing
vidbina_ has quit [Ping timeout: 250 seconds]
kraiskil has quit [Read error: No route to host]
wifasoi has quit [Ping timeout: 264 seconds]
<pepijndevos>
daveshah, IIRC you mentioned yesterday you could do basic packing with a techmap, could you elaborate a bit?
<pepijndevos>
It seems actually more like extract
<daveshah>
That was mwk I think
<daveshah>
Not so much the combining cells together side of packing, but more the converting cell types
<pepijndevos>
But I'm struggling to make it work due to the init parameter... or at all
<daveshah>
Which is a lot of what nextpnr packing is about as validity checks often mean not so much combining is needed
<daveshah>
eg converting various lut primitives to a single common LUT, same for FF and IO
<daveshah>
For packing involving merging cells probably a custom pass would be best
<daveshah>
Oh glad it's useful, lmk if you hit an issues
vidbina_ has joined #yosys
<pepijndevos>
Hmm
<mwk>
pepijndevos: I said yosys passes in general, not just techmap
<mwk>
pmgen might be useful as well, for one
<mwk>
(though I have to admit I haven't fully figured out how pmgen works yet, so take it with a grain of salt)
wifasoi has joined #yosys
<pepijndevos>
mwk, ERROR: No such command: pmgen (type 'help' for a command overview)
<mwk>
it's not a command, it's a... framework/code generator to build commands
<mwk>
have a look at passes/pmgen
<pepijndevos>
Currently trying to use extract, but seems a dead end due to parameters.
<mwk>
yeah, extract sucks
<mwk>
it's a very one-trick pony
<pepijndevos>
This is the second time I'm trying to use it and run into the parameter thing.
<mwk>
what you need is a more general pattern-matching engine
<mwk>
which pmgen tries to be
<pepijndevos>
Sometimes I wonder how normal people use Yosys... maybe they just run synth_ice40 and live happily.
<mwk>
(pattern matcher generator)
<mwk>
well yes
<mwk>
that's exactly how most people use yosys :p
<mwk>
some days they even use *shudder* options to the synth_whatever pass
<mwk>
I'm not sure I can recommend pmgen though
<mwk>
it feels quite ugh to me
<pepijndevos>
I mean... what am I even doing... the generic packer is like a dozen lines of C, surely it can't be too hard to just hand-roll my own python packer using a slightly different primitive.
<mwk>
c++
<mwk>
also, the amount of stuff you need to do in the packer heavily depends on your device and how well the incoming primitives match with the P&R sites
<pepijndevos>
cpedanticpedantic
<pepijndevos>
Right. Disregarding everything complicated, I would say pretty well hehe
<mwk>
it might not be so simple
<mwk>
there are a lot of decisions to make here
<daveshah>
In general, I am leaning towards minimal packing and more validity checking
<mwk>
are LUT and FF separate cells, or do you want to place a combined LUT+FF cell?
<mwk>
your FPGA has wide multiplexers — how do you represent that?
<mwk>
same for distributed RAMs
<mwk>
which also take up several LUTs
<pepijndevos>
mwk, I'm doing a silly PoC, I'm not considering anything like wide muxes.
<mwk>
fair enough
<mwk>
what about LUT+FF though?
<daveshah>
FWIW, both DRAM and wide LUTs can be represented in nextpnr using relative constraints
<daveshah>
(I know mwk knows that, for the benefit of pepijn)
<pepijndevos>
So right now I'm just trying to make the generic target pack a LUT+DFF in a slice.
<daveshah>
imo, LUT+FF should be separate cells/bels if they are separately useable (like Xilinx); combined if not (like iCE40)
<mwk>
agreed
<mwk>
FWIW, they're not separately usable
<daveshah>
A combined primitive makes sense as the placer can't really chose to place them separately in any case then
<pepijndevos>
I can *almost* use the generic packer, except Gowin has a seperate LUT and DFF output, so the cell doesn't match the bel
<mwk>
right
<mwk>
so you need to make a LUTFF cell
<mwk>
4 inputs, two outputs
<daveshah>
I am actually tempted to change the generic cell to meet that spec
<daveshah>
Several FPGAs seem to follow the pattern
<pepijndevos>
I'll *hapily* make a PR for that, seems more useful and easy than some whacky yosys pass or Python mess
<daveshah>
Sure, would make a good first nextpnr PR.
<pepijndevos>
omg, on my way, brb
<pepijndevos>
hehe
<mwk>
of course eventually you'll need to extend your simple cell with more stuff to support muxes, ALUs, RAMs :p
<mwk>
but sure, it's a good way to begin\
<pepijndevos>
What would you think about command-line parameters to make the cell names configurable?
<daveshah>
Well they wouldn't be command line parameters they'd be a Python function like how LUT K is set
<pepijndevos>
mwk, I'm not going to do any of those things in Python. So it's more like... do PoC in Python, then do the real thing properly in C++
<daveshah>
Personally, I'd rather the generic flow core primitives stayed generic
<pepijndevos>
Okay, I'll do the other thing first... the parameters is more work and less important
<daveshah>
You could probably just translate them in the fasm export script
<pepijndevos>
also true
<mwk>
you'd need to convert them on input as well though
<mwk>
at least if you want to keep the yosys output netlist compatible with vendor
<pepijndevos>
Right, with renaming a few things, you could *maybe* (not super likely) use the actual synth_gowin pass with all the extras disabled, rather than the special synth_generic script.
<pepijndevos>
But yea, might as well just use the synth_generic script and rename the output to match
<pepijndevos>
daveshah, I think I got it working. I added a --write command to visualize it with Yosys, do you want that in the PR, or should I leave it the way it was? https://imgur.com/q3Ao1Dl
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<daveshah>
Yeah, add the --write too
<daveshah>
Make sure to update the example too
<pepijndevos>
Yes, I did, that's why I added the write, to verify the example actually looks more or less sane and doesn't have any disconnected Q or F outputs