sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
airwoodix93 has joined #m-labs
airwoodix9 has quit [Ping timeout: 246 seconds]
airwoodix93 is now known as airwoodix9
strobokopp has quit [Ping timeout: 256 seconds]
strobokopp has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
<mtrbot-ml> [mattermost] <astro> zynq eth startup reliability really has degraded in the current codebase :(
<mtrbot-ml> [mattermost] <sb10q> timing related problem? now the code is executing from SDRAM while initializing Ethernet
<mtrbot-ml> [mattermost] <sb10q> so the execution speed is different
<mtrbot-ml> [mattermost] <astro> cold reboots help
<mtrbot-ml> [mattermost] <astro> that's an idea
<mtrbot-ml> [mattermost] <astro> but there shouldn't be anything timing sensitive in the eth driver
<mtrbot-ml> [mattermost] <astro> especially since there wasn't even a timer until very few days ago
<mtrbot-ml> [mattermost] <sb10q> could be a race condition between the cpu writing the registers and something in the hardware
rohitksingh has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 272 seconds]
stroboko1p has joined #m-labs
strobokopp has quit [Ping timeout: 260 seconds]
balrog has quit [Quit: Bye]
mumptai_ has joined #m-labs
balrog has joined #m-labs
mumptai has quit [Ping timeout: 260 seconds]
proteus-guy has quit [Ping timeout: 246 seconds]
mumptai_ has quit [Read error: Connection reset by peer]
mumptai_ has joined #m-labs
mumptai_ has quit [Quit: Verlassend]
mumptai has joined #m-labs
proteusguy has quit [Remote host closed the connection]
mauz555 has joined #m-labs
proteusguy has joined #m-labs
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #m-labs
m4ssi has joined #m-labs
ohsix_ has joined #m-labs
ohsix has quit [Ping timeout: 265 seconds]
<stroboko1p> hi, has anyone looked into https://github.com/m-labs/nmigen/issues/325 yet? I struck it again so I'm investigating a bit
<stroboko1p> I think it happens when a Signal is assigned from a Signal inside an Array of Signals, and another Signal selects which one
<stroboko1p> look at this statement for example: (switch (cat (slice (sig s_sel) 3:4)) (case 1 (eq (slice (sig bus__dat_r) 24:32) (proxy (array [(slice (sig Reg0x40_o_port) 24:32), (slice (sig Reg0x44_o_port) 24:32)]) (sig s_target)))))
<stroboko1p> I'm digging around in python not knowing how nmigen works, but I think what I see is this: a switch, then the only case 1, then an "eq" with this structure:
<stroboko1p> (eq target array[val0,val1] sel)
<stroboko1p> and then this is what rtlil.py works on, right? now that's too deep for me right now, but this is what seems to result from the assignment:
<stroboko1p> (in the rtlil output file) switch sel ; case 1'0 ; assign target val0 ; case 1'- ; assign target val1 ; end
<stroboko1p> in the Verilog output the case 1'- becomes case 2'h?:
<stroboko1p> mhh now I wonder if the case 1'- is RTLIL's way of defining the Verilog "default:" or VHDL "when others =>" case, and yosys doesn't handle it correctly, or if nmigen generates wrong RTLIL
mauz555 has quit [Ping timeout: 265 seconds]
mauz555 has joined #m-labs
mauz555_ has joined #m-labs
mauz555 has quit [Ping timeout: 272 seconds]
mauz555_ has quit []
mauz555 has joined #m-labs
_whitelogger has joined #m-labs
mtrbot-ml has joined #m-labs
silipwn has joined #m-labs
noopwafel has joined #m-labs
sb0 has joined #m-labs
m4ssi has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]