| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has joined #vtr-dev | 02:44 | |
| *** digshadow has quit IRC | 05:06 | |
| *** digshadow has joined #vtr-dev | 07:24 | |
| *** digshadow has quit IRC | 09:17 | |
| mithro | kem_: Morning! | 13:52 |
|---|---|---|
| kem_ | mithro: Hey | 13:59 |
| kem_ | mithro: Did you see the updates on https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/351 | 14:00 |
| tpb | Title: How to model "mutually exclusive" fan out in a rr_graph.xml · Issue #351 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 14:00 |
| mithro | kem_: Not yet, 45 emails to go through this morning :-P | 14:01 |
| mithro | kem_: Not sure I understand vaughn's description | 14: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 edges | 14:55 |
| kem_ | mithro: The key change is that we mark that node as not-re-expandable | 14:55 |
| kem_ | mithro: within VPR | 14:55 |
| mithro | kem_: I don't really know what "re-expandable" means :-P | 14:56 |
| kem_ | mithro: So in standard graph path finding you have a priority-queue/heap of nodes which are being explored | 14:57 |
| kem_ | mithro: The VPR router routes one connection (driver/sink pin pair) at a time | 14: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 heap | 14:58 |
| mithro | daveshah: 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 connections | 14:59 |
| daveshah | mithro: the first step is to make sure that arachne->asc->hlc->bit->verilog is working | 14: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 etc | 15: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 node | 15:01 |
| kem_ | mithro: The standard negotiated congestion algorithm can then handle any inter-net routing conflicts in the standard way | 15:02 |
| mithro | kem_: Okay, still don't quite understand but if your happy with it :-P | 15:05 |
| kem_ | mithro: We think it should work. We can also discuss at the VTR meeting next week. | 15:06 |
| mithro | kem_: Okay | 15:07 |
| mithro | kem_: 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 in | 15:08 |
| kem_ | mithro: Sounds good | 15:08 |
| mithro | kem_: There are a couple of things it adds | 15:08 |
| mithro | kem_: One of the big things is supporting metadata on lots of things | 15:09 |
| *** digshadow has joined #vtr-dev | 15:20 | |
| mithro | kem_: BTW - What is the status of the clock routing changes? It looked like they may have been merged? | 16:07 |
| *** digshadow has quit IRC | 16:23 | |
| *** digshadow has joined #vtr-dev | 16:28 | |
| *** digshadow has quit IRC | 16:53 | |
| *** digshadow has joined #vtr-dev | 17: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-going | 18:04 |
| mithro | kem_: Cool | 18:04 |
| mithro | daveshah: As far as I can tell logic equivalence check for the iceblink works for arachne pnr | 18:11 |
| daveshah | mithro: good | 18:11 |
| daveshah | What if you go through a HLC step? | 18:11 |
| mithro | daveshah: Welp... icebox_asc2hcl and then icebox_hcl2asc fails... | 18:15 |
| daveshah | Well there's ya problem then | 18:15 |
| mithro | https://www.irccloud.com/pastebin/nn2e1znL/ | 18:17 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 18:17 |
| mithro | daveshah: Well - a problem... not necessarily _the_ problem | 18:17 |
| daveshah | mithro: have you attempted to contact @rultz, who did the HLC stuff in the first place, BTW? | 18:17 |
| mithro | daveshah: Nope! | 18:17 |
| daveshah | No idea what's going on there | 18:17 |
| daveshah | mithro: looks like he hasn't done fpga stuff for a while but is working on voctoknopf now | 18:19 |
| mithro | daveshah: Oh - that is kind of cool :- | 18:19 |
| daveshah | Yeah, though you'd be interested in that | 18:20 |
| daveshah | *thought | 18:20 |
| mithro | daveshah: Probably just easier for me to fix the issue :-) | 18:22 |
| daveshah | mithro: sure, but might be worth reaching out to him if he wants to help | 18:22 |
| daveshah | Given he wrote it | 18:22 |
| mithro | okay, fair enough | 18:22 |
| daveshah | He might also like to know that someone is actually using it now :P | 18:23 |
| mithro | daveshah: Okay - it looks like going arachne -> asc -> hlc -> asc -> verilog passes an equivalence check... | 18:34 |
| daveshah | mithro: unless it's a subtle bug in hlc that only something very odd triggers I'd say this sounds like a vpr issue | 18:37 |
| mithro | daveshah: It is most likely an issue in my HLC generation - but I can't figure out what | 18:37 |
| mithro | I was trying to check the checker working because it had a testbenhc | 18:38 |
| *** digshadow has quit IRC | 18:49 | |
| mithro | daveshah: Also assumes I haven't screwed up testing arachne -> asc -> hlc -> asc -> verilog... | 18:49 |
| daveshah | mithro: if it's what you just pushed, looks OK to me | 18:51 |
| mithro | daveshah: This -> https://github.com/mithro/symbiflow-arch-defs/commit/730e4a17947400f881d4cb6acf1f6fbdcb0f7832 ? | 18:51 |
| tpb | Title: ice40: Make the arachne-pnr run an equivalence check. · mithro/symbiflow-arch-defs@730e4a1 · GitHub (at github.com) | 18:51 |
| daveshah | Yeap | 18:51 |
| mithro | daveshah: Guess next step is to write a testbench so I can actually run the iceblink and look at the external state? | 18:52 |
| daveshah | mithro: you can use the yosys "sim" command if you cba with a testbench | 18:53 |
| daveshah | Just tell it which net is clock | 18:53 |
| daveshah | Works with blif too | 18:53 |
| mithro | daveshah: Any idea why in the equivalence vcd output all the \miter.\gate\nXXX always have 0 ? | 18:54 |
| daveshah | No | 18:54 |
| daveshah | Not really sure of the innards of the equiv check | 18:54 |
| mithro | daveshah: I don't see a "sim" command at http://www.clifford.at/yosys/documentation.html ? | 18:56 |
| tpb | Title: Yosys Open SYnthesis Suite :: Documentation (at www.clifford.at) | 18:56 |
| mithro | Hrm.. it seems that page is out of date.... | 18:56 |
| daveshah | https://www.google.at/amp/s/amp.reddit.com/r/yosys/comments/6ulm3m/new_simulation_within_yosys/ | 18:56 |
| tpb | Title: New: Simulation within Yosys : yosys (at www.google.at) | 18:56 |
| daveshah | Docs might be for the 0.7 "stable" version of Yosys. The new 0.8 release will be imminent | 18:57 |
| mithro | looks like something like "sim top -clock clk -n 10000 -vcd out.sim.vcd" or something? | 18:58 |
| daveshah | Yep that sounds about right | 18:58 |
| mithro | daveshah: They are all coming out as "don't care" ? | 19:03 |
| mithro | or what ever "x" is | 19:03 |
| daveshah | Yes, you may need to enable zero initialisation | 19:03 |
| mithro | daveshah: Yeah - already tried with -zinit | 19:03 |
| daveshah | Post your yosys script? | 19:04 |
| mithro | yosys -p "sim -clock clk -n 1000 -vcd out.sim.vcd -zinit top" build-ice40-top-routing-virt-HX1K/example_bitstream.v | 19:04 |
| mithro | include all nets in VCD output, nut just those with public names | 19:05 |
| mithro | :-P | 19:05 |
| mithro | daveshah: There is nothing assigning the clk input to the clk wire.... | 19:06 |
| mithro | In the output verilog... | 19:07 |
| daveshah | Oh, that sounds odd | 19:08 |
| mithro | Is there an implicit assignment or something? - I'm seeing the same in the arachnne versions | 19:08 |
| daveshah | Can you post the output verilog? I don't think I've seen this before. Shouldn't be anything like that | 19:09 |
| mithro | daveshah: https://paste.ubuntu.com/p/zGbkGDdw4c/ | 19:10 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 19:10 |
| daveshah | mithro: the two will be connected in Yosys | 19:11 |
| mithro | daveshah: okay - but that file seems to not sim properly with yosys? | 19:12 |
| daveshah | No idea | 19:12 |
| daveshah | Use the `show` command to see what the circuit looks like | 19:12 |
| mithro | daveshah: Oh -we need to do prep -top top | 19:13 |
| daveshah | Makes sense | 19:13 |
| mithro | thats better! | 19:13 |
| mithro | daveshah: 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 |
| daveshah | Well, I'd compare with the arachne bitstream Verilog | 19:22 |
| mithro | Apparently that is out = in_1 ^ (in_0 & in_2 & in_3) | 19:25 |
| mithro | daveshah: This should give me enough to figure out what is going on, thanks! | 19:28 |
| daveshah | Hopefully you can work it out | 19:28 |
| mithro | daveshah: Yeah - it's probably the LUT rotation stuff | 19:32 |
| mithro | daveshah: Any idea why the eblif and blif output would have different ordering of the LUT pins? | 21:36 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!