<whitequark>
so now we have *both* s.next = 1 and NextValue(s, 1)? I'm not sure what the improvement is, this is exactly as complex but now there's one more way to do FSMs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
sb0 has quit [Quit: Leaving]
<tpw_rules>
whitequark: yeah that's what i wanted to do the AST manipulation for. to turn that into a python If where you could say s.next = 1 inside
<tpw_rules>
but i wasn't sure if you wanted that as a migen feature
<tpw_rules>
i'll toy with that a little but i was implementing it like sb0 suggested
attie has quit [Ping timeout: 264 seconds]
attie has joined #m-labs
marmelada has joined #m-labs
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined #m-labs
FabM_cave has joined #m-labs
FabM_cave is now known as FabM
<whitequark>
tpw_rules: I think Glasgow should stay just plain migen to make it easier to contribute, having two different kinds of syntax impedes that
<whitequark>
but your project has value on its own
<tpw_rules>
that's a valid point. i gather then you would rather see the AST and context manager stuff as a separate project that builds on top of Migen instead of something that will be merged into it?
<whitequark>
that's up to sb0 really, I don't feel like I have the authority to make such changes to migen
<marmelada>
ok, I got two dio bnc, one from master one from satellite
attie is now known as attie\ito
<marmelada>
and signal on satellite is delayed around 226 ns to signal from master
<marmelada>
it seems to be much more than hartytp measured if I recall correctly
<marmelada>
what values did you get sb0?
cjbe has joined #m-labs
<cjbe>
marmelada: with between Kasli DRTIO master-satellite and a short fibre I see about 230ns, so this agrees with what you see.
<cjbe>
For a given set of hardware / fibres this latency is constant to within ~20ps
kuldeep has quit [Ping timeout: 245 seconds]
kuldeep has joined #m-labs
kuldeep has quit [Ping timeout: 256 seconds]
<GitHub-m-labs>
[artiq] marmeladapk opened pull request #1018: Added second argument to DIO.add_STD in master and satellite variant … (master...for_merge) https://github.com/m-labs/artiq/pull/1018
kuldeep has joined #m-labs
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined #m-labs
cjbe__ has joined #m-labs
hartytp has joined #m-labs
<hartytp>
rjo: playing with the servo
<hartytp>
want to check I understand your terminology for the gains
<hartytp_>
rjo: so, the above was a misreading of your maths...oops. But, am I right in thinking that for a P/PI loop, corner = Ki/Kp. But, for a I loop you set w=ki
<hartytp_>
?
<hartytp_>
I find that a bit unintuitive personally
<hartytp_>
for an I-only loop, I think it's easier to just specify Ki. corner is a bit misleading anyway, since it's only f0dB for the LF, not for the overall loop.
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1021: Switched to using Netgear GS608 v4. This is same switch [used at M-Labs](https://github.com/m-labs/artiq/issues/854#issuecomment-380708051). @trxw points out that this switch is currently selling in two version v3 and v4. What version did M-Labs use? Only two hosts attached to the switch. ARTIQ Master PC and Sayma. Still see packet loss. ... https://github.com/m-la
<sb0>
bb-m-labs: force build --props=package=jesd204b conda-lin64
<bb-m-labs>
build #406 forced
<bb-m-labs>
I'll give a shout when the build finishes
<bb-m-labs>
build #2403 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2403 blamelist: Pawe? <marmeladapk@users.noreply.github.com>
<kaolpr>
does anyone know if RT2WB is supposed to work properly? I'm trying to get any data from WB bus using RT2WB but it fails with RTIO busy error. https://hastebin.com/ahusedekar.rb
<sb0>
kaolpr, it's used for the ad9914 dds and works there
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<kaolpr>
sb0, thanks, just wanted to be sure nothing was dropped during development
<jbqubit>
On output of Sayma RTM DAC SMPs I see digital wavetrain not sinusoid as commanded. Looking for USB stick do post Issue. Running yesterday's master.
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1019: We updated JESD and built from master 38b51282226f9. We reloaded RTM AMC .bit and observed successful booting each time. This looks resolved. https://github.com/m-labs/artiq/issues/1019#issuecomment-393330329
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1019: Ignore that post from five minutes ago. I accidentally used a build of the gateware from this morning that predated the JESD204B upgrade to v0.6. Just now I repeated test again using JESD204B=0.6 with SAWG and HMC830 build 38b51282226f9. Boot was successful four times in succession. https://github.com/m-labs/artiq/issues/1019#issuecomment-393345128
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1022: OK. Here's a clue. If ``` sawg.amplitude1.set(.8) ``` there is sinusoidal output. If ``` sawg.amplitude1.set(.9) ``` there is garbage like in screenshot above. ... https://github.com/m-labs/artiq/issues/1022#issuecomment-393347342