strongsaxophone has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
<tux3>
Fun fact, the port syntax with a size but the direction in a separate statement doesn't seem to be supported by Yosys
<tux3>
i.e. "module m( X[40:0] ); output [50:0] X;"
<tux3>
Not sure if this is a bug. I found this code online, apparently VCS accepts it...
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #yosys
citypw has joined #yosys
Vinalon has quit [Ping timeout: 256 seconds]
Vinalon has joined #yosys
_whitelogger has joined #yosys
ZipCPU has quit [Ping timeout: 268 seconds]
ZipCPU has joined #yosys
_whitelogger has joined #yosys
emeb_mac has quit [Quit: Leaving.]
dys has quit [Ping timeout: 250 seconds]
<corecode>
<3 online code
Vinalon has quit [Remote host closed the connection]
jakobwenzel1 has joined #yosys
Vinalon has joined #yosys
rswarbrick has joined #yosys
<rswarbrick>
Hi all! A question about SymbiYosys internals: When making a model in sby_core.py, SymbiYosys uses "hierarchy -simcheck". This doesn't allow blackbox blocks. Hacking out the check, I can blackbox internals to simplify verification. Is there a reason it's needed?
<daveshah>
aiui the SMT backend, etc, will error out on blackbox modules as it doesn't know how to implement them
<daveshah>
If you just want the inputs to be "don't care" and the outputs unconstrained, just ifdef ing out the instantiation should work
<daveshah>
Or using a parameter and generate/if
<rswarbrick>
Huh, that's odd. It seemed to work here. I'll mess around with my local hack for a bit and come back with results!
<daveshah>
Oh, if I'm wrong and the SMT backend is happy to ignore them then adding a flag to disable this check could be a useful patch
Vinalon has quit [Ping timeout: 250 seconds]
<daveshah>
I don't think this should be default behaviour as it could cause a lot of confusion if someone forgets a read_verilog line, for example
<rswarbrick>
daveshah: A flag, rather than changing -simcheck to -check?
<daveshah>
A flag in the sby file
<daveshah>
something like ignore_blackboxes on
<rswarbrick>
daveshah: I understand. But doesn't "hierarchy -check" die if I forget a read_verilog line too? (Or is there no difference between a blackbox module and one where I haven't read the file?)
<daveshah>
Oh yeah, that should be OK actually
<rswarbrick>
daveshah: Ah. It seems that dumping the SMT code was fine, but yosys-smtbmc dies horribly. :-(
<daveshah>
It would still be a problem if someone accidentally does something like read_verilog -lib
<rswarbrick>
Looks like I've got some actual work to do!
<daveshah>
If you remove the blackbox attribute then you end up with a genuinely empty module (note that the Verilog frontend makes empty modules blackboxes by default)
<daveshah>
I guess you want unconstrained outputs, which an empty module should have without the issues of a blackbox
<rswarbrick>
Oh, that makes sense. Is there a command that I can issue to do that?
<rswarbrick>
So "blackbox foo", then "???"
<daveshah>
setattr -mod -unset blackbox foo
<rswarbrick>
Brilliant! It works! :-D
dys has joined #yosys
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
develonepi3 has quit [Remote host closed the connection]
rswarbrick has quit [Ping timeout: 240 seconds]
develonepi3 has joined #yosys
Vinalon has joined #yosys
Vinalon_ has joined #yosys
Vinalon has quit [Read error: Connection reset by peer]
Vinalon_ is now known as Vinalon
seraxis has quit [Quit: おやすみ]
seraxis has joined #yosys
N2TOH_ has quit [Ping timeout: 240 seconds]
N2TOH has joined #yosys
proteusguy has quit [Remote host closed the connection]
indy has quit [Ping timeout: 265 seconds]
Laksen has joined #yosys
develonepi3 has quit [Quit: Leaving]
indy has joined #yosys
emeb has joined #yosys
<thardin>
more questions about multiplication: does yosys do certain optimizations when squaring compared to regular multiplication? and: where roughly in the code is this done?
<thardin>
nm, $mul is the magical thing to search for
citypw has quit [Ping timeout: 264 seconds]
Vinalon has quit [Ping timeout: 260 seconds]
Vinalon has joined #yosys
<ZirconiumX>
thardin: a lot can be done with simple constant evaluation
<thardin>
not if the operands aren't constants :]
Laksen has quit [Quit: Leaving]
<thardin>
is it satgen that actually generates it?
<thardin>
alumacc.cc looks promising
<ZirconiumX>
alumacc turns $mul into $macc
<ZirconiumX>
However mul2dsp turns $mul to a given fixed-width multiply
<ZirconiumX>
And everything with DSP support uses it
<thardin>
hum
<ZirconiumX>
thardin: but no, it can still optimise it by knowing the signals are the same
<thardin>
sounds promising
<ZirconiumX>
A soft multiplier is a bunch of shifts and adds
<ZirconiumX>
The shifts are free because they're constants
<thardin>
another q: I see in rtlil.cc that addMul get max(sig_a.size(), sig_b.size()) to y_size. does this mean I have to put in a "cast" or something for say a 16x16 to result in a 32-bit result?
<ZirconiumX>
Yes: Verilog has very odd expression restrictions
<daveshah>
In this case though I think it should auto size to the size of the result
<daveshah>
So long as q is 32 bit, assign q = a*b; should work
<daveshah>
I guess that addMul isn't used by the frontend
<thardin>
but if I use the intermediate result in an operation then it won't?
<thardin>
in other words, I have to go via a wire or something to be sure I get the right result?
<daveshah>
It depends, tbh
<ZirconiumX>
From earlier: the adds are XORs and ANDs; X ^ X = 0; X & X = X, so you can still optimise based on the knowledge that two signals are identical
<daveshah>
I would recommend using a wire of the right size always
<thardin>
bhasker's primer on verilog didn't mention this unfortunately
<daveshah>
The automatic sizing rules are a bit of a law unto themselves
<thardin>
I guess "upsizing" should always work since the optimizer will trim it appropriately
<Sarayan>
rtlil needs some kind of "there two signals will never be 1 together"
<Sarayan>
I'm sure it can hlep optimizations
<daveshah>
You could add an assertion easily enough
<daveshah>
assertion-driven optimisation would be interesting
<thardin>
heh, the $pow implementation only does 1<<x
<ZirconiumX>
Pow is not cheap in hardware
<whitequark>
combinatorial pow, anyway
<Sarayan>
Hey, hi whitequark, long time no see
<whitequark>
hi
<Sarayan>
how are things for you, bearable?
<whitequark>
not particularly
<Sarayan>
damn
<thardin>
I'd expect x**2 to work tho
<thardin>
maybe x**3
<daveshah>
The synthesis standard 1364.1 says
<daveshah>
> The power operator (**) shall be supported only when both operands are constants or if the first operand is2
<thardin>
ah. aw
<daveshah>
Admittedly, 1364.1 is semi-obsolete but there has never been a subsequent definitive specification of what is synthesisable
<thardin>
but: I see there's some shift and add logic in satgen, is that what actually generates the multiplication?
<daveshah>
so, it's really the best guide to this kind of thing
<daveshah>
No, satgen is only used for SAT-solver-based passes
<daveshah>
It's a combination of alumacc and techmap that generate (soft) multiplication
<daveshah>
and maccmap
<thardin>
let's see.. alumacc turns $mul into $alu. and maccmap doesn't have much to do with multiplication per se
<daveshah>
maccmap has a lot to do with multiplication
<daveshah>
macc is an internal multiply and add cell that is created by alumacc
<daveshah>
maccmap creates alu cells that then either become hard carry logic (in FPGA) or soft adder logic (otherwise)
<thardin>
ah perhaps I shouldn't try to search for just "mul" in maccmap
<thardin>
giving it a read now, thanks for pointing the way :)
<thardin>
so if I understand correctly it's the somewhat confusingly named void add(RTLIL::SigSpec a, RTLIL::SigSpec b, bool is_signed, bool do_subtract) that actually does it
<thardin>
called further down by worker.add(port.in_a, port.in_b, port.is_signed, port.do_subtract);
<thardin>
staring a bit more at it, I think it'll end up doing the more clever thing because of the way add() works
<thardin>
since a[i]*b[j] == a[j]*b[i]
<thardin>
doing anything other than long multiplication in there is bound to get very hairy so best stick to doing other algos at the verilog level
elGamal has quit [*.net *.split]
Stary has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
gorbak25 has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
gmc has quit [*.net *.split]
dxld has quit [*.net *.split]
MoeIcenowy has joined #yosys
gmc has joined #yosys
kbeckmann has joined #yosys
Stary has joined #yosys
dxld has joined #yosys
gorbak25 has joined #yosys
<thardin>
a fun little dive into yosys internals anyway :)
<ZirconiumX>
Why keep it at a "little" dive? :P
elGamal has joined #yosys
jakobwenzel1 has quit [Quit: jakobwenzel1]
<ZipCPU>
ZirconiumX: Lol :D
<thardin>
:p
<thardin>
gotta relax a bit too
gmc has quit [Remote host closed the connection]
jfcaron has joined #yosys
jfcaron has quit [Ping timeout: 264 seconds]
jfcaron has joined #yosys
Vinalon has quit [Ping timeout: 260 seconds]
Vinalon has joined #yosys
emeb_mac has joined #yosys
sensille has joined #yosys
<sensille>
strange. when i initialize a reg for an output port, the design goes up from 11k slices to 33k slices on ecp5. it works fine without initialization, though
<ZirconiumX>
Are you using ABC9?
<daveshah>
Yosys doesn't support initialised BRAM
<daveshah>
*initialised BRAM output registers
<sensille>
ZirconiumX: i don't know, do i have to do anything to do that?
<sensille>
"Running ABC command"
<sensille>
yosys-abc
<daveshah>
I doubt abc has anything to do with this
<daveshah>
abc9 is enabled by adding -abc9 to synth_ecp5, it can reduce design area
<daveshah>
But this seems more like a RAM inference issue
<sensille>
hm. it could be possible one of the outputs is directly linked to a bram output, sec
<daveshah>
Yes, initialisation on bram output will cause inference to fail
<sensille>
there should be one register in between
<sensille>
but yes, bram is gone
<daveshah>
Do you mean one register and that's it, or one register in addition to the usual synchronous read port
<sensille>
so maybe the design is already unnecessary large because i initialize nearly everything
<daveshah>
Yeah, it's one of many bram issues in Yosys unfortunately
<daveshah>
BRAM read ports shouldn't be initialised atm
<daveshah>
Otherwise it will use LUTRAM instear
<daveshah>
*instead
<sensille>
there's an addition register
<daveshah>
It should be fine to initialise that
<daveshah>
Just not the first register
<sensille>
but i've accidentally declared the signal as register and initialized it twice in the hierarchy. strange
<sensille>
it's still somehow linked to BRAM
<daveshah>
The hierarchy is flattened early on
<daveshah>
So even if the initialisation is somewhere else then it may still be attached to the BRAM output
<sensille>
now i still initialize it on the bottom of the hierarchy and it's fine
<sensille>
ok, thanks for the hint
pie_[bnc] has quit [Quit: No Ping reply in 180 seconds.]
kristianpaul has quit [Ping timeout: 260 seconds]
kristianpaul has joined #yosys
pie_[bnc] has joined #yosys
Vinalon has quit [Remote host closed the connection]