synaption[m] has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
jfng has quit [Read error: Connection reset by peer]
marble[m] has quit [Remote host closed the connection]
jryans has quit [Read error: Connection reset by peer]
marble[m] has joined #m-labs
jaeckel has quit [Ping timeout: 258 seconds]
proteusguy has joined #m-labs
proteusguy has quit [Remote host closed the connection]
xobs has joined #m-labs
jfng has joined #m-labs
synaption[m] has joined #m-labs
jryans has joined #m-labs
jaeckel has joined #m-labs
proteusguy has joined #m-labs
m4ssi has joined #m-labs
sb0 has joined #m-labs
<mtrbot-ml_>
[mattermost] <pkulik> cr1901_modern: your post were very helpful in understanding migen, thank you!
mauz555 has joined #m-labs
mauz555 has quit [Client Quit]
proteusguy has quit [Ping timeout: 258 seconds]
plonk_ has joined #m-labs
<cr1901_modern>
pkulik: Glad I could help :)
plonk has quit [Ping timeout: 246 seconds]
sb0 has quit [Quit: Leaving]
futarisIRCcloud has joined #m-labs
cedric has quit [Ping timeout: 272 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m4ssi has quit [Ping timeout: 248 seconds]
bluebugs has joined #m-labs
bluebugs has quit [Changing host]
bluebugs has joined #m-labs
cedric has quit [Ping timeout: 272 seconds]
hartytp has joined #m-labs
<hartytp>
rjo: how well tested is the Urukul profile select logic?
<hartytp>
we had an issue with our profile selection for the AD9910 a while back when using eval boards, and AFAIC the same issue is present here
<hartytp>
profile select lines are supposed to meet S/H on SYNC_CLK if they don't then the maximum toggle rate (1 transition per 2 SYNC_CLK cycles must be observed or the DDS can get into odd states)
<rjo>
using the profile select is not simple. you may want to have a look at the ram issue how i used it. there are a couple comments iirc.
bluebugs is now known as cedric
<hartytp>
as all profiles toggle at once and don't meet S/H w.r.t. SYNC_CLK there can be issues where the different profile pins are latched on adjacent clock cycles, causing DDS errors
<hartytp>
we previously fixed this by ensuring that the profile pins were either synced w.r.t. SYNC_CLK or by enforcing a min delay between pin toggles
<rjo>
sure. that's all known. see my notes in the issue.
<hartytp>
okay
<hartytp>
shouldn't there be a note in the core device doctoring about that, since this is an issue that users are likely to hit?
<rjo>
or you can gray-code it with the obvious consequences.
<rjo>
if there isn't, then that's a welcome addition.
<hartytp>
okay, i didn't see any notes about that. I'll double check and open an issue (/submit a PR if I have time)
<hartytp>
oh, any feedback about the SU-servo PR?
<rjo>
well. i didn't comment on it. ;)
<hartytp>
okay, in that case I'll merge. Thanks for the review
<rjo>
no.
<rjo>
i meant the profile thing.
<hartytp>
oh, sorry...
<rjo>
there are no comments in the example code i posted.
<hartytp>
aah, right, I see what you mean. I meant that there are no notes about this in the core device driver. I hadn't looked at your example yet.
<rjo>
re the suservo thing, it would be nice to have the PR do what the title says. the PR changes the write path but the title is about reading only. and the gateware changes should really be more compact. there is no need to create additional signals. it makes the code harder to read than it already is.
<hartytp>
(or, rather, that I don't recall any notes in the docstring)
<rjo>
a note in the coredevice driver about the implications of the CDC on not meeting S/H and the max toggle rate would be nice.
<hartytp>
re servo: there was another commit that did the gateware the way you suggested
<hartytp>
and also added a note in the doctoring to clarify the assumptions we make
<rjo>
yes. one commit in the PR fixes the write path in the coredevice driver. the other fixes the read path in the gateware.
<rjo>
and also note that the profile select lines go to all four channels.
<hartytp>
Okay, I'm fine doing them as two PRs if you prefer (just rolled them together as the write path issue gets more ugly once the sign extending is added)
<hartytp>
re profiles: ack
<hartytp>
okay, any objections other than splitting the PRs? Do you want another round of reviews, or shall I just split and merge?
<rjo>
the lack of comments and the inconsistency just confused me and makes this take longer. if the code is ok if you add the comments and get rid of the complexity in the gateware. all you should need is the one sign_extend() line. the assignment precedence takes care of the rest.
<rjo>
gotta go.
hartytp has quit [Ping timeout: 256 seconds]
lkcl has quit [Ping timeout: 258 seconds]
lkcl has joined #m-labs
<_whitenotifier-3>
[nmigen] whitequark commented on issue #71: Clock constraints are unreliable due to nextpnr issue - https://git.io/fj0lA
<_whitenotifier-3>
[nmigen] whitequark closed issue #71: Clock constraints are unreliable due to nextpnr issue - https://git.io/fjRcW
<cr1901_modern>
Good thing I kept the object files around from my previous recent build