| *** tpb has joined #vtr-dev | 00:00 | |
| digshadow | still having issues | 00:03 |
|---|---|---|
| digshadow | i'll post | 00:03 |
| digshadow | mithro: QED! | 00:27 |
| mithro | digshadow: YAY! | 00:27 |
| digshadow | two tests? | 00:27 |
| digshadow | trying other | 00:27 |
| mithro | Yeah iceinv and icelut | 00:28 |
| digshadow | second pased | 00:28 |
| mithro | \o/ | 00:31 |
| mithro | digshadow: Need to add arachne-pnr to the env it seems | 00:31 |
| digshadow | gotcha | 00:40 |
| mithro | iCE40 FPGAs have 8 global nets. Each global net can be driven directly from an IO pin. | 01:18 |
| mithro | I'm reading that as "Each global net can be *only* driven directly from an single IO pin" | 01:19 |
| digshadow | mithro: oh btw I did confirm that one of the cr2 I/Os are input only. CLK went to a dedicated clock pin, so that precluded it from being used as an output | 01:19 |
| awygle | mithro: it's... More complicated than that, iiuc | 02:13 |
| mithro | awygle: Oh? | 02:14 |
| awygle | There's two gbuf primitives | 02:15 |
| awygle | One sec.. | 02:15 |
| mithro | digshadow: This is a bit weird -- but it does look like '/' might be valid in vpr port names... | 02:17 |
| awygle | ah yeah, SB_GB and SB_GB_IO | 02:17 |
| awygle | so you can drive them from either a pin or from user logic | 02:17 |
| awygle | and iiuc the index-to-location mapping is different between SB_GB and SB_GB_IO | 02:18 |
| awygle | mithro: ^ | 02:18 |
| mithro | awygle: okay -- I'll worry about that bit later :-P | 02:22 |
| *** digshadow has quit IRC | 03:13 | |
| *** digshadow has joined #vtr-dev | 03:31 | |
| daveshah | mithro: it's worse even than that | 05:57 |
| mithro | daveshah: So - how do I fix that make check error? | 05:57 |
| daveshah | mithro: hard enable global buffer 0's padin and wire every clock to global 0 | 05:58 |
| daveshah | But when you get to real stuff, it's a lot more icky | 05:58 |
| mithro | daveshah: I think I have things working | 05:58 |
| daveshah | OK, just woken up and not at pc. Can you post hlc? | 05:59 |
| mithro | ERROR: Failed to import cell $techmap\gate.$procdff$7 (type $dff) to SAT database. | 05:59 |
| daveshah | That sounds like an issue in the SAT script | 05:59 |
| daveshah | Can you add a clk2fflogic command after prep or proc? | 05:59 |
| mithro | daveshah: I don't see a prep or proc in the EQUIV_CHECK_SCRIPT ? | 06:00 |
| mithro | EQUIV_CHECK_SCRIPT = rename top gate; read_verilog $(SOURCE).v; rename top gold; hierarchy; proc; miter -equiv -flatten -ignore_gold_x -make_outputs -make_outcmp gold gate miter; sat -verify-no-timeout -timeout 20 -prove trigger 0 -show-inputs -show-outputs miter | 06:01 |
| daveshah | After proc; | 06:01 |
| daveshah | Add clk2fflogic; | 06:01 |
| mithro | daveshah: make check passes on both iceinv and icelut | 06:01 |
| daveshah | Sure, but they are combinational | 06:01 |
| mithro | Oh wait - I'm just blind :-P | 06:01 |
| daveshah | Nvm, don't think that was right | 06:02 |
| mithro | daveshah: Still same error it seems... | 06:02 |
| daveshah | Let me get the exact script arachne uses | 06:03 |
| daveshah | After the rename command, replace everything with: hierarchy; proc; miter -equiv -flatten -ignore_gold_x -make_outputs -make_outcmp gold gate miter; sat -verify-no-timeout -timeout 20 -seq 5 -set-at 1 gold 1 -prove trigger 0 -prove-skip 1 -show-inputs -show-outputs miter | 06:06 |
| daveshah | But it may still fail because of reset issues. I need to look at it properly | 06:07 |
| mithro | ERROR: Failed to parse lhs set expression `gold'. | 06:08 |
| mithro | EQUIV_CHECK_SCRIPT = rename top gate; read_verilog $(SOURCE).v; rename top gold; hierarchy; proc; miter -equiv -flatten -ignore_gold_x -make_outputs -make_outcmp gold gate miter; sat -verify-no-timeout -timeout 20 -seq 5 -set-at 1 gold 1 -prove trigger 0 -prove-skip 1 -show-inputs -show-outputs miter | 06:09 |
| daveshah | Replace `-set-at 1 gold 1` with `-set-at 1 in 1` | 06:10 |
| mithro | ERROR: Failed to parse lhs set expression `in'. | 06:13 |
| daveshah | Remove the `-set-at` expression, it doesn't work how I think it does | 06:15 |
| daveshah | So remove `-set-at 1 in 1` | 06:15 |
| mithro | Done! | 06:15 |
| mithro | QED! | 06:15 |
| daveshah | Oh awesome | 06:16 |
| mithro | Solving problem with 222 variables and 559 clauses.. -- SAT proof finished - no model found: SUCCESS! | 06:16 |
| daveshah | Sounds good | 06:16 |
| daveshah | Do you want to know how the global networks really work now? | 06:17 |
| mithro | daveshah: Trying `iceblink` now | 06:17 |
| mithro | iceblink QED! | 06:17 |
| mithro | Solving problem with 2835 variables and 7540 clauses.. -- SAT proof finished - no model found: SUCCESS! | 06:17 |
| mithro | I'm a bit worried that you have made everything pass with QED now :-P | 06:18 |
| daveshah | Well, change one of the HLC lut expressions or something and see if it breaks | 06:18 |
| daveshah | I realise that command only checks for 5 clock cycles | 06:21 |
| mithro | Hrm... I changed one of the LUTs and it's still QED :-/ | 06:21 |
| daveshah | mithro: ^ | 06:22 |
| daveshah | Add -tempinduct to the sat command to check for all clock cycles rather than just the first 5 | 06:22 |
| daveshah | But that may introduce other issues | 06:22 |
| daveshah | Testing designs with small dividers over finite clock cycles would be easiest | 06:22 |
| daveshah | iceblink doesn't actually do anything within just 5 clocks | 06:23 |
| mithro | Can we make it like 1000 cycles? | 06:23 |
| daveshah | Give it a go, that still won't do anything for iceblink unless you make the divider smaller | 06:24 |
| mithro | Change -seq 5 to -seq 1000 ? | 06:24 |
| daveshah | Yeap | 06:24 |
| mithro | So... How do I prove if this is working :-P -- i tried changing all the LUT values and it still doing QED... | 06:25 |
| mithro | btw - I've pushed all my stuff into the 4mcmaster branches | 06:26 |
| daveshah | Make the divider smaller! | 06:26 |
| mithro | localparam LOG2DELAY = 22; ? | 06:27 |
| daveshah | Yep | 06:27 |
| mithro | What value do you recommend? | 06:27 |
| daveshah | Take that down to say 6 or 8 | 06:27 |
| daveshah | With -seq 1000 | 06:27 |
| mithro | https://www.irccloud.com/pastebin/WK9FeFtQ/ | 06:43 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:43 |
| daveshah | mithro: No idea | 06:44 |
| daveshah | Sounds like HLC being weird | 06:44 |
| daveshah | Is that your error, or rlutz's? | 06:44 |
| mithro | My improvement of his error (which was just "ParseError") | 06:46 |
| daveshah | Do you have multiple connections to sp4_h_r_10? | 06:49 |
| daveshah | Or whatever its called in HLC | 06:49 |
| mithro | https://www.irccloud.com/pastebin/I8qiGs9T/ | 06:51 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:51 |
| mithro | daveshah: Looks like this problem | 06:52 |
| mithro | https://www.irccloud.com/pastebin/tPILzJhj/ | 06:52 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:53 |
| daveshah | Yes, that's not allowed in the ice40 bitstream | 06:53 |
| daveshah | Because they share configuration bits | 06:53 |
| mithro | I wonder how that needs to be represented in the rr_graph.... | 06:54 |
| daveshah | No idea | 06:55 |
| mithro | daveshah: https://github.com/mithro/icestorm/commit/09ca75bad7fce215fa03eadf9d189359d0f14b41 | 07:01 |
| tpb | Title: Improve error message. · mithro/icestorm@09ca75b · GitHub (at github.com) | 07:01 |
| daveshah | mithro: nice | 07:02 |
| mithro | daveshah: https://github.com/cliffordwolf/icestorm/pull/150 | 07:02 |
| tpb | Title: Improve error message. by mithro · Pull Request #150 · cliffordwolf/icestorm · GitHub (at github.com) | 07:02 |
| mithro | daveshah: I think if we can figure out how that should be represented in the rr_graph format, then we have working pnr? | 07:06 |
| daveshah | mithro: yeah, there are a few other issues that I think will come up as we go further too | 07:06 |
| daveshah | The main one I see is that the ice40 has 32 local tracks | 07:06 |
| daveshah | These are shared by the 32 LUT inputs, and CEN and reset if the latter two are not on global networks | 07:07 |
| daveshah | That may mean vpr will incorrectly pack some complex designs so they are unroutable. It's been a scourge of arachne, despite some attempts to deal with it | 07:08 |
| daveshah | But until you have promotion of reset and CEN to global networks, it will likely mean big designs like picorv32 need a few tries | 07:08 |
| mithro | daveshah: I can think of two ways to solve that | 07:10 |
| mithro | daveshah: If we push the local tracks back down into the tile, then the packer won't create a packing which uses too many local tracks | 07:11 |
| daveshah | mithro: will vpr be able to then swap then during routing? If not, you may get suboptimal routing as I don't know if all locals are equivalent | 07:12 |
| daveshah | That also relies on you knowing which reset/CEN signals are global before packing | 07:12 |
| mithro | daveshah: VPR also seems to have a lot of options around packing | 07:14 |
| daveshah | mithro: anyway, first step is to fix the rr_graph | 07:16 |
| mithro | Well, I think the first step is for me to go home to bed :-P | 07:17 |
| daveshah | Yeah sure | 07:19 |
| mithro | I need more brain power then I have at 15 past midnight to figure out how to represent this structure.... | 07:19 |
| mithro | daveshah: but I think we are extremely close | 07:21 |
| * mithro is walking home now | 07:21 | |
| daveshah | mithro: sure | 07:21 |
| daveshah | I think a small tweak to vpr will probably be needed, but not sure | 07:22 |
| mithro | daveshah: have to ask kem_ in the morning | 07:23 |
| *** digshadow has quit IRC | 09:14 | |
| mithro | kem_: Morning - is there a way to represent "mutually exclusive" edges in the rr_graph format? IE If you turn on edge A is means you can't turn on edge B or C? | 13:39 |
| kem_ | mithro: Seems like you guys are making progress! | 14:25 |
| kem_ | mithro: I think you should be able to represent it as edges A/B/C connect to a singe RR graph node | 14:25 |
| kem_ | mithro: If that node has capacity 1, then it will be congested if more than one net tries to use A/B/C | 14:26 |
| kem_ | mithro: At which point the router will rip-up and retry to avoid congestion/overuse | 14:26 |
| mithro | kem_: I'm not sure that works because the issue is the "fan out" - IE we can only fan out via a single edge | 14:44 |
| mithro | kem_: these are also pass gates | 15:04 |
| daveshah | Effectively the structure we are dealing with is a bidirectional "analog" multiplexer | 15:05 |
| kem_ | mithro/daveshah: Is there an example I can look at (e.g. in the icestorm or lattice docs)? | 15:08 |
| mithro | daveshah: did you get a chance to repo my work? | 15:08 |
| daveshah | mithro: yeah, I had a quick poke. reducing the log2delay further and I got QED!!! and it was a valid QED as tested by deliberate breakage | 15:09 |
| daveshah | kem_: here is an example https://usercontent.irccloud-cdn.com/file/m1yba8YY/Screenshot%20from%202018-06-05%2017-05-37.png | 15:10 |
| daveshah | from http://www.clifford.at/icestorm/bitdocs-1k/tile_1_16.html | 15:10 |
| tpb | Title: Project IceStorm iCE40 HX1K LOGIC Tile (1 16) (at www.clifford.at) | 15:10 |
| daveshah | in this case, any of these signals can be connected through a transistor to sp4_h_r_10 | 15:10 |
| daveshah | but the config bits are shared, so only one of these connections can be made | 15:10 |
| mithro | This would all be fine if it was unidir | 15:11 |
| mithro | But vpr is trying to using two of these connections at the same time | 15:12 |
| kem_ | OK I think I follow now. | 15:13 |
| mithro | kem_: I'm actually thinking your idea that this is the first half of a mux more probable now | 15:14 |
| kem_ | Like you said, for unidir routing it should work. | 15:15 |
| kem_ | For bidir, by initial thought is you could add a 'dummy' RR node with capacity one, and use it to limit the number of connections through this mux | 15:16 |
| kem_ | But let me think some more about it and talk to folks to see if there is a better approach | 15:16 |
| mithro | daveshah: you were going to give me an understanding of the global tracks - was there anything more complicated rather than just the stuff packing problem? | 15:17 |
| mithro | kem_: I don't see how that works? Vpr will still think it can drive multiple outputs from this dummy rr-node | 15:17 |
| daveshah | mithro: yes. there are limits as to what global tracks can be used for what functions | 15:17 |
| daveshah | all can be used for clocks. half can be used for reset/set. half can be used for cen. any 4 of 8 can be used generally inside each logic tile | 15:18 |
| daveshah | the exact rules I can't remember, but are in the datasheet | 15:18 |
| daveshah | even buffers can be used for set/reset, odd numbers clock enable | 15:19 |
| mithro | kem_: IE the problem is fan-out | 15:19 |
| kem_ | mithro: Yeah, you are right. Let me look into it :) | 15:20 |
| mithro | daveshah: I'm wondering if Yosys should have a "global promotion" type pass.. | 15:20 |
| daveshah | mithro: Clifford spent quite a bit of time fighting the global promotion in Synplify Pro :P | 15:20 |
| daveshah | Global promotion is for PAR, not synthesis | 15:21 |
| daveshah | Particularly as Yosys has no support for pin constraints | 15:21 |
| mithro | daveshah: the idea this is a reset signal is lost by the time it gets to pnr? | 15:21 |
| daveshah | If you use the dedicated global input pins, that ties up a global but Yosys has no way of knowing which | 15:21 |
| mithro | daveshah: in what way? | 15:21 |
| mithro | daveshah: btw Yosys should be able to pass arbitrary attributes / parameters to vpr | 15:22 |
| daveshah | mithro: the problem is the lack of understanding of a physical chip in Yosys | 15:22 |
| daveshah | this would cause serious problems trying to work out things like global buffer locations, global buffer capable IO | 15:23 |
| daveshah | anyway pnr does know it is a reset signal because it connects to loads of reset inputs | 15:23 |
| daveshah | that's how arachne does it | 15:23 |
| mithro | daveshah: I was looking at the global promotion code in arachne | 15:24 |
| mithro | daveshah: was trying to make it use a gb_sb_io instead of a gb_sb when it promotes a global that was on the right pin | 15:25 |
| mithro | daveshah: but I got stuck with an error I couldn't understand about running of the end of a vector which seemed to be because it couldn't find where to place it | 15:28 |
| mithro | I could use some help with that later | 15:29 |
| mithro | Currently walking | 15:29 |
| daveshah | mithro: oh god the global promotion code | 15:37 |
| daveshah | ick | 15:37 |
| daveshah | I'll see if I can help you | 15:38 |
| daveshah | beware the global buffer numbers are different between SB_GB and SB_GB_IO at the same location (this is what awygle mentioned earlier I think), because SiliconBlue... | 15:38 |
| awygle | yup that's what I was alluding to | 15:46 |
| daveshah | I have to say, I would love to meet up with the old SiliconBlue people and find the reason for some of the odder parts of the ice40 | 15:50 |
| mithro | daveshah: So this is my patch -> https://github.com/mithro/arachne-pnr/commit/57b621cf03c3d277b044c50997d9572bac4a220c (it's just a hack at the moment) | 15:52 |
| tpb | Title: HACK - Using gb_sb_io rather than gb_sb · mithro/arachne-pnr@57b621c · GitHub (at github.com) | 15:52 |
| mithro | It dies at | 15:52 |
| mithro | arachne-pnr: src/netlist.cc:666: void Model::check(const Design*) const: Assertion `!p2->is_bidir()' failed. | 15:52 |
| daveshah | mithro: beware that patch will also fail if a non-global pin is used as a clock input | 15:52 |
| mithro | daveshah: Yeap | 15:53 |
| daveshah | but I think the problem you're having is failing to remove the original sb_io | 15:53 |
| daveshah | and/or have non-global stuff attached directly to package_pin | 15:53 |
| mithro | $2 = {<Identified> = {static id_counter = 1859, id = 1847}, m_node = 0x5555558f27a0, m_name = "PACKAGE_PIN", m_dir = Direction::INOUT, m_undriven = Value::X, m_connection = 0x5555558ec4a0} | 15:56 |
| mithro | $8 = {<Identified> = {static id_counter = 1859, id = 1387}, m_node = 0x55555590c5f0, m_name = "D_IN_0", m_dir = Direction::OUT, m_undriven = Value::ZERO, m_connection = 0x5555558ec4a0} | 15:56 |
| mithro | daveshah: I think it needs to be connected to "GLOBAL_ROUTING" not "D_IN_0"... ? | 15:57 |
| daveshah | mithro: the problem is you need to remove the original SB_IO | 15:57 |
| daveshah | SB_GB_IO and SB_IO are mutually exclusive | 15:58 |
| mithro | Where does the SB_IO come from? | 15:58 |
| daveshah | io insertion, in instantiate_io in io.cc | 15:58 |
| daveshah | I think that's called by the time global promotion starts | 15:58 |
| mithro | daveshah: Yeah - looks like it... | 15:58 |
| daveshah | afraid I have a meeting in a minute. Might be able to help again later | 15:59 |
| mithro | I can't tell if port_gc is "port global connect" or "port garbage collect".... | 16:06 |
| *** digshadow has joined #vtr-dev | 16:23 | |
| *** digshadow has quit IRC | 18:31 | |
| mithro | kem_: Anyone have some compelling ideas? | 18:32 |
| daveshah | mithro: the former, i think | 18:36 |
| daveshah | i think it works out what type of port a port is | 18:37 |
| daveshah | so maybe global class even | 18:37 |
| daveshah | i.e. clock, ce, reset/set or logic | 18:37 |
| *** digshadow has joined #vtr-dev | 18:54 | |
| mithro | daveshah: You still around at all? | 20:20 |
| daveshah | mithro: yep | 20:37 |
| mithro | Cannot route from BLK_TL-PLB.lutff_4/out[0] (rr_node: 18772 type: SOURCE ptc: 39 xlow: 13 ylow: 3) to BLK_TL-RAMB.WADDR[0] (rr_node: 16262 type: SINK ptc: 45 xlow: 11 ylow: 12) to -- no possible path | 22:26 |
| mithro | Failed to route connection from '$0\index[9:0][8]' to 'scratchpad.0.0.0' for net 'index[0]' | 22:26 |
| mithro | I'm a bit confused why it is trying to route to BLK_TL-RAMB.WADDR[0] .... | 22:27 |
| mithro | Oh -- this is using ram tiles for some reason? | 22:29 |
| mithro | Welp, disabling memory makes this design *huge* | 22:36 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
