<cr1901>
ERROR: Unsupported or unknown directionality on port PAD of cell gate.\$iopadmap$top.clk ($paramod\FACADE_IO\DIR=t40'0100100101001110010100000101010101010100). <-- I'm guessing that's a fancy way of saying "the SMT2 backend does not support tristates"
<cr1901>
?*
<mwk>
inout ports actually, but yes
<mwk>
this is what -noiopad is for, btw
<cr1901>
Yes, and I have a testcase where nextpnr breaks a yosys design where noiopad was used
<cr1901>
and have been talking to gatecat about this in DM and am unsure whether I should just plain remove -noiopad from synth_machxo2 and error out if nextpnr sees an I/O signal w/o a pad
<cr1901>
and fix synth_smt2
<cr1901>
or what
<mwk>
-noiopad is meant for two things
<mwk>
formal verification and out-of-context mode
<mwk>
it should stay for these two
<mwk>
... out-of-context is probably not particularly important for a tiny device, but still
<cr1901>
Right, I'm using it to create a miter to compare pre and post-pnr designs
<mwk>
but, hm
<cr1901>
That's a reasonable use case, yes?
<mwk>
post-pnr is tricky because these IO cells are left
<mwk>
but... you can use techmap to flatten the FACADE_IO definition into the design, which will result in no more inout ports
<cr1901>
is deminout also required?
<cr1901>
(That was my next step, btw)
<mwk>
no
<mwk>
if you replace the cells with their insides via techmap, there won't *be* a port
<cr1901>
I think I'm worried whether SMT2 can handle PAD being used on both the RHS and LHS of an assign
<cr1901>
(even after flattening)
<cr1901>
but I'll try and see what happens
<mwk>
there may also be a tribuf that needs some handling
<cr1901>
In all my designs I'm testing I don't actually use tristate functionality, so it should all "go away" with a sufficient number of yosys passes :P
<mwk>
... assuming they actually work
<mwk>
tribufs are... let's just say I don't trust our handling of those
<cr1901>
I have faith
<cr1901>
(for now)
<mwk>
.. I consider it more likely than not that you'll uncover some bugs
<mwk>
as in, in yosys core
<cr1901>
I'll at least report them, but I'm not sure how useful I'll be fixing them. Part of the reason I want to create miters is because I don't trust that my models are mistake-free compared to yosys' built-in ones
<cr1901>
This is fine and definitely what I intended :)
<cr1901>
So indeed, maybe it's better to just plain error out instead of trying to pnr this
<mwk>
... I would recommend either fixing the nextpnr bug here properly by auto-adding IOBs, or making it a hard error to have a pin with a missing IOB
<mwk>
yes
<cr1901>
I do not support auto-adding IOBs at all, in fact I remove them forcefully during packing (I'm not sure if the auto-IOB functionality is going away or not, but I don't want to deal w/ them)