<cr1901_modern>
Should I send it anyway even though the prereq patch hasn't been merged?
<cr1901_modern>
(Also last activity: 7 weeks ago T_T)
X-Scale has quit [Ping timeout: 248 seconds]
X-Scale has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
mumptai has joined #m-labs
rohitksingh_work has joined #m-labs
<GitHub113>
[smoltcp] whitequark commented on issue #104: > When the third duplicated ACK is detected, it uses self.timer.set_for_retransmit(timestamp) with the current timestamp to schedule a faster retransmit. This requires few lines of code, however it is a bit hacky IMO.... https://github.com/m-labs/smoltcp/issues/104#issuecomment-389055950
mumptai has quit [Remote host closed the connection]
<rjo>
cr1901_modern: no idea. i don't bother interdependencies between patches when submitting. once the first patches are pulled the others become valid
<GitHub-m-labs>
[artiq] jordens commented on issue #992: That implementation has a couple issues. It would require a lot of restructuring, it doesn't fit the memory layout, the pipelining would suffer, the cycle length would increase. It would need 32*8*2+2*8 words (~16 bit) storage. And it's really tricky to get the clearing and readout working given the collisions. And there are a couple conceptual issues as well. PI ringing
<GitHub54>
[smoltcp] whitequark commented on issue #213: Let's just rename those to `udp` and `tcp`. If some hardware supports checksums for IPv4 but not IPv6, the driver can just disable offload to both. I feel like simplicity is more important than supporting such crap in an optimal way. https://github.com/m-labs/smoltcp/issues/213#issuecomment-389158806
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs>
artiq/master 9f5b762 whitequark: firmware: remove some unnecessary unwraps.
<GitHub-m-labs>
artiq/master b549261 whitequark: firmware: update the signature of #[lang="panic_fmt"].
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<sb0>
whitequark, what is the size of satman now?
mumptai has joined #m-labs
<whitequark>
sb0: probably about the same
<whitequark>
this wasn't about the satman
<sb0>
whitequark, is the separate i/d memories issue solved?
<whitequark>
sb0: what's the point of working on it?
<whitequark>
just back them both with the same piece of BRAM
<sb0>
whitequark, does that meet timing?
<whitequark>
ah, that was the issue...
<whitequark>
I'll look
<sb0>
well I don't know, that was a question. having both I and D in the same physical BRAM cells increases constraints on P&R and potentially degrades timing.
<sb0>
this also results in larger BRAMs, which also degrades timing.
<whitequark>
oh, I was thinking about having one BRAM for I$, one for D$, and the rest as a backing memory to both
<sb0>
meh, yeah that will work, but it's not resource-efficient
<whitequark>
you said that all available BRAMs can be used for the CPU memories
<sb0>
and not performance-efficient either
<whitequark>
or almost all
<sb0>
not that the latter matters much for satman
<whitequark>
well, is it worth spending a lot of time making satman slightly more efficient?
<whitequark>
and at the cost of a complicated linking process
rohitksingh has quit [Quit: Leaving.]
<sb0>
is it really complicated? I remember doing something like this with C many years ago, and that it wasn't particularly hard
<whitequark>
I can do it, but I think that it's pointless complexity
<whitequark>
sb0: it wasn't my goal but satman did become a bit smaller
<GitHub-m-labs>
artiq/master f8a9dd9 Florent Kermarrec: serwb/genphy: add device parameter (not used here, but this way all the phys share the same parameters), scrambling is also now always enabled.
<GitHub-m-labs>
artiq/master 2c627cd Florent Kermarrec: serwb/scrambler: simplify and set scrambler input data to 0 when sink.stb == 0
<GitHub-m-labs>
artiq/master 7fe49a7 Florent Kermarrec: firmware/runtime/session: fix compilation when no rtio core
<bb-m-labs>
build #2347 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2347 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>