<sb0>
interesting, the MMCM locked signal seems actually synchronous to the PFD clock or something like that
<GitHub-m-labs>
[artiq] whitequark commented on issue #1007: Yes. The root cause is I removed the unconditionally_dereferenceable LLVM patch because it was unsound while upgrading to LLVM 6.0. I am reimplementing that in the ARTIQ compiler now. https://github.com/m-labs/artiq/issues/1007#issuecomment-390705259
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<sb0>
hm, turns out redpitaya is quite buggy as well
<felix_>
the camera link chip used in the spec permutates the bits before it serializes them; you can get the mapping of bits from the datasheet of the camera link interface chip. so you have the mapping of bits to the interface to that chip and in the datasheet of that chip is the mapping to the bits on the wire
<cr1901_modern1>
_florent_: Good point wrt oscillator tolerance. I didn't think of that.
<cr1901_modern1>
rjo: >I can argue just as well for smallest absolute error or max frequency that's less or equal to the desired one.
<cr1901_modern1>
Would giving the user a choice in whether to use rel error, abs error, or max freq (default to max freq) be okay
cr1901_modern1 has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
ardavast__ has quit [Read error: Connection reset by peer]
ardavast has joined #m-labs
<rjo>
cr1901_modern: too complicated. i'd actually consider just erroring when there is no exact match and telling the user what the closest frequencies are to his request.
mumptai has quit [Quit: Verlassend]
ardavast has quit [Remote host closed the connection]
ardavast has joined #m-labs
<cr1901_modern>
rjo: This is what I wanted to do originally. The problem is that migen deals w/ clock periods, and the oscillator deals w/ frequencies. And in FP a * (1/a) != a
<cr1901_modern>
guess I could do int(1/default_clock_period)
<whitequark>
cr1901_modern: just treat "anything within typical XO tolerance" as a match