<rjo>
whitequark: could you summarize the progress on the ethernet issue?
<rjo>
whitequark: did you get around to testing whether it also appeared on older codebase?
<rjo>
sb0, whitequark: i'll have to manually sync the docs with the webserver as long as the buildbot is broken.
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<sb0>
rjo, ok. due to changes in conda I'm not sure if it can still build release-1 anyway
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 264 seconds]
<rjo>
sb0_: ffrom what i can see with the release-2 build, the ethernet issue also occurs there.
<rjo>
i.e. MAC
<sb0_>
yeah it's liteeth dropping packets with a too short preamble
<rohitksingh>
sb0_: Hi! Sorry for late response. I'm working on the mor1kx modification. I have few queries:
<rohitksingh>
1. Do we want to upstream any changes in the mor1kx? In my opinion since those changes are highly requirement specific to us and also intrusive in design, it may not be good idea to upstream those. Maybe going with patch would be better?
<rohitksingh>
2. Should I use Migen for the BRAM + Wishbone wrapper for the Instruction Memory? iirc Migen can indeed generate dual-port memory with separate clock domains. Or, should I just go with Verilog itself?
<sb0_>
I suppose it should be tolerant of non-standard peers (or whatever snafu is happening again) and simply ignore an arbitrary number of preamble bytes until it gets the start-of-frame character
<sb0_>
rohitksingh, I don't think it's particularly specific, even ARM has it (it's called TCM)
sb0__ has joined #m-labs
sb0_ has quit [Read error: Connection reset by peer]
<rohitksingh>
sb0__: Great. Verilog it is then. I'll try to make it configurable via parameters
<rjo>
sb0__: AFAICT the preamble should be ignored completely at the frame level. it is only there for synchronizing the clock at the phy level.
<sb0__>
rohitksingh, though unlike ARM we don't have to support both cache and TCM enabled at the same time at different addresses
<rohitksingh>
okay
<sb0__>
it seems that preamble shrinkage/growth is rather normal with ethernet
<sb0__>
clock correction is supposed to be applied on inter-packet gap, but of course if everyone did that and only that, it would be too simple
<sb0__>
The IEEE 802.3-2008 specification (see clause 35) allows for up to all of the seven preamble bytes that proceed the Start of Frame Delimiter (SFD) to be lost in the network. The SFD is always present in well-formed frames.
<rjo>
sb0__: ack. we should just trigger on sfd
<rjo>
whitequark, sb0__, _florent_: anyone actively working on that?
<sb0__>
a single byte of preamble can be lost across the 1000BASE-X system (the actual loss occurs in the 1000BASE-X PCS transmitter state machine)
<sb0__>
There is no specific statement for this preamble loss in the IEEE 802.3-2008 specification; the preamble loss falls out as a consequence of the state machines (see figures 36-5 and 36-6 in the IEEE 802.3-2008 specification).
<sb0__>
...chain 8 or more 1000BASE-X repeaters, network broken?
<sb0__>
what is happening is, with base-x you can only start a transmission on even symbol positions, and apparently it's OK to drop the first preamble byte if the transmission starts on an odd position. if your chain of repeater alternates what it considers odd or even, and afaict nothing prevents that, then it doesn't work ...
<rjo>
imho no. if a repeater is allowed to reframe, then it needs to do so with the full, i.e. reconstructed preamble.
<rjo>
i.e. has minimum latency of the preamble
<rjo>
anyway, what a "repeater" is and is allowed to do might not be well defined.
<rjo>
rohitksingh: what are you working on? do you have an exposé?
sb0_ has joined #m-labs
sb0__ has quit [Read error: Connection reset by peer]
sb0__ has joined #m-labs
sb0__ has quit [Read error: Connection reset by peer]
<whitequark>
rjo: yes, I am
sb0_ has quit [Ping timeout: 260 seconds]
<rohitksingh>
rjo: Hi! I'm not sure what is meant by exposé. Google says "a report in the media that reveals something discreditable." Anyways, I'm working on adding single-cycle instruction memory (like TCM, as said by sb0 above) mor1kx. I'll remove wishbone interface for instruction bus, and instead add a dual-port memory in the middle. A different master can write to the dual-port memory, and mor1kx will fetch its instruction from it.
<rohitksingh>
rjo: goal is to decrease mor1kx's BRAM utilization
<rjo>
whitequark: ack. if there is no progress soon, i'll give it a shot.
<rjo>
rohitksingh: i see. nice! i meant: do you have an issue to track that, or a wiki page or something else with details of the specification/design/plan, do you have a time plan?
<whitequark>
actually, I can simplify that further
<rjo>
whitequark: "x & y == z" is not "x & (y == z)"
<whitequark>
oh
<whitequark>
sink.data.eq(sfd) ?
<rjo>
If(sink.stb & sink.data == preamble, ...)
<whitequark>
yes, I see where the bug is
<rjo>
then i dont know what you mean by "sink.data.eq(sfd) ?" ;)
<whitequark>
nevermind, looked it up
<rjo>
just precedence rules
<rjo>
whitequark: but what do you do with dw == 16 and the odd/even problem?
<whitequark>
oh, hrm
<whitequark>
ok, feel free to fix this yourself
<whitequark>
ttps://hastebin.com/iworiceraq.py
<whitequark>
this is my last iteration
<whitequark>
right now dw==8 always
<GitHub95>
[smoltcp] phil-opp commented on issue #90: The current socket API requires regular polling, which causes overhead (due to unnecessary polling when no new data is there) and latency (the time between data arrival and the next poll).... https://github.com/m-labs/smoltcp/pull/90#issuecomment-349668727
<GitHub180>
[smoltcp] whitequark commented on issue #90: > The closure passed to poll reacts immediately to every received packet. It can continue exactly the tasks that are waiting for the packet. It can also react to control commands without latency (e.g. to a reset command).... https://github.com/m-labs/smoltcp/pull/90#issuecomment-349670500
<rjo>
whitequark: ack. i'll see this through.
<whitequark>
rjo: I plan to get it working with dw==8
<whitequark>
right about now
<rohitksingh>
rjo: Oh, okay. Not currently, but thanks for the idea. I should put up these information somewhere, probably in Github.
<GitHub108>
[artiq] whitequark commented on issue #849: @sbourdeauducq I have thought about it and making the core device print backtraces is a good idea and is easy, because that code is already in libstd (and we only need to tweak it slightly for our embedded environment). This will however bloat the runtime even further (which I personally don't consider a problem whatsoever). https://github.com/m-labs/artiq/issues/849#issuecomment-349713016
<GitHub142>
[smoltcp] phil-opp commented on issue #90: I need to think about it a bit more, but it seems like a good solution. It should allow us to use a closure based interface if we want to:... https://github.com/m-labs/smoltcp/pull/90#issuecomment-349717017
<GitHub178>
[artiq] gkasprow commented on issue #854: @sbourdeauducq are you sure you produce valid TXCLK o 125MHz? You said that Link is established, so does the LINK LED on front panel is ON? On my board I observe packets in and out.... https://github.com/m-labs/artiq/issues/854#issuecomment-349743231
<GitHub103>
[artiq] gkasprow commented on issue #854: @sbourdeauducq are you sure you produce valid TXCLK o 125MHz? You said that Link is established, so does the LINK LED on front panel is ON? On my board I observe packets in and out.... https://github.com/m-labs/artiq/issues/854#issuecomment-349743231
larsc has quit [*.net *.split]
larsc has joined #m-labs
<GitHub24>
[sinara] gkasprow pushed 1 new commit to master: https://git.io/vbCf9
<GitHub177>
[artiq] sbourdeauducq commented on issue #849: Sure go ahead, we have 1+GB RAM (though flash is more limited). As long as it can be easily disabled for running on the block-RAM of the RTM FPGA... https://github.com/m-labs/artiq/issues/849#issuecomment-349814709