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
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
kuldeep has quit [Ping timeout: 264 seconds]
kuldeep has joined #m-labs
fengling has joined #m-labs
sandeepkr has joined #m-labs
bentley` has joined #m-labs
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 244 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 264 seconds]
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<sb0>
rjo, what spec? Joe's?
<sb0>
in his spreadsheet, I see 4 SFP and VHDCI (and, of course, RTM)
<sb0>
the VHDCI is for TTLs since, of course, he does not want to fund kasli
sandeepkr has quit [Remote host closed the connection]
<rjo>
the amc spec.
sb0 has quit [Quit: Leaving]
rohitksingh_work has quit [Quit: Leaving.]
<rjo>
sb0: are the idelay taps sufficiently predictable in their cumulative value that we can pinpoint sysref-rtio to one dac clock cycle?
<larsc>
it's +-10ps per tap for kintex
<rjo>
sb0: and about the sgmii thing. it seems to me that it would be much smarter to develop an transiever based phy ignoring all the Xmii things. the kcu105 has two sfp ports and transciever-based ethernet seems much more generic and future proof.
<rjo>
larsc: absolute or relative? in other words: is tapN then N*X +- 10ps or N*X +- N*10ps?
<larsc>
each tap adds 20ps of uncertainty
rohitksingh_work has joined #m-labs
<larsc>
so the later
<whitequark>
another binutils bug...
<larsc>
so if you turn it full up to 31, it's 600ps
<rjo>
ah. and +- 5ps with a teaspoon of HIGH_PERFORMANCE
<larsc>
the idelay also has a inherent uncertainty of around 400ps
<larsc>
on a kintex7
<larsc>
but if you place two of them next to each other the delay should probably be similar
<larsc>
hm, the datasheet says for a clock pattern the jitter is supposed to be 0
<rjo>
that 400ps being inherent to the location or PVT-dependent?
<larsc>
so maybe that works for you
<larsc>
rjo: it's what the timing report for difference in hold and setup propagation through the idelay
<larsc>
it is probably pvt
<larsc>
like worst case and best case
<larsc>
well, min delay and max delay
sb0 has joined #m-labs
sandeepkr has joined #m-labs
<sb0>
larsc, where did you get that 10ps value from?
<sb0>
the datasheets says "39ps average" and remains silent about other properties, like deviation
<sb0>
whitequark, did you find hk/sz machine shops via the contacts i gave you?
<whitequark>
not yet
<sb0>
I want to make that ECDL...
<whitequark>
sb0: do you just need the thing from figure 4.1?
<whitequark>
ah, I see there are more of them
<sb0>
yeah, there are a bunch of things, and it is safe to assume the given dimensions will not work because the diode laser and/or the piezo du jour will have different sizes
<sb0>
usual yak shaving
<whitequark>
ok, so do you want me to make a CAD design and find somewhere to manufacture it?
rohitksingh_work has quit [Quit: Leaving.]
<rjo>
sb0: in sayma we should try very hard to not use the internal pll.
<rjo>
sb0: yeah. maybe we need it for the fmc-ebz.
<rjo>
larsc: doesn't the on-chip pll (e.g. ad9154) completly sabotage jesd204b sc1 sysref timing? deviceclock is now internal to the device.
<rjo>
and, looking at ad9154, figure 84 (page 81): is it common practice to "isolate" a device 3.3 V power rail from a (supposedly perfectly fine) already existing 3.3 V power supply by using a 12 V power supply instead plus a buck converter plus two LDOs?
<rjo>
sb0: the hmc7044 that larsc recommends does output up to 3 GHz directly.
<rjo>
the ad9528 does not.
<larsc>
rjo: I think the idea is that sysref resets all internal dividers of the pll
<larsc>
not sure if it does though for this chip
<rjo>
larsc: ack. but there would still be the s/h timing that needs to be met w.r.t. that (now internal) deviceclock.
<larsc>
s/h of which signals?
<rjo>
larsc: i guess you are right. the latency variation spec changes from [0, 1] dac_clock to [-1, 1] when using the pll.
<rjo>
sysref w.r.t. the (now internal) deviceclock after the pll.
<rjo>
sysref needs to meet timing w.r.t. the actual deviceclock, just meeting it w.r.t. the reference clock going into the pll is not enough.
<rjo>
larsc: when you guys do subclass 0.5, I assume that the fpga (or another chip) generates sysref from its deviceclock. is that just tedious to get the timing right or is it almost impossible?
<larsc>
such a setup usually uses the s/h monitor in the converter device
<sb0>
seriously, the ARL bureaucrats are absolute terminal morons
<larsc>
that will only give you a certainty that all converters see sysref in the same deviceclock cycle, but not which one
<rjo>
that doesn't matter, does it?
<larsc>
not for mcs
<rjo>
for anything?
<larsc>
your converter and logic lmfc will be out-of-sync
<larsc>
logic=fpga
rohitksingh_work has joined #m-labs
<larsc>
so you can get into trouble with sync sampling
<rjo>
sb0: just found an entry "partical counter" in fbo.gov.... hahaha.
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
larsc: i thought that since the latency from analog to the "framing domain" (where lmfc matters) is deterministic, everything is fine.
<rjo>
if they all see sysref in the "same" deviceclock cycle, then that clock cycle is synchronized. by definition. no?
<larsc>
the fpga does not know in which devicelock cycle
<larsc>
so the lmfc in the converters are aligned
<larsc>
but non-aligned to the fpga lmfc
<larsc>
that part makes sense?
<sb0>
first you have to submit invoices using some broken and arcane website that has an invalid SSL certificate and is lousy with javascript bugs that make you have to start over again if you change focus in a way it doesn't like
<sb0>
registering to that website requires making a phone call
<sb0>
then you submit the invoice, and separate payment instruction by FAX
<sb0>
using an arcane form that you have to request from someone else
<sb0>
but! not all bureaucrats are aware of this, and when anyone with admin access scans the system for invoices with missing data, they will immediatly mark them as rejected, and you have to start over
<sb0>
with a comment about inputting payment data in yet another place
<sb0>
this is the third time this shit happens
<sb0>
so, payment data needs to be put in: 1) fax 2) attachments (for bureaucrats not aware of #1) 3) comments (for bureaucrats saying "we cannot accept attachments" even though the aforementioned shitty website has a somewhat working function to add them)
<sb0>
and of course, as soon as one of the morons rejects the invoice, everything restarts from zero
<rjo>
larsc: not to me ;) my understanding is still that if both sides notice that a deviceclock cycle has been marked by sysref that this cycle is the start of a multiframe and then everything between the two lmfc counters is determined.
<sb0>
how do those fuckers ever get anything done?
<rjo>
sb0: from their point of view, they simply don't need to.
<rjo>
larsc: are you referring to the (unknown but fixed/deterministic) delay from the fpga emitting sysref to the converters seeing it?
<larsc>
rjo: I guess
<sb0>
rjo, I suppose that all fig. 84 says is it recommends two separate linear regulator for AVDD33 and IOVDD+SIOVDD33
<sb0>
and dedicated to those
rohitksingh has joined #m-labs
<sb0>
whereas the 3.3V input may be more noisy
<sb0>
it's coming from 12V because it has a separate step at 3.8V before the linear regulators