<sb0>
it's interesting that the MCH asks for a password for the web interface, but not for the natview interface. if you speak the natview protocol, you are trusted?
<whitequark>
sb0: maybe that's why it's udp
<sb0>
i also wonder how many buffer overflows and other vulns this thing has
<sb0>
whitequark: firewalls can equally block (or not) tcp and udp
<whitequark>
do you have a binary of the firmware there?
<sb0>
ftp://natmch:natmch@ftp.nateurope.com
<whitequark>
the... archive is password-protected?
<whitequark>
including the release notes and update instructions?
<sb0>
possibly. if you want to try recovering from the device, it's up - tschernobyl.lab.m-labs.hk
<sb0>
please just don't break it
<whitequark>
ahahaha great name
<whitequark>
no i'll just run john the ripper on the zip
<whitequark>
i mean, it starts off like they're using cgi scripts with gets() or something
<sb0>
wtf, vivado doesn't crash anymore after I ran the exact same command again
<key2>
lol
<key2>
have u checked ur memory ?
<acathla>
C'est tombé en marche (I don't know the english for this) !
<d_n|a>
sb0: drtio destination 0 is always supposed to be local RTIO, right? I'll fix up the get_rtio_destination_status() calls in the examples, then
<sb0>
d_n|a: no, you can put local RTIO anywhere using the routing table
<sb0>
local RTIO is not special
<sb0>
it doesn't even have to be hop 0 in the gateware, though that's a sensible convention
<d_n|a>
sb0: Sorry, I was being imprecise; what I meant is that it should be exposed somewhere as a user-facing destination
<sb0>
well, you don't even have to have local RTIO channels
<d_n|a>
All the busy-wait loops that previously were get_drtio_link_status are now off by one (assuming default routing tables)
<sb0>
and get_drtio_link_status() on local RTIO returns True as it should
<sb0>
so that's not a problem
<sb0>
*get_rtio_destination_status
<d_n|a>
Agreed, not a problem. It's just that s/get_drtio_link_status/get_rtio_destination_status/g isn't enough; the index also needs to be shifted by one (assuming default routing tables)
<sb0>
it doesn't need to, the destination number is abstract
cr1901_modern1 has joined #m-labs
<d_n|a>
I'm just talking about the examples/previous DRTIO user code
<sb0>
yes. it is valid to call get_rtio_destination_status() on a destination number which is then mapped to local RTIO by the routing table.
<sb0>
or are those examples failing to check status for a destination that they then use?
cr1901_modern has quit [Ping timeout: 250 seconds]
<d_n|a>
sb0: The loops in e.g. examples/kasli_sawgmaster are now off by one. I'll fix it
<_whitenotifier-e>
[nmigen] 104player opened issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZT4
Xark has quit [Ping timeout: 245 seconds]
<_whitenotifier-e>
[nmigen] 104player commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTB
<_whitenotifier-e>
[nmigen] 104player deleted a comment on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTB
<_whitenotifier-e>
[nmigen] 104player commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTR
<_whitenotifier-e>
[nmigen] whitequark commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTE
Xark has joined #m-labs
<adamgreig>
whitequark: I've definitely hit that ^ error in #23 a few times when trying to hook up top level modules
<adamgreig>
mostly when doing ill advised things with Fragment though so..
<whitequark>
adamgreig:
<whitequark>
the root cause is I can't write a proper Select condition for yosys
<whitequark>
the problem is that i don't even know what's wrong
<whitequark>
i should just remove that check, it's no longer relevant
<d_n|a>
sb0: Seems like timing is marginal again - the above failing change is a noop gateware-wise
Gurty has quit [Ping timeout: 252 seconds]
mumptai has quit [Quit: Verlassend]
<_whitenotifier-e>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhZLq
<_whitenotifier-e>
[nmigen] whitequark closed issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZT4
<adamgreig>
whitequark: should I have to manually specify the ports for my top-level module, either when doing rtlil.convert or with Fragment.add_ports, or should it be inferred?
<whitequark>
manually in rtlil.convert
<whitequark>
outputs will never be inferred
<adamgreig>
ack
<whitequark>
and i think inferring inputs should not be always done either
<adamgreig>
yea that's fine, i can easily enough track which ports i need
<adamgreig>
in my top module i'm frag=m.lower(platform) and then frag.add_ports(...) so that the fragment i return already has ports, is that ok?
<adamgreig>
since i then pass it back up and rtlil and verilog convert it and would rather the thing above not know about the ports