sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sandeepkr has joined #m-labs
sandeepkr has quit [Remote host closed the connection]
sb0 has joined #m-labs
sandeepkr has joined #m-labs
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 256 seconds]
<sb0>
rjo, any need for wide data readback?
<whitequark>
sb0: what are the next priorities?
<whitequark>
reimplementing the DDS stuff?
<sb0>
sounds good. I don't think switching between regular RTIO and DMA buffers in gateware is a good idea, and DDS as it is now would get in the way
<sb0>
is it possible that the dma context manager tweaks the dynamic linker to replace the rtio syscalls so that the cost of the test is not incurred at every event?
<whitequark>
sure, why not
<sb0>
whitequark, and the only config that needs to be supported is 9914 and one-hot selection signals
<sb0>
and you can pulse all the FUD at the same time (by asserting multiple one-hot sels) unlike what the code does now
<sb0>
this removes the time during which the output of the DDSes are inconsistent during a batch
<GitHub24>
[artiq] sbourdeauducq commented on commit b714137: 5/6 second? https://git.io/vXbGl
kuldeep has quit [Ping timeout: 250 seconds]
sb0 has quit [Quit: Leaving]
sandeepkr has quit [Quit: Leaving]
<GitHub83>
[artiq] sbourdeauducq commented on issue #623: What is that sideband cooling pulse sequence that causes trouble? https://git.io/vXbZc
<GitHub2>
[artiq] sbourdeauducq pushed 2 new commits to release-2: https://git.io/vXbZB
<GitHub2>
artiq/release-2 9910449 David Leibrandt: gateware: increase RTIO FIFO sizes for NIST_CLOCK. Closes #623
<GitHub2>
artiq/release-2 2513511 Sebastien Bourdeauducq: gui: 2.0 -> 2 in logo
<GitHub120>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vXbZR
<GitHub120>
artiq/master 4a62e09 David Leibrandt: gateware: increase RTIO FIFO sizes for NIST_CLOCK. Closes #623
<GitHub67>
[artiq] sbourdeauducq closed issue #623: Increase RTIO FIFO depths in class NIST_CLOCK https://git.io/vXdJy
sb0 has joined #m-labs
<sb0>
whitequark, oh and #621 (in 2.x) which is trivial iirc but has impact
<sb0>
and backport #591
<sb0>
unless that backport is complicated
<whitequark>
591 is weird
<whitequark>
it's fixed "properly" on phaser/master branches, by adding the relevant hooks to LLVM
<whitequark>
that is not trivial to backport because we're using LLVM 3.9 there, and 2.x uses 3.8 (I think?)
<whitequark>
I could port 2.x to 3.9 as well if you want, but it's more than just a cherry pick
<sb0>
okay then let's move this to 3.0
<whitequark>
ack wrt 621
<GitHub100>
[artiq] sbourdeauducq closed issue #591: run another instcombine+sccp after licm or something like that https://git.io/vXbnq
sb0 has quit [Quit: Leaving]
<whitequark>
sb0: why is there a false path constraint from cd_sys.clk to cd_rtio.clk?
<whitequark>
ah, hm
<whitequark>
* vivado prefers rsys_clk over sys_clk (despite the assignment hierarchy)
<whitequark>
(We need DONT_TOUCH and/or KEEP verilog annotations to fix this)
<GitHub178>
[artiq] jordens commented on issue #591: @whitequark Is this more difficult than adding a few more passes? https://git.io/vXb82
<GitHub59>
[artiq] whitequark commented on issue #591: @jordens The fix in the phaser branch was completely different, in fact it didn't involve adding passes at all (but making the analyses more precise); this requires migrating 2.x to LLVM 3.9.... https://git.io/vXb8x
<GitHub8>
[migen] whitequark pushed 1 new commit to master: https://git.io/vXbRq
<GitHub8>
migen/master a3cc612 whitequark: fhdl.verilog: escape names not starting with [a-zA-Z_].
<GitHub168>
[migen] whitequark pushed 1 new commit to master: https://git.io/vXbEH
<GitHub168>
migen/master c5ee158 Ivan Uvarov: add platform file for DE0-CV
<GitHub110>
[artiq] whitequark commented on issue #622: @dleibrandt The primary problem in your case is that you haven't marked `t` as kernel invariant. Once this is done, the `pulse` and `pulse_mu` variants generate exactly identical code.... https://git.io/vXbuE
mumptai_ has quit [Quit: Verlassend]
mumptai has joined #m-labs
<GitHub95>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vXbgJ
<GitHub129>
[artiq] whitequark commented on issue #622: @dleibrandt To help debug these issues, commit f5cca6b includes a pass that automatically detects attributes that may be marked kernel invariant:... https://git.io/vXbgT
<GitHub30>
[artiq] whitequark commented on issue #622: @dleibrandt To help debug these issues, commit f5cca6b includes a pass that automatically detects attributes that may be marked kernel invariant:... https://git.io/vXbgT
<GitHub90>
[artiq] whitequark commented on issue #622: @dleibrandt To help debug these issues, commit f5cca6b includes a pass that automatically detects attributes that may be marked kernel invariant:... https://git.io/vXbgT
<GitHub75>
[artiq] whitequark commented on issue #622: @dleibrandt To help debug these issues, commit f5cca6b includes a pass that automatically detects attributes that may be marked kernel invariant:... https://git.io/vXbgT
unknownhorizonsd has joined #m-labs
sb0 has joined #m-labs
unknownhorizonsd has quit [K-Lined]
<GitHub100>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vXbV4
<GitHub52>
artiq/release-2 ec645d3 whitequark: coredevice.dds: work around the round(numpy.float64()) snafu.
<sb0>
whitequark, i don't want to be dealing with signals that have names that are not valid identifiers.
<whitequark>
sb0: what's the problem with that?
<sb0>
for one this will cause problems with any future VHDL backend
<sb0>
and generally this is unwarranted complexity
<whitequark>
that's not exactly a complex patch
<sb0>
the patch itself is not complex as you point out, but who knows if EDA tools deal with the extended names correctly etc.
<whitequark>
also, VHDL also has the \ thing
<sb0>
why do you want to use it?
<whitequark>
I don't, there's a guy here who is learning migen and he complained. so I fixed that
mumptai has quit [Quit: Verlassend]
<whitequark>
I suppose moving the regexp into Signal() is also acceptable but I see no real improvement
<sb0>
there will be problems elsewhere if he starts using invalid identifiers.
<whitequark>
where?
<sb0>
create a subsignal with a non-valid identifier in migen.build, then python will complain
<sb0>
and doing that is generally just asking for trouble.
<whitequark>
okay, that's a better argument
<sb0>
in fact python won't complain, it will create an object with the invalid identifier, but you can only access it with getattr()
<sb0>
the regular access is SyntaxError
<whitequark>
I wouldn't strictly call that broken but it's somewhat unergonomic
<sb0>
and seriously, EDA tools break often enough when you're not using gadgets, and \\ brings nothing to the table but is likely to run poorly-tested code paths
<whitequark>
well in that case I could simply change the patch to replace such characters with their hex codes or something
<whitequark>
to avoid \. though I am not convinced that it will be widely broken anyway
<whitequark>
not handling escaping properly, especially when the target language supports it well, is sloppy
<sb0>
the names are normally extracted from python.
<sb0>
which already has those constraints
<whitequark>
fine.
<sb0>
in the #622, how is self.t a kernel invariant? set_time_kernel writes it
<whitequark>
that's with the set_time
<whitequark>
with set_time_kernel it cannot be a kernel invariant, I guess I was unclear
<whitequark>
the reason LLVM doesn't optimize it is because of aliasing
<whitequark>
hm
<sb0>
well his example was unclear
<whitequark>
actually, I just thought of a way to optimize attribute accesses *much* better
<sb0>
set_time is not useful
<whitequark>
we might be able to even avoid the need for specifying kernel_invariant sometimes
<whitequark>
and the example above should just work, if I'm thinking this right
<sb0>
the example is: "for t in [20*us, 15*us, 10*us, 5*us, 2*us, 1*us]: pulse(t)"
<whitequark>
ohh
<whitequark>
that needs loop unrolling
<sb0>
or pre-computing the list in machine units as David is doing
<whitequark>
#516 I think
<whitequark>
sure
<whitequark>
#516 would allow further optimization
<sb0>
unrolling will hit limits when the list is long
<GitHub57>
[artiq] sbourdeauducq commented on issue #622: Kernel invariants won't actually help here, ``t`` is not one when ``set_time_kernel`` is used. https://git.io/vXbKz
<bb-m-labs>
build #1100 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1100 blamelist: whitequark <whitequark@whitequark.org>, Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs>
build forced [ETA 32m49s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
ERROR: Could not find a match for CheckLiteral Directive (/var/lib/buildbot/slaves/debian-stretch-amd64-1/artiq/build/artiq/test/lit/embedding/syscall_flags.py:9 Literal: '; Function Attrs: nounwind')
<rjo>
whitequark: re 591: you can use phaser before the master merge. or try some DDS code in release-2 that looks similar to the phaser code. AFAICT it should also exhibit the problem.
<rjo>
whitequark: when you were playing with the IR code last time (llvm 3.8), adding the passes seemed to be a valid fix or work-around. IMHO that would help a lot in release-2.
<sb0>
rjo, yes, the DDS phase modes will have a problem with DMA.
<sb0>
how is that handled in phaser?
<rjo>
sb0: i think some of the attribute changes broke the constraints. it doesn't find the sys_clk sometimes..
<rjo>
sb0: only phase coherent mode is a problem. the other modes are fine.
<rjo>
sb0: i would implement phase coherent mode with a reference oscillator that can be used to do coherent updates relative that one reference frequency. afaict that covers the lab use cases.
<sb0>
bb-m-labs, force build --branch=release-2 artiq
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<sb0>
rjo, why not multiply like the C code does right now?
<sb0>
whitequark, when rewriting the dds code, can you consider how phase modes are going to work with DMA?
<GitHub187>
[artiq] sbourdeauducq commented on issue #623: ...on master, but passes on release-2. https://git.io/vXbDI
<GitHub48>
[artiq] sbourdeauducq closed issue #623: Increase RTIO FIFO depths in class NIST_CLOCK https://git.io/vXdJy
<GitHub147>
[artiq] sbourdeauducq commented on issue #623: So this will stay in release-2 and be available with 2.1 unless we have problems with it again, and will not be in 3.x. https://git.io/vXbDa