<Maizar>
I need same sample code (for example state machine) for nmigen & migen to compre both my mail mnavahan2@gmail.com
<Maizar>
an have it ?
<Maizar>
Can Have It ?
<Dar1us>
have you tried googling for it?
<Dar1us>
you shoudl be able to find examples online for both
<Maizar>
Yes not any compare find by me :-(
<mtrbot-ml>
[mattermost] <sb10q> well, what is stopping you from comparing them yourself? have you found both examples?
<Maizar>
The fsm.py from migen & nmigen have very diffrent
<Maizar>
one clear same fsm.py Exampels push me & my compere is finish .....
<Dar1us>
I can't parse that..
<Dar1us>
also, it's not really clear what your end goal is
Stormwind_mobile has quit [Read error: Connection reset by peer]
<Maizar>
i start learn both migen & nmigen then i need find similarity & diffrent for clear view ...
<mtrbot-ml>
[mattermost] <hartytp> @sb10q thanks for the review. One thing I don't understand is the purpose of the DDMTD...
<mtrbot-ml>
[mattermost] <hartytp>
<mtrbot-ml>
[mattermost] <hartytp> If the algorithm is to use the SERDES as a S/H violation detector and then stick SYSREF in the middle of the valid region, and if you can trust that the HMC7043 delay is well-behaved/linear then why do you need the DDMTD? Is this just an additional diagnostic? Does the HMC7043 delay not behave as well as I expect from the data sheet? Or am I missing something?
<mtrbot-ml>
[mattermost] <sb10q> we don't know the state of HMC7043 outputs vs. RTIO clock
<mtrbot-ml>
[mattermost] <sb10q> the DDMTD core sorts this out
<mtrbot-ml>
[mattermost] <sb10q> the HMC7043 only sees the muliplied (2.4GHz) clock
<mtrbot-ml>
[mattermost] <sb10q> when generating SYSREF from it, there are 2400/150 possibilities for the phase within a RTIO clock cycle
<mtrbot-ml>
[mattermost] <hartytp> ok, true. So then my description on the wiki is not correct.
<mtrbot-ml>
[mattermost] <sb10q> using the SERDES and putting it in the middle of the s/h ok region might work, but it's harder to see what is happening
<mtrbot-ml>
[mattermost] <sb10q> if there's any issue it'll result immediately in obscure behavior
<mtrbot-ml>
[mattermost] <sb10q> the DDMTD makes testing/debugging easier
mumptai_ has quit [Read error: Connection reset by peer]
<mtrbot-ml>
[mattermost] <sb10q> and there may be issues, since we don't know if determining s/h limits will be precise enough i.e. << 1 cycle of the 2.4GHz clock
mumptai_ has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> it should work based on current results, but as soon as it doesn't it's immediately going into "WTF is going on sync is broken" territory
<mtrbot-ml>
[mattermost] <hartytp> yes, I see that. So, that means that the description I wrote on the wiki is not right
<mtrbot-ml>
[mattermost] <sb10q> the HMC7043 delays work as expected when using the firmware library functions (with the workarounds like enabling the SYSREF FSM)
<mtrbot-ml>
[mattermost] <hartytp> I see, so is this a fair description then: we use the DDMTD + S/H validator to pick a SYSREF<>RTIO clock phase relationship that ensures S/H is met at the SysrefSampler. Once we've fixed that delay, we use the DDMTD core to ensure that at each boot the same phase relationship is restored to a precision of less than one DAC clock cycle.
<mtrbot-ml>
[mattermost] <sb10q> yes
<mtrbot-ml>
[mattermost] <hartytp> ok, I see, I'd just missed that second part.
<mtrbot-ml>
[mattermost] <hartytp> thanks
<mtrbot-ml>
[mattermost] <sb10q> if things work well, we can remove the DDMTD core and have another and simpler algo with just the SERDES, but that would remove a fair bit of the diagnostics
<mtrbot-ml>
[mattermost] <sb10q> and those have been very useful during development
<mtrbot-ml>
[mattermost] <hartytp> completely agree with that. I guess the SERDES would probably work. At present it's 600MHz so presumably measuring the transitions we can upsample to 2.4GHz without issue
<mtrbot-ml>
[mattermost] <hartytp> but the DDMTD is a nice addition
<mtrbot-ml>
[mattermost] <sb10q> no it's 2.4GHz for all synch purposes
<mtrbot-ml>
[mattermost] <sb10q> the sync system never sees the 600MHz
<mtrbot-ml>
[mattermost] <sb10q> the DAC samples SYSREF with its final post-interpolation clock
<mtrbot-ml>
[mattermost] <hartytp> What I mean is that the SERDES is sampling at 4x150MHz but presumably is actually good enough to measure the transitions from a 2.4GHz clock
<mtrbot-ml>
[mattermost] <sb10q> ah
<mtrbot-ml>
[mattermost] <hartytp> i.e. I think we're saying the same things but I'm not sure I have quite the correct vocabulary for this
<mtrbot-ml>
[mattermost] <sb10q> yes, probably, though the sample rate doesn't really matter here
<mtrbot-ml>
[mattermost] <sb10q> jitter is what matters
<mtrbot-ml>
[mattermost] <sb10q> siphaser works with something like that and seems to achieve rather good performance
<mtrbot-ml>
[mattermost] <hartytp> well, you can average jitter out. My point was just that if the SERDES is specified to work nicely at 600MHz then it can probably actually do something useful at 2.4GHz with a little averaging
<mtrbot-ml>
[mattermost] <sb10q> SERDES spec is >1GHz
<mtrbot-ml>
[mattermost] <hartytp> IIRC they're really good as very high-frequency, broadband chokes. A big inductor would become self-resonant at too low a frequency, a small inductor wouldn't block the low frequencies
<mtrbot-ml>
[mattermost] <hartytp> so you taper between the two
Stormwind_mobile has joined #m-labs
<mtrbot-ml>
[mattermost] <hartytp> @sb10q pushed some changes to the wiki. It's more verbose now, but I think it's correct and clear about what we're doing. If you have a moment could you skim an eye over it?
Stormwind_mobile has quit [Ping timeout: 256 seconds]
<mtrbot-ml>
[mattermost] <hartytp> @sb10q I have a Kasli v2.0 and a scope in front of me. Can you remind me what the issue with the WR I2C was? If there is something I can look at quickly to help debug it then let me know...I haven't heard anything from @weidazhang so I think we're on our own on this one
<mtrbot-ml>
[mattermost] <sb10q> Si549 registers are not written by the gateware
<mtrbot-ml>
[mattermost] <hartytp> hmm...okay...I'll have a quick look
Stormwind_mobile has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
proteusguy has quit [Ping timeout: 240 seconds]
proteus-guy has quit [Ping timeout: 265 seconds]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
acathla has quit [Ping timeout: 256 seconds]
proteusguy has joined #m-labs
proteus-guy has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
ohsix has quit [Ping timeout: 256 seconds]
mauz555 has quit [Read error: Connection reset by peer]
ohsix has joined #m-labs
Maizar has quit [Remote host closed the connection]