adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
emeb_mac has joined #yosys
Degi_ has joined #yosys
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
N2TOH_ has quit [Ping timeout: 265 seconds]
<tux3>
Does yosys support something like `logic [instance.param:0] x;` if? I have a module instance with default parameters/localparams that the parent doesn't really need to know about...
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #yosys
N2TOH has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 265 seconds]
citypw has joined #yosys
zkms has quit [Quit: reboot]
zkms has joined #yosys
N2TOH_ has quit [Ping timeout: 265 seconds]
N2TOH has joined #yosys
<daveshah>
tux3: no, hierarchical parameter refs aren't supported
emeb_mac has quit [Quit: Leaving.]
<sensille>
is parameter propagation in yosys reliable? i have a strange case here which i haven't boiled down yet. it looks like as if i have to give the parameter a default value on each level. when i use 0 on all but the top, yosys complains about not being able to determine a width
<sensille>
i find it already strange that i have to give the paramter a default value
<sensille>
what i mean is that i pass a parameter down the hierarchy from top to bottom
<daveshah>
I've never seen a problem with parameter propagation
<daveshah>
the default value requirement is a Verilog thing, not a Yosys requirement
<sensille>
ah
<daveshah>
If you don't want Yosys to elaborate each module with its default parameterisation, use read_verilog -defer
<sensille>
so the problem is that with the default parameter the code is not synthesizable
<sensille>
which in my case makes sense
<sensille>
ok, so i don't need to worry that in the end the wrong value is used
pie_[bnc] is now known as pie_
pie_ is now known as pie__
pie__ is now known as pi^e
pi^e is now known as pi^e_
pi^e_ is now known as pie_[bnc]
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #yosys
Sarayan has quit [Remote host closed the connection]
<lambda>
huh, I kind of expected `$signed(x) + $signed(y)` to extend both values to the same size, but apparently not - what's the point of using $signed() then?
<ZirconiumX>
lambda: the Verilog LRM says that operations are only signed if both sides are signed
<ZirconiumX>
So $signed() reinterprets it as signed
<ZirconiumX>
The actual expression width matching is done by the operator itself, which is... Highly inconsistent
<lambda>
that's what I was thinking, but from what I can tell `$signed(3'b100) + $signed(5'b00001)` becomes `5'b00101`, while I'd expect `5'b11101`
<lambda>
does that only work as expected if all operands as well as the target signal are the same width
<lambda>
?
<ZirconiumX>
Yeah, Verilog generally zero-extends, not sign-extends
<ZirconiumX>
Unless you're in a ?: block
<ZirconiumX>
Actually, correction
<ZirconiumX>
It sign-extends if you assign it to a wire, but zero-extends inside a ?:
<lambda>
oh, ?: as in ternary if?
<lambda>
VHDL might not look as pretty with its Ada-isms, but at least it's not an inconsistent mess, sheesh
<ZipCPU>
Be aware ... bit-wise concatenations are unsigned as per the spec
<ZipCPU>
So if you want to multiply A * { 1'b0, B}, you'll be multiplying by an unsigned number
<lambda>
I guess that makes sense, I wouldn't expect `{1'b0, x}` to ever be negative
<ZipCPU>
Sure, but what about A * { B[MSB-1], B } ?
<ZipCPU>
Where you tried to sign extend it by a bit?
<lambda>
ouch
<ZipCPU>
I suppose you could do $signed({B[MSB-1], B]), but I tend to just place the bit-concatenations in their own wires, and declare the wires as signed
<ZipCPU>
I've just been burned too many times by this operation not working like I think it should
<lambda>
I'll just stick with VHDL or DSLs unless I absolutely have to use Verilog
<ZirconiumX>
lambda: yeah I use nMigen which gets it right as far as I can tell
<ZirconiumX>
Even if that results in some level of unexpected behaviour, it's not *unintuitive*
Sarayan has joined #yosys
<ZirconiumX>
Like someone having a 32-bit right-hand-side to a shift (by accident) and nMigen (by spec) producing a 2^32 bit result
<ZirconiumX>
(which Yosys choked on, but)
<lambda>
hehe, yeah, the additional abstraction it grants has its price of course, but usually just in the form of increased resource demand, not pulling your hair out
<lambda>
in other news, `test_cell $div $mod2 $rem` finally passes now
<ZirconiumX>
Great, so now you need to write a combinational modulus algorithm
<ZirconiumX>
(have fun with that)
<lambda>
well techmap already has a combinational div/rem, so I'm just converting rem to mod
<lambda>
as far as I can tell no cells are added anywhere else in opt_expr
<ZirconiumX>
lambda: Since $mod gets upgraded to $rem, replace it with $rem
<ZirconiumX>
$mod == $rem, right?
<ZirconiumX>
But $mod2 is the proper modulus semantics
<lambda>
ZirconiumX: oh yes, but the current opt_expr logic for $mod seems to be for actual modulo ($mod2), so now I need to implement $rem
<mwk>
*sigh* ok, since apparently noone else told you
<mwk>
we had a yosys dev meeting yesterday
<ZirconiumX>
This is gonna be good
<mwk>
the consensus reached was that current $mod should remain as $mod
<mwk>
because a) renaming stuff unnecessarily messes with compatiblity, b) Verilog calls the damn thing modulo, and yosys is primarily a Verilog synthesizer
<mwk>
so just add the new cell with some new name (I'm voting for $truemod)
* ZirconiumX
facepalms
<lambda>
can't say I agree, but whatever, it's just naming. I still need to get the functionality for both rem and mod
<mwk>
right
<ZirconiumX>
Can we at least put a comment on $mod pointing out that it is named $mod for historical reasons, then?
<ZirconiumX>
Despite having remainder semantics
<mwk>
fair enough
<mwk>
... right, thanks for the reminder, I forgot to raise *that* issue...
<mwk>
(duplicated cell documentation in the manual/ directory and in the help messages)
<ZirconiumX>
Also, you still have a review pending ^.^
<mwk>
... yes
<lambda>
so everywhere internally it should be $mod and $truemod? or can we at least use $truemod and $rem internally and keep $mod as an official alias for $rem on all outside interfaces?
<mwk>
please don't
<mwk>
that would just add to the confusion
<lambda>
as if using a $mod that isn't actually a mod all over the code wasn't confusing...
<ZirconiumX>
Bikeshedding, I realise, but $modulus might be my pick
<ZirconiumX>
Either way it's not fun
emeb has joined #yosys
peepsalot has quit [Ping timeout: 240 seconds]
<mwk>
daveshah: so about the FF stuff again, my general plan would be to make yosys match all FF types early in the flow (even if unsupported in hw) to aid optimizations (eg we could kill off peepopt_dffmux if we just recognized dffse/dffes in all flows), then call a new `dfflegalize` pass right before abc to ensure only FFs actually supported by the target remain
<mwk>
that dfflegalize pass should replace some per-target custom passes we're currently using (in paritcular for ice40 and ecp5)
<Vinalon>
apparently the "boxes are not in a topological order."
<ZirconiumX>
File a bug
<ZirconiumX>
This is for Eddie to fix
<Vinalon>
okay; I guess I'd better make sure it still happens with the most recent version then, thanks
X-Scale has quit [*.net *.split]
emily has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
kmehall has quit [*.net *.split]
awygle has quit [*.net *.split]
GenTooMan has joined #yosys
emily has joined #yosys
kmehall has joined #yosys
awygle has joined #yosys
X-Scale has joined #yosys
dpiegdon has joined #yosys
<dpiegdon>
hi everyone,
<dpiegdon>
thanks to the developers of yosys and all the other great tools I now use regularly!
<ZirconiumX>
Heh, thank you
<dpiegdon>
I have a question about localparams, I hope you can help me:
<dpiegdon>
I often use a localparam to calculate the number of pins required in a module interface, e.g.: localparam pincount=$clog(max_value). this seems fine, and I can use the value pincount in the module interface: input wire [pincount-1:0] val;
<dpiegdon>
but some functions like $ceil or $sqrt render the value incalculable. if I use those localparams in the module interface, I get an error: ERROR: Failed to detect width for parameter \PINCOUNT!
<dpiegdon>
is this a bug, or is it wanted behaviour? is it even legal to use localparams in the interface? I think many other tools raise an error if I do that. is there a description somewhere in the documentation, which functions are valid, which are not in that context?
<ZirconiumX>
dpiegdon: So, I looked at the LRM, and the answer is that $sqrt and $ceil return real (i.e. float) numbers
<ZirconiumX>
And you need an integer for a bit width
<ZirconiumX>
If you take the Verilog 2005 LRM, Table 17-18 describes the real-math functions
<dpiegdon>
ah! so $ceil is the problem.
<dpiegdon>
I used $ceil(... $sqrt( ...) ), as i though that'd return an int
<dpiegdon>
I'll look into it, thanks!
<Vinalon>
hm...well, I re-built yosys with the most recent version, and the -abc9 option seems to work now, but now my designs end up ~2x as large and won't fit in my target chip, with or without the flag.
<ZirconiumX>
What's your target chip?
<Vinalon>
iCE40UP5K
<ZirconiumX>
I would advise against ABC9 for iCE40
<ZirconiumX>
Use it for ECP5, but not iCE40
<daveshah>
Either way, 2x as large sounds like a definite bug
<Vinalon>
hm, okay - thanks. Regardless, using the latest yosys commit seems like a significant regression from the one that I was using
<ZirconiumX>
Vinalon: What's your input HDL? As in, what are you trying to do with it
<Vinalon>
yeah, I'm in the process of re-building and installing ed4fa19b, where I was. I'm using nMigen, so RTLIL
<ZirconiumX>
I'm wondering if something like -dsp would help
<ZirconiumX>
No, as in "what does it do"
<ZirconiumX>
Like, is it a SoC?
<Vinalon>
oh - yes, it's an RV32I CPU.
<daveshah>
Can you create a GitHub issue with the ilang
<ZirconiumX>
Try passing -dsp to enable multiplier inference, for example
<daveshah>
Regardless of flags, size for a non trivial design shouldn't increase by 2x across regisions
<daveshah>
*revisions
<Vinalon>
sure, I'll generate that and quantify the differences between versions
<daveshah>
Thanks
<Vinalon>
and I haven't quite made it to the multiply/divide extension yet, but it's worth a try :)
<daveshah>
Is there a reduction in the number of SB_RAM40_4Ks?
<dpiegdon>
awesome! so the solution seems to be to use $rtoi($ceil(...)). thanks ZirconiumX !
<Vinalon>
yes, but only from 6 to 4
<ZirconiumX>
That still matters a lot
<daveshah>
Even 2 RAMs means a lot more logic
<daveshah>
The question is why those RAMs are no longer being mapped
<Vinalon>
I mean, the old revision used 6 and the new one uses 4 (but many more LUT4s)
<ZirconiumX>
<daveshah> Even 2 RAMs means a lot more logic
<Vinalon>
well, I'll include the report summaries when I file an issue