<sb0>
can I expect something other than vivado breakage by putting a BUFGCE_DIV into the feedback path of a MMCM?
<sb0>
yeah of course it's vivado breakage
<sb0>
CRITICAL WARNING: [DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell MMCME2_BASE. The computed FVCO is 299.985 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 2.000, CLKIN1_PERIOD = 6.66700, and DIVCLK_DIVIDE = 1 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).
<sb0>
typical xilinx garbage
<sb0>
they force you to put the dividers outside the MMCM, without any consideration for the consequences, such as deterministic phase or VCO frequency computations
<sb0>
oh and of course, then it breaks a completely unrelated part of the design by refusing the place it
<sb0>
*to place it
<sb0>
geez I wish someone one day makes FPGAs that don't suck and drive X&A out of business
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #925: I suggest focusing 4.0 on supporting the new hardware - there are enough issues with it already and this compiler change doesn't seem simple. Let's move it to 5.0? https://github.com/m-labs/artiq/issues/925#issuecomment-374832583
<GitHub-m-labs>
artiq/master f8c2d54 Sebastien Bourdeauducq: ttl_serdes_ultrascale: configurable SERDES ratio. Also try X4 on Sayma
<GitHub-m-labs>
artiq/master 9c2d343 Sebastien Bourdeauducq: sayma: use SERDES RTIO TTL...
<sb0>
yeah the mmcm is great for deskew they say, EXCEPT for the random skew introduced by their imbecilic, non-deterministic BUFGCE_DIV
rohitksingh_work has quit [Ping timeout: 265 seconds]
rohitksingh_work has joined #m-labs
AceChen has quit [Ping timeout: 268 seconds]
bunnie has joined #m-labs
<bunnie>
Quick sanity check question: is it common for migen to have non-deterministic netlists, e.g. from run-to-run the same script generates a slightly different top.v file with no changes otherwise to the Python code?
<bunnie>
I've noticed sometimes I have to "compile twice" to get my design to work, and I thought it was a timing issue except I opened the routed checkpoint and found that whole nets were missing from the final design
<bunnie>
I'll dig into this more but in particular I think maybe whatever is generating the CSR address space isn't consistent from run to run. Maybe I'm doing something wrong and my code has a built-in ambiguity that migen is tossing a coin to resolve?
<sb0>
bunnie, it's not common and should be fixed when it happens. the root cause of this is, the non-deterministic iteration order of python dictionaries/sets
<sb0>
bunnie, as a quick fix you can use PYTHONHASHSEED
<sb0>
the long term solution is to find wherever in migen/misoc/your code there is a non-deterministic iterator, and replace it with something deterministic
<sb0>
or convince guido to abandon the non-deterministic behavior
<sb0>
which produces funny behavior in other places, e.g. .pyc files are typically non-reproducible
ncl has quit [Remote host closed the connection]
<bunnie>
OK thanks, that's very helpful. It confirms I'm not crazy. I'll read up about the PYTHONHASHSEED.
<bunnie>
I guess this means for code to be "tested", it must be noted which PYTHONHASHSEED it's tested against, otherwise it's hard to guarantee validation.
ncl has joined #m-labs
<bunnie>
btw, do you happen to know of any public docs on migen "records"? The migen manual 0.5 refers to them but doesn't go into the API. In particular I'm wanting to confirm my understanding of the "keep" and "omit" behaviors.
<sb0>
bunnie, no, the code should not use non-deterministic iteration
<sb0>
and should be fixed when it does. no mandatory pythonhashseed workarounds, this isn't xilinx software
<_florent_>
bunnie: for your design, do something like this: ttps://github.com/enjoy-digital/netv2-soc/commit/12f058c14bb58a03176ee864de2f37e08a2b082d
<_florent_>
bunnie: it should solve your non-determinism issue
<bunnie>
thanks. I'll do that, and set the hash seed. the compilation process is already random enough, I don't need more variables moving around when chasing down issues!
<bunnie>
also, when i'm doing a stream connect() operation and "keep" is specified, that means to connect *only* the items on the keep list, and omit everything else even if they could be connected?
<_florent_>
bunnie: yes that's what keep/omit means
<cr1901_modern>
>is it common for migen to have non-deterministic netlists
<cr1901_modern>
I have never seen this happen ._. Doesn't mean it can't, just I've never seen it
<cr1901_modern>
I'm pretty sure "omit" is used in the context of Record.connect. It used to be called "leave_out"
<cr1901_modern>
Any signals in the omit set aren't connected between two records when using Record.connect. I don't remember what "keep" does
<cr1901_modern>
or where it's used*
<bunnie>
thanks all!
<rjo>
sb0: are the LOCs on sayma helping? did you test that?
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.5.0/20171114221957]]
<hartytp>
The whole thing will drift around much more than that on thermal tinescales
<rjo>
sure. but now your amplitude noise at 1-1MHz offsets is limited by the ADC...
<hartytp>
Maybe
<hartytp>
Or still dl
<hartytp>
Anyway for g>1 the in amp limits
<hartytp>
Difference between novo and sampler there is just bw
<hartytp>
Iirc
<hartytp>
And this is assuming pd etc is <10ppm noise
<hartytp>
If integrated run
<rjo>
what do you mean by "loop gain low"? that's exactly where it hits you. you are not averaging, no lowpass filtering before the adc will help you.
<hartytp>
Depends on the gain of all components in the loop
<rjo>
with novogorny we were in-amp limited for 100 and 1000. ok. those match with the increased BW.
<hartytp>
Got to go. Tl;Dr I'm not fussed about 1lsb of add noise
<hartytp>
Adc
<rjo>
once you are at the ADC, the only component that would be relevant would be a <<1 MHz narrowband filter after the DDS to smooth out the AM noise you just added.
<rjo>
it's not a drama, but saying categorically that Sampler is better in every regard is confusing (to put it lightly) if it has in fact 12 dB worse RMS noise and 6 dB worse noise density in the lowest gain setting.
awygle has quit [Remote host closed the connection]
rqou has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.2/20180316222652]]
awygle has joined #m-labs
forrestv has joined #m-labs
<rjo>
hartytp: please do the zotino pull request. it's nearly impossible to discuss changes otherwise. it's fine if -- after starting the PR -- the content changes. that's the idea.
<rjo>
hartytp: otherwise good if you tested it. i am a bit uncertain that div_read=4 will work through the LVDS repeaters, FPGA, cable round trip. Since this is not critical i'd err on the robust side.
hartytp has joined #m-labs
<hartytp>
rjo: okay picking things up
<hartytp>
Firstly, sampler
<hartytp>
Let's trace this
<hartytp>
Triage
<hartytp>
Preamble: normally I consider "sampler" and "novogorny" to be names for different hw revisions on the same dedign
<hartytp>
For now let's take "sampler" to mean "Any design with the new adc"
<hartytp>
And "novogorny" to be the old adc
<hartytp>
You raise 2 separate issues: low gain noise and high gain noise
<hartytp>
High gain noise: afacit this is not a novogorny v sampler issue but an independent decision that was made for v2 to raise the bw at the expense of worse noise
<hartytp>
Iirc the v1 design didn't really work because the inamp can't drive the adc properly
<hartytp>
So we needed to alter the driver regardless of the adc
<hartytp>
When
<hartytp>
I did that I changed the bw. It's legitimate to question whether that was the right move. If you want to do that please open an issue on gut hub
<hartytp>
Nb changing this is just a few rcs so no big deal
<hartytp>
Low gain noise: this was expected for the new adc
<hartytp>
Any comparisons between the boards I made should have had a caveat word like "significant"
<hartytp>
E.g. sampler will be more expensive than novogorny but afacit the difference is less than potential bulk-buy discounts so we're better off producing more copies of the same design
<hartytp>
I don't seem the adc noise increase in sampler to be significant since its only 1lsb
<hartytp>
note that the analogue filter has a gentle cut off at 250kHz
<hartytp>
So the pd etc noise will not be attenuated that much by the 1MHz
<hartytp>
So id generally expect more than 1 lsb of noise due to that plus pickup etc
<hartytp>
So I do not expect that to be a limit
<hartytp>
(I also expect out-of-band laser noise to be a bigger contribution in most setups)
<hartytp>
That's why I'm dismissive of this decision
<hartytp>
And, again, I think we're better of with one design produced in bulk and really well tested and supported than two designs if the performance advantage of novo is so marginal
<hartytp>
Zotino: ack
<hartytp>
The code wasn't in a state where I considered it acceptable to submit a pr
<hartytp>
It's now basically there but there are changes I haven't tested yet on the hw
<hartytp>
Had to leave lab unexpectedly today or would have done that
hartytp has quit [Quit: Page closed]
<rjo>
hartytp: i think sampler is a fine device and is an excellent compromise. just that i wasn't aware that the ADC is worse. and the 1000 gain setting is also weird. the bandwidth should be limited by the INA to the same as for novogorny. still the noise is twice as high.
<rjo>
and the inamp-adc interface in novogorny could have been fixed by increasing the r, c there.
<rjo>
i don't think there is much to improve on sampler in that regard. it's fine.
hartytp has joined #m-labs
<hartytp>
Rjo: fwiw iirc the issue with novo was that low r/High c upset the inamp while high r/Low c gave bad duty-cycle-dependent glitches when the adc sampled
<hartytp>
Seemed to need an extra buffet amp to drive the adc
<hartytp>
Ack on the high gain setting stuff. Can you post an issue and I'll investigate on our board
<hartytp>
Fwiw the numbers you posted are still fine for our noise eater application, but it's Sri wpryb