clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
citypw has quit [Ping timeout: 258 seconds]
voxadam has quit [Read error: Connection reset by peer]
voxadam has joined #yosys
phire has quit [Ping timeout: 264 seconds]
emeb_mac has joined #yosys
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 255 seconds]
bwidawsk has quit [Quit: Always remember, and never forget; I'll be back.]
bwidawsk has joined #yosys
futarisIRCcloud has joined #yosys
PyroPeter has quit [Ping timeout: 248 seconds]
citypw has joined #yosys
emeb has quit [Quit: Leaving.]
PyroPeter has joined #yosys
citypw has quit [Read error: Connection reset by peer]
citypw has joined #yosys
vonnieda has joined #yosys
proteusguy has joined #yosys
phantomcircuit has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
jevinskie has joined #yosys
loxodes has quit [Quit: WeeChat 1.4]
_whitelogger has joined #yosys
emeb_mac has quit [Ping timeout: 258 seconds]
rohitksingh has joined #yosys
_whitelogger has joined #yosys
maikmerten has joined #yosys
dys has joined #yosys
_whitelogger has joined #yosys
gnufan_home has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #yosys
maikmerten has quit [Remote host closed the connection]
gnufan_home has left #yosys [#yosys]
togo has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
maikmerten has joined #yosys
dys has quit [Ping timeout: 258 seconds]
vid has joined #yosys
hacking4fun has joined #yosys
mms has quit [Ping timeout: 246 seconds]
vid has quit [Ping timeout: 255 seconds]
maikmerten has quit [Quit: Verlassend]
hacking4fun has quit [Quit: Leaving]
Jybz has joined #yosys
citypw has joined #yosys
_whitelogger has joined #yosys
emeb has joined #yosys
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
vid has joined #yosys
<tnt> Any verilog semantics expert in the audience ?
<tpb> Title: VexRiscv-Min variant misbheaving · Issue #7 · m-labs/VexRiscv-verilog · GitHub (at github.com)
<tnt> Is the simulator wrong, or is this unspecified ...
vid has quit [Ping timeout: 258 seconds]
<emeb> That's a tricky one.
<tnt> if it was obvious, I wouldn't be asking :P
<emeb> Of course!
<emeb> Digging around in my copy of Thomas & Moorby doesn't give any good insight into this.
<emeb> (Of course it's not the greatest reference on Verilog, but they did create the language...)
<tnt> Yeah I tried reading the specs and ... I'm really not more informed than before either :p
<emeb> I found a SNUG paper by Sutherland from long ago that looked like it might have some insight, but no...
<ZipCPU> I just looked through the issue and I'm struggling to understand the core of the issue
<ZipCPU> Is there a statement misbehaving? Or a question of Verilog?
<tnt> ZipCPU: If you look at the screenshot you'll see the _halt signal is '1'. But if you look at the verilog, you might expect it to be '0'.
<tnt> And that's because in the verilog process it sets IBusSimplePlugin_cmd_valid to 0 after it was evaluated and caused IBusSimplePlugin_iBusRsp_stages_0_halt to be '1'. And iverilog apparently doesn't re-run that process after.
<ZipCPU> Is that because cmd_valid and _halt are set in the same blcok?
<tnt> yes. if you split them or if you set _valid at the beginning, it works as expected.
<ZipCPU> So ... isn't that how simulation is supposed to work though? The blocking statements in the always block get executed in order, and you (the designer) are supposed to handle any dependencies
<emeb> Probably a red herring, but I'm bothered by a combinatorial process that modifies a signal based on the state of that signal. Seems like that's ripe for zero-delay feedback problems.
<tnt> that's the question ...
<tnt> emeb: well valid doesn't depend on valid.
<ZipCPU> I've seen several examples of what would otherwise be combinatorial processes placed together into one, and so declared as no longer feedback loops
<ZipCPU> So, if you have two signals whose dependencies intertwine, and you place them within the sample always @(*) block, you (as the engineer) are supposed to deconflict the dependencies with the order of the statements
<ZipCPU> The simulator trusts you (the engineer) to have sorted our the dependencies
<emeb> tnt: oh - misread that then.
Jybz has quit [Ping timeout: 258 seconds]
Jybz has joined #yosys
emeb has left #yosys [#yosys]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined #yosys
pointfree has joined #yosys
emeb_mac has joined #yosys
emeb_mac has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 252 seconds]
dys has joined #yosys
vonnieda has quit [Ping timeout: 252 seconds]
vonnieda has joined #yosys
_whitelogger has joined #yosys
emeb_mac has joined #yosys
dys has quit [Ping timeout: 268 seconds]
_whitelogger has joined #yosys
TFKyle has quit [Quit: :q!]
Jybz has quit [Ping timeout: 246 seconds]
citypw has quit [Ping timeout: 258 seconds]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
togo has quit [Quit: Leaving]