<whitequark>
doesn't AsyncFIFO already implement the "style #2" from the paper?
<whitequark>
(side note: GrayCounter is weird, shouldn't it be GrayEncoder and GrayDecoder and shouldn't they be in coding ?)
<cr1901_modern>
IME, gray counters are generally considered a good CDC primitive when you can use them
<whitequark>
I am aware
<whitequark>
this is purely a code organization concern
<whitequark>
feels to me that GrayCounter just introduces more indirection where you probably want to instantiate a regular binary counter on a higher level in the design and encode that
<cr1901_modern>
I don't think it's weird to have them under CDC; I've never used them outside of that reason.
<sb0>
whitequark: asyncfifo is based on this paper, yes. i don't remember the details, I wrote this years ago
<sb0>
if style #2 matches the code, that's probably what it is
<whitequark>
yeah, I read it thoroughly and it matches style #2, which is probably good
<sb0>
i don't get what's happening with the gth ethernet code on sayma. it's happy to communicate with itself, but not with other devices
<sb0>
could be just some silly hardware issue though. i could try it on the kcu105 i guess...
<sb0>
oh and also send some test pattern and receive it on kasli
<sb0>
if the transceiver clock frequency is fucked for some reason, that would show it clearly when transmitting a square wave
<sb0>
could be simply that greg didn't populate a 200MHz oscillator contrary to what the schematics say
<sb0>
sayma is 99% debugging, as usual
<sb0>
whitequark: GrayCounter is basically a convenient way to have the current and next values both in binary and in gray
<sb0>
that was useful for some things but i'm not sure if that's the case anymore. check what is using it.
<whitequark>
only FIFO
<whitequark>
and I think it's actually more code
<whitequark>
or rather, DRTIO is using it, but not that feature. it just uses i and q.
<sb0>
artiq/gateware/drtio/link_layer.py uses it.
<whitequark>
yes. i just said that.
hartytp has joined #m-labs
<hartytp>
is np.ceil implemented in artiq python/is there a convenient equivalent?
<whitequark>
iirc it isn't
<_florent_>
sb0: i did a very quick test yesterday of your ku_1000basex phy on the kcu105, but it was also not working.
<_florent_>
sb0: happy to help a bit to debug that next week if it's still not working or do some tests
<_florent_>
sb0: but i was generating the 200MHz clock from a PLL and disabling DRC check REQP-1753 (it's working for testing on 7-Series, but haven't tested that before on Ultrascale)
hartytp_ has joined #m-labs
<hartytp_>
sb0: ping
<sb0>
hartytp_: yes?
<hartytp_>
pll works
<sb0>
cool
<sb0>
reliably? at all power cycles? at 600, 1000, 1200, 2400MHz? with deterministic phase?
<hartytp_>
so far only tested 600MHz, but if that one works the others will
<hartytp_>
but, yes, seems to work
<sb0>
if that one works the others will? hmm. optimistic...
<hartytp_>
:)
<hartytp_>
Don't worry, I'll test other configurations next
<hartytp_>
but, seriously, there isn't much to go wrong there
<hartytp_>
important point is that the feedback through the output divider does seem to work
<sb0>
_florent_: what is the si570 frequency on your board?
<sb0>
you can probably use that
<sb0>
_florent_: also the CPLL should run at 2500MHz, and this is controlled by p_CPLL_FBDIV, p_CPLL_FBDIV_45 and p_CPLL_REFCLK_DIV
<sb0>
using other frequencies is doable by changing those parameters, and it doesn't seem there is much that can go wrong there
<sb0>
I would not trust GTGREFCLK on Ultrascale.
<sb0>
GTGREFCLK definitely has a lot of jitter that also depends on fabric activity
<sb0>
_florent_: also for using the si570 you only have to change the pin numbers
<sb0>
even though it is in another transceiver quad, surprisingly, vivado is actually capable of configuring the routing correctly
<sb0>
the GTH is the only I/O feature that is less fucked on Ultrascale compared to 7-series
<sb0>
_florent_: the kcu105 has an auxiliary FPGA that contains a factory design that lets you set the si570 frequency with a simple uart interface
proteusguy has joined #m-labs
_whitelogger has joined #m-labs
proteusguy has quit [Ping timeout: 245 seconds]
<hartytp_>
sigh....there is something odd going on with this pll. The phase seems non-deterministic at the level of well sub 1 VCO clock cycle
proteusguy has joined #m-labs
<hartytp_>
damn
<hartytp_>
so, the options are:
<hartytp_>
1. figure out what undocumented features this PLL has and how to bypass them. although, given how small the phase glitches I'm seeing are, it's going to be hard to really convince ourselves that they're truly gone
<hartytp_>
2. give up on this pll and use the hmc830 (have to decide how we're going to measure the output phase and reset as necessary)
<hartytp_>
3. use the hmc830 with an external output divider, which we can reset, although that has all the usual issues
hartytp_ has quit [Quit: Page closed]
hartytp has quit [Ping timeout: 256 seconds]
proteusguy has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
proteusguy has joined #m-labs
<_florent_>
sb0: ok i'll do a test with the si570
<d_n|a>
bb-m-labs: force build --branch=pull/1176/merge artiq
<bb-m-labs>
build forced [ETA 59m04s]
<bb-m-labs>
I'll give a shout when the build finishes