<sb0>
_florent_, well the error message says it cannot drive BUFR. why did your code work at all? did you actually test it with a BUFR, in which case the error message is incorrect?
<sb0>
oh you are chaining BUFG and BUFR ...
<sb0>
it seems vivado removes the intermediate BUFG
<sb0>
what is this clock division for anyway?
<sb0>
I don't think we should support RTIO clock frequencies that are not the frequency of TXOUTCLK
<GitHub90>
[artiq] sbourdeauducq commented on issue #854: That's not the problem, and if it were, debugging it would be easier by looking at elastic buffer underflows and overflows than by probing signals on the board. https://github.com/m-labs/artiq/issues/854#issuecomment-359643927
<GitHub102>
artiq/master 25fee1a Sebastien Bourdeauducq: gtp_7series: use QPLL second channel
<sb0>
rohitksingh-demo, are you going to complete the mor1kx work or should I reassign it?
<rohitksingh-demo>
sb0: I'm of the opinion is that if you already have someone to work on mor1kx, I would be glad if you reassign it. No point in stalling/delaying it when I can't get much time to work on that
<rohitksingh-demo>
sb0: I would be happy to help anyone get started with it.
<GitHub15>
[artiq] sbourdeauducq commented on issue #904: I see. Well, Sayma is a development system at the moment and building from source is the primary way, so for now the priority is to get source builds working correctly (not conda). https://github.com/m-labs/artiq/issues/904#issuecomment-359671262
<GitHub136>
[artiq] sbourdeauducq commented on issue #903: Yes, it's due to switching to new-style conda noarch package that happened in 2.4, since after an update of conda the old-style noarch packages began to have various bugs and problems. Maintaining conda takes constant work... https://github.com/m-labs/artiq/issues/903#issuecomment-359705735
<GitHub174>
[artiq] sbourdeauducq commented on issue #903: Yes, it's due to the switching to new-style conda noarch package that happened in 2.4, since after an update of conda the old-style noarch packages began to have various bugs and problems. Maintaining conda takes constant work... https://github.com/m-labs/artiq/issues/903#issuecomment-359705735
<GitHub82>
[smoltcp] canndrew commented on issue #129: For example, there could be a `Nat<D>` type which wraps a `Device` and implements `Device`. Any IP packets sent from the underlying device get their source endpoint mapped to some global endpoint before being sent from the `Nat`. And vice-versa for incoming packets sent to the `Nat`.... https://github.com/m-labs/smoltcp/issues/129#issuecomment-359752715
<sb0>
_florent_, for JESD SC1 sysref clock phase determination so it meets s/h. what about doing a scan at every firmware startup and printing the results?
<sb0>
this will also allow spotting potential differences between boards easily and help with debugging
rohitksingh-demo has quit [Ping timeout: 240 seconds]
rohitksingh-demo has joined #m-labs
rohitksingh-demo has quit [Client Quit]
<rjo>
sb0: greg's comment with his screenshots doesn't seem to be addressing the 1.8v issue.
<rjo>
sb0: weird that _florent_'s board is also acting up now. just because we are running heavy bitstreams now on all boards?
<sb0>
rjo, maybe that, or maybe because it's been running for days
<rjo>
sb0: or something peculiar with both of your power supplies...
<sb0>
there could be some degradation over time. before I added the capacitor sayma1 was failing in 20-30s
<rjo>
ack.
<rjo>
sb0: _florent_ and you are both working on sc1 right now? i'll land another cleanup of some vivado timing constraint generation hopefully today and then i'll fix the spi bug, and then work on the pending sayma feature issues.
<sb0>
rjo, mostly _florent_
sb0 has quit [Quit: Leaving]
<GitHub151>
[smoltcp] batonius commented on issue #129: I would like to see routing in `smoltcp`, but I think it should be implemented on top of (or as a part of) a more general support for multiple interfaces, something we lack right now, otherwise, it makes little sense. There were some (quite vague) ideas discussed in #55, which overlap with your proposal to a significant extent, but I haven't come up with a specific design
<rjo>
sb0, _florent_: https://hastebin.com/efeqiyuhaq.pl you had this (and everything else between the sys and serdes CDs as a false path. but i can't see any CDC mechanism in there.
hartytp has joined #m-labs
<hartytp>
rjo: FWIW, I would have preferred a higher speed grade on Kasli
<hartytp>
my thinking is that it doesn't inflate the overall cost of Kasli noticeable amount and it could be helpful in the future
<hartytp>
I didn't really voice this at the time because there had already been so many arguments over the design and I figured you'd veto it anyway
<hartytp>
also, you were happy with the speed grade, and you're in a better position to judge what's actually needed than I am
<hartytp>
but, if you're open to it, I'd definitely prefer to move to something faster
<rjo>
hartytp: yes i haven't heard a reason why the current speed grade is not good enough. just "doesn't inflate cost noticably" and "could be helpful" is not sufficient. we need to do better than that. it should be clear that the sum of all things that "could be helpful" and "don't inflate the cost significantly" diverges.
<rjo>
hartytp: so yes, once we have a valid technical reason to select a different speed grade, we should definitely do it.
<hartytp>
rjo: ack. that's why I didn't raise it before.
<hartytp>
out of curiosity though, what about the issues you had getting the OR1k to meet timing on Kasli?
<rjo>
hartytp: ;) the dilemma is that each of these decisions needs a lot of thinking and testing and planning.
<rjo>
it still doesn't meet timing.
<hartytp>
that's a problem, right?
<hartytp>
wouldn't that be easier with the faster speed grade
<hartytp>
?
<hartytp>
that would be an argument for it, wouldn't it?
<rjo>
yes. once there is more logic than bare misoc it stops meeting timing. it's around the dcache which leads me to speculate that it has to do with the size of the bus.
<rjo>
i can try with a different speed grade but my guess is that it won't help and that the problem is systematic.
<hartytp>
rjo: if it's quick to do then I'd be really interested to hear if a different speed grade helps.
<rjo>
20 levels of logic just won't fly
<hartytp>
sure
<hartytp>
so, what's the situation then (I've lost track). AFAICT, you have ARTIQ on Kasli, right? So, have you just reduced the clock speed to something like 80MHz
<hartytp>
and, what is your plan for the near term? Just run at the lower speed, or try to optimise the cpu?
<hartytp>
(to get it running at 125MHz)
<hartytp>
One thing that really concerns me here is that it's crucial for us to have Sayma in our system, so it has to work with Kasli
<hartytp>
so, I want to make sure that there aren't any timing issues with getting Kasli running at 150MHz RTIO_Coarse (otherwise, will have to alter Sayma to 125MHz)
<rjo>
i am ignoring the timing failure. 125 MHz. the plan is to tweak it/find the low-hanging fruit until it works.
<rjo>
that frequency doesn't have anything to do with the rtio frequency.
<rjo>
both cpus are 125 MHz on all boards so far.
<hartytp>
okay, so tweak the OR1k design to get it to meet timing?
<rjo>
and/or the bus
sb0 has joined #m-labs
<hartytp>
rjo: sure, I get that the cpu and rtio frequencies are independent. that was a separate point.
<hartytp>
rjo: okay. ack. is that WPI atm?
<rjo>
WPI?
<hartytp>
s/WPI/WIP
<sb0>
it meets timing sometimes, but it's very fragile
<hartytp>
okay
<sb0>
have you tried increasing the dcache size?
<sb0>
hartytp, btw the rtio core also has problems (sometimes) at 150MHz
<rjo>
sb0: no. i tried decreasing. but timing closure is a bit lower on my priority list right now.
<hartytp>
on Sayma or on Kasli?
<sb0>
hartytp, so, sometimes we can do this Sayma-compatible 3Gbps DRTIO that you want, sometimes we cannot, depending on vivado's mood
<sb0>
on kasli
<sb0>
sayma doesn't have many timing problems
<rjo>
sb0: if you can find time, that would be great. i would have to understand how the dcache works first.
<sb0>
hartytp, btw the kasli drtio code for master and satellite is there, but barely tested
<hartytp>
sb0: well, that's a potentially real problem for us. Kasli is just no good to us if it can't work with Sayma. So, either Kasli needs to go to 150MHz or Sayma to 125MHz
<hartytp>
again, if the higher speed grade makes that easier to do on Kasli then it's a big deal for us
<rjo>
hartytp: it would be good if you could invest time into writing a 125 MHz sayma target
<hartytp>
sb0: great! I was hoping to have a look at that next week
<hartytp>
rj0: it's on my list of things to look at
<hartytp>
but, right now there are enough other issues with Sayma that I fear that kind of investigation could turn into a huge time sink. I was hoping to get the current sayma working a bit more reliably first!
<hartytp>
sb0: if you rebuild for the higher speed grade, what happens?
<sb0>
usually the negative slack is less, more like -0.3ns. and sometimes it passes.
<sb0>
haven't tried yet. my guess is it would work.
<sb0>
the failure is in the part of the rtio core that compares timestamps and outputs events when their time comes
<hartytp>
rjo: well, we still have time to change this for Kasli v1.1, so I'd urge you to at least consider it.
<sb0>
smaller timestamps would potentially help (we're at 64-bit now)
<hartytp>
Hardware is generally **much** cheaper than software development
<rjo>
hartytp: maybe. but you need to be reasonably sure that (a) there is not a software issue as well (b) the hardware solution will work in the future as well (remember that software solutions are much more flexible and can be applied later).
<sb0>
on the DRTIO satellite, the 150MHz timing has passed last time I compiled it so I don't have a failure report to show you atm
<hartytp>
rjo: true, but at least there is no risk that the higher speed grade could break things afaict. Worse case it's just a bit of money wasted
<hartytp>
and we can always revert to a slower one with a BOM change later on if we really want
<sb0>
higher speed grade is pretty risk-free, it's just xilinx speed-binning silicon
<sb0>
they may even sell the higher speed grade as a lower speed grade if that's part of their business strategy
<hartytp>
fwiw avnet shows the XC7A100T-3FGG484E as $190, with the -2 as being about $150 so we're taking about something like $40 on a $1000 board
<hartytp>
so, quite a small increase in cost overall.
<rjo>
hartytp: and from what i can see so far, a higher speed grade on kasli is just a waste of money and time. timing fails the same way on a -3 speed grade.
<hartytp>
if that's the case then it's a moot point
<hartytp>
okay
<sb0>
I wonder if that timestamp comparison could be pipelined somehow
<sb0>
especially as we're comparing with a free-running counter
<rjo>
sb0: yes. and we can easily shave of ~4 bits dynamic range.
<hartytp>
anyway: tl;dr just want to reiterate how important it is to us (and others that I've talked to) that Kasli-Sayma works!
<rjo>
hartytp: who else is commited to using Kasli-Sayma?
<sb0>
mm, basic pipelining would limit the max rtio event rate
<sb0>
and it would fail in nasty ways
<sb0>
(when the rate is over spec)
hartytp has quit [Ping timeout: 260 seconds]
<sb0>
oh, maybe just adding a buffer (on FDs) at the output of the FIFO would do it.
<sb0>
a good portion of the delay is block RAM and FIFO counter
<rjo>
sb0: did you test that si5324 commit on kasli?
<sb0>
we don't need to define clocks for false paths anymore << xilinx fixed it?
hartytp has joined #m-labs
<sb0>
oh, there is a different command in migen. ok
<hartytp>
rj0: you should check this with them, but my understanding is that both NIST and Joe/ARL/UMD anticipate combining Sayma and Kasli/Urukul/etc in the same experiment
<hartytp>
(AFAICT, a lot of people silently expects this to work and will be surprised to hear that there is a potential issue)
<GitHub2>
artiq/master aada38f Robert Jordens: kasli, kc705: remove vivado "keep", cleanup a constraint
<GitHub2>
artiq/master 85102e1 Robert Jordens: sayma_rtm: derive clocks automatically...
<GitHub2>
artiq/master 7d1b3f3 Robert Jordens: sayma_rtm: set CFGBVS/CONFIG_VOLTAGE, compress
<rjo>
hartytp: we have tried but i have a hard time getting some of them to keep us involved. it works well with a couple of groups. it might be best if the necessary attitude change originates with successful users, like you.
<hartytp>
ack
<hartytp>
anyway, I still think it's pretty reasonable (and highly desirable) if all Sinara hardware can be used in the same experiment
<hartytp>
that's one of the biggest plusses of this whole thing for us
<hartytp>
and it seems totally doable, even if it needs some extra work/funding to get there
<rjo>
yes. exactly. but there are several operational etc conditions attached to that.
<hartytp>
right
<rjo>
bb-m-labs: force build --props=package=artiq-sayma_amc-standalone artiq-board
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<rjo>
bb-m-labs: force build --props=package=artiq-kasli-opticlock artiq-board
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<cjbe__>
rjo: FYI we have our Kasli talking on the network using the same model of GBIC as you
<cjbe__>
rjo: however it only worked on a DLink DGS-108 - with a Netgear JGS516 (the model I sent to HK) I do not get a 'link up' indicator at either end
<sb0>
hartytp, yep, don't install the jesd core from conda
<sb0>
take the git
<hartytp>
already done that and building. Just thought it worth mentioning that conda is broken atm
<sb0>
I know about it, will fix it after sc1 is done and tested
<sb0>
cjbe__, i'll have a look if i have time (getting a kasli soon)
<sb0>
if it's not the Xilinx GTP acting up, it's quite easy to debug with microscope and a minimal design (compiles reasonably fast)
<cjbe__>
sb0: great - no hurry from our end. I am very happy it worked out of the box!
<cjbe__>
sb0: you mentioned earlier on that Kasli DRTIO master / slave is getting there (but not tested yet) - I have a pair of Kasli, is it worth me having a try now?
<sb0>
cjbe__, maybe. it's rather quick to test...
<sb0>
Florent tested that the transceiver (only) gets a link, using another board
<sb0>
things that can cause trouble are: glue code with drtio (the latter is tested in simulation, kc705, and sayma), si5324 programming, and timing failure
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
mumptai has joined #m-labs
<GitHub82>
[artiq] dhslichter commented on issue #888: > Which exactly is that FIFO you need expanding? Since you are the main users of those packages, we can also build them with the FIFO sizes you want.... https://github.com/m-labs/artiq/issues/888#issuecomment-359885374