00:14 <litghost> hackerfoo: Is this BRAM or LUT-RAM?

00:14 <litghost> hackerfoo: LUT-RAM I expect to work in autosim

00:15 <litghost> hackerfoo: BRAM lacks sim models stil

00:15 <litghost> l

00:15 <hackerfoo> I think it was both. I'll check in a minute.

00:20 <hackerfoo> I just tried dram_test_64x1d:

00:22 <litghost> hackerfoo: The 'x' on the write_enable indicates a problem somewhere

00:27 <hackerfoo> It's probably because rx=x

00:30 <hackerfoo> Nevermind, that only affects the LEDs.

00:55 <hackerfoo> I don't understand why nrst doesn't affect anything. I don't trust the simulation.

10:00 <sf-slack2> <acomodi> litghost, mithro: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/599 this is the zero-capacity PR upstream

10:00 <tpb> Title: check_rr_graph: make zero capacity nodes valid and not drawn. by acomodi · Pull Request #599 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

13:14 <sf-slack2> <acomodi> litghost, mithro: if all the small patches get merged upstream the only issue preventing upstream VTR to be used in SymbiFlow is the `adjacency check` which now is treated as an error

13:56 <sf-slack2> <acomodi> litghost, mithro: can you provide some insights on the small PRs I have opened on VTR upstream? https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/599 and https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/600

13:56 <tpb> Title: check_rr_graph: make zero capacity nodes valid and not drawn. by acomodi · Pull Request #599 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

14:02 <sf-slack2> <tmichalak> @mithro: @litghost: I think we are really close to having a stable prjxray database generation. Apart from dedicated PRs with the remaining fixes I also created a DNM PR with all of them to see if something else comes up before all other PRs get merged. After the merges the only thing left to do is re-enabling the harness generation which was disabled as it would fail due to missing bit definitions. The restored

14:02 <sf-slack2> harness for Artix should just work. For Zynq however, there is a small change required in the create_design_json script due to some extra bits I am writing about here: https://github.com/SymbiFlow/prjxray/issues/746#issuecomment-490499100 I added a PR (https://github.com/SymbiFlow/prjxray/pull/851) which basically adds a white listing mechanism per architecture in order to successfully pass the generation of design.json

14:02 <sf-slack2> despite the fact that the white listed bits are not in the database. I tested it along with the xc7frames2bit PR in symbiflow-arch-defs and the counter example on the Zybo board worked.

14:02 <tpb> Title: unknown bit in zynq7 harness · Issue #746 · SymbiFlow/prjxray · GitHub (at github.com)

16:06 <sf-slack2> <acomodi> mode selection feature merged! :slightly_smiling_face:

16:08 <litghost> acomodi: Yay!