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
rohitksingh-demo has joined #m-labs
<GitHub66>
[smoltcp] dlrobertson opened pull request #126: Increase required size for ICMPv4 packets (master...update_check_len) https://github.com/m-labs/smoltcp/pull/126
Ishan_Bansal has quit [*.net *.split]
reportingsjr has quit [*.net *.split]
cyrozap has quit [*.net *.split]
rjo has quit [*.net *.split]
kuldeep has quit [*.net *.split]
gric has quit [*.net *.split]
cyrozap has joined #m-labs
rjo has joined #m-labs
kuldeep has joined #m-labs
reportingsjr has joined #m-labs
Ishan_Bansal has joined #m-labs
<mithro>
whitequark: You seem to like doing crazy things - any idea if we could LD_PRELOAD something which did userspace emulation of vsyscall to allow ancient statically linked binaries to work when vsyscall is disabled in the kernel?
<bb-m-labs>
build #1955 of artiq is complete: Failure [failed python_coverage_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1955 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
whitequark, when you do your firmware hotswapping tricks, does it run the bios again?
<sb0>
I want to program some phase offsets into the BIOS instead of putting them in the bitstream, since the vivado trash takes so long to recompile for ultrascale
<sb0>
and the interface is basically a signal that you pulse to increment the phase
<sb0>
there is no easy way to reset the phase to the original position
<sb0>
so if the BIOS runs twice, the phase offset is twice what it should be.
<sb0>
i_CLKFBIN=mmcm_fb, o_CLKFBOUT=mmcm_fb,
<sb0>
WARNING: [Timing 38-41] Feedback on MMCME3_ADV cell MMCME3_ADV forms an incomplete loop.
<sb0>
this is of course followed by >1hr runtimes of the vivado garbage since it's trying to optimize some impossible thing with the clocks
<cr1901_modern>
Why can't you add a false path?
<sb0>
there are false paths
<sb0>
the vivado junk takes them into account when it was a PLLE2_BASE
<sb0>
but not when using the ultratrash MMCME2
<sb0>
*MMCME3
<cr1901_modern>
Xilinx's rules for deciding whether two different clocks are synchronous are screwy. For a DCM on S6, it can prove that the output is a multiple of the input and thus the two clocks are synchronous. Sometimes.
<cr1901_modern>
Wonder if it's trying to do the same here and failing
<cr1901_modern>
(maybe not, since ISE != Vivado)
<sb0>
hmm, when using MMCME2 and letting vivado retarget it, it seems to behave
<cr1901_modern>
retarget?
<sb0>
using old fpga primitives (e.g. mmcme2 or plle2_base from 7series) in newer fpgas (e.g. mmcme3 from ultrascale) and having vivado convert them automatically
<rohitksingh-demo>
cr1901_modern: oh sb0 already replied...I was gonna reply too
<sb0>
once in a blue moon, xilinx think of relevant features like that...
<rjo>
sb0: i'd like to talk about the si5324 wiring on kasli. doyou have a minute?
<sb0>
yea
<rjo>
rohitksingh-demo: are you interested in a nice application of tweaking the mor1kx?
<rjo>
rohitksingh-demo: have a look at the kasli bitstream in artiq and see how it can be made to meet timing.
<rjo>
sb0: i am wondering about changing the crystam from 114.xxx MHz to 125.
<sb0>
hm, why?
<rjo>
sb0: and moving the fpga clkrec to clk2.
<sb0>
to the clkin2 input? that won't work
<rjo>
because then we could fail-over between the recovered drtio clock and the crystal and the the external clock.
<rjo>
yes clkin2
<rjo>
it can't do fail-over between the xo and clkin2?
<sb0>
no. the fail-over is actually between clkin1 and clkin2, and the crystal is internally routed to clkin2
<rjo>
ok. if that's the case, i'd still change the crystal to 125 mhz, leave clkin2 on the sma and clkrec on clkin1.
<rjo>
125 mhz XO is allowed (according to DSPLLsim).
<sb0>
the doc also says that the si5324 works better when the clock ratios are not simple multiples, which is why they have this weird crystal frequenca
<sb0>
why do you want to change it?
<rjo>
then we would not need different pll parameters when feeding 125 mhz externally (clkin2), 125 mhz recovered (clkin1) and the XO (xa/xb/clkin2).
<sb0>
why not send the external 125MHz through the FPGA on CLKIN1?
<sb0>
unlike many xilinx components, things like BUFGMUX actually work well
<rjo>
way too jittery.
<sb0>
even after going through the si5324 pll?
<sb0>
what is the si5324 clocking anyway?
<rjo>
see the schematic.
<sb0>
well if you're going to answer like that then don't ask me questions, I'll tell you "see the si5324 datasheet"
<rjo>
i am pretty sure you know what the si5324 is clocking.
<sb0>
can the ultra-jitter-sensitive parts be clocked with a direct path from the clean 125MHz?
<rjo>
they should be clocked that way. but i don't see how to do that easily. that's also why i want to remove that part of the clocking fanout.
<rjo>
sb0: do you remember where they said that fractional n is better than integer n in the datasheet? i think this is what you were referring to. i can't find it.
<sb0>
it wasn't in the datasheet itself, but some other doc
<sb0>
let me look for it ...
<sb0>
rjo, what exactly do you need to clock?
<sb0>
other than the FPGA?
<rjo>
but ok. for spurs fractional n is better. for integrated noise, integer-n is better. i get that.
<rjo>
sb0: we need to clock the fpga fabric, the transceivers, and a path to the panel SMA (in case that clock is the reconstructed DRTIo clock), and a path to an internal MMCX (reconstructed DRTIO clock for internal use), and a diff path to the backplane (same).
<rjo>
i.e. the clocking tree is fine with the single 4x fanout on clkout1 and clkout2 going to the sma.
<sb0>
To avoid spurs, avoid outputs that are an integer (or near integer) of the XA/XB frequency.
<sb0>
on p. 74
<sb0>
iirc there are longer explanations in that manual
<rjo>
ack. ok. i am happy. let's keep that part the way it is and just remove the 8x fanout.
<rjo>
the only wrinkle is that we can't fail over between external 100mhz and the XO and we need different pll parameter sets for those two configs.
<rjo>
well. we could come up with a way to have the fpga route the 125 mhz from XO on the gtp clock input to clkin1 and fail over between that and the external clock.
<rjo>
another thing. are you ok with dumpping the 50 mhz xo on the fpga? the 125 mhz xo on the gtp works well feeding the fabric.
<sb0>
yeah that should be fine, have you tested it to make sure there are no vivado surprises?
<rjo>
sb0: i have been using it in that configuration.
<sb0>
my MMCME2 for example doesn't produce the warning anymore but the vivado router runtime is still messed up
<rohitksingh-demo>
rjo: sure! I'll look into that! Is the timing failing in mor1kx?
<rjo>
using both O (to GTP) and ODIV2 (to fabric) of that IBUFDS_GTE2 works well so far.
<sb0>
rjo, so you are feeding *both* the transceiver and the fabric and there is no Xilinx BS going on?
<sb0>
ok...
<rjo>
rohitksingh-demo: yes. i have played a bit with the dcache parameters but no change. i am far from understanding the dcache internals.
<sb0>
rjo, have you managed to open vivado projects produced by migen and then edit the placed-routed design?
<sb0>
maybe the PLLE2_BASE can be kept, and then the phase edited by the vivado GUI, since the MMCM primitives won't cooperate
<rjo>
sb0: i haven't tried editing. just looking.
<sb0>
that also avoids the BIOS bug mentioned
<sb0>
rjo, okay. here it says the design has not been implemented, even when it has
<sb0>
so it wants to run synthesis and P&R again
<rohitksingh-demo>
rjo: okay, I'll look into that...btw when is _florent_ departing from HK?
<sb0>
rjo, so I don't fully understand your clocking plan.
<_florent_>
rohitksingh-demo: on saturday
<rjo>
sb0: just FYI, you can use the checkpoints that migen has vivado generate to do that kind of inspection somewhat nicely.
<rjo>
sb0: what part. happy to elaborate.
<sb0>
the general idea
<sb0>
is it like sayma, where there is a dac clock that should be in phase with the recovered drtio clock?
<sb0>
(dac clock externally distributed)
<sb0>
why is there a 100MHz clock on kasli at all, when the drtio frequency is 125?
<rohitksingh-demo>
_florent_: awesome! you are eagerly awaited here!
<rjo>
multiple use cases (a) single kasli, 100 mhz ref into the sma=clkin2, fpga feeds 125 mhz from gtp through clkrec to clkin1, clkout1 125 mhz to fpga/gtp/etc, clkout2 125 mhz (or something else) to sma by population option.
<rjo>
100 mhz is the/a standard reference frequency from rubidium/maser/gps/caesium
<rjo>
(b) kasli as drtio slave, fpga recovers 125 mhz, feeds into clkin1, fail-over with 114.xx mhz xtal on clkin2, clkout etc same as before.
<sb0>
how is the 100M reference used?
<rjo>
to provide accurate timing.
<sb0>
you want to multiply 100M->125M with the si5324?
<rjo>
sb0: yes.
<sb0>
for DRTIO mastering the Si5324 does not do clock switching
<sb0>
it's a pure frequency synthesizer, or stays unused if we clock the transceiver in another way. so we can do as you say, simply never connect the crystal to clkin2, and use your reference clock instead
<sb0>
with different PLL parameters
<rjo>
sb0: but to implement switching between external (sma) clock and internal (either the si5324 xo or the gtp xo) it needs to.
<sb0>
with a single kasli we also don't use the si5324 so it's available for that too
<rjo>
if you don't do that switching, then we have a configuration/bitstream for single-kasli-with-external-clock and one for single-kasli-with-internal clock.
<GitHub179>
[artiq] whitequark commented on issue #897: Ah, no, the firmware should rather always initialize the PHY and not rely on the bootloader to do that. We had code to do that but I think I accidentally removed it while refactoring. https://github.com/m-labs/artiq/issues/897#issuecomment-358611479
<GitHub126>
misoc/master e85fce9 Sebastien Bourdeauducq: Revert "sayma: use MMCM instead of (retargeted) PLLE2_BASE"...
<rjo>
i'll look into auto failover between clkin1 (from the 125 mhz xo) and clkin2 (100 mhz external). having more places where the user needs to understand details of the clocking tree is the second best solution.
<sb0>
?
<rjo>
? to what part?
<sb0>
does the user need to specify more information than whether the externally supplied clock should be used?
<rjo>
yes. if there is auto failover he doesn't have to specify anything.
<sb0>
but this is an anti-feature imo
<sb0>
the system could silently use another clock than what the user thinks it is using
<GitHub29>
[smoltcp] batonius opened issue #127: smoltcp doesn't replace unspecified src addresses with local addresses for UDP and TCP sockets https://github.com/m-labs/smoltcp/issues/127
<rjo>
i don't think that's an issue. we can use an led or a check in the runtime to verify that. still less code. and it makes testing much easier. IME this is also how other devices operate. use the reference if there is one.
<sb0>
the current kc705 code doesn't do that and no one has complained about it...
<sb0>
and I disagree that it's less code
<rjo>
you can't use the lack of complaints to argue that something is the best solution.
<sb0>
that was an additional argument to the "anti-feature" one
<GitHub84>
[smoltcp] dlrobertson commented on issue #126: There is another check just below this with `header_len`. `header_len` is still 4 for all unknown types though. Perhaps this change should be to `header_len`. Then we can simplify `check_len`. https://github.com/m-labs/smoltcp/pull/126#issuecomment-358619717
<sb0>
oh I take it back, the vivado gui thing is not reasonable at all
<sb0>
all it does is add commands in your .xdc file that override what the verilog says during synthesis
<sb0>
this used to possible with fpga_editor... sigh
<rjo>
sb0: i have noticed vivado not recognizing the false paths that we add in the xdc using the custom properties.
<rjo>
we define the custom properties in the tcl, but vivado doesn't save them in the xpr so when you open the xpr and load the xdc it doesn't mark the false paths.
<rjo>
at least some false paths (the multireg and asyncresetsynchronizer ones).
<sb0>
ah. anyway it seems I should be using the checkpoint mode instead to do this editing...
<sb0>
it's actually even scriptable in batch mode. open_checkpoint top-routed.dcp, set_property xxx, write_bitstream
<sb0>
with the ultrascale runtimes through the roof, we're probably going to need this kind of editing a lot...
<sb0>
the write_bitstream bloat is also ultrascaled, but ultrascaled from a smaller initial value, so it's not too bad
<hartytp>
I assume that by "not working" you mean "not locking"
<hartytp>
that's not a very useful diagnostic as it's binary, so doesn't give any diagnostic info
<hartytp>
much better would be a register dump after the lock attempt times out
<hartytp>
then we can see if the vco is on the correct range etc
<hartytp>
if you get a chance can you do that
<hartytp>
?
<hartytp>
otherwise, I'll do it next week
<hartytp>
anyway, this is still progress: Weida got the PLL working with an eval board + FPGA so we know those registers work
<hartytp>
I'l checked clock input and supplies
<hartytp>
so most likely remaining candidate is glithc/timing issue on SPI
<hartytp>
Later next week Weida and I will take his working FPGA code that he uses with his eval board and load it onto Sayma RTM
<hartytp>
hopefully that should work
<hartytp>
if not, we'll get a scope out and compare the physical signals on the two boards
<hartytp>
either way, we'll get there!
<hartytp>
in the meantime, just keep using the external clock input
hartytp has quit [Ping timeout: 260 seconds]
rohitksingh-demo has quit [Quit: Leaving.]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
sb0 has joined #m-labs
rohitksingh-demo has joined #m-labs
<sb0>
hartytp, how many times did he get it working? on sayma, sometimes it works for a dozen times in a row then breaks ...
<sb0>
(at least the previous code - not the registers - did...)
<sb0>
*your registers
hartytp has joined #m-labs
<hartytp>
also he tried manually setting the vco range (rough output frequency) and checked that the output frequency changed. That didn't work reliably on Sayma last time I checked
<hartytp>
anyway, we'll load his code onto Sayma and see if it still works!
<hartytp>
in the meantime, the reg dump would help if you can get it easily
<hartytp>
anyway, this is all still a WIP, but will let you know when we have something on Sayma
<sb0>
unfortunately the ad9154 doesn't seem to have this feature ...
<larsc>
pretty sure it does
<larsc>
all of the new ones have it
<larsc>
oh right, its a DAC
<larsc>
yeah, the DACs don;t have it
<sb0>
but it seems, there is still a feature that tells you when you get sysref jitter +/- 1 DAC clock cycle
<sb0>
then you can find two consecutive sysref phase regions during which this jitter happen, and eventually set sysref in the middle
<dlrobertson>
whitequark: could use some feedback on some stuff with the impl of ICMPv6
<dlrobertson>
protocols like NDISC use ICMPv6 and I really don't want the number of variants of the Icmpv6Repr to explode or worse the number of setters/getters for Icmpv6Packet specific to types to explode
<dlrobertson>
I've been thinking about making the Icmpv6Packet only include the first four bytes for Icmpv6 packets not in RFC 4443 and adding something like data() which is then parsed by an NDISC specific parser
<dlrobertson>
thoughts about this? any ideas about possible better ways to do this?
<sb0>
INFO: [Designutils 20-2272] Running write_bitstream with 8 threads.
<sb0>
wtf
<sb0>
why do you need 8 threads to do that, especially in such a slow manner
<_florent_>
sb0: ok i'll look at the ad9154 datasheet
<_florent_>
sb0: your a7_gtp with drp sequence works on my board, let's reintegrate the drtio code and seems what breaks things....
<sb0>
_florent_, you can also try to add the phase align to it...
<sb0>
if you can reuse (not copy-paste) code that's even better
<sb0>
the 1.8V bug on sayma1 has become really terrible. the board typically dies in ~30 seconds...
<sb0>
and often doesn't start at all
<_florent_>
sb0: yes i can first try to add phase align
<sb0>
_florent_, well the buffer bypass is just normal init + phase align, essentially
<sb0>
isn't it?
<_florent_>
sb0: yes, but we need to reintegrate part of the pcs (8b10) and remove the mmcms
<sb0>
removing the mmcms is straightforward
<sb0>
you just hold {T,R}XUSRRDY to 1, and put a BUFG between {T,R}XOUTCLK and {T,R}XUSRCLK + {T,R}XUSRCLK2
<sb0>
I actually have to compress the bitstreams now to get a chance to see an ethernet packet before the board dies
<sb0>
what a mess...
<sb0>
okay I'm getting all the packet right now, except for a few bytes at the beginning and end
<sb0>
the vivado batch bitstream editing strategy is definitely good
<sb0>
only the last byte in the CRC is corrupted...
<sb0>
I suppose the rx_ctl timing is fucked
<sb0>
I also have one missing preamble byte
<sb0>
debugging the TX is probably going to be another PITA and will likely require another FPGA board to dump stuff at the GMII level
<sb0>
while hoping that the media converter, PHY, etc. don't drop frames with broken CRCs
<sb0>
this rgmii interface and its tight timing margins is really a pain
<GitHub153>
[artiq] sbourdeauducq commented on issue #854: I got RX to work correctly now, but TX is still broken. Are the traces about the same length on the PCB? Does the PHY expect the TX clock to be sent at the same time as the data? 90 degrees late? https://github.com/m-labs/artiq/issues/854#issuecomment-358728188
<sb0>
oh amazing, reconfiguring the tx pll breaks the rx pll
<sb0>
vivado at its best
<sb0>
anyway. got the first three pings packets from this sayma ethernet trash fire
<sb0>
it's of course a royal pain in the ass to test, since the board dies in 20 seconds from the 1.8V bug
<sb0>
I have a script that generates bitstreams with various PLL phases, and then "echo > /dev/ttyACM0; sleep 5; openocd -f sayma_new.cfg -c "pld load 1 bitstream_$PHASE"
<GitHub57>
[artiq] dhslichter commented on issue #896: @jbqubit we do not intend to do our own ARTIQ builds on Windows (can use a Linux box if this is really necessary), but we do require the ability to run ARTIQ on Windows. This means maintaining CI for conda packages for Windows. https://github.com/m-labs/artiq/issues/896#issuecomment-358784847