<sb0>
disabling the dummy signals for synthesis is OK, but this...?
<sb0>
won't this break reset_less clock domains that use bitstream initialization of flip-flops?
<_florent_>
it's still the issue with the initial not supported by Synplify Pro...
<sb0>
I'm pretty sure this also breaks simulations, as the "always @(*)" won't get executed at the beginning (unlike initial) and thus the corresponding signals won't get initialized
<sb0>
what about using the "reg signal = reset_value;" syntax? does synplify grok that?
<sb0>
it's equivalent to initial begin, unlike what you have done
* sb0
thinks we should have unittests for all those verilog corner cases, so that such patches immediately bomb
<_florent_>
before reading the infos you posted on the IRC, I've implemented this
<_florent_>
the idea is to keep initial when supported by tools, and use alternatives when not supported...
<_florent_>
(that's just some infos for our discussion)
<sb0>
sounds more painful than only using the set of features that all proprietary shitware will support...
<sb0>
xilinx ise does support $readmemh
<_florent_>
it's ok for quartus too
<sb0>
icarus verilog also supports it
<sb0>
so, in that case, drop initial blocks for BRAM completely
<sb0>
= less complexity, less code to maintain
<_florent_>
Yes I aggree
<_florent_>
can I use .init extention for memory initialization files?
<_florent_>
extension
<sb0>
sounds good.
<sb0>
the second (pretty unrelated) problem is initializing _registers_ at bitstream load
<sb0>
using always @* will break simulations (unless you use one of those dummy signals to get the block to run once at the beginning), and I'm not sure that all synthesizers will understand it
<sb0>
it's also counter-intuitive code. always @* is typically for describing comb logic, not resetting registers
<sb0>
what about the "reg name = init_value" syntax? it works with ISE
<sb0>
is not counter-intuitive, and is equivalent to the initial block
<sb0>
iirc icarus verilog also groks it
<_florent_>
yes, I was not aware of that syntax, if it works I totally aggree
<sb0>
it seems that with systemverilog you can also initialize block RAMs with that syntax, which would alleviate the pain of managing multiple output files
<sb0>
but I don't know anything about tool support.
<sb0>
_florent_, can I revert that part of your patch that does the always @*? we should try to get the migen fhdl backend to output correct code at all times...
<_florent_>
yes you can
<_florent_>
(or I can do it)
<GitHub7>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/hcrd
<GitHub7>
migen/master bdc47b2 Sebastien Bourdeauducq: Revert "fhdl/verilog: do not use initial begin in _printinit (not accepted by all synthesis tools ex: Synplify Pro does not accept it)"...
<_florent_>
OK thanks
<sb0>
I'm pretty sure synplify would support something like "reg name = value" for reg init... that's definitely a desirable fpga feature
<_florent_>
going to try that
<sb0>
_florent_, btw, instead of removing the dummy signals from the fhdl output
<sb0>
would it work to encapsulate the offending code in "// synthesis translate_{off,on}" pseudocomments?
<sb0>
this way we have a single output for both simulation and synthesis. would be useful to export migen cores for use in non-migen designs...
<_florent_>
in fact this dummy signal is only specific to Icarus verilog, we should maybe try to fix Icarus or report this behaviour
<_florent_>
this way we can remove all this, because it's fine with Verilator
<sb0>
it's not only specific to icarus verilog... it's the verilog standard
<sb0>
verilator is the one that doesn't apply the standard here for performance reasons
<_florent_>
with modelsim or others commercial simulator this dummy signal is also needed?
<sb0>
the purpose of the dummy signal is to get the always @* blocks to run once at the beginning of the design, and initialize those combinatorial signals that are declared as regs
<sb0>
any event-driven Verilog simulator will need it, I believe
<_florent_>
not sure this is clearly specified in the standard, but you can also revert this patch if you want
<sb0>
the Verilog standard says that blocks are only run when signals in their sensitivity lists change value
<sb0>
without the dummy signal, there is no solid reason for those blocks to be run at design initialization
<sb0>
it works with verilator only because it's a cycle-driven simulator, i.e. it has the same comb/sync separation that migen has
<sb0>
but the verilog standard is event-driven
<sb0>
the idea of disabling the dummy signal for synthesis is fine, especially if it breaks some synthesizers
<sb0>
I'm just suggesting a potential better way of disabling it, which would enable us to keep the same verilog output file for both simulation and synthesis
<sb0>
and also, get rid of some function arguments in migen
<sb0>
_florent_, the question is: if you do this with the lattice tools
<sb0>
// synthesis translate_off
<sb0>
initial begin {...some code that breaks the synthesizer}
<sb0>
// synthesis translate_on
<_florent_>
should be OK
<sb0>
will it still fail to synthesize the design, or will it just ignore the offending bit?
<sb0>
OK. so I propose we revert your patch, and simply add those // synthesis pseudocomment around the dummy signal stuff.
<_florent_>
yes
<_florent_>
you do it?
<sb0>
I don't have the lattice tools... can you do it? (so you can double-check it works)
<sb0>
if the lattice tools act up, we can keep your patch
<_florent_>
yes I'll do it
<_florent_>
thanks
_florent_ has quit [Quit: Leaving]
aeris_ has quit [Quit: en a pas]
aeris_ has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
_florent_ has joined #m-labs
<GitHub72>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/hCul
<GitHub72>
migen/master 2fc2f8a Florent Kermarrec: migen/genlib/io: use 0 instead of Signal() for default rst value (immutable thanks sb)
antgreen has joined #m-labs
aeris_ has quit [Ping timeout: 245 seconds]
aeris_ has joined #m-labs
<ysionneau>
hum, when I spawn an asyncio Task and send the request to influxdb, each time I leak one page of heap
<ysionneau>
if I remove the influxdb request, then memory is stable
_florent_ has quit [Quit: Leaving]
Gurty has quit [Read error: Connection reset by peer]
Gurty has joined #m-labs
<ysionneau>
it even leaks with explicit calls to gc.collect() (that was just for testing), and even following the advice I saw about aiohttp to always flush response buffer by doing yield from response.release()