kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
bluesceada has quit [Changing host]
bluesceada has joined #yosys
dlobato has joined #yosys
dlobato has quit [Remote host closed the connection]
vidbina has joined #yosys
vidbina has quit [Remote host closed the connection]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 260 seconds]
vidbina has joined #yosys
gsmecher has joined #yosys
unkraut has quit [Ping timeout: 246 seconds]
unkraut has joined #yosys
<lambda>
woah, someone sure greased the release machine :D
<FL4SHK>
lambda: what do you mean?
<lambda>
FL4SHK: only a little over three months between releases? that's quite a nice change of pace after the >2y gap between 0.9 and 0.10
<mwk>
we basically decided to do monthly releases from now on
<mwk>
we're not *quite* there yet with the infrastructure and processes for that, but we're getting there
<lambda>
awesome
<FL4SHK>
lambda: I see
<FL4SHK>
Does yosys support SV classes as namespaces?
<FL4SHK>
I heard yosys supports more of SV now
<FL4SHK>
That's one thing I generally don't expect synthesis of SV to support, but at the same time, it's how the SV standard mentions to do type generics with structs and subprograms.
<FL4SHK>
such that you can do `my_class #(.member_t(int))::my_struct_t`
<FL4SHK>
I normally use nMigen for synthesizable code, and I may be continuing that.
<mwk>
nope, there is no support for classes at all
<mwk>
it's not even recognized as a keyword from what I see
<FL4SHK>
That's unfortunate
<FL4SHK>
sv2v it is if I get back into SV
<FL4SHK>
For the record
<FL4SHK>
I'm not referring to use of classes directly, just as namespaces
<mwk>
there is a new verilog frontend planned, but uhh it's kind of not the highest priority right now
<FL4SHK>
like packages, but with the power to parameterize them
<mwk>
yeah, I know
<FL4SHK>
Cool
<mwk>
I'm unfortunately a little too familiar with SystemVerilog
<FL4SHK>
I haven't written much SV lately
<FL4SHK>
nMigen seems like it's able to do every high level thing I'm interested in
<FL4SHK>
if combined with the extensions to nMigen that I wrote
<mwk>
yeah, it is quite great
<FL4SHK>
OH, you're in #nmigen as well, derp
vidbina has quit [Ping timeout: 268 seconds]
gsmecher has quit [Ping timeout: 268 seconds]
FabM has quit [Ping timeout: 268 seconds]
gsmecher has joined #yosys
FabM has joined #yosys
FabM has joined #yosys
vidbina has joined #yosys
<cr1901>
*Homer "New Billboard Day" voice*: New yosys release!
Kamilion has quit [Read error: Connection reset by peer]
<gatecat>
cr1901: you need a call to `techmap` to turn the `$not` into a `$_NOT_` before abc
<gatecat>
abc only works on the gate-level cells
emeb_mac has joined #yosys
somlo has quit [Remote host closed the connection]
dys has quit [Ping timeout: 260 seconds]
ec has joined #yosys
<cr1901>
gatecat: Okay, you are correct, and my patch as-is is wrong. I didn't notice this was happening because nextpnr doesn't error on unknown cells if --pack-only is specified, just warns that it wasn't placed.
<cr1901>
I don't like my solution at all. I wish iopadmap supported active-low tristates, but Idk how to add that functionality (nor do I know whether it would be accepted since it's feature creep)
dys has joined #yosys
<mwk>
cr1901: wrt your tribuf pull request, I think it's time I did something about neg-polarity tristates properly
<mwk>
ie. I'd like to cook a proper solution soon-ish and avoid multiple synth passes dealing with the same problem in completely different ways
<mwk>
maybe a whole iopadmap refactor would be appropriate, hmm
<mwk>
> I don't like my solution at all. I wish iopadmap supported active-low tristates
<mwk>
oh yes, it should
<mwk>
it's not fully obvious to me yet whether it's the right place to put *all* handling, there may be merit in splitting the "polarity decision" and "IO pad mapping" parts into two passes
<mwk>
but we definitely need better support
<mwk>
and generic support
<cr1901>
Fine, I'll hold off then and let you do your thing. I'm not begging for tristate support yet for my designs. If I truly need it, I can do *points to the shit in my PR* manually.
<cr1901>
I mainly added this to test part of my nextpnr PR (I'll make that now), but I'm satisfied the nextpnr functionality works and I don't _need_ my yosys PR merged.
<mwk>
mhm, right
<cr1901>
Honestly, makes me feel a lot better to hold off for now :P
<mwk>
so
<mwk>
you need the inverter extracted before the LUT mapping happens
<mwk>
and, if the inverter happens to be $not, before techmapping happens
<mwk>
a simple solution to your problems is to just move iopadmap early enough in the script, like synth_xilinx does
<mwk>
there's no reason why pad mapping should happen *late*, after all
<cr1901>
I do not have a particular reason why it's done late. Probably more "don't touch it, lest I break something". But it's already broke. So that'll work.
<mwk>
yeah, you copied from one of the passes that does it late because the target uses an active-high enable
<mwk>
synth_xilinx is different because it needs active-low enable
<mwk>
but really, it should just be done early everywhere for consistency
<mwk>
... anyway
<mwk>
I think a better solution would be to enhance the cell library a bit
<mwk>
have both active-high and active-low versions of the $_TBUF_ / $tribuf cells
<mwk>
and, like for FFs, have a pass that legalizes tribuf cells to be either all-positive or all-negative
<mwk>
and then iopadmap's job would be simplified because it can always expect tribuf cells of the right polarity already and can happen as late as you'd like
<mwk>
while the tribuf-legalize pass could be somewhere earlier
<mwk>
that also gives us a target-independent active-low tribuf cell, which IMO is nice
<cr1901>
Maybe I'd add a new-section called "legalize" between "flatten" and "coarse"
<mwk>
no
<cr1901>
Would it go w/ "map_ios" then?
<mwk>
you already have a conceptually similar dfflegalize call, don't you?
<mwk>
I think they belong together
<cr1901>
yea, I call that the "map_ffs" pass
<cr1901>
err map_ffs section*
<cr1901>
I can't tell you what past-me was thinking other than "yes I did copy from synth_ecp5 most likely and pared it down to what I need"
<mwk>
whitequark: do you have any opinions on the above?
<whitequark>
nothing that bears mentioning
<cr1901>
Cool, I'm finishing up my nextpnr PR
kraiskil has joined #yosys
<mwk>
whitequark: ack
Kamilion has joined #yosys
Kamilion has quit [Changing host]
vidbina has joined #yosys
<cr1901>
"tribuflegalize" is the solution I like best, FWIW. It'll pair well w/ dfflegalize and generate gate-level cells before abc has had a chance to run. It might even enable me to remove the iopadmap mess completely and techmap directly to FACADE_IO (we'll see...)
kraiskil has quit [Ping timeout: 256 seconds]
<mwk>
you'd still need to map the plain I/O buffers, no?
kraiskil has joined #yosys
<cr1901>
Maybe, I thought I could map _TBUF_ to FACADE_IO directly
<cr1901>
I'll have to actually look and see and not just think out loud :P
<cr1901>
nextpnr PR opened. And with that, barring any fixups, Mr. Nextpnr's Wild Ride has come to an end for now
kraiskil has quit [Ping timeout: 268 seconds]
<mwk>
it's a little trickier than that
<mwk>
there's a reason why the bidirectional I/O pad cells have *4* pins, not *3* like a tribuf
<mwk>
that's an important bit that iopadmap takes care of