<daveshah>
No, but you can follow it with a call to regular abc if you really want to
jakobwenzel has joined #yosys
elGamal has quit [Ping timeout: 264 seconds]
elfGamal has joined #yosys
sajattack has joined #yosys
Vinalon has quit [Ping timeout: 250 seconds]
s_frit has joined #yosys
FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #yosys
s_frit_ has joined #yosys
s_frit has quit [Ping timeout: 264 seconds]
<ZirconiumX>
How well does Yosys optimise multiplication by a constant?
<daveshah>
Mult by 1 or any other power of 2 should be optimised away altogether
<daveshah>
Anything else will be mapped as normal, but if it doesn't become a DSP slice then the constant adder bits should be somewhat optimised iirc
<daveshah>
so with synth_ice40
<daveshah>
8x8->8 multiply with no constants is 67 LUT4, 2 CARRY
<daveshah>
8bit x constant 3 -> 8 multiply is 7 LUT4, 6 CARRY
<daveshah>
so actually it does pretty well
<ZirconiumX>
Hmm. This is one of the rare cases where I'd actually prefer it didn't get lowered into a carry chain
emeb has joined #yosys
<anuejn>
ZirconiumX: for a test i did recently rathre well
<ZirconiumX>
I'm trying to count the number of 1 bits in an input (population count), and it seems like the standard software approaches behave poorly in hardware
<anuejn>
https://files.niemo.de/ecp5_mul.jpg shows the lut4 count on the y-axis and the constant on the x-axis for an 8-bit multiplier with that given constant
<ZirconiumX>
Neat
<anuejn>
if you are interested, i can put the (nmigen) code somewhere
<ZirconiumX>
Eh, it's not that important right now
<anuejn>
k
Vinalon has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
<lambda>
why do gates such as $div have both A_SIGNED and B_SIGNED parameters, yet only work correctly when they have the same value (either both signed or both unsigned)?
<ZirconiumX>
Define "correctly", here. What division identity are you expecting?
<lambda>
well InternalCellChecker catches it (kernel/rtlil.cc:830), I'm just wondering why they are separate if they are obviously only allowed to be set to the same value
<ZirconiumX>
To catch internal bugs, I suppose
<lambda>
but then why not just have an IS_SIGNED parameter?
<ZirconiumX>
So that code that operates on internal cells can relatively generically check input signedness across cells
<lambda>
alright - I just got tripped up that the models in, for example, techlibs/common/simlib.v, won't work if the parameters have different values, with no obvious check for that in the verilog
<ZirconiumX>
Because internalCellChecker checks it instead of the Verilog
<lambda>
that's fair, just have to make sure I add that check there as well for the $rem I'm working on
<lambda>
oh I know, I guess I'm adding actually $mod (or $mod2 for compatibility, dunno)
<ZirconiumX>
I feel like $mod2 is probably the right name, since otherwise you have de facto broken RTLIL
<ZirconiumX>
Which has no formal compatibility guarantees, but I think it would still be frowned on and a potential source of bugs
<lambda>
right
<daveshah>
$GenuineMod
<lambda>
$properMod
<ZirconiumX>
$real_mod_for_real_this_time
<lambda>
the final name will just be a matter of search-and-replace, gonna leave it at mod2 for now
citypw has quit [Ping timeout: 240 seconds]
jfcaron has joined #yosys
<ZirconiumX>
lambda: remember what I said about not breaking RTLIL?
<ZirconiumX>
Your patch breaks RTLIL
<lambda>
ZirconiumX: oh, as in remain backwards compatible as well? alright, I'll look into that
<ZirconiumX>
Because you're removing all the $mod cell checks, so old IL will not work properly
<lambda>
I interpreted it as just not silently changing the behaviour of $mod
<ZirconiumX>
That too :P
<lambda>
I'll add the checks back then :)
<ZirconiumX>
We can phase out $mod[1] but in the meantime it should stay to minimise damage.
<lambda>
is there any central point all IL goes through that could be used to emit a deprecation warning?
<mwk>
if nothing else in yosys creates $mod cells, read_ilang would be a good place
<ZirconiumX>
This still presents a problem though: now new Yosys would generate $mod2/$rem.
<ZirconiumX>
Which wouldn't be recognised by old Yosys.
<ZirconiumX>
Do we care?
<lambda>
ZirconiumX: would changing RTLIL::Module::addCell to automatically convert "$mod" to "$rem" be an option? that seems to be about the only place that instantiates RTLIL::Cell directly
<ZirconiumX>
I think so, yeah.
<ZirconiumX>
But ask mwk
<lambda>
it's also what's called by read_rtlil, so that'd be covered
<mwk>
that should work, I suppose
Vinalon has quit [Read error: Connection reset by peer]
Vinalon has joined #yosys
tautologico has joined #yosys
<ross_s>
Back with another question... has anyone run into what seems to be a three cycle lag with the ODDRX1F primitive? I haven't spotted anything in the TN1265 app note to explain it, but I could be missing something.
<mwk>
turns out adding yosys cells is loads of fun with finding all relevant files you need to modify, and I'd rather do it once
<mwk>
any other FF types you'd like to see in yosys?
<mwk>
my list currently has: the above; a variant of $dffsr with enable (ie. async reset + async set + clock enable); a variant of $dlatch with only one of set/reset
<ZirconiumX>
mwk: Truth be told I'm not entirely sure how the flop works here
<mwk>
in theory, xilinx can also implement sync set + sync reset [+ clock enable], but tbh recognizing the patterns would probably be more trouble than it's worth
<mwk>
[and it only applies to *old* xilinx anyway]
<daveshah>
Yeah, that seems good enough
<mwk>
ZirconiumX: eh, fair enough
<mwk>
there seems to be some stuff about async loads?
* ZirconiumX
digs up the Intel flop diagram
<daveshah>
ECP5 via nextpnr supports async loads, but it is undocumented officially
<mwk>
but that's probably more than I'm prepared to handle right now; the three extra flops above at least don't require new major codepaths
<daveshah>
(and sync loads)
<daveshah>
I was assuming the async loads can continue using DFFSR
<daveshah>
Not optimal but it works
<mwk>
right...
<daveshah>
99 times out of 100 they come from crappy HDL anyway
<mwk>
that's certainly true
<mwk>
also you mentioned a ff type with async set + reset, set having priority over reset
<mwk>
it would certainly make the ff library more regular, but uh, I don't think it was supported by any hw ever?
<daveshah>
I wouldn't be surprised if some asic libraries had it
<mwk>
hmm.
<mwk>
still... doesn't seem worth it to implement it now
Vinalon_ has joined #yosys
Vinalon has quit [Ping timeout: 265 seconds]
N2TOH_ has joined #yosys
jfcaron has quit [Disconnected by services]
jfcaron_ has joined #yosys
N2TOH has quit [Ping timeout: 256 seconds]
<tnt>
So any risky recent changes in yosys that would be risky / potentially breaking ?
<az0re>
tnt: risky for what?
<tnt>
User reported a litexsoc working with 9b982e92 and broken with master
<tnt>
but with all the branches merges in between, the bisect doesn't work so good :/
<az0re>
There has been lots of cleanup recently
<az0re>
But I would look at the ID(*) modifications
<ZirconiumX>
I don't see why that would break stuff