sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
rohitksingh_work has joined #m-labs
cr1901_modern has quit [Ping timeout: 244 seconds]
cr1901_modern has joined #m-labs
rohitksingh_work has quit [Quit: Leaving.]
rohitksingh_work has joined #m-labs
<sb0>
I'm a bit skeptical of the Github authentication by mobile phone app... how is that more secure than a SSH key?
<rjo>
it's not really the same. you do 2fa. and then it's similar to the ssh key: something you have (ssh key, or your phone) plus something you know (ssh key password, github password+phone lock). and many people are actually using a hardware dongle for generating the totp for 2fa, not a phone.
<sb0>
are you doing that?
<sb0>
what dongle? yubico?
<rjo>
yes.
<sb0>
ah nice, they have a NFC one
<rjo>
yes. and it's sturdy enough to survive at least a year on my (physical) keyring without any visible damage.
<sb0>
if i can trust the pile of nonsense that passes as ACPI table on my tablet, i have a broadcom NFC chip on I2C with one GPIO for IRQ. there is a driver for android...
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
* rjo
loves how -- after decades -- drawing diagrams still doesn't have a killer application. after uml, dia, graphviz, tikz, corel draw, powerpoint, illustrator, and thousands of other apps, we now have extremely fancy tools to do .... drum roll ... ascii/unicode monospace text graphics: https://monodraw.helftone.com/
sandeepkr has quit [Ping timeout: 264 seconds]
sandeepkr has joined #m-labs
<rjo>
larsc: we would like the register map of the AD9154 and AD9516 in nice form as a header.
<rjo>
larsc: any idea how to best get that? does AD have it (e.g. generated from HDL)? do you have tools to generate it from the datasheets? is there a (semi-)consensus or a recommendation/template from you or AD on what that should look like?
<rjo>
larsc: or is there a way to extract it from the SPI tool that comes with the eval boards?
<larsc>
well, it's the same digitially, just different analog performance, so it should be identical
<larsc>
9517 is pretty much the same as 9516
<rjo>
excellent!
<rjo>
would one suspect that those xmls are also used in the various SPI controller applications that are shipped?
rohitksingh_work has quit [Quit: Leaving.]
<rjo>
larsc: where are those "AXI core ADC" and DACs used?
<larsc>
to be honest I have no idea where all the XML files are used
<larsc>
they are used in our reference designs
<larsc>
the AXI cores
<larsc>
it's basically what JESD calls the transport layer
<larsc>
+ PRBS checks, simple DDS etc
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 265 seconds]
<sb0>
rjo, how large should the RTIO write transactions be?
<sb0>
taking the phaser into account
<rjo>
sb0: ~180 bit data currently max IIRC.
<rjo>
sb0: but, we should keep in mind the use case of a BRAM-sample-by-sample-burst RTIO channel.
<rjo>
sb0: there it would be (guessing) something like 256 samples * 16 bit.
<rjo>
sb0: i'd probably design variable length DRTIO packets up to ethernet MTU size.
rohitksingh_work has joined #m-labs
<rjo>
_florent_: i'm writing a little xml-to-.h converter for those.
<sb0>
rjo, what are those sample packets for? efficient spline knot packing?
<sb0>
the packet length is one thing, the other is what you put into the FIFOs at the receiving end
<sb0>
are the FIFOs going to take large entries, with a 64-bit timestamp and 180-bit data payload?
<sb0>
or should there be one or more "pure data fragments" FIFO entries that complete the payload of a regular entry that succeeds it?
<sb0>
are phaser messages always the same size on a given channel?
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub178>
[artiq] jordens pushed 2 new commits to phaser: https://git.io/vi5Bm
<GitHub178>
artiq/phaser 0e7557c Robert Jordens: ad9154: add register map from ad9144.xml
<GitHub178>
artiq/phaser 028a783 Robert Jordens: phaser: spi tweaks
<rjo>
sb0: no. this was discussed a while ago. people with short-burst and full-bandwidth requirements want to push raw DAC samples. this would be added onto the SAWG channel.
<rjo>
the receiving FIFOs can just truncate to whatever they can handle max.
<rjo>
sb0: no each sawg channel has ~9 rtio channels. they have data widths from 3 to 180 bit.
<rjo>
also for the bigger rtio channels (3rd order splines), it's very convenient to submit events with just the first 16 data bits, that would be a very efficient and automatic way to represent a zeroth-order spline.
<sb0>
yes, so it would make sense to have a FIFO with a small data word width, and you use several entries to represent a more complex programming
<rjo>
the entire entry needs to be a single entry in the FIFO. could you explain why fragmenting the DRTIO pakets would be helpful?
<rjo>
no. they burst at full rate
<sb0>
that's not specifically for DRTIO, that's for efficiently using the FIFO space
<sb0>
so we do need one reprogramming every ~8ns?
<rjo>
but i don't see a way to unpack at the output end efficiently.
<rjo>
yes.
<sb0>
unpacking is easy: add a shift register, FIFO entries that are of the "data" type (without timestamp) are loaded into that shift register, regular FIFO entries get their data concatenated with the shift register, then the full word is sent to rtlink
<rjo>
afaict BRAM is not a problem here. 128 entry-fifos for all the rtio channels would use a small fraction of the device.
<sb0>
but that becomes moot if we need 8ns peak rate
<rjo>
not really moot. both facts lead to the same conclusion.
<sb0>
so when you submit an event with just the first 16 data bits, the other are set to zero (and not the value they had before), correct?
<rjo>
yes. that would be sensible.
<sb0>
how do the bursts work on the FIFO side?
<rjo>
for the splines, truncate and zero-pad to max size is desirable.
<sb0>
OK. that's easy.
<sb0>
so, for the raw sample bursts
<sb0>
do we just send regular RTIO events with carefully computed timestamps that produce a continuous waveform, and samples as data payload?
<rjo>
hmm. for the bursts, i would actually have one entry hold the N (2, 4, 8, whatever f_DATA/f_RTIO_coarse is) samples of a single clock cycle.
<sb0>
ok, that's what I was describing
<rjo>
and those samples would be added to the output on the rtio timestamp they are valid.
<rjo>
ack.
<sb0>
that's kinda inefficient, but it works
<rjo>
then we don't need that big pakets for that mode. 8*16 = 128
<rjo>
inefficient only w.r.t. the channel address and timestamp.
<sb0>
maybe there can be some sort of "burst" flag in the FIFO
<sb0>
and corresponding support in the DRTIO packet
<rjo>
for the timestamp i was hoping we could support two formats: 16 bit channel-relative and 64 bit absolute.
<sb0>
or timestamp auto-increment
<rjo>
then all you pay is 16 bit channel, 16 bit timestamp, maybe 8 bit command/rw.. overhead of paket header.
<rjo>
or even autoincrement. yes.
<rjo>
and channel can also be optional, same channel if not supplied.
<sb0>
okay there are two things here: 1) packing efficiently in the DRTIO packet 2) packing efficiently in the receiver's RTIO FIFO
<sb0>
for the DRTIO packet, those things are easy: <channel> <initial timestamp> <data> [<timestamp auto-increment value> <n*more data>]
<sb0>
(handling the FIFO full condition will need a bit of work though)
<sb0>
for packing in the FIFO, hmm
<rjo>
i suspect (2) will be both hard and potentially not necessary/beneficial.
<sb0>
yes
<rjo>
the paket format looks good. might need a paket type or command field to distinguish r/w, status, in-band signalling...
<sb0>
yes, I'm just describing the write payload here
<sb0>
so, for the in-band signalling
<rjo>
and i think that the dma data format will probably be exactly the dtrio wire format framed by paket length fields.
<rjo>
ack.
<rjo>
or more precisely the dma format is the write payload format. (modulo timestamp offset)
<sb0>
we can force the non-realtime traffic to use short packets (e.g. 32 bits) - those are always transmitted in one cycle at 125MHz on a 5Gbps 8b10b link
<rjo>
or whatever we call that format. maybe "write payload format"
<sb0>
and non-realtime traffic is only considered when there is nothing realtime to transmit
<sb0>
on a 1.25Gbps link they'd take 4 cycles
<rjo>
i thought we had said that we would do fixed allocation (something like 99% RT)
<sb0>
yes, but I'm not sure if that's a good idea
kuldeep_ has joined #m-labs
<rjo>
don't we want to guarantee that non-RT will get through?
sandeepkr_ has joined #m-labs
<sb0>
hm, that would be good, yes
<sb0>
maybe we can encode it in the choice of special characters used in idle/RT packet delimiters
<sb0>
there are three possible commas
sandeepkr has quit [Ping timeout: 244 seconds]
kuldeep has quit [Ping timeout: 265 seconds]
<sb0>
guaranteeing a periodic comma makes link resynch easier, it may as well carry some non-RT info
<sb0>
so, we can use one comma to mark non-RT idle, and the other two to transmit non-RT 1 or 0
<sb0>
it makes transmitting non-RT traffic quite inefficient when there is no RT traffic, but it's a very simple protocol
<sb0>
how important is it to have a EMI-friendly idle pattern?
<rjo>
sb0: as we discussed, periodic comma is very bad for noise.
<rjo>
i am pretty sure this will turn out to be wanted.
<sb0>
but will that noise go anywhere it does damage?
<sb0>
even with RTM?
<rjo>
it's up to 12 times on the backplane, and the drtio link will be in proximity to the jesd links (which are scrambled also for that reason) near the sayma fpga.
<rjo>
i wouldn't implement spread-idle right now. but i wouldn't count on being able to easily encode stuff there.
rohitksingh has joined #m-labs
<sb0>
well, we can disable commas completely after link init, and then scramble everything
<sb0>
we'd need a good tool to estimate the spectrum of a 8b10b sequences...
<sb0>
since we're always going to need special characters
rjo has quit [Quit: leaving]
rjo has joined #m-labs
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #m-labs
kyak has quit []
<sb0>
rjo, ok so what about this scheme
<sb0>
after link initialization, we stop sending periodic commas
<sb0>
for the idle and non-RT traffic, we choose 8 (among the 12 possible) 8b10b special characters
<sb0>
those 8 characters are selected by a scrambler, and at the scrambler input we can transmit a 3-bit word
<sb0>
we can use 100 to delimitate non-RT frames, and 0XY to transmit the two bits XY of non-RT data
<sb0>
RT frames are delimited by any special character
<sb0>
(and RT payload is also scrambled with another scrambler)
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.3.0/20160802213348]]
digshadow has joined #m-labs
kyak has joined #m-labs
kyak has joined #m-labs
Aaron has joined #m-labs
Aaron has quit [Client Quit]
<GitHub54>
[artiq] enjoy-digital pushed 1 new commit to phaser: https://git.io/vidvt
<GitHub54>
artiq/phaser f8499a9 Florent Kermarrec: ad9516: add register map from ad9517.xml and manual adaptation
<larsc>
_florent_: have you started on jesd tx yet?
hobbes_ has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
sandeepkr_ has quit [Ping timeout: 255 seconds]
kuldeep_ has quit [Ping timeout: 255 seconds]
bentley` has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
hozer has quit [*.net *.split]
siruf has quit [*.net *.split]
balrog has quit [*.net *.split]
kaaliakahn has quit [*.net *.split]
[florian] has quit [*.net *.split]
whitequark has quit [*.net *.split]
cyrozap has quit [*.net *.split]
siruf has joined #m-labs
cyrozap has joined #m-labs
whitequark has joined #m-labs
mithro has quit [Ping timeout: 265 seconds]
bentley` has joined #m-labs
kristianpaul has joined #m-labs
hozer has joined #m-labs
sandeepkr_ has joined #m-labs
kaaliakahn has joined #m-labs
balrog has joined #m-labs
kuldeep has joined #m-labs
[florian] has joined #m-labs
sandeepkr_ has quit [Max SendQ exceeded]
sandeepkr__ has joined #m-labs
kuldeep is now known as Guest83096
Guest83096 has quit [Quit: Leaving]
sandeepkr__ has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
sandeepkr__ has joined #m-labs
mithro has joined #m-labs
mumptai has quit [Ping timeout: 276 seconds]
mumptai has joined #m-labs
mumptai has quit [Remote host closed the connection]