<_florent_>
rjo:great! I was looking at your changes in the core, thanks.
<_florent_>
rjo: have you tested 10 Gbps?
<rjo>
_florent_: yeah. feel free to complain/discuss.
<rjo>
_florent_: doing so. but i am battling xilinx constraints right now.
<_florent_>
rjo: you have problem meeting timings?
sandeepkr has joined #m-labs
<rjo>
_florent_: just the usual difficulty of teaching xilinx the right clock signal to mark as the false path.
<rjo>
_florent_: and the scrambler sometimes fails timing. but that might be fall-out.
<_florent_>
rjo: you changes are fine for me, I'm just wondering why you removed the MultiReg on self.stpl_enable
<rjo>
_florent_: because it's in the same clock domain. isn't it?
<rjo>
_florent_: hmm. but you could debate whether it actually end up there. since the csrs are owned by the banks, they might actually end up in a very different CD.
<rjo>
_florent_: OTOH assuming that the CSRs are in the same CD as "sys" (modulo renaming) seems to be the usual modus operandi.
<rjo>
_florent_: but if you concur, i'll add it back in.
<_florent_>
rjo: yes. MultiReg have to be handled manually on CSR, maybe we should handle that in the Control module
<_florent_>
rjo: but in your design, at the top level "sys" clock domain of CSR is not the same than "jesd" clock domain right?
<rjo>
_florent_: yes. my design is actually an example where the CSRs end up being somewhere else.
<rjo>
_florent_: i'll add it back in.
<_florent_>
rjo: I think we can consider the control signals from the core as asynchronous
<_florent_>
rjo: so we can keep the MultiReg in the core
<rjo>
_florent_: yes. it's definitely fine here. but it's not the usual modus operandi in other CSR cores.
<_florent_>
rjo: if control signals are synchronous to jesd clock domain, then it will just add a bit of latency
<rjo>
_florent_: sidenote: i also tried using fewer BUFGs for the CDs (BUFR/BUFMRs instead) but that never worked out. i think for designs with more of these transmitters that might end up being necessary.
<_florent_>
rjo: ok, was it failing at P&R or just not working on board?
<rjo>
_florent_: failing in route.
<rjo>
didn't try on board, might do so actually.
<rjo>
_florent_: nope. doesn't work. not even CGS...
<_florent_>
rjo: ok
<rjo>
_florent_: ha. now it does.
<rjo>
whitequark, sb0: still in the lab?
<rjo>
(you know what i am asking)
<_florent_>
rjo: it's possible the transceivers are not initialized correctly each time due to the workaround
<sb0>
rjo, Peter is installing the remote control switch right now
<rjo>
yippie!
<rjo>
_florent_: ah. maybe i misunderstood you above. the attempts with BUFR/BUFMR failed because of location constraints. the current artiq phaser branch failed because of timing.
<sb0>
rjo, scope is on for a now, we'll take it down in a moment
<sb0>
we are reorganizing stuff a bit
<rjo>
sb0: what was on the screen? flat lines or sinusoids?
<whitequark>
rjo: sinusoids
<rjo>
yay!
<rjo>
whitequark: thanks. then also 10 GBps works (sometimes) with data.