<GitHub190>
[smoltcp] whitequark commented on issue #19: I'm done with the refactoring, I think you will find that the new code is *significantly* better. https://git.io/v5s2x
<GitHub52>
[smoltcp] batonius commented on issue #19: Nice. Could you have a brief look at my branch to see if you're ok with the overall design before I start rebasing it? https://git.io/v5soX
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<GitHub90>
[smoltcp] whitequark commented on issue #19: Your egress packet handling will have to be redone. One thing I'm working on right now is having `poll` compute the earliest interval by which it should be called next in absence of inbound packets. On hosted platforms this lets me use `select` or whatever, and on embedded platforms this will let me go in deep sleep very efficiently.... https://git.io/v5sMK
_whitelogger has joined #m-labs
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
key2 has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub121>
sinara/master dd04ffd Robert Jordens: move NACTI poster to wiki...
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
mumptai has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<sb0>
_florent_, I don't see why we need one clock per TX and that sounds wrong
<sb0>
all transceiver channels, when transmitting, should be clocked from the same clock and have fixed latencies
<sb0>
then each of them recovers one RX clock (based on the TX clock and the CDR), and sends that to the rest of the drtio design by driving the corresponding domain in TransceiverInterface
<sb0>
_florent_, in the transceiver user guide, there is a description of how to do that
<sb0>
"Using TX Buffer Bypass in Multi-Lane Manual Mode"
<sb0>
or "Using TX Buffer Bypass in Multi-Lane Auto Mode". not sure if we need auto or manual phase alignment. in fact we shouldn't need phase alignment at all (or rather, it should be pushed into the silicon/PLL) if the xilinx transceiver design wasn't fucked
<sb0>
I heard those transceivers contain a hardened microblaze processor to deal with some of the mess
<larsc>
Altera has hard-macro Nios cores in their transceivers for calibration, etc.
<larsc>
but the clocking is more flexible than on Xilinx
<larsc>
TX bonding is easier
<sb0>
calibration of what?
<sb0>
internal clocks?
<larsc>
VCO for the PLLs and also the analog frontend
<larsc>
but of course the calibration doesn't work when you run the PLL in the recommended mode... always picks the wrong VCO band
<larsc>
well, one of the the PLL types
<larsc>
and they don't allow you to manually select the band
<_florent_>
sb0: that's the same clock but not the same clock domain since reset based on the each fsm
<sb0>
_florent_, where does this reset need to be connected exactly?
<sb0>
and if you create a clock domain inside a module in migen, then create several of those modules, the clock domains become local to each submodule. the clock domain name conflicts are resolved automatically.
<_florent_>
we only start rx init when tx is initialized
<sb0>
_florent_, and you are creating multiple BUFG_GT
<sb0>
no?
<_florent_>
yes we have multiple BUFG_GT
<sb0>
the user guide says a "master" transceiver should be designated, and its BUFG_GT output shared for all lanes
<sb0>
or did I misunderstand that?
<sb0>
also the master should be in the middle of the quads - just don't pick the first
<sb0>
*don't just
<sb0>
so for the rx reset - how about using ResetInserter(), or creating submodule-local clock domains?
<cr1901_modern>
Yea, apparently it uses Minix and a 486
<cr1901_modern>
very interesting...
<cr1901_modern>
Used to use ARC, interesting little CPU made by Argonaut. Don't hear much from them anymore
<sb0>
three 486's
<sb0>
I wonder what drugs Intel are doing
<sb0>
they came up with ACPI, and kept digging
<ohsix>
acpi is perfunctory, apm (/ letting the firmware do everything) didn't work
<ohsix>
extremely broad strokes, it's just a way for the os to take over/become aware about the stuff they know about, and let the firmware do some other stuff withotu conflicting
<sb0>
I don't see how writing firmware code in some arcane language (and typically with a massive load of bugs in virtually every real-world implementation) instead of x86 machine helps
<sb0>
also, talking to devices after the OS has booted is the job of the OS
<sb0>
which is what ends up happening in many cases anyway, due to the ACPI code being crippled with bugs
<cr1901_modern>
sb0: Have you ever tried doing programming using ACPI (curious)?