<GitHub87>
[artiq] sbourdeauducq commented on pull request #776 586fa87: You added your SPI PHY *after* those SPI buses, so their channel numbers are not affected. Only the DDS channel number is affected, as far as I can tell (off the top of my head). https://github.com/m-labs/artiq/pull/776#discussion_r126385552
<GitHub38>
[artiq] sbourdeauducq commented on pull request #776 586fa87: @mntng you need to do a ``platform.request()``, ``mmc_spi`` is just a regular Python local variable, it won't appear there just because you added it to the Migen platform file. https://github.com/m-labs/artiq/pull/776#discussion_r126385202
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
_florent_, is your Sayma RTM card on the way?
<_florent_>
sb0: I'm not sure Greg already sent it
<_florent_>
sb0: I validated ddr3 32 & 64 with software delays initialization, I'm going to integrate that in migen/misoc
<_florent_>
sb0: thanks for the link
<sb0>
okay. now the next priority should be the wishbone bridge
<_florent_>
sb0: ack
<GitHub54>
[artiq] jordens commented on issue #778: One clarification on FIFO level and timestamp storage: If we give room for 4k RTIO channels for a large system (SAWG is 10+ each), 64 bits for the TS estimate and 16 bits for the level estimate, then that would use 12 RAMB36E1. That is not prohibitive. Such a compact storage for that data obviously depends on enumeration and DRTIO switch support throughout (#619). The enumeration and flattening of the addres
<sb0>
rjo, for hierarchical channel addressing I'd do it this way: the master has in flash storage a map of logical device number > hierarchical device path
<sb0>
then RTIO channel numbers are 0xAABBBB with AA the logical device number and BBBB the channel inside that device
<sb0>
that map also comes handy when determining what transceiver channels should be up before the system is considered operational
<rjo>
sb0: i would let the master enumerate all channels and then have it tell the switches the port offsets. then the tree is flat and the switches just have to add/subtract the port offests.
<rjo>
in general the necessity to do flattening is there whether you do it at the channel or at the device level.
<sb0>
how does this work with the device database?
<rjo>
in the same way. the master can also spit out the map between hierarchical and flat address at the same point.
<rjo>
at the same time.
<sb0>
if a link is down then it'll silently use the wrong drivers on the wrong channels unless an additional mechanism is implemented
<sb0>
also sharing the per-channel timestamp/token memory across different RTIO cores is somewhat inelegant and annoying
<sb0>
*different DRTIO master cores
<rjo>
given the map, translating the ddb from hierarchical addresses to flat address during loading is not hard.
<sb0>
plus if we have someday a crossbar with high-performance DMA that can feed multiple DRTIO master cores at the same time, it won't work
<rjo>
how do you want to do the flattening at the device level?
<sb0>
encode each hop independently in the address sent by the DRTIO master core
<rjo>
you scheme above only had 8 bit device address.
<rjo>
in general the RTIO tree will be very imbalanced. that leads to pretty bad usage of the address space if you just concatenate.
<sb0>
yes, then that gets mapped to a longer hierarchical address by the entry in the flash storage
<rjo>
unless you use variable length addressing. but i don't know how that carries through.
<sb0>
yes it uses more bits, but it's simpler, and the total number of hops is limited by latency anyway
<rjo>
how's that? and what do you mean by latency here.
<rjo>
it not only uses more bits but it also doesn't scale.
<sb0>
_florent_, have you missed the "sinara" folder in the migen platforms?
<GitHub157>
[artiq] jordens commented on issue #773: Above you propose an API modification (which I don't understand), describe the current documentation, and raise something about "add sawg/spline knot points or modify existing knot points". I have responded to the latter. I am unsure what you are referring to. https://github.com/m-labs/artiq/issues/773#issuecomment-314142402
<rjo>
sb0: how is the RTT latency limiting throughput?
<sb0>
it's not limiting throughput other than from the occasional token requests, but those have a very small impact
<sb0>
with a simple 32-bit address and 4 bits per hop, that's 16 possible hops and 8ns to transmit the address. is that not good enough?
<rjo>
a tree depth of just 4 (including the root and the leaf node). that is just two actual switch levels. that's small. with 32 bit addresses the other things down the pipeline also become more expensive.
<sb0>
hm? that's 16 switch levels
<rjo>
latency is not really an issue afaict. after all RTT latency is what this entire architecture works around.
<sb0>
er, 8
<rjo>
an address is 0xABCDEEEE where 0xEEEE is the channel address at the leaf and A, B, C, D are switches with up to 16 ports each.
<sb0>
I meant the routing address. it's mapped from the logical device number by the gateware, the CPU doesn't have to deal with it. the total address would be 48 bits...
<GitHub161>
[artiq] jordens commented on issue #773: I don't get it. The link you supply is not your proposal, it is my implementation, and it is already committed. What do you want me to comment on? https://github.com/m-labs/artiq/issues/773#issuecomment-314194093
<rjo>
sb0: that's at least 32 bits more than with a flattened channel map.
<rjo>
sb0: and the timestamp might shrink quite a bit if we implement delta compression there. then the channel/device address would dominate the packet size.
<rjo>
and yes. a tree depth of 8 would be ok for all things i can see coming up.
<GitHub167>
[artiq] jbqubit commented on issue #773: Not sure why the links (there are two) are causing confusion. Maybe different browsers render differently -- I see a difference in vertical scrolling in Chrome that could be confusion which isn't present in Firefox. Anyway....... https://github.com/m-labs/artiq/issues/773#issuecomment-314253517
<GitHub194>
[artiq] hartytp commented on issue #780: > On the WUT side, @marmeladapk was working on this but now it's assigned to @michallgaska and Tomasz. Please work with the M-Labs guys to develop this interface.... https://github.com/m-labs/artiq/issues/780#issuecomment-314264211
<GitHub60>
[artiq] jbqubit commented on issue #780: In parallel with the EEM hardware testing, a WUT student (@marmeladapk ) was working on writing ARTIQ drivers back in June. But there wasn't much progress. I posted the discussion in this Issue to externalize the discussion. Agreed the most efficient approach at this point is for M-Labs to write the interface. https://github.com/m-labs/artiq/issues/780#issuecomment-314266218