<sb0>
rjo, JESD204 SYNC and SYNCOUT are currently connected through the RTM. I'm a bit unfamiliar with this part of JESD - do we actually need them?
<sb0>
request is sent to the transmitter via the SYNCOUT signal
<sb0>
of the link.
<sb0>
why would they lose synchronization?
<sb0>
If any lane in a link loses synchronization, a resynchronization
<sb0>
and why can't this go over SPI?
<sb0>
so it seems you need SYNCOUT...
<sb0>
_florent_, ^
<sb0>
it's used at the beginning too
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
larsc has quit [Remote host closed the connection]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 258 seconds]
<sb0>
whitequark, do we need to have artiq/runtime and artiq/runtime.rs?
<_florent_>
sb0: not sure what you call SYNC and SYNCOUT, but this is the same SYNC signal that is use to detect valid CGS (SYNC deasserted by DAC) and loose of synchronization (SYNC reasserted by DAC)
<_florent_>
sb0: so I think we are already using this signal
<rjo>
whitequark: sure there is a way to express optional dependencies.
<rjo>
yep. i have no idea where the _ren comes from.
<sb0>
where did the _part* go?
<sb0>
rjo, try putting both ports in write first
<sb0>
including the read-only one
<rjo>
what do you mean by that? the two ports are write-first
<sb0>
no, your read-only port uses the read-first style "memdat <= mem_grain0_part0[memory0_adr0];"
<sb0>
try switching to "register the address + asynch read" write-first style.
<sb0>
NB: the latest Xst coding guide says the same as your 2006 document, which could avoid this problem with dual-port memories
<rjo>
sb0: both ports are generated by migen (write-first). do you want me to change emit_verilog()
<sb0>
rjo, I know they are generated like that by migen. but it uses different styles in this case, which may not be the right thing to do, or it should use the style from your document
<rjo>
ok.
<sb0>
maybe try editing the verilog manually first, and see if ise still does the wrong thing
<sb0>
rjo, migen writes the build commands into a shell script so you can simply run that again to avoid overwriting your changes
lars_ has joined #m-labs
bentley` has quit [Ping timeout: 246 seconds]
<rjo>
yep. got that.
<rjo>
this one i have never seen before: INFO:Xst:3227 - The RAM <Mram_mem_grain0_ren>, combined with <Mram_mem_grain0>, will be implemented as a BLOCK RAM, absorbing the following register(s): <memadr> <memadr_x>
<sb0>
but address collisions would seem potentially undefined to me, or depending on other silicon properties, since the two ports can have different clocks
<rjo>
sure. for different clocks they are always undefined afaik.
<sb0>
yes, does the xilinx silicon have the right timing so that they are not, when the two clocks are the same?
<sb0>
this potentially requires extra circuitry too
<rjo>
ack. i'll just tweak the read-only ports to use the same mechanism as rw ports. that should be minimally invasive for now.
<sb0>
rjo, regarding this new Vivado RAM template: they use blocking assignments for signals that go outside the always block
<sb0>
this has the potential for producing very obscure simulation bugs
<sb0>
Verilog blocking assignments are nasty and generally should be avoided
<sb0>
e.g. @posedge(clk) b = a; @posedge(clk) c = b; @posedge(clk) d = c; has a latency between a and d that varies on the simulator du jour, maybe also on unrelated changes in the code
<whitequark>
sb0: I *am* fixing the build
<whitequark>
let me push my yesterday's LLVM code, which should fix one of the two tests...
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-all
<bb-m-labs>
build forced [ETA 1h51m37s]
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-all
<bb-m-labs>
build forced [ETA 1h51m37s]
<bb-m-labs>
I'll give a shout when the build finishes
* cr1901_modern
is trying to free up drive space for a Vivado and Quartus install
<cr1901_modern>
sb0: approx how big is a vivado install if you know?
<cr1901_modern>
maybe do a du on /opt/Vivado, or whatever?
<sb0>
rjo, "The FPGA's built-in transceiver PLLs are not very flexible, so if easy changing of the RTIO clock frequency is desired, we should consider replacing the XOs with PLL synthesizer chips." << actually we can just use the si5324
<sb0>
the XOs are still useful for debugging though, in case we suspect the Si5324 is acting up
<sb0>
rjo, a problem with RTIO switches, especially the cut-through variety, is the Metlino/Sayma AMC DRTIO and Sayma AMC/RTM DRTIO would operate at different speeds
<rjo>
sb0: yes. i was about to say that as well.
<rjo>
can the si5324 be wired (sic) so that it does something right from the beginning for a freshly manufactured board or do we need I2C to program it?
<rjo>
sb0: different speeds have the issue of alignment again.
<sb0>
we need i2c
<sb0>
there are many parameters in there, and you can't tell it to do something just by setting a few pins
<rjo>
and they can still be cut-through by adding a fifo big enough to hold half a packet. plus minimum-path-speed determination during enuermation.
<rjo>
yes. then how do we debug it if we don't have a clock from it?
<sb0>
debug what?
<rjo>
ah. is that what you are saying?
<rjo>
the si5324
<sb0>
the Si5324 is for clocking transceivers, the logic can be clocked by another oscillator
<rjo>
si5324 + independent XO.
<rjo>
yes.
<sb0>
I'm proposing two XOs: a backup XO for the transceivers (not used in theory), plus another XO for clocking logic (we can find schemes without, but it's cheap and convenient)
<sb0>
that "logic" includes the management softcore CPU in a satellite, and the DDR3 controller
<sb0>
since DDR3 is picky about what frequencies it will run at, it would be unwise to clock that from DRTIO
<rjo>
we need one XO+si5324 to do clock recovery from the link and to drive rtio logic. we need another XO to configure the si5324. and we can use that latter XO to run the cpu and the mem controller etc.
<rjo>
is that what you are saying?
<sb0>
for clock recovery, a Si5324 alone is enough
<sb0>
no XO is required
<sb0>
but I want to add one (we can DNP it later) as it may make transceiver debugging easier
<sb0>
that XO goes to another GTREFCLK and is independent of the Si5324
<rjo>
on another GT clock input different from the SI5324 input?
<sb0>
yes
<rjo>
that would only be required if we can't get the SI5324 to output something during early GTX bring-up, right?
<sb0>
yes, or if we suspect issues with its transitions between internal/external reference sources
<rjo>
i.e. if freerun mode is broken.
<rjo>
yep. lgtm.
<sb0>
the other XO, yes, it's for what you mention
<rjo>
technically we can also just use the clocks coming in from the rtm.
<rjo>
... for that DRTIO bootstrap purpose.
<sb0>
but again that other XO is not strictly necessary, we can use the RTM clock or piggyback on the GMII clock
<sb0>
but those things are cheap and convenient
<rjo>
sure.
<sb0>
I see Greg has put the other XO (OSC2) but forgot the one on GTREFCLK
<rjo>
larsc: hmm. ok. and you say that's not the same as the 3 PClock cycles of "variable DETERMINISTIC LATENCY"?
<larsc>
yeah, I have no idea
<larsc>
lets wait and see what the experts have to say
<larsc>
it is a bit unfortunate that there is no specification of the term
<larsc>
In some of the LVDS converter datasheets you find '1 DAC latency is defined as the elapsed time from a data sample clocked at the input to the device until the analog output begins to change.'
<larsc>
but those don't have a elastic buffer
<larsc>
the question is, is this variable latency before or after the elastic buffer
<whitequark>
how about adding your monitoring thing to ubuntu-trusty-buildbot.lab.m-labs.hk ?
<rjo>
whitequark: sure. will do. how do i log in?
<rjo>
whitequark: even windows can do munin.
<whitequark>
oh, please put that on the windows VMs either
<rjo>
"also" or "don't"?
<whitequark>
er, also
<whitequark>
let me figure out auth
<rjo>
whitequark: i'll do the windows thing first.
<whitequark>
both win7-buildbot and win7-experimental are logged in
<rjo>
whitequark: experimental works now. buildbot seems down
<rjo>
whitequark: if the router wasn't really short on flash space (~40kB) i'd also put it there.
<rjo>
whitequark: and because many ISPs are not doing 6to4 anymore (e.g. Vodafone/Kabel Deutschland), i also started setting up a henet tunnel to the PoP in HK but also there I'd need a bit of flash memory...
<whitequark>
down? it's not down...
<whitequark>
oh, that's probably some IP weirdness
<whitequark>
try lab.m-labs.hk:5900
<whitequark>
rjo: yeah. you (or I) can rebuild the squashfs to get flash. but I can't fit much there.
<whitequark>
I think you can already set up a SIT tunnel
<rjo>
that URI closes the connection immediately.
<whitequark>
that's the VNC
<rjo>
whitequark: why should the vnc port on the actual VM IP not work?
<rjo>
whitequark: it works for -experimental
<whitequark>
is it routed to V6 or V4?
<rjo>
whitequark: we are talking about two things here.
<rjo>
the vnc stuff is ipv4 and works for -experimental but not for -buildbot for me.
<whitequark>
ohh
<whitequark>
are you *sure* you set things up on -experimental?
<rjo>
i didn't finish setting up the henet v6 tunnel because i couldn't install that 6in4 (sit) package.
<whitequark>
let me check something
<rjo>
i vnc'ed into win7-experimental and that's where it is running now.