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 quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
rohitksingh_work has joined #m-labs
_rht has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
sb0: Is it possible to instantiate a flip-flop with an async preset/reset in Migen? I'm leaning toward no, but unfortunately I need one to generate a synchronization stream for an ADPLL :/.
<cr1901_modern>
I need something equivalent to "always @ (preset or posedge clk)";
<sb0>
instantiate it directly. but I'm not convinced that you need it.
<sb0>
in most cases I've seen, people 1) don't actually need asynchronous components 2) use them anyway, badly, and make a buggy design
<sb0>
synchronous designs are easier to get right, so try to stick to them
fengling has joined #m-labs
<sb0>
with async designs, you can very easily end up with nasty intermittent bugs if you are not very careful
<cr1901_modern>
I suppose I could turn the serial stream into a separate clock domain. Although it would not be a symmetrical clock by ANY stretch of the imagination.
<sb0>
they may look simpler, but they are not
<sb0>
what is the serial stream? I don't know what you are trying to do
<cr1901_modern>
sb0: See DM. Would prefer not to reduce SNR.
<cr1901_modern>
I guess I'll just either instantiate directly (completely breaks my division of platform-agnostic and platform-specific code) or create a separate Verilog file, create instances and add that to the project file before building (my preferred solution).
sb0 has quit [Quit: Leaving]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 265 seconds]
kuldeep_ has joined #m-labs
kuldeep has quit [Ping timeout: 252 seconds]
sandeepkr has quit [Ping timeout: 244 seconds]
sandeepkr has joined #m-labs
mumptai has joined #m-labs
_rht has quit [Quit: Connection closed for inactivity]
mumptai has quit [Remote host closed the connection]
sandeepkr_ has joined #m-labs
kuldeep_ has quit [Ping timeout: 252 seconds]
sandeepkr has quit [Ping timeout: 276 seconds]
kuldeep_ has joined #m-labs
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 258 seconds]
hozer has joined #m-labs
key2 has joined #m-labs
<key2>
The LVDS can only be done on the transceiver pair of the xilinx ? or any differential pairs ?
<larsc>
only special pairs
<larsc>
or what is the question?
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<key2>
larsc: basically I wanted to know if I wanted to interface a CSI-2 Camera which uses mipi D-PHY, what was my best option between converting the paris into LVDS and interfacing it with the FPGA, which would require then deserializing.., or, using a deserializer which would bring me 24 bits and interfacing it wiht the FPGA
rohitksingh has joined #m-labs
<GitHub193>
[artiq] jordens pushed 2 new commits to master: https://git.io/v65R4
<GitHub193>
artiq/master df876a4 Robert Jordens: doc: expand/refine getting_started_core
<GitHub193>
artiq/master 69ea3d3 Robert Jordens: doc: rtio concepts, closes #451
<larsc>
key2: depends on your max clock I guess
<GitHub67>
[artiq] jordens pushed 3 new commits to release-2: https://git.io/v65Ea
<GitHub67>
artiq/release-2 e07fd01 Robert Jordens: doc: cleanup git checkout instructions (see #542)
<GitHub67>
artiq/release-2 1c85e95 Robert Jordens: doc: expand/refine getting_started_core
<GitHub67>
artiq/release-2 2da1dba Robert Jordens: doc: rtio concepts, closes #451
<cr1901_modern>
I haven't needed ODELAY personally. I've never actually instantiated LVDS primitives on my own
<cr1901_modern>
According to mithro, any LVDS pair can be used for basic HDMI, but if you want monitor resolutions that would be used by someone today, you need a special gigabit pair of differential transcievers
<larsc>
yeah, 1080p@60Hz is 1.5GHz
<cr1901_modern>
(Related: I love minispartan, but there's def some poor design decisions there for doing HDMI :/)
rohitksingh has quit [Quit: Leaving.]
key2 has quit [Ping timeout: 264 seconds]
sandeepkr__ has quit [Ping timeout: 264 seconds]
sandeepkr__ has joined #m-labs
<rjo>
_florent_: are you doing ok with the jesd stuff? i am reading through the survival guide and the subclass 1 synchronization scheme.
mumptai has joined #m-labs
<larsc>
if you can get away with it only support scrambling, the non scrambling path is a mess
<larsc>
subclass zero synchronization is pretty straight forward and all the magic is in the board layout
<rjo>
larsc: overall there seem to be about a thousand things that can go wrong.
<rjo>
subclass zero synchronization is non deterministic. that's a no-go for us. (it's ok for now but needs to be subclass 1 later)
<rjo>
i suspect they generally didn't separate the layers in that thing very well. or the layers are just really complicated.
<rjo>
the scrambling is very nice and desirable. it's just that it needs a scrambler ;)
<larsc>
what is a bit annoying that multi-chip synchronization and determinitic latency are bound to each other
<larsc>
a few of our eval boards break the spec because they want the former, but not the later, quite annoying
<rjo>
i always thought they necessarily need to be bound.
<rjo>
larsc: which boards? ad9154?
<larsc>
for mcs you want the output latency of the converter to be deterministic, but not necessarily the input latency in the logic device
<larsc>
rjo: mostly FMC-...-EBZ boards
<rjo>
certainly deterministic latency is sufficient for multichip sync.
<rjo>
larsc: hmmm. also the ad9154 fmc-ebz?
<larsc>
I haven't looked at that one
<rjo>
i didn't see anything about that in the datasheet.
<larsc>
give me a sec
<rjo>
does your statement above only refer to ADCs?
<larsc>
mcs basically means I want to ensure that data that is sampled at the same time is received in the logic device at the same time
<larsc>
but the total delay does not necessaily matter
<larsc>
similar for DACs you want to ensure that the data processed in the logic device is converted at the same time in the DAC
<larsc>
or in the DACs
<larsc>
but you might be Ok with the delay from logic device to DACs changing between power-ups
<rjo>
are you interpreting mcs as "relative to other chips" and det-lat as "relative to a certain plane in the fpga/asic"?
<rjo>
ok. i think that's what you mean.
<larsc>
yes
<rjo>
yes. det-lat is stricter than mcs and sufficient for it.
<larsc>
yes
<rjo>
ok. we want det-lat. ;)
<rjo>
if the ad9154 fmc-ebz only exposes the stuff for mcs but not det-lat, then i am worried/angry.
<larsc>
the ad9154-ebz was not done by the group I work for, so it is probably ok ;)
<rjo>
ha
<rjo>
could you point me to the problem in one of the boards where it exists?
<larsc>
what's important is sysref, if it is source synchronous all is good, if it is system synchronous that's not so good
<rjo>
agreed.
<larsc>
so basically you want sysref to originate at the same source as your device clock
<rjo>
yes.
<larsc>
some boards don't do that
<larsc>
I called it subclass 1/2
<larsc>
call
<larsc>
or 0.5
<larsc>
It's really annoying when you have to do the software for those boards
<rjo>
ha. JESD204B 33⅓: The Final Insult
<rjo>
got a pointer to a board?
<rjo>
larsc: in linux iio/zio/whatever is hip nowadays?
<larsc>
sysref is sourced from the FMC header on that board
<rjo>
yes. one would want the clock chip (AD9517) to source it, right (modulo trace matching).
<rjo>
larsc: is there a full zc105 "linux userspace <-> kernel <-> fabric <-> jesd204b <-> adc/dac" stack?
<larsc>
for new designs we usually recommend either HMC7044 or AD9528
<larsc>
rjo: no
<larsc>
I'm working on improving the stack at the moment
<larsc>
the current solutions are quite basic
<larsc>
and do not support dem-lat
<larsc>
at all
<larsc>
det-lat
<larsc>
only mcs
<rjo>
ok.
<rjo>
larsc: could you have a quick glance at ftp://ftp.analog.com/pub/HSSP_SW/HSCDAC/Documents/AD9154/AD9154-FMC-EBZ%20RevA%20Schematic.pdf sheet 7 bottom right?
<larsc>
what am I looking for?
<rjo>
looks like that ad9516 sources CLK and SYSREF (at least in some configuration). and that a SYSREF fanout goes to the carrier.
<rjo>
that would be correct for doing subclass 1, right?
<larsc>
yes
<larsc>
JP2 and JP5 should be in B position
<rjo>
ok. then the fpga needs to derive its transciever clock out of that SYSREF and phase it to meet the various S/H timings.
<rjo>
yes.
<larsc>
In the FPGA the important part is that you make sure that SYSREF is sampled source synchronous and there is no CDC or anything on the sysref path to the lmfc
<larsc>
this means don't use RX or TXOUTCLK
<larsc>
for clocking your logic
<larsc>
use the deviceclock
<larsc>
that is sourced from the clock chip
<larsc>
and potentelly a BUFIO
<larsc>
and sample sysref on the negedge
<rjo>
yes. but there is some CDC from the LMFC (at SYSREF) to the transcievers.
<rjo>
deviceclock?
<larsc>
the clock from the clockchip to the FPGA is called deviceclock
<larsc>
(I think)
<larsc>
rjo: where do you have CDC?
<rjo>
is that not the SYSREF fanout to the carrier?
<rjo>
well in the transciever fabric at some point the entire octet juggling needs to get the framed data (clocked with SYSREF) into the transcievers which are ultimately clocked at the linerate (which i would derive from SYSREF).
<larsc>
regarding clocks: I put this together a while ago:
<rjo>
ah. ok. there is a SYSREF fanout to the carrier on a regular diff pair. _and_ there is GBTCLK0_M2C. GBTCLK0_M2C does not need to be SYSREF but can be something more useful (i.e. deviceclock)
<larsc>
rjo: correct
<larsc>
Xilinx requires that the deviceclock is linerate/40
<rjo>
ok.
<rjo>
_florent_: ^^^ all this might be helpful.
<larsc>
rjo: there is CDC from the tranceiver to the elastic buffer at some point, but the LMFC is used to compensate for any non-det introduced by the CDC
<rjo>
yes. the entire subclass 1 det-lat just blindly compensates for all the non-det at both ends, afaict.
<larsc>
your writes to the elastic buffer might have different delays between power-ups, but the reads are aligned to the LMFC
<rjo>
elastic buffer at the FPGA side?
<larsc>
at the receiver side
<larsc>
FPGA for ADC, converter for DAC
<rjo>
ok.
<rjo>
is there a difference between an "elastic buffer" and a "FIFO"?
<larsc>
not for jesd
<larsc>
it's a bad term in my opinion
<larsc>
but that's what the spec calls it
<rjo>
ack.
<larsc>
usually what you refer to as a elastic buffer is when you have CDC between too clock domains with the same nominal clock, but different references
<larsc>
so you have a few ppm differences in rate
<larsc>
the elastic buffer dynamically inserts or removes dummy samples to compenstate for it
<larsc>
with jesd there is no such thing
<rjo>
out of curiosity: how much is the xilinx jesd204b core?
<larsc>
to buy?
<rjo>
so it is more of a stuffer/stripper?
<rjo>
buy/rent/use/license whatever.
<larsc>
I've heard 6k
<larsc>
not sure how accurate that is
<rjo>
per lane? ;)
<larsc>
per giga octet ;)
<rjo>
ha.
<larsc>
but as I said I'm reworking the stack, so wait and see what the future holds ;)
<rjo>
sounds good. we will soon have an open jesd204b core. i would expect it to be really good. maybe then you guys can rewrite the warning on that wiki page.
<larsc>
yeah
<rjo>
larsc: how is zio looking? is there some consolidation among the ?io kernel subsystems now or have they all found their niche?
<larsc>
zio is just cern, IIO is everybody else
<larsc>
I've tried to convince the ZIO people that we should converge onto a common solution a few years ago, but no luck
<larsc>
so it's going to continue to exist as a out-of-tree project
<rjo>
and the various comedi things are just aging legacy?
<larsc>
there is some work on the framework, but all the majority of supported platforms is legacy
<rjo>
ack.
<rjo>
anyway. thanks a lot for the jesd insight! i guess there might be more questions coming down the road.
<rjo>
larsc: another question about the ad9154-fmc-ebz schematics: if i want to do det-lat between two of those (i.e. two kc705 and two ad9154-fmx-ebz), i see a few problems. i see no way to get both the deviceclock and sysref to the "other" kc705/ad9154 combo.
<rjo>
i could clock the clock chips with the same source and then pump one of the two deviceclocks going to the kc705 to its buddy kc705 to then shift/delay samples accordingly. but that doesn't give me what i want, right?
<larsc>
yes, this is often an overlooked usecase
<rjo>
argh.
<larsc>
some boards allow you to connect an external refernce and a sync signal to keep the clock chips synchronous
<larsc>
clock sync does not seem to be connected in this case
<larsc>
you can provide an external sysref
<larsc>
but you'd have to get it to the fpga as well
<rjo>
where?
<larsc>
j3
<larsc>
and then chnage jp23 and jp24
<rjo>
j3 is one of the dac outputs in my schematics (sheet 2)
<rjo>
still ftp://ftp.analog.com/pub/HSSP_SW/HSCDAC/Documents/AD9154/AD9154-FMC-EBZ%20RevA%20Schematic.pdf ?