<GitHub29>
[artiq] sbourdeauducq commented on issue #644: Maintaining features takes work, especially when there are major code modifications or rewrites, like those involved in the ARTIQ-3 runtime. The test mode was not explicitly funded by NIST, it's just something that I had done mostly to have a way to access DDSes at a low-level; back then the ARTIQ-Python compiler was not as powerful and some of the DDS logic had to be done in C and built into the runti
<GitHub99>
[artiq] sbourdeauducq commented on issue #773: TTL devices do RTIO replace, so that e.g. ``.on()`` followed by ``.off()`` is equivalent to just ``.off()``. Following a mailing list discussion, this feature ought to be kept (https://ssl.serverraum.org/lists-archive/artiq/2016-November/001052.html). But it is enabled at the RTIO device level for all RTIO operations to that device, and cannot currently be applied to certain operations only. https:
<GitHub20>
[artiq] sbourdeauducq commented on issue #773: Having some filtering (e.g. per address) on what RTIO operations have ``replace`` enabled is doable, but it will take some work and increase FPGA resource usage a bit. https://github.com/m-labs/artiq/issues/773#issuecomment-312770668
<GitHub176>
[artiq] sbourdeauducq commented on issue #773: TTL devices do RTIO replace, so that e.g. ``.on()`` followed by ``.off()`` is equivalent to just ``.off()``. Following a mailing list discussion, this feature ought to be kept (https://ssl.serverraum.org/lists-archive/artiq/2016-November/001052.html). But it is enabled at the RTIO channel level for all RTIO operations to that channel, and cannot currently be applied to certain operations only. ht
<GitHub79>
[artiq] sbourdeauducq commented on issue #773: Having some filtering (e.g. per address) on what RTIO operations in one channel have ``replace`` enabled is doable, but it will take some work and increase FPGA resource usage a bit. https://github.com/m-labs/artiq/issues/773#issuecomment-312770668
rohitksingh_work has joined #m-labs
Thaong has quit [Ping timeout: 260 seconds]
<mithro>
So, I've seen a lot of work recently about "resetless optimisations" - I was wondering how things being resetless helps improve FPGA utilization / optimisation?
<attie>
you don't need to route the reset signals, I would guess
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 246 seconds]
<mithro>
Hi everyone - The Linux.conf.au 2019 talk / tutorial / miniconf proposals are now open - https://linux.conf.au/proposals/ -- I'm thinking of putting together a miniconf for Migen / LiteX
<GitHub98>
[migen] enjoy-digital pushed 2 new commits to master: https://git.io/vQzzh
<GitHub98>
migen/master d8b55c7 Florent Kermarrec: genlib/record: replace leave_out param with keep and omit params in Record.connect...
<GitHub98>
migen/master 2b063a3 Florent Kermarrec: genlib/record: add "do" to reserved_keywords
<GitHub46>
[artiq] jordens commented on issue #771: The positive maximum of a signed integer is one less (`(1 << N - 1) - 1`) than the negative maximum (`(1 << N - 1)`). This is intrinsic and you will also find it with such fine hardware as National Instruments DACs. Currently, scaling involves multiplication with a power of two. Changing the behavior would make that calculation more expensive. https://github.com/m-labs/artiq/issues/771#issuecomment-31280
<GitHub141>
artiq/master 2910b1b Florent Kermarrec: artiq/gateware/rtio/dma: replace leave_out with omit in Record.connect
<bb-m-labs>
build #1600 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1600 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<rjo>
_florent_: you need to bump the migen build dependency in artiq:conda/artiq-dev/meta.yml
<GitHub87>
[artiq] jordens commented on issue #771: The positive amplitude of a signed integer is one less (`(1 << N - 1) - 1`) than the negative amplitude (`(1 << N - 1)`). This is intrinsic and you will also find it with such fine hardware as National Instruments DACs. Currently, scaling involves just a simple multiplication with a power of two. Changing the behavior would make that calculation more expensive. You have the choice. https://github.com/m-l
<GitHub12>
[artiq] jordens commented on issue #771: This is not just gateware. If there was one more bit, it would make each of the four coefficients on that spline one **byte** wider, from the kernel support, all the way down into the gateware. I'd much rather change the scaling factor. https://github.com/m-labs/artiq/issues/771#issuecomment-312866701
<GitHub148>
[artiq] jordens commented on issue #771: @jbqubit no. amplitude1/2 have the same issue. just there the scaling factor is already dense and therefore I moved the problem from "1.0" to "1.0 + epsilon" and thus "out of your zone of curiosity".... https://github.com/m-labs/artiq/issues/771#issuecomment-312870674
<GitHub48>
[artiq] sbourdeauducq commented on issue #771: We can also test that the floats passed are in the range ``[-1.0;1.0[``? (or ``]-1.0;1.0[`` if it makes it easier to test with any applicable bit twiddling hack) https://github.com/m-labs/artiq/issues/771#issuecomment-312872480
<GitHub42>
[artiq] jordens commented on issue #771: I don't think testing will help. It does give the user some error message. But it is more expensive than changing the scaling factor and it fails as soon as someone becomes curious and expects those tests to be applied to the spline outputs as well. https://github.com/m-labs/artiq/issues/771#issuecomment-312873239
<GitHub36>
[artiq] jordens commented on issue #774: @jbqubit `ttl.pulse()` are two events. `sawg.smooth()` is one event. With one event you can only ever get a replacement or a collision. With two events you can also get sequence errors. you can not compare those two cases.... https://github.com/m-labs/artiq/issues/774#issuecomment-312873824
rohitksingh_work has quit [Read error: Connection reset by peer]