<GitHub-m-labs>
artiq/master b82158a Florent Kermarrec: firmware/ad9154: add stpl test
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #1022: @jbqubit: as discussed on IRC, i did some changes on the reset of the elastic buffers + implemented the stpl test. Can you test again? (i'm not able to visualize outputs). https://github.com/m-labs/artiq/issues/1022#issuecomment-394540247
<bb-m-labs>
build #2420 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2420 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
sb0 has joined #m-labs
cr1901_modern1 has joined #m-labs
kaolpr has quit [Ping timeout: 265 seconds]
kaolpr has joined #m-labs
cr1901_modern has quit [Ping timeout: 256 seconds]
<sb0>
"if the two sides of the EB always have the same phase" << not really, if you replace the EB with a register then you have to make sure that s/h are met
<sb0>
in general it'll work, since the jitter widow is small, but it's not a 100% reliable solution that works in all cases
<sb0>
*window
dlrobertson has quit [Quit: WeeChat 2.1]
rohitksingh_work has joined #m-labs
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1022: @enjoy-digital when I look at the bigger picture of the JESD system, I don't see how your fix can help. You have the GTH input clock which gets multiplied to many-GHz by the GTH PLL(s), and then a number of unsynchronized dividers generate the clocks for each lane. So, lane clocks, which are also the read clocks for the elastic buffer, can have any phase with resp
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1022: I just tested the latest code on hardware, and expectedly (from my understanding, the JESD behavior has not changed at all): this and the #1040 bug are still there. https://github.com/m-labs/artiq/issues/1022#issuecomment-394575337
<GitHub54>
[smoltcp] pothos commented on issue #224: @barskern Yes, that's one point, but also the retransmit should only be scheduled if there is data to be sent out. In the tcpdump in the end the packets of both sides just have length 0. https://github.com/m-labs/smoltcp/issues/224#issuecomment-394577867
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1022: @enjoy-digital when I look at the bigger picture of the JESD system, I don't see how your fix can help. You have the GTH input clock which gets multiplied to many-GHz by the GTH PLL(s), and then a number of unsynchronized dividers generate the clocks for each lane. So, lane clocks, which are also the read clocks for the elastic buffers, can have any phase with res
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
<larsc>
_florent_: there is another ambiguity. jref and jsync, these are generated in the common clock domain, but are sampled in each of the PHY domains, this could also result in a offset of 1 clock cycle
<larsc>
if you send jref and jsync through the EB thogether with the data the problem should go away
<larsc>
basically what you need to make sure of is that the datastream and the synchronization signals that control the link state machine have a deterministic relationship
<sb0>
larsc, may be simpler to put the EB on the raw transceiver data?
<_florent_>
hartytp: ack for the errors, then it's probably better you continue investigating the others points with low speed version.
<hartytp>
what other points?
<hartytp>
the new init sequence seems to have fixed all the crashes (although, with serwb failing to init most of the time, it's hard to get good statistics)
rohitksingh has joined #m-labs
<hartytp>
I'll check the HMC7043 outputs, but other than that, it's just the ser-wb and JESD issues
<_florent_>
i'm working rignt now on the JESD issues
<hartytp>
can you check the diff I posted and make sure I've applied your patch correctly, please
<hartytp>
cool
<hartytp>
okay, I'm happy if you would prefer to do that first
<hartytp>
larsc: have you used the HMC704x RFSYNCIN?
<_florent_>
hartytp: for the errors you see on ser-wb, i think it's a corner case in the scrambling. If we want to be sure, i can prepare a patch for you to user ser-wb at 1gbps without scrambling
<hartytp>
larsc: thanks. I can't see s/h requirements for the rfsyncin
<hartytp>
anyway, here was my though: in future we will probably implement wr, so our FPGA clock will be phase locked to the 1.2GHz clock we feed into the HMC7043
<hartytp>
to get deterministic latency on the HMC7043 outputs w.r.t. the FPGA clock, it should be enough to feed the ~100MHz into the RFSYNCIN input of the 7043 and set the registers easily
<hartytp>
that then gives us synchronization between multiple converter cards more or less for free
<GitHub-m-labs>
[artiq] jordens commented on issue #1048: Are you sure? Do you mean both profile settings and rf switch of `suservo0_ch0` end up on `urukul1, ch3`? I just checked again with the code in master (gateware and example) and it's fine there. https://github.com/m-labs/artiq/issues/1048#issuecomment-394628966
<hartytp>
I was wondering if it might be possible to feed the HMC7043 from an FPGA output, using a PLL inside the FPGA to provide a phase shift
<hartytp>
or is the jitter too high?
<hartytp>
feed the HMC7043 RFSYNCIN from the FPGA that is
<hartytp>
(for a clock up to 2.4GHz(
<hartytp>
)
<larsc>
I wouldn't recommend that without a jitter cleaner
<hartytp>
so, the other option is to feed the HMC7043 RFSYNCIN from the 100MHz reference via a phase shifter. AFAICT, that should work fine, right?
<sb0>
yes, having this sort of synch between cards would be really nice
<GitHub-m-labs>
[artiq] jordens commented on issue #1048: Are you sure? Do you mean both profile settings and rf switch of `suservo0_ch0` end up acting on `urukul1, ch3`? I just checked again with the code in master (gateware and example) and it's fine there. https://github.com/m-labs/artiq/issues/1048#issuecomment-394628966
<sb0>
the current system was thought of assuming that we won't get good phase noise with a recovered clock
<sb0>
but it is complicated (the bad kind of complicated, i.e. likely prone to obscure bugs and bumping into frustrating fpga and clock chip misfeatures) and not user-friendly as they need to supply an external clock with a carefully tuned phase
<hartytp>
sb0: right
<hartytp>
Wieda is making good progress on his all digital KC705 WR demo with the nice Ti DCXO
<hartytp>
Weida
<sb0>
what kind of phase noise performance would we get if we send the si5324 output into the hmc830?
<hartytp>
I posted that on git hub a while back
<hartytp>
not too bad
<hartytp>
ideally though we'd scrap the si5324
<hartytp>
for the next hw revision, i'd ideally like to have both the si5324 and the DCXO and use solder jumpers or something to select
<sb0>
we can put the 5324 in bypass mode if that improves phase noise
<sb0>
then the 830 would have to clean the CDR noise
<sb0>
no. to try to avoid spending time on debugging the initial idea, especially if we're going to scrap it on v2
<hartytp>
can we just agree not to try to get sc1 working between cards on v1.0?
<sb0>
that depends when the v2 boards get made
<hartytp>
ack
<hartytp>
so, the other option is to replace the XTal on sayma with the DCO
<sb0>
if we're at a point when rework wires keep breaking and wasting people's time, that's another reason to push forward v2
<hartytp>
I've done that on Kasli, easy to do dead bug it upside down and solder short air wires
<hartytp>
we could then use the Si5324 as a buffer (enable the PLL with fin=fout)
<hartytp>
it slightly degrades the noise, but not a real problem
<hartytp>
we'd need to hook the lmk61e07 I2C bus to something, but that shouldn't be too hard to bodge somewhere
<sb0>
which xtal, the si5324 one?
<hartytp>
right
<hartytp>
I outlined this before as a half-way house
<hartytp>
we replace the SI5324 XTal with a DCXO
<sb0>
I see
<sb0>
that's quite a hack
<hartytp>
yes
<hartytp>
but, that's what prototyping is
<hartytp>
as I see it, if the noise for WR turns out okay (I hope to have a demo up and running within a week)
<hartytp>
then it's a *much* nicer and easier solution
<sb0>
for i2c there is the 2.54mm gpio header we're using already for ethernet rework
<hartytp>
than the tricks we've talked about before
<hartytp>
ack
<sb0>
so yes, that's easy
<hartytp>
right
<rjo>
you need to break it to the duke/umd folks asap if 2 saymas v1.0 can't/won't be phase-deterministic and convince them.
<hartytp>
just needs Weida's KC705 code to be ported
<hartytp>
yes
<hartytp>
but: (1) do they really need phase determinism between the two cards, or is 8 channels enought?
<sb0>
they need 16
<hartytp>
(2) to enable it would just be a small rework, much easier than the stuff we've already had to do
<hartytp>
but, yes, Joe would need to sign off on it
<sb0>
though, it's not clear where their second sayma would come from
<hartytp>
anyway, going back a sec
<hartytp>
my comment is that atm the RFSYNC is connected to the LLRFBP
<sb0>
Joe or Ken or Kim
<hartytp>
(IIRC it was a bit of a "we probably won't use this signal, but let's connect it to the LLRFBP anyway")
<hartytp>
it might make more sense to add a connection between that and the HMC7043 reference input via a phase shifter IC
<hartytp>
hmm, duke/umd want to use Sayma at about 200MHz=5ns period=14ps/deg
<hartytp>
cjbe measured that with si-phaser, the Si5324 phase is actually good to about 10ps (better than the 90ps that sb0 quoted)
<sb0>
hartytp, so your hack is LMK61E07 into the si5324 crystal, generating 150MHz, and wr-style softpll reprogramming the LMK over I2C?
<hartytp>
basically yes
<hartytp>
not softpll
<hartytp>
fixed point loop filter
<hartytp>
but yes
<sb0>
hartytp, yes, 90ps sounded a bit high to me, but that's what cjbe initially measured, no?
<hartytp>
^ cjbe
<hartytp>
sb0: precisely it would be
<sb0>
cjbe_, ^
<hartytp>
LMK61E07 as XO reference for Si5324
<hartytp>
Si5324 operating as a PLL with fin=fout
<hartytp>
(we have characterised that and it's fine)
<hartytp>
DDMTD as a PFD and then a fixed-point loop filter to phase lock the Si5324 output to the GTX reference
<sb0>
what does your implementation look like? do you have a repository with the code already?
<hartytp>
however, we'd then need to connect the SI5324 output to the HMC7043 RFSYNCIN
<hartytp>
which is on the ERNI RFBP con
<hartytp>
working on it
<hartytp>
atm it's not something you'd want to look at (Wieda is doing LF in FP maths using Xilinx cores)
<sb0>
how fast does your loop filter need to run?
<hartytp>
DCXO max update rate is 8kHz IIRC
<sb0>
ah, yes that's what I was fearing
kaolpr has quit [Remote host closed the connection]
<hartytp>
it's a mess atm, but the code is pretty trivial, so the idea would be to get Weida to write something more civilised once he's proved the concept
<hartytp>
anyway, for sayma v1.0, I don't think we need to do that
<sb0>
I wonder if it sounds reasonable to run that in a ISR inside the satman firmware
<sb0>
(timer ISR)
<hartytp>
I'd argue that if the Si5324 is more like 10ps then it's good enough for v1.0 applications, which will be limited to a couple of hundred MHz
<hartytp>
and 1-2deg phase uncertainty is fine for the time being IMHO (I don't think their gates are 4 nines yet )
<sb0>
just connect the 5324 to the 830?
<hartytp>
rigth
<hartytp>
which is just a mux setting once you've hooked DRTIO
<hartytp>
*but* we need to route a Si5324 output to the HMC7043 RFSYNCIN
<hartytp>
(I'm assuming that the SI5324 outputs have deterministic latency w.r.t each other. is that correct?)
<sb0>
ah, the sayma feature explosion is useful this time.
<sb0>
yes, they do
<hartytp>
what is CDR_CLK2_CLEAN used for?
<sb0>
hartytp, I don't think it can be 10ps, the MMCM steps in siphaser are ~15ps (1/56 the MMCM VCO period)
<sb0>
let me check how fast we can crank up that VCO
<hartytp>
FWIW, that's not a feature explosion, but careful planning -- I pushed for this from ages back, Weida and I did simulations of expected noise performance before Sayma v1.0 went to manufacture
rohitksingh has joined #m-labs
<hartytp>
so, AFAICT, the only rework that needs to be done is to hook CDR_CLK2_CLEAN up to the HMC7043 RFSYNCIn
<hartytp>
then, it's just a matter of finding the right phase for that and we're good
<sb0>
it's already at the max... the Ultrascale VCO isn't faster than the Artix-7 VCO
<sb0>
so it won't get better than 15ps
<hartytp>
if steps are in 15ps then we would expect about 10ps, right? Should be able to set it to about 1/2 steps
<sb0>
set it to 1/2 steps?
<hartytp>
well, the worse-case is where the ideal phase lies half way between two values
<hartytp>
to the error is 1/2*step size
<hartytp>
isn't it?
<hartytp>
anyway, 15ps should still be fine, it's 1deg at 200MHz
<sb0>
in that case, the algorithm will sometimes give you one step and sometimes the other, i.e. you get 15ps of random error
<hartytp>
That's plenty for everything anyone will do with Sayma v1.0
<hartytp>
well, the variation is +-7.5ps
<hartytp>
not +-15ps
<hartytp>
I assume cjbe's 10ps was rms not pk-pk
<sb0>
an ODELAY tap can also be up to 15ps, so that won't help either
<hartytp>
but, anyway, I think we're on the same page, and I still think it's not a problem
<sb0>
or at least not much
<sb0>
ok
<sb0>
hartytp, the siphaser calibration is one-time at link init, so rms == pk-pk
<sb0>
tpw_rules, I've been thinking, maybe that other tool could be installed alongside migen and could be able to take the original migen/misoc cores, so we can keep the legacy code
<sb0>
i.e. invoke migen for converting migen modules to verilog
<tpw_rules>
yeah i don't want to obsolete everything, just add a few (on the surface) simple tools to make certain things easier
<sb0>
ok
<sb0>
well that's a defensible approach too
<sb0>
tpw_rules, re. this example, that's quite a bit of boilerplate
<sb0>
tpw_rules, another thing I've been thinking of, which is also a major change, is mixing comb and sync freely
<sb0>
just like we can do in FSMs right now with NextValue
<sb0>
I mean a generalization of this
<tpw_rules>
yeah, it's not perfect. you could even shorten it to @pyfunc(self.sync) and get rid of a line and a tab
<tpw_rules>
yeah this already supports that. signal.next is a sync assignment and signal.val is a combinatorial assignment.
<tpw_rules>
well right now it throws an exception if you try to mix them, but that's cause i wanted to preserve current behavior
<sb0>
tpw_rules, and you can mix them in If()?
<sb0>
ah, ok
<sb0>
it's a lot more useful if they can be mixed
<tpw_rules>
i had thought of ways to do that, basically bisecting the If and constructing one with all sync and one with all comb
<sb0>
this is why I introduced NextValue in FSMs, because it's particularly useful there, but it's just an ad-hoc solution
<tpw_rules>
but it seemed kind of antithetical to the design goals in the first place, with the completely independent .sync and .comb
<sb0>
if we have a more general solution, it's useful elsewhere + NextValue can go
<sb0>
tpw_rules, this design goal, in hindsight, wasn't the best
<tpw_rules>
you can mix them in an fsm context
<sb0>
"signal.next = x" and "signal.val = x" is superior
<sb0>
maybe another context manager can be used to select the clock domain for .next
<sb0>
and mixing clock domains isn't allowed, which sounds like a reasonable thing to do
<tpw_rules>
but for background i learned of all of this by looking into whitequark's glasgow thing. they wanted to do all the custom analyzer modules in migen, but mine is 99% literal verilog and fitting that into migen's world now is ugly so i worked on some tools to make it make more sense for that case. i never intended to change any behavior of existing code
<tpw_rules>
that's why i liked the AST solution. just add a decorator and then it's plain python syntax. mixing the two isn't hard, for example in the bitonic sorter. i don't want the AST to become like myhdl, where it's trying to translate loops and other nonsense. the only transformation it really does is take an if: else: and turn it into If().Else(), then execute it to construct the If migen's way
<sb0>
tpw_rules, i.e. you don't want to undertake a larger project of doing a "migen v2" that involves breaking certain principles?
<tpw_rules>
you could say that, but only because i just learned of migen 2 weeks ago. it seemed rather rude to walk in and uproot everything
<sb0>
tpw_rules, imo the "migen v2" will happen at some point. and if we have a half-baked solution in migen v1 with ast conversions, then we end up having 3 different languages to do the same thing, which is a bit messy imo
<tpw_rules>
if you're interested in that project, we could look into it
<tpw_rules>
you'll note i haven't bothered to make any docs cause this is just experiments to see what i like
<hartytp>
sb0: nb Si5324 phase shift is 200ps resolution
<sb0>
hartytp, between outputs?
<hartytp>
yes
<sb0>
that depends on the frequency of the internal PLL
<hartytp>
right
<hartytp>
so for a 1.2GHz clock (800ps period) that should be plenty to align the RFSYNCIn
<sb0>
tpw_rules, I've been thinking about it for about a year, but had no time to implement it, sayma bugs not helping
<hartytp>
for a 2.4GHz DAC clock it sounds a bit marginal
<cjbe_>
sb0, hartytp: With the Kasli master-slave over 10 restarts the pk-pk clock deviation is 95ps, c.f. ~60ps pk-pk over time without restarting the si
<sb0>
hm, where is this 60ps deviation coming from?
<sb0>
cjbe_, have you looked at all at sayma drtio?
<hartytp>
cjbe_: thanks
<hartytp>
nope
<hartytp>
!
<hartytp>
sb0: could be the cheap reference crystal
<hartytp>
the lock is low BW and not great at taking out thermal drifts in the crystal freq
<sb0>
sayma drtio worked rather well ime, maybe because the rtm isn't involved so far
<sb0>
hartytp, right
<tpw_rules>
sb0: whitequark mentioned myhdl, but strongly implied migen's goal wasn't in that direction. i don't quite like myhdl either, it's pretty thin on top of verilog
<sb0>
tpw_rules, yep.
<hartytp>
sb0: so if sounds like something like a couple of deg RMS phase fluctuations with time/over restarts
<sb0>
I started using myhdl, then started migen when saw myhdl wouldn't do what I wanted (and any discussion in that direction was shut down)
<hartytp>
(100ps pk-pk is probably something like 15ps rms)
<tpw_rules>
and that's why the ast portion isn't designed like myhdl. it doesn't construct verilog, it constructs plain old migen objects. it does do the same context manager futzing that context managers do, but nothing deeper.
<cjbe_>
sb0, I did not investigate the noise of the si5324 much. I previously observed that "over ~40 hours the Si5324 master-satellite clock phase has a pk-pk of 55ps (stddev 6ps) - this is pretty much at noise floor of how I am measuring it"
<sb0>
cjbe_, ok thanks
<hartytp>
cool, well that sounds good enough for a v1.0 proof of concept
<hartytp>
for WR, we should be able to improve the phase stability by using a high quality XO and implementing a third order LF
<sb0>
tpw_rules, alright. but I still feel like this AST converter feels a bit tacked-on, and not as general as the context managers + global state
<sb0>
tpw_rules, you'd need to learn the other way of using migen, when you hit limitations of the AST converter. not nice.
<tpw_rules>
see i see it as the reverse
<tpw_rules>
the limitations of the ast converter are very high, and it's useful in basically one case. if you're just using the ast converter, no point in using migen.
<sb0>
tpw_rules, and I have no bad feelings about you forking migen and experimenting with the language design.
<rjo>
hartytp: btw: have greg add you to the "dev" team on sinara-hw
<tpw_rules>
why don't i make some improvements based on your feedback, write some docs of how actually it all works, and maybe that will help with the parts you like and want to improve with the fabled v2?
<tpw_rules>
it all works == how a migen user would use it
<GitHub-m-labs>
[artiq] hartytp opened pull request #1049: Sayma RTM: hold hmc7043 in reset/mute state during init. (master...hmc7043_rst) https://github.com/m-labs/artiq/pull/1049
<sb0>
tpw_rules, ok
<sb0>
tpw_rules, don't forget the module management, which might also be good to fit into the global state/stack paradigm
<tpw_rules>
cool. i'll leave you all with real quantum mechanics then
<tpw_rules>
i never really investigated that, what do you mean
<sb0>
tpw_rules, you need a stack-ish global state to implement "with If" etc.
<tpw_rules>
constructing a class and doing .submodules += seems reasonable enough to me
<tpw_rules>
yeah
<sb0>
the "current module" could be also pushed into that stack
<sb0>
that would avoid a common error with migen which consists in forgetting to add a submodule to self.submodules
<tpw_rules>
oh. so instantiating a Module would be able to see the current one in the stack and automatically add it
<tpw_rules>
makes sense
<sb0>
tpw_rules, you might also want to look into outputting several verilog files (one per module). but that's pretty tricky.
<tpw_rules>
i mean my original goal was to have all the phancy stuff boil down to regular old migen objects and interactions between them
<sb0>
tpw_rules, yes, if you don't do the multiple-file thing maybe you can still produce a _Fragment object
<sb0>
tpw_rules, I'd ditch the existing migen Module thing though
<GitHub-m-labs>
[artiq] hartytp commented on issue #794: One more time with brain attached. Now looking at the two 150MHz outputs from the HMC7043. I can confirm that the relative phases of these outputs is not stable across FPGA loads with the current ARTIQ master.... https://github.com/m-labs/artiq/issues/794#issuecomment-394655771
<sb0>
tpw_rules, also, if we do the stack with modules, maybe the migen name algorithm, which is another common source of complaint, can be replaced
<tpw_rules>
heh i'm not yet familiar enough with migen to understand those things. but i'll look
<_florent_>
hartytp: have you been able to test ser-wb without the scrambling?
<sb0>
tpw_rules, initially there was just Fragment, then Module was tacked on. there are simpler ways of doing it.
<tpw_rules>
what's wrong with Module? it would become kind of redundant if all of its attributes are replaced by context managers, but inheriting from it still seems useful
<_florent_>
hartytp: ok, and so it was also failing when reloading both AMC and RTM?
<sb0>
tpw_rules, oh, also, Module should probably split the logic-building part from __init__ into a separate function
<_florent_>
hartytp: sorry, just to be sure, you also reloaded the rtm?
<sb0>
__init__ creates just the interface, then another method builds the logic (if it needs to be built)
<tpw_rules>
huh, it explicitly says it doesn't have an __init__?
<tpw_rules>
it looks like it's already that way?
<sb0>
tpw_rules, I mean, when you use Module you put both the interface and the logic in __init__ right now
<tpw_rules>
oh ok
<sb0>
it makes a long method, and it also slows down things when you just want to extract information about the design and not convert it to verilog
<tpw_rules>
yeah i wished for a separation from that
<hartytp>
yes, I ran artiq_flash
<sb0>
tpw_rules, there are many breaking changes like that, which is why I think it is better to just introduce a new language
<tpw_rules>
what about connecting modules together? right now the only way is to do a comb assignment. but i think it would be nice to either make it constructor arguments or allow setattr to add that assignment
<sb0>
tpw_rules, but keep backward compat for legacy cores, of which there are many, by supporting the simultaneous installation of both migen versions
<_florent_>
ok, then let's use low speed version for now, i'm looking at jesd
<tpw_rules>
but then you can't connect an old module to a new one?
<sb0>
tpw_rules, and the new one can handle modules written for the old one
<sb0>
tpw_rules, there needs to be support for that
<sb0>
I don't think it's particularly complicated
<sb0>
only the simulation is a bit tricky
<tpw_rules>
hm ok. i think we're not understanding each other then. my idea for the docs i said i would write was a few changes you could pull and then improve the existing thing. but you want to scrap that and design from the ground up, mostly?
<sb0>
tpw_rules, yes.
<sb0>
tpw_rules, though here's another idea
<tpw_rules>
like i'm still in the mindset of layer on top of current migen so all the new features reduce to that and everything interoperates
<sb0>
tpw_rules, maybe the FHDL backend can be kept, perhaps with non-breaking minor changes
<sb0>
then simulation isn't problematic
<tpw_rules>
but if you wanna do like ghdl too
<tpw_rules>
and have them be separate things
<sb0>
tpw_rules, yes, maybe FHDL/Fragment can be kept
<sb0>
perhaps with some cleanup, new features, and non-breaking changes
<tpw_rules>
i don't feel qualified or knowledgeable enough to redesign for 'g'hdl
<hartytp>
_florent_: ack
<sb0>
i.e. factor the namer out of FHDL, so the new migen can reimplement it
<tpw_rules>
but let me get my non-breaking new features in documentation and better examples and then we can discuss
<tpw_rules>
anyway i have to run. i'll be back later!
<sb0>
ttyl
<sb0>
tpw_rules, oh, also. zero-length signals.
<sb0>
i.e. Signal(0) or Signal(max=1)
<hartytp>
_florent_: one question about serwb
<hartytp>
we didn't enable the vtc right
<hartytp>
so could my issues be thermal?
<_florent_>
hartytp: i don't think so since this is happening right after the calibration
<hartytp>
ack
<hartytp>
anyway, I haven't looked at the code, but it seems interesting that with low line rate, I see no errors on the link test, but I get stuck in a loop where it fails to init repeatedly
<_florent_>
yes, it's probably related to a reset, but haven't found yet. I know that if you reload amc or rtm, it recovers
<GitHub-m-labs>
[artiq] sbourdeauducq commented on pull request #1049 33921ec: Why not use the GPIO out core instead of adding this to the CRG? CRG is normally used to clock the local design only. https://github.com/m-labs/artiq/pull/1049#discussion_r193032483
<GitHub-m-labs>
[artiq] sbourdeauducq commented on pull request #1049 33921ec: And there is no time for the HMC7043 to wreak havoc between the release of its reset line and the SPI write that mutes it? https://github.com/m-labs/artiq/pull/1049#discussion_r193033838
<GitHub-m-labs>
[artiq] sbourdeauducq closed pull request #1049: Sayma RTM: hold hmc7043 in reset/mute state during init. (master...hmc7043_rst) https://github.com/m-labs/artiq/pull/1049
<GitHub8>
[smoltcp] barskern commented on issue #224: @pothos yes that is correct. I will look into that. I think I have to move the detection of duplicate ACKs to a different branch of the bigger `match` within the `process` function. Currently it will only look at the ACK field and respond based on that. https://github.com/m-labs/smoltcp/issues/224#issuecomment-394673817
<hartytp>
sb0: thanks for fixing that PR. I haven't used misoc GPIO yet, and am a bit short of time right now to figure out how they work
<sb0>
hartytp, thanks for fixing the 7043!
<hartytp>
building with SAWG now to double check that the init still works with that
<hartytp>
np, hopefully with the JESD fix we will have sc1 now
<GitHub-m-labs>
misoc/master fb92c5e Sebastien Bourdeauducq: gpio: support setting reset values
<bb-m-labs>
build #2421 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2421 blamelist: Thomas Harty <thomas.harty@physics.ox.ac.uk>
<GitHub-m-labs>
artiq/master af88c4c Sebastien Bourdeauducq: clean up hmc7043 reset
<sb0>
there are still lots of serwb problems...
<sb0>
maybe serwb needs to be drastically simplified
<sb0>
just use a protocol similar to rs232, low bit rate and static timing, simplify higher level protocol and error handling, and add a CRC32 to avoid *any* data corruption
<sb0>
and there should be timeouts on both sides to avoid lockups
<sb0>
maybe timeout and crc failure should be the only possible errors.
<sb0>
sc1 is almost working, I have a 9MHz waveform and I either get 0.0035 radian or -3.0121 radian between the DACs
<sb0>
but serwb craps out 1/3 of the time
<sb0>
ah and 3.0189 sometimes
<sb0>
hartytp, how many times did you test the hmc7043 phase difference? can there be some intermittent bug there?
rohitksingh has joined #m-labs
<sb0>
well maybe the desynch is due to the JESD elastic buffer bug
<sb0>
might not be worth looking further until this is fixed
<sb0>
the magnitude of the desynch is ~53ns with roughly corresponds to some JESD204 timescales, off the top of my head
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #794: SC1 now seems to work intermittently. Maybe the desynch is simply due to the JESD204 elastic buffer bug. Here are the phase differences in a 9MHz waveform that I measured between the two DACs, reloading the bitstream every time:... https://github.com/m-labs/artiq/issues/794#issuecomment-394701523
<_florent_>
sb0: do you want to do a test with the jesd204b changes?
<sb0>
_florent_, thanks. recompiling...
<cjbe_>
sb0: no, I am not using those tmux sessions
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #794: SC1 now seems to work intermittently. Maybe the desynch is simply due to the JESD204 elastic buffer bug. Here are the phase differences in a 9MHz waveform that I measured between the two DACs, reloading the bitstream every time. Unit is radian.... https://github.com/m-labs/artiq/issues/794#issuecomment-394701523
<_florent_>
sb0: with the hmc7043 fixes, do you now have deterministic phase scan?
<sb0>
_florent_, no.
<sb0>
but this one isn't expected to be deterministic
<hartytp>
sb0: I've tried across a few power cycles and FPGA loads, but the two 150MHz HMC7043 outputs always have the same phase difference
<hartytp>
not affected by sawg/non sawg
<marmelada_>
has your patch has been merged yet?
rohitksingh has joined #m-labs
<hartytp>
before my latest patch, the phase was different every boot (large dividers so many possibilities)
<hartytp>
FWIW, I haven't seen a single error apart from serwb since the rework
marmelada has quit [Ping timeout: 260 seconds]
rohitksingh has quit [Read error: Connection reset by peer]
<marmelada_>
oh horay, this patch doesn't need amc gateware to be rebuilt!
rohitksingh has joined #m-labs
<hartytp>
:)
<hartytp>
sb0: well, the phases are synchronised to <1ns (my scope probe grounding is too poor to measure better than that atm) which wasn't true before the patch
<sb0>
hartytp, yes, but I wonder if they are synchronized to within <1ns all the time, or if typical treacherous sayma behavior is going on, e.g. it'll synchronize 9 times out of 10
rohitksingh has quit [Client Quit]
<sb0>
anyway let me see what happens after the jesd fix
<hartytp>
I've tried about 10
<hartytp>
worked every time
<hartytp>
this seems solid
<sb0>
ok
<hartytp>
but there are diagnostics on the HMC7043 we can read out if we still have issues once the jesd is fixed
<GitHub-m-labs>
[artiq] jordens commented on issue #1054: IMHO it would be better to seize the opportunity to change the API into a single method `enable(bitmask)` (`set(channel)`: `enable(1 << channel)` for backwards compat). That's less code for more feature and additionally represents the underlying protocol. https://github.com/m-labs/artiq/pull/1054#issuecomment-394742393
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1053: Yes, it is supposed to work like this. Experiments can use multiple files, and the client cannot know what to send. You can use a shared network folder to solve this problem. https://github.com/m-labs/artiq/issues/1053#issuecomment-394743183
<GitHub-m-labs>
[artiq] hartytp commented on issue #1040: Sawtooth looks good on my board with new JESD. I can post photos later if that helps, but accross a few loads, I haven't seen any glitches on the outputs. https://github.com/m-labs/artiq/issues/1040#issuecomment-394752092
<hartytp>
okay, that's it from me
<hartytp>
modulo the phases status bit (which I'll leave to you guys) and the serwb everything I've tested seems to work
<hartytp>
I'm not going to have time to look at sawg and, anyway, it's not really my area
marmelada has quit [Quit: Page closed]
mumptai has joined #m-labs
<larsc>
hartytp: "Setup and hold time is around 300ps.
<larsc>
i believe that is relative to the rising edge of the clk
<GitHub113>
[smoltcp] dlrobertson commented on issue #227: This is due to the current lack of MLDv2 support (currently working on it). The reason dd80b22 doesn't return `Unrecognized` is because we didn't continue processing a packet that had `Hop-by-Hop` options present. https://github.com/m-labs/smoltcp/issues/227#issuecomment-394801145
<GitHub198>
[smoltcp] podhrmic commented on issue #227: In that case, what do you think about replacing `iface.poll(&mut sockets, timestamp).expect("poll error");` in server with proper match statement, so the errors are printed/logged, but the server example keeps running? It just seems to be silly to not panic on `Unrecognized` but fail otherwise. https://github.com/m-labs/smoltcp/issues/227#issuecomment-394809440
<GitHub-m-labs>
[artiq] hartytp commented on issue #1040: @jbqubit @sbourdeauducq and anyone else who is working with Sayma v1.0: I strongly suggest that you reconnect the HMC7043 RESET line before doing any further debugging. We've seen that not holding the HMC7043 in RESET during init caused crashes on two separate boards (mine and @marmeladapk's). It's quite possible that other boards are affected in different ways, even if
<GitHub144>
[smoltcp] podhrmic opened pull request #228: Log and print poll errors instead of crashing the server (master...server_update) https://github.com/m-labs/smoltcp/pull/228
<GitHub9>
[smoltcp] m-labs-homu closed pull request #228: Log and print poll errors instead of crashing the server (master...server_update) https://github.com/m-labs/smoltcp/pull/228
<GitHub-m-labs>
[artiq] klickverbot commented on issue #1040: That is true, but for the current prototype phase, missing clock recovery is easier to tolerate than random crashes. A "proper" bodge might be preferable, as Greg points out, if we all agree on which pin to route the reset to avoid having to use different firmware builds. https://github.com/m-labs/artiq/issues/1040#issuecomment-394892054