03:50 <sb0> rjo, do you have a preference for bitonic sort over odd–even mergesort?

03:50 <sb0> in fpga implementation that is

05:49 <sb0> those sorting networks would be useful to implement scalable rtio conflict resolution (replace)

06:44 <GitHub123> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/8fea3614127162a51df9a6455ae0af67a933e3e7

06:44 <GitHub123> artiq/master 8fea361 Sebastien Bourdeauducq: firmware: always use 8 characters to abbreviate git commit hashes

07:07 <bb-m-labs> build #622 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/622

07:20 <bb-m-labs> build #493 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/493

07:20 <bb-m-labs> build #1559 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1559

09:51 <rjo> sb0: i am no expert. bitonic seems to be slightly larger but has perfectly balanced logic levels. http://dbis.cs.tu-dortmund.de/cms/en/publications/2012/sorting-networks/sorting-networks.pdf

10:14 <sb0> are we going to do non-realtime i2c over drtio?

10:21 <GitHub36> [artiq] jordens pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/8fea36141271...424b2bfbd864

10:21 <GitHub36> artiq/master 424b2bf Robert Jordens: rtio: describe rio and rio_phy domains a bit more

10:21 <GitHub36> artiq/master 219dfd8 Robert Jordens: rtio: add one register level for rio and rio_phy resets...

10:21 <rjo> i don't think so.

10:22 <rjo> sb0: on 219dfd8, let me know if you see a nicer way to do this.

10:22 <rjo> bb-m-labs: force build --props=package=artiq-kc705-phaser artiq-board

10:22 <bb-m-labs> build forced [ETA 17m31s]

10:22 <bb-m-labs> I'll give a shout when the build finishes

10:31 <sb0> rjo, does this really help with timing?

10:31 <sb0> the AsyncResetSynchronizer output is already a register

10:32 <sb0> which is driven asynchronously, so the AsyncResetSynchronizer can be placed pretty much anywhere in the design

10:32 <sb0> and its output needs to be distributed to all reset inputs in the domain.

10:33 <sb0> now you are just adding another register at the output, that also can be placed pretty much anywhere, and whose output has the same load

10:33 <sb0> your strategy is to have vivado duplicate that second register?

10:35 <sb0> rjo, maybe put the intermediate clock domain, the AsyncResetSynchronizer and the register into a small module?

10:35 <sb0> then instantiate twice instead of the original two AsyncResetSynchronizer

10:48 <bb-m-labs> build #623 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/623

11:01 <bb-m-labs> build #624 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/624

11:09 <rjo> sb0: yes. but the amount of code is about the same.

11:10 <rjo> sb0: and don't the CDs have to be globally unique?

11:13 <bb-m-labs> build #494 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/494 blamelist: Robert Jordens <rj@m-labs.hk>

11:13 <bb-m-labs> build #1560 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1560

11:14 <sb0> rjo, no, the CDs don't have to be globally unique

11:15 <rjo> ah right i remember the example

11:15 <sb0> when there is a CD conflict at a node in the module tree, each sub-module gets its own version of the CD

11:16 <sb0> geez https://stackoverflow.com/questions/33173235/macro-that-generates-a-function-with-arguments-determined-by-the-macro

11:17 <sb0> okay I'll just copy-paste...

11:17 <rjo> sb0: also, i'd like to implement the false path to the first register of the asyncresetsync. (set_false_path -to [get_cells rst_meta_reg]). i am unsure where to inject that without causing to much trouble.

11:17 <sb0> instead of using macros

11:17 <sb0> rjo, is there a way to do it with verilog pseudocomments?

11:18 <sb0> doing it cleanly is otherwise impossible without major changes in migen/migen.build

11:19 <sb0> well. maybe you can look through the design in migen.build, spot the AsyncResetSynchronizers, and add those commands to the script

11:19 <sb0> actually that should be simple enough

13:10 <rjo> sb0: no pseudocomments afaict.

13:11 <rjo> sb0: ok to merge the resetless-signals branch in migen? happy to revert it again if there are problems.

14:21 <rjo> sb0: that A.R.S. get's lowered really late. and the actual register is only created then (in verilog.convert()). after that, the lowered specials are forgotten...

14:34 <rjo> ahaaa. there are user-defined attributes. that's not too bad.

17:22 <sb0> rjo, the command needs to be on the FD instance?

17:22 <sb0> if you can have the command on signals then you can get the signal before verilog.convert()