<GitHub87>
[smoltcp] nisalmenuka2 commented on issue #179: Thanks. But can I build it with an older version of Rust? Is it possible to use an older version of the 'managed' crate to overcome the above issue? https://github.com/m-labs/smoltcp/issues/179#issuecomment-372943448
<rjo>
whitequark: how is the windows build and installation coming along?
<whitequark>
rjo: having isp uplink problems again
<rjo>
sb0, whitequark: i need windows fixed today. which vm do i use for testing, what's the password/vnc?
<whitequark>
can't really access the vm via 128kbps hspa either.
<GitHub50>
[smoltcp] whitequark commented on issue #179: Not really, since these functions are only available on the nightly channel anyway (they were recently stabilized but are not yet present in a stable release). https://github.com/m-labs/smoltcp/issues/179#issuecomment-372944609
<rjo>
whitequark: ack.
sb0 has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rjo>
_florent_: thanks. i think you covered 2, 3, 4, 5. does 1 sound worthwhile to be put into the testing pipeline?
<rjo>
how reassuring that *O*DELAYE3 is also CTRL-ed by *I*DELAYCTRL...
<rjo>
(6) if "There is one IDELAYCTRL module per nibble (eight per bank).", then aren't we missing a few? i have no direct idea how to fix that though.
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 256 seconds]
<larsc>
iirc the tools auto duplicate the IDELAYCTRL
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
<rjo>
larsc: but that means all IDELAYCTRLs across the device need to have the same clock and settings because there is no way for Vivado to map that, right?
<larsc>
all the duplicated ones will have the same clock and setting
<larsc>
you don't tell the tools where to place the IDELAYCTRL it will just place it next to the I/ODELAYs it controls
<rjo>
but the IDELAYCTRL CLK inputs may be different and the RDY usage may be different. does vivado have enough info to figure out which IDELAYCTRL to duplicate where?
<sb0>
could we be missing the obvious and the dram is not sending correct data because e.g. it's activate-to-read timing is not respected? that wouldn't really explain the more frequent failures with sawg though (maybe a power supply drop or increased noise, but it's a bit far fetched)
<sb0>
once a row is activated, the dram is basically a sram within that row... useful for testing IO while taking a lot of parameters out of the equation
<sb0>
"basically a sram" includes "refresh can be ignored" (if the contents of the other rows doesn't matter)
<sb0>
so the dram can be put under low-level cpu control, the dfi injector supports that and also supports retrieving the read data
<_florent_>
sb0: we are already using the dfi injector for read leveling
<sb0>
okay, so the eye diagrams are with the injector and then the memtest with the gateware controller
<sb0>
correct?
<_florent_>
yes
<sb0>
ok, so it really looks like ultrascale ios crapping out ...
<sb0>
I wonder if LOCing the BUFGCE and BUFGCE_DIV to their no-SAWG position helps
<rjo>
_florent_: and now we have 'WARNING: [DRC REQP-1655] enum_DELAY_TYPE_FIXED_RST_GND: When the ODELAYE3 ODELAYE3_22 DELAY_TYPE is FIXED, the RST pin should be GND.' so you were right and xilinx was wrong.
<_florent_>
sb0: yes that would maybe help
<_florent_>
rjo: ok, do you revert that or should i do it?
<sb0>
rjo, when do you expect the grabber gateware to be ready? will you be working on it? should I do parts of it?
Rex0r has joined #m-labs
RexOrCine has quit [Ping timeout: 264 seconds]
<rjo>
sb0: i have the roi processors done. the lvds interface/iserdes/pll and the rtio interface are missing. there is no big urgency with the gateware. maybe 2-3 months.
<rjo>
sb0: i think it's better if you look at the saymas now than at the grabber gateware. you have the boards in HK.
<rjo>
sb0: but if you really want to and if there is slack, feel free to work on the cameralink interface. i think the serdes/pll part is right up your alley.
<rjo>
whitequark: ok. artiq 4.0.dev ... is installable just fine under windows.
<rjo>
i cleaned up the "root" (a.k.a. base) conda environment on vm-experimental and removed the obvious m-labs packages from that. just in case it interferes with other environments and tests.
<rjo>
_florent_, sb0: where does the 16 cycle delay (ic_reset_counter, ic_reset) of the IDELAYCTRL.RST come from? was that copied over from kintex?
hartytp has quit [Quit: Page closed]
<rjo>
_florent_, sb0: fyi, i have annother tweak to the idelayctrl/{i,o}{delay,serdes}e3 reset sequence pending.
sb0 has quit [Quit: Leaving]
attie has quit [Ping timeout: 264 seconds]
attie has joined #m-labs
attie has quit [Quit: leaving]
attie has joined #m-labs
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<sb0>
Alternatively if you require the MMCM outputs to be phase aligned (that is CLKOUTx_PHASE) and cannot apply the correctcontrols and control the timings from Fig: BUFGCE_DIV alignment, you can use aseparate BUFG clock buffer for fabric connections.
<sb0>
CLK and CLKDIV ports for the OSERDES are driven by BUFG's that are only connected to the OSERDES and will have similar loading/routing. CLKOUT1 and CLKOUT2 could also be used for other component primitives (ISERDES, IDELAY, ODELAY, IDELAYCTRL) as long as the routing destinations are similar.
<sb0>
maybe ultrascale/vivado is crapping out due to the large load imbalance on the two clock nets when SAWG is there
<sb0>
iirc the Xilinx MIG uses asynchronous CDC (with corresponding latency) and a dedicated SDRAM clock domain and would be immune to that...
<rjo>
_florent_, sb0: is the dqs preamble/postamble thing something that still needs investigating?
<rjo>
sb0: we could have dedicated BUFGCE{_DIV,} for SDRAM from the same MMCM/PLL output to isolate the load. but i would bet that the load skew is already included in the vivado timing models.
attie has quit [Ping timeout: 276 seconds]
attie has joined #m-labs
<_florent_>
rjo: i don't think the dqs preamble/postamble is the issue (not done on artix7/kintex7 and works fine)
<rjo>
_florent_: ok. anything i can look at/review that seems worthwhile?
Rex0r has quit [Ping timeout: 260 seconds]
Rex0r has joined #m-labs
<rjo>
current data point: on sayma-1 with artiq a315ecd1 and misoc 5a29984d and sawg, over ~50 boots, the read and write eye is >100 taps wide and stable in position. not much noticable difference with and without sawg.
<whitequark>
rjo: thanks
<whitequark>
do I understand it right that you only verified the package installability manually?
<rjo>
whitequark: yes. as in 'conda create -n artiq-4-dev -c m-labs/label/dev -c m-labs -c defaults -c conda-forge artiq=4.0.dev=724+git.....'