<GitHub76>
sinara/master e56bb59 Paweł: Kasli - all extensions routed
<whitequark>
sb0: some
<whitequark>
I'm figuring out the various MIIs
<whitequark>
is there a reason liteeth ignores RXERs?
<whitequark>
shouldn't that result in immediately dropping any attempt to decode the frame?
<sb0>
no. likely packets should be dropped when rxer has been asserted within them. _florent_ any comment?
<whitequark>
other than that let me commit and push my counters stuff
<sb0>
on the other hand, this should have little/no practical impact, since packets corrupted at the physical level are virtually guaranteed to fail ethernet CRC
<whitequark>
sb0: what about the case where the ethernet core continues to process what it thinks is a packet and as a result misses the preamble of another one?
<sb0>
is there such a case?
<whitequark>
I'm not sure
<whitequark>
I'm thinking about the reasons the bug can manifest
<sb0>
I think ethernet has an interframe gap of many cycle that should prevent this from happening
<whitequark>
ok
<sb0>
is the bug due to the ethernet core dropping frames, or some tcp software issue?
<whitequark>
we've figured that it's not a TCP issue long ago
<whitequark>
it's not reproducible on any hardware I tested it though
<whitequark>
only cjbe's hardware
<whitequark>
so now I'm adding various counters that will increase if the core drops packets for some reason
<whitequark>
well, added
<sb0>
any hardware you tested = the 100M and 1G switches in the lab?
<whitequark>
yes, and rjo's switch also has a different model
<whitequark>
from those which fail
<sb0>
whitequark, can you write that down in the issue and ask that they send us problematic switches?
<whitequark>
ok
<GitHub118>
[smoltcp] dlrobertson commented on issue #66: The destination address is not checked to see if it is the broadcast address before sending ICMP error responses currently (RFC 1122 § 3.2.2). Currently this conditional is the only thing keeping us from causing a broadcast storm due to a weird broadcast packet. The specific panic is [here](https://github.com/m-labs/smoltcp/blob/master/src/iface/ethernet.rs#L369), and is due to the packet created for
<GitHub0>
[smoltcp] whitequark commented on issue #66: @dlrobertson Wow, your tests already paid off. Thanks a lot! https://git.io/vFLbI
calle__ has joined #m-labs
mumptai_ has quit [Ping timeout: 248 seconds]
<whitequark>
sb0: btw what's no_retiming?
<shuffle2>
is it better to use DifferentialOutput or just OBUFDS? DifferentialOutput seems nice as it's theoretically cross platform, right? can't get it to work tho :p
<shuffle2>
seems most m-labs code just uses OBUFDS directly
<sb0>
whitequark, it prevents the synthesizer from moving combinatorial logic across the register, i.e. the signal to which it is applied should be a direct D flip-flop output
<sb0>
shuffle2, please give precise descriptions of problems instead of "can't get it to work" etc.
<cr1901_modern>
sb0: What type of optimization would move a signal from "direct D flip-flop output"? I'm sure there are a few
<sb0>
retiming
<cr1901_modern>
Oh, hence "no_retiming"
<cr1901_modern>
Makes sense
<cr1901_modern>
what does "shreg_extract" do since both are required for CDCs
<cr1901_modern>
(or at the very least you force-emit code w/ both of them)
<sb0>
prevents use of SRL16/SRL32 primitives which have poor metastability resistance
<whitequark>
sb0: are attributes like no_retiming portable?
<whitequark>
i.e. can I put one in liteeth?
<sb0>
whitequark, yes, in theory they are, i.e. if the backend implements them properly
<cr1901_modern>
no_retiming is not a Xilinx-ism?
<sb0>
retiming is not a xilinx invention
<sb0>
srl16 is, but on platforms that don't have this kind of thing the attribute can simply be ignored
<cr1901_modern>
I'm sure it's not an Xilinx invention but, I'm asking if other synthesizers will bitch.
<sb0>
the backend in migen.build is supposed to insert the appropriate constraints for each synthesizer
<cr1901_modern>
Oh that's what you mean by "if the backend implements them properly"?
<cr1901_modern>
e.g. for instance, icestorm backend doesn't support MultiReg (or AsyncResetSynchronizer for that matter) b/c I never added the MultiRegImpl for it
<cr1901_modern>
whitequark: i.e. can I put one in liteeth? <-- you mean, like `foo = Signal(attr="no_retiming")`, correct?
<whitequark>
yes
<cr1901_modern>
whitequark: Taking a quick look, for eg yosys, I can't find any indication "no_retiming" is support (ditto w/ arachne-pnr). So it's prob ignored.
<sb0>
no one is taking care of the yosys backend. does it work?
<sb0>
yes but it's been replaced
<cr1901_modern>
sb0: Yes, it works fine.
<whitequark>
yosys doesn't do retiming
<whitequark>
that needs feedback from timing analysis, right?
<cr1901_modern>
My point is whether it causes synthesis to fail
<sb0>
or some heuristics ...
<cr1901_modern>
i.e. yosys bombs w/ an error saying "I don't understand this attribute, so I won't continue"
<whitequark>
no
<cr1901_modern>
sb0: "no one is taking care of the yosys backend." Did you mean icestorm or Xilinx flow?
<sb0>
both
<cr1901_modern>
icestorm works fine. Do you want something added in particular? I'll send a patch if so.
rohitksingh has joined #m-labs
<cr1901_modern>
Can't impl MultiReg b/c no support. I could do AsyncResetSynchronizer though.
<whitequark>
no support for what?..
<cr1901_modern>
no_retiming
<cr1901_modern>
or equivalent
<whitequark>
and why do you need that?
<whitequark>
MultiReg doesn't even use no_retiming
<whitequark>
(it actually probably should)
<whitequark>
oh nvm it does use no_retiming
<whitequark>
then some of the artiq code is superfluous.
<cr1901_modern>
whitequark: "(2:00:41 AM) sb0: whitequark, it prevents the synthesizer from moving combinatorial logic across the register"
<whitequark>
so?
<sb0>
whitequark, what code is superfluous?
<cr1901_modern>
In case yosys decides to be clever, tell it "no, don't be clever"
<sb0>
there is also a no_retiming on regs that are then sampled by the MultiReg, to avoid combinatorial glitches
<whitequark>
oh
<sb0>
and get transition times as short as possible
<whitequark>
combinatorial glitches as in?
<cr1901_modern>
fwiw, the one time I used CDCs on ice40, multireg worked fine. But it's still "more correct" to have the attributes (and I was just blindly assuming sb0 knows what he's doing ;)
<sb0>
if you have a reg followed by a massive combinatorial function, there is a long period after each cycle during which the output can glitch
<sb0>
and your problem is self.errors.status.eq(self.errors.status + 1)
rohitksingh has quit [Ping timeout: 260 seconds]
<sb0>
fsm.act is combinatorial, when the FSM is in that last state you are combinatorially setting errors.status to errors.status+1
<whitequark>
ohhh
<whitequark>
thanks
<sb0>
you can use NextValue, or add a sync counter + an increment signal driven by the fsm
<whitequark>
yeah, I know what to do
<sb0>
as for 1-cycle pulses feeding MultiReg, there is a risk that it is missed if the source domain is faster than the destination domain. consider PulseSynchronizer or BlindTransfer
<whitequark>
it's not a 1-cycle pulse
<whitequark>
though PulseSynchronizer would be cleaner now that I think about it
<sb0>
but PulseSynchronizer expects 1-cycle pulses
<whitequark>
sure, I can move the edge detection logic into CRCChecker
zhoygzsoav has joined #m-labs
zhoygzsoav has quit [Remote host closed the connection]
<mntng>
whitequark: when will you finish using the kc705 ?
<GitHub196>
[artiq] whitequark commented on issue #837: @cjbe I haven't been able to reproduce the issue on any of the network hardware we have. Please send us both of the problematic switches. Before that, please recheck with the master branch, since I've added CRC error and dropped packet counters to MAC, and any changes in them will be logged at WARN. https://github.com/m-labs/artiq/issues/837#issuecomment-340367115
<whitequark>
15m
<sb0>
mntng, can you post your current shift register driver code?
<sb0>
whitequark, so we can create a folder, say, /var/boardlocks, with one dummy file per board, then artiq_devtool or "flock /var/boardlocks/kc705 bash" or "flock /var/boardlocks/kc705 sleep 1800" when using manually
<sb0>
well that sleep command is problematic since you don't know it's it waiting on the lock or executing sleep
<cr1901_modern>
Most likely he ran a Wizard to generate the file within Xilinx' GUI
<shuffle2>
if that's whats going on there, can the same be done with migen?
<cr1901_modern>
and then just included them in the project
<shuffle2>
i'd like to be able to write the bitstream from the zynq's arm core, and then continue using the arm cores to interface with the (newly loaded) logic. but even using vivado to add the PS7 cruft doesn't seem to help :/
<shuffle2>
arms just die
<sb0>
bb-m-labs, force build --branch=master artiq
<bb-m-labs>
build forced [ETA 41m01s]
<bb-m-labs>
I'll give a shout when the build finishes
<shuffle2>
oh sweet, just had to poke is_partial_bitstream sysfs entry (even tho i think...it's not partial, it just makes the driver do the correct thing)
<sb0>
the reported difference in rtio_counter between the log message and the DMA output message is 200-300µs, which matches the underflow behavior I was seeing
<sb0>
whitequark, are you *sure* it's not the CPU that takes this time to write the DMA register for some reason? how and where exactly did you check the performance counters?
<sb0>
geez what an obnoxious bug
<sb0>
whitequark, it's a runtime bug.
<sb0>
I added another call to rtio::log right before dma_playback engages the gateware, and the hundreds µs are spent between the kernel's call to core_dma.playback() and that rtio::log call in dma_playback
<sb0>
how exactly did you do this performance counter testing? why did it seem to show a different result?
<GitHub129>
[smoltcp] jackpot51 commented on issue #66: @whitequark, I believe @dlrobertson is working on a fix, to prevent the ICMP error message from being sent https://git.io/vFtRW
<mithro>
You guys are using buildbot for your builds these days, right?
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
<rjo>
mithro: yes. seen it. but i don't see yet how that's going to look with LVDS/SE, FMC-HPC/LPC, CC/non-CC, bidir, etc.
<rjo>
mithro: yes. buildbot.
<mithro>
rjo: Just dumped some more random info into the connect issue bug -- Just trying to collect my thoughts.
rohitksingh has quit [Quit: Leaving.]
<rjo>
mithro: ack.
<cr1901_modern>
mithro: "You were interested in connectors / expansion headers in migen/misoc?" Could you elaborate?
<GitHub4>
[smoltcp] dlrobertson opened pull request #67: Do not send ICMPv4 responses to broadcasts (master...improve_dst_unreachable) https://git.io/vFqBj
<GitHub136>
[smoltcp] dlrobertson commented on pull request #67 8dd35b3: Does something like this belong in `wire::icmpv4`? https://git.io/vFq0m
<GitHub35>
[smoltcp] dlrobertson commented on pull request #67 8dd35b3: According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`. https://git.io/vFq0q
<GitHub111>
[smoltcp] dlrobertson commented on pull request #67 3a28298: According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`.... https://git.io/vFq0q
<GitHub173>
[smoltcp] dlrobertson commented on pull request #67 3a28298: Does something like this belong in `wire::icmpv4`?... https://git.io/vFq0m
<GitHub103>
[smoltcp] dlrobertson commented on pull request #67 3a28298: According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`.... https://git.io/vFq0q
<GitHub151>
[smoltcp] dlrobertson commented on pull request #67 3a28298: > According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`.... https://git.io/vFq0q
<cr1901_modern>
mithro: Well, I suppose I should be thankful that my post on migen lasted a month before rjo proposed an API change
<cr1901_modern>
sb0: Is that simulation API you proposed with dylibs still what you want?
<GitHub107>
[smoltcp] dlrobertson commented on pull request #67 3a28298: > According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`.... https://git.io/vFq0q
<GitHub149>
[smoltcp] dlrobertson commented on pull request #67 3a28298: > According to RFC 792 up to 64 bytes of the original payload should be included. Since the header is separate, that is `64 - sizeof(ip header)`.... https://git.io/vFq0q