<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #946: That's due to the analyzer interfering (it is writing back to the memory the full DMA sequence, using IO bandwidth, causing bus arbitration delays, DRAM page cycles, etc.). With the analyzer disabled I get 207mu instead of ~1150mu.... https://github.com/m-labs/artiq/issues/946#issuecomment-371709719
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #946: The KC705 is less affected because the wider DRAM words make linear transfers (which is what the DMA core and the analyzer are doing) more efficient. We could reach similar efficiency on Kasli by implementing optional long bursts in the DRAM controller. https://github.com/m-labs/artiq/issues/946#issuecomment-371710280
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #946: The KC705 is less affected because the wider DRAM words make linear transfers (which is what the DMA core and the analyzer are doing) more efficient. We could reach similar efficiency on Kasli by implementing optional long bursts in the DRAM controller, and supporting them in the DMA and analyzer cores. https://github.com/m-labs/artiq/issues/946#issuecomment-37
<GitHub-m-labs>
[artiq] cjbe commented on issue #946: Right - if I am reading the SDRAM core correctly, it is currently not buffering reads and writes, or optimising access patterns. So on Kasli during a DMA sequence, in worst case of DMA and analyser data in same bank:... https://github.com/m-labs/artiq/issues/946#issuecomment-371753897
attie has quit [Remote host closed the connection]
<rjo>
sb0: i guess we are doing the other more pertinent things before #946, right?
<rjo>
marmelada: hello!
<marmelada>
sb0: with latest commit I get "cannot find function `wdly_dqs_taps_read` in module `ddrphy`"
hartytp has joined #m-labs
<hartytp>
what misoc are you using?
<marmelada>
right, I'll update everything
<marmelada>
ok, I've had it, I'll switch to updating everything manually with git
<hartytp>
yes
<hartytp>
i conda uninstalled (--force) misoc
<hartytp>
git clone --recursive
<hartytp>
then pip install -e . in my artiq-dev environment
<hartytp>
that worked
<hartytp>
tbh, given the weird bitstream-bitstream variations we're seeing, I think it would be much better if _florent_ bumped misoc etc and built the binaries
<marmelada>
recursive clone of misoc?
<hartytp>
that way we'd all at least be using the same files
<hartytp>
leaving out the --recursive gives some libunwind error
<marmelada>
whoa, thanks for saving me some time :)
<hartytp>
np
<hartytp>
_florent_ just a thought, but would it be better to fix the known timing errors before sinking too much more time into the SDRAM
<hartytp>
they're probably not related, but somehow spending time on weird issues like this in a design with known timing violations doesn't seem like a good idea
<hartytp>
might be worth fixing the timing and going over the vivado output carefully before doing too much more
<sb0>
hartytp, what timing errors? the ethernet?
<sb0>
just disable ethernet for testing sdram
<hartytp>
yes
<hartytp>
remind me how to do that?
<hartytp>
I just worry that the ethernet timing issues are making vivado do something stupid elsewhere, which is causing this chaos
<sb0>
what doesn't make sense, however, is why the vivado [redacted] is causing this timing error
<sb0>
we're using the recommended BUFGCE_DIV and its non-deterministic phases, but it's still unhappy
<sb0>
rjo, why did you say it was ethernet?
<sb0>
_florent_, serwb_serdes_20x_clk is also failing TPWS when SAWG is enabled
<marmelada>
sb0: could we change implementation strategy to extraTimingOpt? "Includes alternate algorithms for timing-driven optimization"
<sb0>
I don't know if that deals with TPWS
<sb0>
or just general logic
<sb0>
what is happening right now is vivado doesn't meet the skew specifications between the multiplied clocks for the ioserdes, even though we're using the recommended buffers
<sb0>
If the design still fails to meet the requirement, the next step is to try to reduce the skew between the CLK and CLKDIV pins by assigning a CLOCK_DELAY_GROUP to the nets.
<sb0>
This tells the Vivado Implementation tools to balance the two clock networks. An example of the CLOCK_DELAY_GROUP is below:
<sb0>
geez, they had something that worked well in 7series, why did they mess it up
<sb0>
marmelada, rjo in my SAWG build it met timing
<marmelada>
Xilinx' advice on timings: Launch a run for every strategy Pick the best one from design runs table
hartytp_ has joined #m-labs
<hartytp_>
sb0: I agree, this is frustrating
<hartytp_>
As a novice with FPGA design, the lesson I've taken away from this is not to underestimate the amount of work involved in switching FPGA families
<hartytp_>
e.g. to US
<marmelada>
hartytp_ I can try your bitstream on another sayma
<hartytp_>
marmelada: just to double check, does the exar fix make any difference to this?
<hartytp_>
if there are timing failures, we could be marginal so that PVT makes the difference between errors and no errors
<hartytp_>
marmelada: do you remember where _florent_'s patch for the eye scan is
<hartytp_>
my feeling here is that looking at the memtest passed/failed is almost useless, since it can pass even with bad eyes. it's kind of random
<hartytp_>
the only useful data is a complete eye scan, so I'll rebuild with that and redistribute
<sb0>
moving from spartan6 to kintex7 wasn't like that...
<marmelada>
hartytp_ I did this on board with fixes
<marmelada>
hartytp_: and I'll check on board without fixes
<sb0>
spartan6 also has a lot of misfeatures, like uncalibrated and generally uncalibrable iodelays that corrupt data if the delay becomes more than 1UI. kintex7 was a breath of fresh air.
<sb0>
marmelada, hartytp_ I've uploaded my binaries that pass timing
<sb0>
with sawg
<marmelada>
m-labs.hk/sayma?
<sb0>
yes
<rjo>
sb0: because that's where it failed timing.
<sb0>
rjo, yeah sure but I'm asking for the timing report etc. more info
<rjo>
sb0: will upload.
<sb0>
those new binaries with SAWG pass the memtest
<sb0>
reliably it would seem, i rebooted the board ~10 times
<sb0>
WARNING: [Synth 8-6040] Register <88><F3><9D>/L^? driving address of a ROM cannot be packed in BRAM/URAM because of presence of initial value.
<hartytp_>
let me know when you want me to rebuild the gateware and try again
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: i did some changes on the IO constraints (to try to match MIG constraints) and integrated the eyescan in the firmware. I'm stopping for today, you can rebuild if you want. https://github.com/m-labs/artiq/issues/908#issuecomment-371807757
<hartytp_>
"WARNING: [DRC PDRC-153] Gated clock check: Net CLKB0 is a gated clock net sourced by a combinational pin ISERDESE2_i_1/O, cell ISERDESE2_i_1. This is not good design practice and will likely impact performance. For SLICE registers, for example, use the CE pin to control the loading of data. WARNING: [DRC PLHOLDVIO-2] Non-Optimal connections which could lead to hold violations: A LUT ISERDESE2_i_1 is driving clock pin of 1 cells. This
<hartytp_>
on Sayma_RTM
<hartytp_>
is that worth worrying about?
<hartytp_>
anyway, it would be good for someone to go over the vivado outputs and check that there is nothing pointing to potential issues with Sayma
<hartytp_>
(someone who knows better what to look for than I do)
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: no, i don't have others ideas for now. On your last bistream that was failing, you had stranges values for write leveling: (140* 147* 173* 164*). I don't explain it. If you are able to reproduce it, we will maybe have a better idea with the scan that is now done for write leveling. https://github.com/m-labs/artiq/issues/908#issuecomment-371811481
<sb0>
hartytp_, worst case that can break serwb. something _florent_ should fix ...
<sb0>
strangely enough, the kintex-7 ddr phy also does this kind of local clock inversion but we don't get that warning
<rjo>
hartytp_: i don't have it. have you tried it?
<hartytp_>
rjo: working on it now
<hartytp_>
but, Sayma is a bit of a black hole that my time all seems to dissapear into
<hartytp_>
so no timeline yet
<hartytp_>
was going to add it to opticlock
<hartytp_>
do you want a pr?
<hartytp_>
sb0: I see the same in Sayma AMC
<hartytp_>
"WARNING: [Place 30-568] A LUT 'IDDRE1_i_1' is driving clock pin of 5 registers. This could lead to large hold time violations. First few involved registers are: IDDRE1_4 {ISERDESE3} IDDRE1_3 {ISERDESE3} IDDRE1_2 {ISERDESE3} IDDRE1_1 {ISERDESE3} IDDRE1 {ISERDESE3}"
<rjo>
hartytp_: would be nice. yes. on eem7 if possible.
<hartytp_>
right
<hartytp_>
that's what I'm doing#
<sb0>
Sayma is a bit of a black hole that my time all seems to dissapear into << yes, that's what my experience has been as well for the past 7 months
<hartytp_>
sb0: well, I think we can fix all that.
<hartytp_>
I do wonder if tracking down these vivado warnings would be a good next step
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #951: > CRITICAL WARNING: [Common 17-165] Too many positional options when parsing 'main_bufgce_div/O', please type 'get_nets -help' for usage info. [/home/ion/scratch/tph/artiq/artiq_sayma/standalone/gateware/top.xdc:695]... https://github.com/m-labs/artiq/issues/951#issuecomment-371821056
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #951: @hartytp There's myriad of warnings and critical warnings you can get. If we could for example suppress some levels of information they would stand out more. https://github.com/m-labs/artiq/issues/951#issuecomment-371822326
<GitHub-m-labs>
[artiq] whitequark commented on issue #951: @hartytp We already flag the build on timing violations (it's a warning in buildbot). Not for critical warnings because there are so many for bullshit reasons, like adding files with multiple TCL commands and not one... https://github.com/m-labs/artiq/issues/951#issuecomment-371822986
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #951: It seems to be ``-of``, which is not documented but appears in other examples and application notes. Vivado no longer complains about the command. https://github.com/m-labs/artiq/issues/951#issuecomment-371830230
<whitequark>
at least, the library doesn't initialize with a very descriptive error called "UnexpectedError", and the last thing it does is trying to open /proc/bus/usb
<whitequark>
so much for that VM idea...
<sb0>
whitequark, why not put fake usb ports on the vm?
<sb0>
hm, so you have to set up a payment gateway account first
<whitequark>
yes
<whitequark>
hm, this is very odd
<whitequark>
picam sends an UDP broadcast packet and the camera responds, and it actually receives it via recvmsg
<whitequark>
but the returned list of cameras is empty
d_n|a has quit [Ping timeout: 260 seconds]
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: it seems your board has different write leveling behaviour that the others. I'll try to artificially reproduce this behaviour on our board (by adding additionnal initial delay to dq/dqs) to see if it's handled correctly by the gateware/firmware. https://github.com/m-labs/artiq/issues/908#issuecomment-371854504
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: it seems your board has different write leveling behaviour than the others. I'll try to artificially reproduce this behaviour on our board (by adding additionnal initial delay to dq/dqs) to see if it's handled correctly by the gateware/firmware. https://github.com/m-labs/artiq/issues/908#issuecomment-371854504
<marmelada>
hartytp_: where can I check if there's any output of hmc830
<marmelada>
?
<rjo>
marmelada: j58/j59
<hartytp_>
marmelada: same link as before?
<hartytp_>
what RF frequency are you expecting?
<hartytp_>
I just stuck a scope probe on the output coupling capacitor
<hartytp_>
IIRC, there is also a UFL that you can connect to
<marmelada>
yes
<marmelada>
hartytp_: I don't know, I haven't a faintest clue what's happening in Greg's code right now ;)
<marmelada>
I just want to check if it works as advertised
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: i don't have idea for board-board variations but with your traces, i see that the firmware is not doing write leveling correctly: On your last capture the firmware is selecting 184* for Module 0 where it should select something like 346. It does that because we have some oscillation at the end of the 1 to 0 zone and are not robust to that. I'm going to im
<marmelada>
hartytp_: I don't get currently any response on rtm uart, perhaps it's wrong baud rate
<marmelada>
I'll check few things during weekend, but otherwise I'll try it again on monday
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Well, since there are no gaps in the working region, only a particularly noisy transition region, I agree that a more robust algorithm should work. ... https://github.com/m-labs/artiq/issues/908#issuecomment-371881213
<marmelada>
sb0: I should be able to flash rtm with openocd, right?
<rjo>
marmelada: artiq doesn't do anything on the rtm uart iirc. and there is no flash on the rtm, slave serial loading via the amc is not yet funded and not yet working.
<rjo>
marmelada: but "artiq_flash .... load" will load the rtm gateware as well.
<GitHub-m-labs>
misoc/master d167def Florent Kermarrec: sdram_phy/kusddrphy: add odelaye3 on all outputs (to have identical delays on all outputs before software dq/dqs delay configuration)
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Thanks. Will do that on Monday. Fingers crossed! Thanks again for all the hard work on on this. We've fixed quite a few potential issued so hopefully we're getting there.... https://github.com/m-labs/artiq/issues/908#issuecomment-371943378