<hartytp>
I see, so while it's in the serwb init failure loop, reload the RTM only?
<_florent_>
yes
<_florent_>
ok thanks a lot, i have to go and won't probably be available in the afternoon, but if you post results, i'll analyze that and try to fix tomorrow
<hartytp>
will do
<hartytp>
if you think of anything else then let me know
hartytp has quit [Ping timeout: 260 seconds]
_whitelogger has joined #m-labs
Shikadi has joined #m-labs
<rjo>
sb0: are you sure that migen's expression size and signedness is generally sound? e.g. the example given in verilog 2001 4.4.2 (answer = (a + b) >> 1; //will not work properly).
<sb0>
hartytp, no, µTCA crate management is full of bugs and totally unusable with sayma
<sb0>
the best behavior I have seen (intermittently) is the sayma is powered for half a second and then dies
<sb0>
ironically, among the pile of bugs that manifest themselves when sayma is inserted, one of them kills the fans completely but makes the MCH think the fans are running
<sb0>
then you have to pull the power cord, otherwise the crate PSU cooks itself
<sb0>
(this happens intermittently)
<sb0>
rjo, maybe not; can you file issues?
<sb0>
I have not touched this code for years and don't remember every detail...
<hartytp>
I would like to look at #1064 by trying out other vivado versions
<hartytp>
but Sayma doesn't meet timing on anything other than 2018.1 afaict
<hartytp>
Vivado complains about the way ethernet timing is currently done, and removing those LOCs gets it to stop complaining and meet timing
<hartytp>
so, I want to check that there really isn't a better way of doing this
<hartytp>
is this *really* what Xilinx recommend for RGMII?
<hartytp>
aah, just saw that you have posted a uTCA issue
<hartytp>
never mind then, thanks!
sb000 has joined #m-labs
<sb000>
hartytp, if you're not using ethernet, in theory things are working without any LOC
<hartytp>
right, and I do plan to remove them during testing
<sb000>
also, to meet timing with the other vivado version, and ethernet, in theory you can set the LOC to whatever the autoplacer put the components, and redo rgmii phase tuning
<hartytp>
and there is no way of doing this without LOCs?
<sb000>
you can use the ethernet-yakshaving repos for the phase tuning, IME the results with LOC could be then reproduced
<sb000>
within misoc/artiq
<sb000>
i don't know why you like to pick on those constraints so much. AFAICT they aren't causing much of a problem
<rjo>
isn't the usual approach to do proper input delay constraints instead?
<rjo>
then you are not fighting PnR
<sb000>
there's one for the tx clock
<sb000>
(iirc)
<sb000>
the purpose is to set the phase between the clock sent to the chip and the clock to oddr
<sb000>
with the limited odelay range, it is difficult to do
<hartytp>
rjo: thanks for fixing that
<hartytp>
will post in a sec, but SAWG output looks good
<hartytp>
(well, modulo the fact that I don't have a reconstruction filter)
<sb000>
one way to deal with that one without loc is to generate both clocks from the same MMCM
<sb000>
but! right now the oddr are clocked from the system clock.which has non deterministic phase due to bufgce_div
<sb000>
so you need a dedicated mmcm anyway (and you use one more clock in the design)
<hartytp>
is there no way to deal with that?
<sb000>
also, arguably, two clocks from the same MMCM is a LOC in disguise
<sb000>
if you put a new mmcm for both the oddr and chip clock, and redo the phase tuning, then things work in theory for tx without this explicit LOC you dislike
<sb000>
the ethernet core does not require the tx clock be synchronous to the system clock
<sb000>
it just happens to be so in the sayma case
<hartytp>
sb0: it's more a case of "that Vivado doesn't like" than me
<hartytp>
why Sayma?
<sb000>
because both the system clock and rgmii clock are 125MHz
<sb000>
I.e. 125M was already available so I just used it
<sb000>
that's all
<sb000>
for rx, hm, might be worth a try without LOC
<sb000>
it's a more common mmcm use case, from a clock capable pin, so, the skew between mmcm locations may be low enough to be tolerable
<hartytp>
I have an ethernet adapter on the way from greg so will be able to test this soon
<hartytp>
okay, so worst case it's serdes + odelay
<sb000>
yes
<sb000>
but you lose resolution
<hartytp>
not with odelay as well
<hartytp>
that seems pretty easy to implement
<sb000>
odelays are complicated on ultrascale, but yes in theory it works
<hartytp>
well, in any case, I don't think the odelays should be neccessary
<sb000>
then when editing the bitstream for phase tuning you need to figure out how to set the serdes pattern plus the odelay value
<hartytp>
I know that we had a silly small eye a while back
<hartytp>
but AFAICT, that should be resolved now that greg fixed the hw issues with the phy
<sb000>
maybe. but ethernet is still so fragile that I want to avoid things that can break like that
<sb000>
a large part of the difficulty here is testing
<hartytp>
is it still fragile after the latest hw fixes?
<hartytp>
that's news to me
<sb000>
you tell me. I haven't seen so many boards.
<sb000>
note that rgmii is ddr
<hartytp>
I know
<sb000>
so with the serdes your granularity really is 1/4 ui
<hartytp>
ack
<hartytp>
although, I thought that RGMII was usually SDR with an 8-bit bus
<hartytp>
I agree that this will be a bit of a PITA to tune if the eye is 0.5ns wide. But, if it's a couple of ns, then it will be easy to find a SERDES tap that works and then tweak the ODELAY
<hartytp>
that really doesn't seem difficult
<hartytp>
e.g. much less frustrating than fighting against timing issues that arise because of LOCs
<hartytp>
so, I'll have a look at that when I look at ethernet
<hartytp>
Rx...
sb000 has quit [Ping timeout: 260 seconds]
<hartytp>
sb0: remind me where the bufg_div comes into this and what the issues are there?
<GitHub-m-labs>
[artiq] jbqubit commented on issue #794: Running 4.0.dev+1133.g0b086225. Compare phase between a pair of channels spanning both DACs on single Sayma. Set frequency0 to 40 MHz. Measured phase difference using Tek FCA 3003 Timer using 10k samples of 10 ms intervals. Saw stdv < 1 deg with peak deviation < 9 deg. Cycling off power and reloading 5 times I see variation in mean relative phase of ... https://githu
<GitHub-m-labs>
[artiq] jbqubit commented on issue #794: I got the fancy scope back so can make a better measurement. Scope and 100 MHz clock to Sayma are phase locked. Still using 4.0.dev+1133.g0b086225 . ... https://github.com/m-labs/artiq/issues/794#issuecomment-396091242