Saturday, 2019-05-18

*** tpb has joined #yosys00:00
*** citypw has quit IRC00:41
*** voxadam has quit IRC01:24
*** voxadam has joined #yosys01:25
*** phire has quit IRC02:07
*** emeb_mac has joined #yosys02:08
*** gsi__ has joined #yosys02:09
*** gsi_ has quit IRC02:12
*** bwidawsk has quit IRC02:35
*** bwidawsk has joined #yosys02:40
*** futarisIRCcloud has joined #yosys02:41
*** PyroPeter has quit IRC02:51
*** citypw has joined #yosys02:55
*** emeb has quit IRC02:55
*** PyroPeter has joined #yosys03:05
*** citypw has quit IRC03:21
*** citypw has joined #yosys03:23
*** vonnieda has joined #yosys03:32
*** proteusguy has joined #yosys03:46
*** phantomcircuit has joined #yosys03:57
*** citypw has quit IRC03:57
*** jevinskie has joined #yosys04:54
*** loxodes has quit IRC05:32
*** _whitelogger has quit IRC05:38
*** jevinskie has quit IRC05:39
*** _whitelogger has joined #yosys05:40
*** emeb_mac has quit IRC07:16
*** rohitksingh has joined #yosys07:49
*** _whitelogger has quit IRC07:59
*** mms has joined #yosys08:01
*** _whitelogger has joined #yosys08:01
*** maikmerten has joined #yosys08:28
*** dys has joined #yosys08:29
*** _whitelogger has quit IRC08:35
*** _whitelogger has joined #yosys08:37
*** gnufan_home has joined #yosys08:40
*** rohitksingh has quit IRC08:53
*** rohitksingh has joined #yosys08:54
*** maikmerten has quit IRC09:16
*** gnufan_home has left #yosys09:34
*** togo has joined #yosys09:34
*** rohitksingh has quit IRC09:39
*** maikmerten has joined #yosys10:22
*** dys has quit IRC10:36
*** vid has joined #yosys10:42
*** hacking4fun has joined #yosys10:45
*** mms has quit IRC10:47
*** vid has quit IRC11:21
*** maikmerten has quit IRC11:29
*** hacking4fun has quit IRC11:34
*** Jybz has joined #yosys11:38
*** citypw has joined #yosys11:48
*** _whitelogger has quit IRC12:29
*** _whitelogger has joined #yosys12:31
*** emeb has joined #yosys12:56
*** MoeIcenowy has quit IRC13:00
*** MoeIcenowy has joined #yosys13:01
*** vid has joined #yosys13:32
tntAny verilog semantics expert in the audience ?13:46
tpbTitle: VexRiscv-Min variant misbheaving · Issue #7 · m-labs/VexRiscv-verilog · GitHub (at
tntIs the simulator wrong, or is this unspecified ...13:46
*** vid has quit IRC13:49
emebThat's a tricky one.13:55
tntif it was obvious, I wouldn't be asking :P13:56
emebOf course!13:57
emebDigging around in my copy of Thomas & Moorby doesn't give any good insight into this.14:20
emeb(Of course it's not the greatest reference on Verilog, but they did create the language...)14:21
tntYeah I tried reading the specs and ... I'm really not more informed than before either :p14:37
emebI found a SNUG paper by Sutherland from long ago that looked like it might have some insight, but no...14:52
ZipCPUI just looked through the issue and I'm struggling to understand the core of the issue14:55
ZipCPUIs there a statement misbehaving?  Or a question of Verilog?14:55
tntZipCPU: 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'.14:57
tntAnd 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.14:58
ZipCPUIs that because cmd_valid and _halt are set in the same blcok?14:58
tntyes. if you split them or if you set _valid at the beginning, it works as expected.14:58
ZipCPUSo ... 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 dependencies14:59
emebProbably 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.15:00
tntthat's the question ...15:00
tntemeb: well valid doesn't depend on valid.15:00
ZipCPUI've seen several examples of what would otherwise be combinatorial processes placed together into one, and so declared as no longer feedback loops15:00
ZipCPUSo, 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 statements15:01
ZipCPUThe simulator trusts you (the engineer) to have sorted our the dependencies15:01
emebtnt: oh - misread that then.15:02
*** Jybz has quit IRC15:29
*** Jybz has joined #yosys15:29
*** emeb has left #yosys15:57
*** futarisIRCcloud has quit IRC16:21
*** rohitksingh has joined #yosys16:21
*** pointfree has joined #yosys16:21
*** emeb_mac has joined #yosys16:25
*** emeb_mac has quit IRC16:40
*** rohitksingh has quit IRC17:23
*** dys has joined #yosys19:18
*** vonnieda has quit IRC20:10
*** vonnieda has joined #yosys20:27
*** _whitelogger has quit IRC20:38
*** vonnieda has quit IRC20:39
*** vonnieda has joined #yosys20:40
*** _whitelogger has joined #yosys20:40
*** emeb_mac has joined #yosys22:07
*** dys has quit IRC22:52
*** _whitelogger has quit IRC22:56
*** _whitelogger has joined #yosys22:58
*** TFKyle has quit IRC23:05
*** Jybz has quit IRC23:12
*** citypw has quit IRC23:52

Generated by 2.13.1 by Marius Gedminas - find it at!