<tpb>
Title: asynchronous reset mechanism of D flip-flop in yosys - Page 1 (at www.eevblog.com)
citypw has quit [Ping timeout: 245 seconds]
dys has joined #yosys
rohitksingh_work has quit [Ping timeout: 268 seconds]
_whitelogger has joined #yosys
promach has quit [Ping timeout: 246 seconds]
phire has quit [Ping timeout: 264 seconds]
phire has joined #yosys
dys has quit [Ping timeout: 248 seconds]
emeb_mac has quit [Ping timeout: 245 seconds]
[Ristovski] has joined #yosys
[Ristovski] is now known as Ristovski
cr1901_modern has quit [Ping timeout: 248 seconds]
cr1901_modern has joined #yosys
GoldRin has quit [Read error: Connection reset by peer]
promach has joined #yosys
m4ssi has joined #yosys
promach has quit [Ping timeout: 258 seconds]
gmc has joined #yosys
<gmc>
howdy folks, i was wondering, how do the a << b operators synthesize with yosys? is that even something yosys does, or is that down to arachne-pnr?
<daveshah>
this defines how a shift operator maps to logic
<daveshah>
later passes in Yosys (e.g. abc) will then map this to LUTs
<gmc>
interesting, thanks..
<gmc>
not sure how a for loop would translate into lut's yet though
<daveshah>
This effectively creates muxes using ?:
<daveshah>
Those muxes are then mapped to LUTs further downstream (usually in the abc pass)
<gmc>
i was thinking a case statement, but something along those lines is what i expected
<gmc>
(then again a case would probably become a mux too)
<daveshah>
Yes, nothing is mapped directly a LUT - it all goes through intermdiate logic like muxes and optimisation first
<gmc>
i'm a bit confused as to how 'buffer = {buffer, (2**i)'b0};' is valid verilog though, but i guess this verilog is somehow special or maybe it is legal in some recent iteration of the standards?
<daveshah>
It may not be legal - this file is pretty much Yosys-specific anyway
GoldRin has joined #yosys
<ZirconiumX>
You could probably make it legal through something like `buffer = {buffer, {2**i{1'b0}}}`, right?
<ZirconiumX>
(mostly testing my own knowledge of Verilog here)
<daveshah>
Yes, that looks more correct
<gmc>
i don't think so, i believe the number of repetitions needs to be a constant
<daveshah>
In this case `i` can be considered constant
<gmc>
sure enough, if i try that it gives a 'error: A reference to a wire or reg (`i') is not allowed in a constant expression.'
<gmc>
(or well, iverilog does anyway, should try that with yosys for good measure)
<gmc>
oh vsim also doesn't like it
<ZirconiumX>
i is not a wire or a reg :P
<gmc>
i know that.. you tell iverilog and modelsim that ;)
<gmc>
but indeed, yosys doesn't complain about it..
<gmc>
i'd still like to be able to simulate my hdl before synthesizing though :)
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
brasilino has quit [Remote host closed the connection]
<ZirconiumX>
That's why we have separate models of cells for simulation
<gmc>
oh, i did not know yosys did simulation as well!
<ZirconiumX>
It doesn't, really
<ZirconiumX>
But you can use this to simulate a synthesized design
emeb has joined #yosys
vonnieda has joined #yosys
<pepijndevos_>
So what does the sim command do then, if not simulate?
<daveshah>
It does simulation, but not in the same way as a traditional Verilog simulator
<daveshah>
Yosys doesn't process stimuli, the event model, delays, etc
<daveshah>
instead the sim command allows a simple clock to be specified
<gmc>
hmm some other thing i've been trying to figure out with yosys is why https://pastebin.com/v2xs7bcq gives an error 'Warning: Identifier `\myfoo.BAR' is implicitly declared at implicit.v:35.' and 'Warning: Wire top.\myfoo.BAR is used but has no driver.'
<tpb>
Title: [VeriLog] module foo #( parameter BAR = 3'b111 )( input [2:0] in, output [ - Pastebin.com (at pastebin.com)
<gmc>
iverilog and modelsim are happy about it, and I think the verilog standard allows it, but then again there's so many standards and i'm new to verilog anyways (used vhdl before)
<ZirconiumX>
gmc: BAR is a parameter, not a wire/reg
<gmc>
ok, but if i write 'top_in = 3'b111' it's fine.. once i instantiate a module, isn't the parameter like a constant?
<ZirconiumX>
It's a constant inside the module, I believe
<gmc>
3'b111 is not a wire/reg either
voxadam has quit [Read error: Connection reset by peer]
voxadam has joined #yosys
<ZirconiumX>
I'm pretty sure BAR is out of scope here
<gmc>
hmm i was under the impression that you could always access anything in verilog in the hierarchy by walking through the hieracrhy with dot-seperated paths
<gmc>
and iverilog and modelsim think this is fine again..
* ZirconiumX
digs out the specification
<gmc>
which one? :)
<ZirconiumX>
IEEE 1364-2005
<gmc>
i was looking at 1800-2009, but hadn't found it yet
<ZirconiumX>
Yosys' SystemVerilog support is a bit shaky
<gmc>
i used this to synthesize: yosys -p "read_verilog implicit.v; synth_ice40 -top top -blif top.blif" -q
<tpb>
Title: Internal module wires are not accessible using dot notation · Issue #647 · YosysHQ/yosys · GitHub (at github.com)
<ZirconiumX>
4.10 Parameters
<ZirconiumX>
Verilog HDL parameters do not belong to either the variable or the net group. Parameters are not variables; they are constants.
<ZirconiumX>
In other words, it's not a net
<ZirconiumX>
So if I read this spec correctly, Yosys is correct here and iverilog/modelsim are wrong
<gmc>
interesting (and a bit disappointing :)
<ZirconiumX>
Do you want to define a constant with a name?
<gmc>
yes, i guess i will need to `define instead of (ab)using parameters for this
<ZirconiumX>
Actually parameters are fine for this
<ZirconiumX>
But you want to use `localparam` here
<gmc>
i had that before, but then changed it to parameter because of this implicit definition thing
<ZirconiumX>
For example, in module top, add `localparam FOO = 3'b111;`, and then you can reference `FOO` in `top`.
<daveshah>
I believe hierarchical references are primarily a simulation feature
<daveshah>
They might be valid in synthesis in some of the newer SystemVerilog standards
<gmc>
ah yes, but I want to define the constant values in the module (in my actual design the module is in a different file and `included)
<gmc>
correction, i had localparam, but had to refactor to parameter to satisfy modelsim..
AlexDaniel has quit [Remote host closed the connection]
AlexDaniel has joined #yosys
<corecode>
hm, i can't pass -p and -s at the same time?
<ZirconiumX>
corecode: yes you can
<ZirconiumX>
But -p executes after -s, I believe
<corecode>
doesn't look like, at least not for my version
<ZirconiumX>
Which version do you have?
m4ssi has quit [Remote host closed the connection]
maikmerten has joined #yosys
Jybz has joined #yosys
_whitelogger has joined #yosys
<corecode>
compiled some weeks agin
<corecode>
oh no, chip simulation works, bitstream doesn't work. it does run, but not how i expect it to run - only one out of 6 channels has output
<corecode>
(u4k)
vonnieda has quit [Ping timeout: 246 seconds]
<corecode>
very derp.
<corecode>
mcu fail
vonnieda has joined #yosys
fsasm has joined #yosys
maikmerten has quit [Remote host closed the connection]
Jybz has quit [Quit: Konversation terminated!]
fsasm has quit [Ping timeout: 248 seconds]
<bwidawsk>
so check_label stuff in the script pass serves as both a sync point as well as bookends for the steps in synthesis you wish to run, is that accurate?
<daveshah>
bwidawsk: primarily, it allows you to use -run label or -run from:to
<bwidawsk>
so from a state sense, you can never expect the previous block has run...
<daveshah>
For FPGA synthesis usually it's fair to say any end user would run all the parts
<daveshah>
Partial runs would only be for debugging
<bwidawsk>
daveshah› thanks
<daveshah>
But the only state in the script itself should be the options
<daveshah>
All other state should be in the RTLIL netlist
<daveshah>
It's fair to assume that a previous block has run at some point in time
<daveshah>
But the design might have been dumped to a file and loaded again, for example, maybe for debugging
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
AlexDaniel has quit [Read error: Connection reset by peer]