Friday, 2018-06-08

*** tpb has joined #vtr-dev00:00
*** digshadow has joined #vtr-dev02:44
*** digshadow has quit IRC05:06
*** digshadow has joined #vtr-dev07:24
*** digshadow has quit IRC09:17
mithrokem_: Morning!13:52
kem_mithro: Hey13:59
kem_mithro: Did you see the updates on
tpbTitle: How to model "mutually exclusive" fan out in a rr_graph.xml · Issue #351 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrokem_: Not yet, 45 emails to go through this morning :-P14:01
mithrokem_: Not sure I understand vaughn's description14:53
kem_mithro: It's similar to the idea I proposed earlier. You would introduce a 'special' node in the RR graph which represents the exclusivity of all the related edges14:55
kem_mithro: The key change is that we mark that node as not-re-expandable14:55
kem_mithro: within VPR14:55
mithrokem_: I don't really know what "re-expandable" means :-P14:56
kem_mithro: So in standard graph path finding you have a priority-queue/heap of nodes which are being explored14:57
kem_mithro: The VPR router routes one connection (driver/sink pin pair) at a time14:57
kem_mithro: If you have a fanout > 1 net, you put the nodes previously used to route connections of the same net back onto the heap14:58
mithrodaveshah: ping - I'm kind of stuck with figuring out why the verification doesn't work -- I tried creating a bunch of smaller LUT tests...14:58
kem_mithro: Allowing the router to 're-expand' from the routing used by existing connections14:59
daveshahmithro: the first step is to make sure that arachne->asc->hlc->bit->verilog is working14:59
kem_mithro: The result is that you get net routing that is more tree-like, instead of star like, which is better for wirelength/timing etc15:00
kem_mithro: The problem with the mutually exclusive edges is that it isn't legal to re-expand through some of the edges. Adding the dummy edge and not re-expanding it ensures that only one connection of a given net will use any of the exclusive edges.15:01
kem_mithro: *dummy node15:01
kem_mithro: The standard negotiated congestion algorithm can then handle any inter-net routing conflicts in the standard way15:02
mithrokem_: Okay, still don't quite understand but if your happy with it :-P15:05
kem_mithro: We think it should work. We can also discuss at the VTR meeting next week.15:06
mithrokem_: Okay15:07
mithrokem_: I'm going to send a WIP pull request for the ice40 HLC stuff -- I'm not really happy with it yet, but wanted to get your feedback on the direction it should go in15:08
kem_mithro: Sounds good15:08
mithrokem_: There are a couple of things it adds15:08
mithrokem_: One of the big things is supporting metadata on lots of things15:09
*** digshadow has joined #vtr-dev15:20
mithrokem_: BTW - What is the status of the clock routing changes? It looked like they may have been merged?16:07
*** digshadow has quit IRC16:23
*** digshadow has joined #vtr-dev16:28
*** digshadow has quit IRC16:53
*** digshadow has joined #vtr-dev17:30
kem_mithro: Yes, routing clocks over the inter-block routing network should now be supported.18:04
kem_mithro: However the work on actually modelling proper clock networks is still on-going18:04
mithrokem_: Cool18:04
mithrodaveshah: As far as I can tell logic equivalence check for the iceblink works for arachne pnr18:11
daveshahmithro: good18:11
daveshahWhat if you go through a HLC step?18:11
mithrodaveshah: Welp... icebox_asc2hcl and then icebox_hcl2asc fails...18:15
daveshahWell there's ya problem then18:15
tpbTitle: Snippet | IRCCloud (at
mithrodaveshah: Well - a problem... not necessarily _the_ problem18:17
daveshahmithro: have you attempted to contact @rultz, who did the HLC stuff in the first place, BTW?18:17
mithrodaveshah: Nope!18:17
daveshahNo idea what's going on there18:17
daveshahmithro: looks like he hasn't done fpga stuff for a while but is working on voctoknopf now18:19
mithrodaveshah: Oh - that is kind of cool :-18:19
daveshahYeah, though you'd be interested in that18:20
mithrodaveshah: Probably just easier for me to fix the issue :-)18:22
daveshahmithro: sure, but might be worth reaching out to him if he wants to help18:22
daveshahGiven he wrote it18:22
mithrookay, fair enough18:22
daveshahHe might also like to know that someone is actually using it now :P18:23
mithrodaveshah: Okay - it looks like going arachne -> asc -> hlc -> asc -> verilog passes an equivalence check...18:34
daveshahmithro: unless it's a subtle bug in hlc that only something very odd triggers I'd say this sounds like a vpr issue18:37
mithrodaveshah: It is most likely an issue in my HLC generation - but I can't figure out what18:37
mithroI was trying to check the checker working because it had a testbenhc18:38
*** digshadow has quit IRC18:49
mithrodaveshah: Also assumes I haven't screwed up testing arachne -> asc -> hlc -> asc -> verilog...18:49
daveshahmithro: if it's what you just pushed, looks OK to me18:51
mithrodaveshah: This -> ?18:51
tpbTitle: ice40: Make the arachne-pnr run an equivalence check. · mithro/[email protected] · GitHub (at
mithrodaveshah: Guess next step is to write a testbench so I can actually run the iceblink and look at the external state?18:52
daveshahmithro: you can use the yosys "sim" command if you cba with a testbench18:53
daveshahJust tell it which net is clock18:53
daveshahWorks with blif too18:53
mithrodaveshah: Any idea why in the equivalence vcd output all the \miter.\gate\nXXX always have 0 ?18:54
daveshahNot really sure of the innards of the equiv check18:54
mithrodaveshah: I don't see a "sim" command at ?18:56
tpbTitle: Yosys Open SYnthesis Suite :: Documentation (at
mithroHrm.. it seems that page is out of date....18:56
tpbTitle: New: Simulation within Yosys : yosys (at
daveshahDocs might be for the 0.7 "stable" version of Yosys. The new 0.8 release will be imminent18:57
mithrolooks like something like "sim top -clock clk -n 10000 -vcd out.sim.vcd" or something?18:58
daveshahYep that sounds about right18:58
mithrodaveshah: They are all coming out as "don't care" ?19:03
mithroor what ever "x" is19:03
daveshahYes, you may need to enable zero initialisation19:03
mithrodaveshah: Yeah - already tried with -zinit19:03
daveshahPost your yosys script?19:04
mithroyosys -p "sim -clock clk -n 1000 -vcd out.sim.vcd -zinit top" build-ice40-top-routing-virt-HX1K/example_bitstream.v19:04
mithro        include all nets in VCD output, nut just those with public names19:05
mithrodaveshah: There is nothing assigning the clk input to the clk wire....19:06
mithroIn the output verilog...19:07
daveshahOh, that sounds odd19:08
mithroIs there an implicit assignment or something? - I'm seeing the same in the arachnne versions19:08
daveshahCan you post the output verilog? I don't think I've seen this before. Shouldn't be anything like that19:09
tpbTitle: Ubuntu Pastebin (at
daveshahmithro: the two will be connected in Yosys19:11
mithrodaveshah: okay - but that file seems to not sim properly with yosys?19:12
daveshahNo idea19:12
daveshahUse the `show` command to see what the circuit looks like19:12
mithrodaveshah: Oh -we need to do prep -top top19:13
daveshahMakes sense19:13
mithrothats better!19:13
mithrodaveshah: The issue seems to be this line -> assign n30 = /* LUT    7  3  7 */ n2 ? 1'b0 ? n4 ? n12 ? 1'b0 : 1'b1 : n12 ? 1'b1 : 1'b0 : n4 ? 1'b1 : 1'b0 : n4 ? 1'b1 : 1'b0;19:21
daveshahWell, I'd compare with the arachne bitstream Verilog19:22
mithroApparently that is         out = in_1 ^ (in_0 & in_2 & in_3)19:25
mithrodaveshah: This should give me enough to figure out what is going on, thanks!19:28
daveshahHopefully you can work it out19:28
mithrodaveshah: Yeah - it's probably the LUT rotation stuff19:32
mithrodaveshah: Any idea why the eblif and blif output would have different ordering of the LUT pins?21:36

Generated by 2.13.1 by Marius Gedminas - find it at!