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
<sb0>
whitequark, the default timer can give you an interrupt when it reaches 0
<sb0>
but aren't you using this timer for something else already?
<whitequark>
it's used for sleeping
<whitequark>
but that's not a problem at all
<cyrozap>
In Migen, if I have a Signal(1) "foo" and a Signal(8) "bar", how do I select bit bar[foo] without getting the error "TypeError: Cannot use type <class 'migen.fhdl.structure.Signal'> (<Signal foo at 0x7fc4a68aee10>) as key"?
<sb0>
Array(bar[i] for i in range(len(bar)))[foo]
<cyrozap>
sb0: Thanks, though that seems a little verbose... I'm just trying to assign a bit from a Tx buffer to an output pin in an FSM using NextValue--is there a better way of doing that?
<sb0>
if you're simply clocking out bits for a serial transmitter, make a shift register instead anyway
sandeepkr has joined #m-labs
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr_ has quit [Ping timeout: 264 seconds]
kuldeep_ has quit [Ping timeout: 272 seconds]
kuldeep_ has joined #m-labs
kuldeep_ is now known as kuldeep
sb0 has quit [Quit: Leaving]
sandeepkr has joined #m-labs
rohitksingh_work has joined #m-labs
sb0 has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 265 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
FabM has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 252 seconds]
<_florent_>
larsc: as rjo said, we are trying to do something like that: http://www.enjoy-digital.fr/share/ad9154_no_dacpll.png, but by looking at the official and preliminary datasheet, it's still unclear to me how to do that
<_florent_>
larsc: the SERDES PLL should be configured correctly in my design, but I'm not sure if the DACCLK at the input is correct ((should be CLK+-) and could explain why I'm not able to get the SERDES PLL to lock.
<_florent_>
larsc: in case you have some advices on how to use this mode that could help :)
<larsc>
_florent_: do you configure anything on the clockpath or leave it at power-on reset defaults
key2 has joined #m-labs
<key2>
hi
<key2>
sb0: do you have an example or instruction or even a tip on how you get lm32 debugging over uart ?
<key2>
(or lm32 debugging over jtag if it's there..)
<rjo>
_florent_: for testing, and as a workaround for this specific issues we can use the dacpll in 1:1
<rjo>
_florent_: is that figure from the rev-PrI datasheet?
<_florent_>
rjo: yes that's the figure from the rev-Prl datasheet
<_florent_>
rjo: I'm now testing different frequencies on the input, and I'm able to get the PLL locked in some cases without using the PLL but not for the values I expected. I'm trying to understand
<_florent_>
rjo: able to get the SERDES PLL locked in some cases without using the DAC PLL
<larsc>
which cases?
<_florent_>
larsc, rjo: in fact it seems the clock at the input of the SERDES_PLL is CLK+- divided by 4
<_florent_>
larsc: according to the datasheet I would have expected it to be CLK+-
<_florent_>
larsc: I tried to play with the divider at the input of the SERDES_PLL to be sure it was not this one that was stuck to 4
<_florent_>
larsc: but the divider is behaving correctly
<_florent_>
larsc: do you see something that could explain this behaviour?
<larsc>
what makes you think it is divided by 4?
<larsc>
do you set the upper bits of the register to 1?
<_florent_>
of AD9154_REF_CLK_DIVIDER_LDO?
<_florent_>
what I'm doing:
<_florent_>
setting AD9154_SPI_CDR_OVERSAMP to 2
<_florent_>
this should give a divider of 1 at the input
<_florent_>
then I'm playing with the input frequency
<_florent_>
when I have input_freq > 35MHz*4 and input_freq < 80MHz*4 I'm able to get the lock
<_florent_>
otherwise I get PLL_OVERRANGE_L_RB when too low
<_florent_>
or PLL_OVERRANGE_H_RB when too high
<_florent_>
now when I set AD9154_SPI_CDR_OVERSAMP to 1 (divider of 2)
<_florent_>
I get the lock for input_freq > 35MHz*8 and input_freq < 80MHz*8
<_florent_>
so it seems that the divider at the input of the SERDES_PLL is working fine, but there is another divider by 4 somewhere
<larsc>
and changing REF_CLK_DIVIDER_LDO makes no difference?
<_florent_>
it does because I see that I have to multiply my input frequency by the div factor to get the lock
<_florent_>
larsc: do you set the upper bits of the register to 1? --> of which register?
<larsc>
REF_CLK_DIVIDER_LDO, but I see you do
* whitequark
sighs
<whitequark>
I've spent the last three days on what is, apparently, a miscompilation of __muldi3
<whitequark>
64-bit multiplication, that is, which returns zeroes for a reason that still elides me
<whitequark>
turns out rust uses a mul-with-overflow intrinsic in the allocator to detect, well, overflows (commendable)
<whitequark>
but the intrinsic is implemented by going to 33-bit numbers
<whitequark>
which are legalized into 64-bit numbers
<whitequark>
which aren't directly supported and so get to a software fallback from compiler-rt
<whitequark>
which is broken.
<larsc>
_florent_: so what you see is the divider of CDR_OVERSAMP and REF_CLK_DIV and then an additional divide by 4?
<rjo>
whitequark: are you in the lab?
<sb0>
rjo, i am
<_florent_>
larsc: yes
<sb0>
rjo, what did you want again? second kc705 on network?
<rjo>
sb0: ah! just looks like the aircon is running. could you connect the ad9154-kc705 to the ethernet switch?
<rjo>
sb0: yes.
<whitequark>
rjo: do you have a temp sensor there somewhere?
<_florent_>
larsc: in fact Figure 42, I would have expected fREF to the CLK+- of the chip, but it seems to be CLK+-/4
<larsc>
but maybe the older ones have the same setup
<_florent_>
ok thanks I'm going to look at that
<_florent_>
larsc: can you share more information about your setup (number of lanes, bitrate, interpolation mode)? just to try to figure out things
<larsc>
4 lanes, 10Gbps, no interpolation
<rjo>
nice 12 GS/s. that'll get some physicists drooling.
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<larsc>
rjo: but only with 2x interpolation
<rjo>
larsc: sure. 6 GS/s data rate still. weird though, that it's not IQ.
<larsc>
you can run it in IQ mode when you use the NCO (with a lower baseband rate)
<larsc>
for the ad9154 I'd assume for now that there is a fixed div 4 that they forgot to document. I can ask around and get some more information tomorrow
<_florent_>
larsc: yes thanks, I'm going to assume that too and see if I'm able to get CGS working
rohitksingh_work has joined #m-labs
<rjo>
larsc, _florent_ the fmcdaq2 is a very similar setup. they have refclock = dacclock = 1 GHz, no pll, no interpolation
<_florent_>
rjo: at least the behaviour I see seems to match
<rjo>
_florent_: but that is a black box. where do you believe you have to account for it?
<_florent_>
rjo: just to understand what was the input clock of the SERDES since I was not able to get the lock
<rjo>
_florent_: sure. but i'd also like to see why you think the divider helps you understand that. ;)
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<_florent_>
rjo: ?? sorry, I don't see your point, I just wanted to be sure I was correctly configuring the chip. At least assuming the divider now make things clear (for me :))
<rjo>
_florent_: could you give me a minute and explain how it clarifies things? i'd like to know whether i am missing something.
<_florent_>
rjo: I was trying to see from where was coming this fREF, was it DACCLK or something else. The only others parts of the spec where fREF is mention if for the clock input of the chip.
<_florent_>
rjo: but yes, between DACCLK and fREF we have a black box that is not documented, with the divider inside that, and another one for the interpolation
<rjo>
_florent_: fREF in AD9154-B/fig 47, page 36, i assume.
<_florent_>
rjo: yes
<rjo>
to me it is the following: that fref is dacclk divided by interpolation and lanes multiplied by converters etc. in such a way that it is what it says: bit-rate/40.
<larsc>
but maxbitrate/40 is a lot faster than the max pfd
<rjo>
_florent_: this is (AFAICT) also the reason why you need to do some transport layer setup (L F M N etc) _before_ you setup the SERDES PLL.
<_florent_>
yes that's it. In fact I think I was trying to understand how this was generated from the input clock, but that part is not documented
<rjo>
larsc: there is a 1,2,4 divider before the pfd in that schematic.
<larsc>
hm, that works
<rjo>
larsc: there is DivFactor
<sb0>
rjo, looks fine
<sb0>
is there any problem?
<rjo>
_florent_: ack. it's not documented.
<rjo>
sb0: not anymore. i had assumed you had tightened it already.
<rjo>
sb0: on the second kc705, i am sometimes getting: "Read delays: 7:00-11 6:00-11 5:03-13 4:03-14 3:09-20 2:00-06 1:00-09 0:32-33" on the sdram init and a memtest failure. when it is "0:00-09", it works.
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
rjo, same bitstream (bitwise) or recompiled?
<rjo>
same bitstream. just reconfig.
<rjo>
sb0: it's random whether or not it happens afaict.
<rjo>
roughly 1 in 6 boots fail.
<rjo>
but maybe it is bitstream dependent as well. i'll watch out whether other bitstreams have the same problem.
bentley` has joined #m-labs
rohitksingh has joined #m-labs
<_florent_>
rjo, larsc: I finally got CGS working.... (lanes in LANEDESKEW and LANEENABLE registers are the logical lanes and not the physical ones...)
<sb0>
good!
<larsc>
good job!
<_florent_>
just got the ILA received by the AD9154, parameters seems to be decoded correctly :)
<_florent_>
larsc: BTW I added a counter to it
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.3.0/20160802213348]]