<rjo>
and while i remember it: a neat optimization for systems with lots of CSRStorage(write_from_device=False) might be to have a BRAM just for readback. that would reduce the resources needed for that potentially very large and distributed readback mux tree.
<sb0>
rjo, yes, but you expect a Signal to be a leaf node, not something that contains other Signals
<rjo>
sb0: ack. but could CSR* at least alias to their "dominant Signal" when used in expressions?
<sb0>
how would that "alias" work? fhdl level?
<sb0>
how about just making the property names shorter?
<rjo>
na. shorter proerty names does not help me.
<rjo>
fhdl could try to .__fhdl__() things it does not know about.
<sb0>
hmm, alright ...
<sb0>
in wrap() I suppose
<rjo>
yes. maybe. i have not fully thought that through though.
sj_mackenzie has joined #m-labs
FabM has quit [Ping timeout: 264 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 245 seconds]
FabM has joined #m-labs
fengling has joined #m-labs
<GitHub31>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/v4Qjx
<GitHub31>
artiq/master 9826b19 Sebastien Bourdeauducq: gui/scan: adapt layout to show more decimals
<sb0>
larsc, do you know why high speed DACs include those annoying clock domain transfer mechanisms?
<sb0>
i.e. you have a data clock and a analog clock with some buffer in-between whose apparent function is to cause you trouble when synching multiple dacs
<sb0>
...and sure enough, include some pesky serial configuration interface with a ton of obscure registers. if they made them act like like D flip flops + resistor network, they would be too easy to use.
<larsc>
absorbing jitter and what not
<larsc>
usually these chips have a sync pin that resets all the fifos at the same time
<whitequark>
hm, no, I didn't implement interleaving correctly yesterday...
<sb0>
next step: ACPI plug and play
<sb0>
how does this absorb jitter? do they have a PLL?
<larsc>
depends on the part
<sb0>
but for those that do not have a built-in PLL, the dual-clock feature is imbecilic, right?
<larsc>
I don't know
<larsc>
there might be a performance reason
<larsc>
have a low-jitter low-fanout clock for the DAC
<larsc>
and one with more jitter for the interface
<larsc>
and for the high speed stuff you usually want to be source synchronous for the data interface as well
<larsc>
meaning the clock will be generated by the fpga
<larsc>
(the interface clock)
<larsc>
and that most certainly adds noise
<larsc>
usually you just use a ODDR with inputs set to 1 and 0 that is clocked by the same clock as the logic that generates the digital data
<sb0>
low-fanout? when you have a lot of DACs to synchronize, that clock has high fanout
<sb0>
and there are low jitter clock distribution chips
<larsc>
the source synchronous makes more sense
<sb0>
yes
<larsc>
I was just sorting my thoughts ;)
<sb0>
it just displaces the problem though. using ODELAY so that each DAC interface meets timing would be easier than dealing with the proprietary and obscure DAC synchronization mechanism du jour.
<larsc>
well, if you are not source synchronous you are a lot more sensible to e.g. temperature
<larsc>
sensitive
rohitksingh has joined #m-labs
<sb0>
the synchronization line is also sensitive to temperature and voltage
rohitksingh has quit [Client Quit]
<larsc>
well the idea is that you give them all the same length
<sb0>
I don't see this working well with a simple FIFO reset for synch. if it toggles near a transition of the clock, some DACs will register it in one cycle and others in the other cycle...
<larsc>
which is probably why the sync needs to be clock synchronous
<larsc>
which chip are you talking about in particular
<larsc>
?
<sb0>
not any chip in particular... all those that I have looked at have this dual-clock mechanism and synch problems
<larsc>
if the chip has a JESD chip the synchronization handling is standardized
<larsc>
a JESD interface
<larsc>
for LVDS there might be custom solutions
<sb0>
yes, and I guess you need it anyway with JESD due to CDR jitter
sj_mackenzie has quit [Ping timeout: 240 seconds]
<sb0>
for the lvds ones, if the synch line is system synchronous, you'd rather make the data the same instead of introducing this FIFO complication
<sb0>
maybe this was done in spartan-6 times where output delays were crappy... but the 7-series ones are nice
<GitHub76>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/v4dbL