| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has quit IRC | 02:49 | |
| *** kem_ has quit IRC | 02:49 | |
| *** digshadow has joined #vtr-dev | 02:49 | |
| *** kem_ has joined #vtr-dev | 02:49 | |
| *** ZipCPU has quit IRC | 02:54 | |
| *** ZipCPU has joined #vtr-dev | 02:54 | |
| mithro | jhol / daveshah -> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/132 | 05:34 |
|---|---|---|
| tpb | Title: Add methods to RoutingGraph to determine whether any sink nodes are i… by benreynwar · Pull Request #132 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 05:34 |
| mithro | nope - that wasn't what I meant to link | 05:35 |
| mithro | jhol / daveshah: iceblink routing - https://paste.ubuntu.com/p/JVf6gv8gpv/ -- need to get the carry working | 05:37 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 05:37 |
| *** digshadow has quit IRC | 13:34 | |
| mithro | jhol / daveshah: morning | 16:20 |
| jhol | mithro: hi | 16:20 |
| mithro | jhol: Did you see the HLC routing output stuff above? | 16:21 |
| jhol | I did - very impressive | 16:21 |
| mithro | jhol: I still need to get the internal tile stuff back into the output | 16:22 |
| jhol | sure | 16:23 |
| mithro | jhol: I do think that hlc turned out not to be a great choice for the output format, but we now have most of a C++ library for easily generating HLC output | 16:24 |
| mithro | jhol: Do you understand how HLC is suppose to work? | 16:29 |
| jhol | in what sense? | 16:29 |
| jhol | it seems a bit ad-hoc, I didn't find any documentation about it | 16:29 |
| mithro | jhol: Like - I'm a bit confused why the lutff_3/in0 net is called lutff_3/in0 rather than in0 in this example; | 16:30 |
| mithro | https://www.irccloud.com/pastebin/Z01B8yvV/ | 16:30 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 16:30 |
| jhol | well yes lutff_3/ is unecessary there, but... | 16:31 |
| jhol | I think the cell wrapper there is just a abbreviation - it will try prefixing the pin names with lutff_3/ unless you explicitly specify a pin from another cell | 16:32 |
| mithro | jhol: I also think I had forgotten how slow writing things in C++ is :-P | 16:33 |
| jhol | oh yes | 16:33 |
| jhol | it's why I wanted this code moved out into a python script that operates on the .place and .route files | 16:34 |
| jhol | -- well one of the reasons | 16:34 |
| mithro | jhol: As well, the enable_dff is basically controlling the lout or dout mux (IE direct LUT output or FF output selection mux), right? | 16:38 |
| jhol | that's right | 16:38 |
| jhol | because there is no lout/dout net/mux in icebox | 16:39 |
| mithro | jhol: and what does the "LC_i[8] is the CarryEnable bit. This bit must be set if the carry logic is used." do? | 16:39 |
| mithro | jhol: And looking at this output | 16:43 |
| mithro | https://www.irccloud.com/pastebin/0stIjmZ6/ | 16:43 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 16:43 |
| mithro | That is effectively not using the LUT, right? | 16:43 |
| jhol | not using the LUT - just the carry? | 16:44 |
| mithro | jhol: Yeah - the output is being set to a constant 0 and then is not being routed anywhere? | 16:44 |
| jhol | yes - in_1 is one of the inputs to the SB_CARRY | 16:45 |
| daveshah | looks like a carry feed in | 16:45 |
| daveshah | a feed through LUT | 16:45 |
| daveshah | this from arachne or VPR? | 16:45 |
| mithro | daveshah: arachne | 16:45 |
| daveshah | yep. it inserts feed through LUTs to get signals into the carry chain, because they can't be routed in directly | 16:45 |
| daveshah | I think this is due to the DFFE business we discussed a while ago | 16:46 |
| jhol | mithro: I don't know *why* you can enable/disable the carry, but you can, so I guess the answer you must enable it if you want it | 16:46 |
| daveshah | jhol: power saving | 16:46 |
| mithro | daveshah: Well that LUT is just *not* being used the output is constant and it doesn't go anywhere | 16:46 |
| daveshah | ice40 is very power optimised | 16:46 |
| daveshah | mithro: sorry /s/LUT/logic cell/ | 16:46 |
| daveshah | the LUT is not used, but the carry part of the logic cell is needed for feed in | 16:47 |
| mithro | What happens if you don't use "enable_carry" on one of the lutff in a cell? | 16:48 |
| daveshah | I assume the carry chain parts don't function | 16:49 |
| daveshah | probably feeding 0 out of carry_out, but I wouldn't bank on that | 16:49 |
| daveshah | I think it's for power saving rather than functional purposes | 16:49 |
| jhol | daveshaw - shame you can't power-off the LUT of the FF | 16:51 |
| jhol | -- though maybe that's implicit in the configuration you do to it | 16:51 |
| daveshah | yes, maybe how it is implemented internally means it doesn't matter | 16:52 |
| daveshah | it may be that enable_carry is also set to 0 to avoid feeding crud into the carry chain but keeping it at constant 0 before a carry section starts | 16:52 |
| mithro | lutff_4/cout -> in_3 | 16:53 |
| mithro | I can't find which bit configures that? | 16:54 |
| daveshah | mithro: https://github.com/cliffordwolf/icestorm/blob/cc3c1906abe64a52ffd84a31558d87de2b74bc31/icebox/iceboxdb.py#L2038 | 16:55 |
| tpb | Title: icestorm/iceboxdb.py at cc3c1906abe64a52ffd84a31558d87de2b74bc31 · cliffordwolf/icestorm · GitHub (at github.com) | 16:55 |
| mithro | Oh - it's part of the routing and not part of the logic tile... | 16:56 |
| daveshah | yeah, part of the input mux I suppose | 16:56 |
| mithro | btw - we still seem to have question marks for some of the bits? | 16:57 |
| daveshah | example? | 16:58 |
| mithro | https://usercontent.irccloud-cdn.com/file/sE20utHt/image.png | 16:59 |
| daveshah | that's where icebox_html doesn't know the type | 17:00 |
| daveshah | not an actual unknown bit | 17:00 |
| daveshah | AFAIK there is no known bitstream generated from icecube that leaves unknown bits after icebox_explain | 17:00 |
| mithro | daveshah: So what are they? | 17:01 |
| daveshah | they are constant zero | 17:01 |
| daveshah | or at least not used by icecube | 17:01 |
| daveshah | sorry, doesn't know the type wasn't a good explanation | 17:01 |
| daveshah | not in the database would be a better description | 17:02 |
| mithro | daveshah: Column 7 very much looks like a row of unused routing bits.... | 17:03 |
| daveshah | mithro: unlikely | 17:04 |
| mithro | daveshah: Other option would be some type of padding.... | 17:04 |
| daveshah | more likely, mostly due to physical layout or tile changes between revisions | 17:05 |
| mithro | daveshah: Or maybe something to do with internal testing? | 17:06 |
| daveshah | also possible | 17:07 |
| mithro | That poor lonely carry_in_mux bit in column 49 too :-P | 17:09 |
| daveshah | half of the column become the column buffer bits in the 8k | 17:09 |
| daveshah | http://www.clifford.at/icestorm/bitdocs-8k/tile_1_32.html | 17:09 |
| tpb | Title: Project IceStorm iCE40 HX8K LOGIC Tile (1 32) (at www.clifford.at) | 17:09 |
| daveshah | don't know why they moved, or what the old column buffer bits become | 17:09 |
| mithro | I think I have a more concrete idea about what fasm should look like after doing this HLC stuff | 17:17 |
| daveshah | have you seen my prototype ECP5 config language? | 17:17 |
| mithro | Oh, it would be good if someone could help test benreynwar's routability checker code | 17:17 |
| mithro | Nope? | 17:17 |
| daveshah | https://usercontent.irccloud-cdn.com/file/21gjiH9H/nes.config | 17:17 |
| daveshah | big example attached | 17:18 |
| daveshah | here's a single tile | 17:18 |
| daveshah | https://www.irccloud.com/pastebin/CDw6eW5K/ | 17:18 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 17:18 |
| benreynwar | mithro: For testing I can write a slow and simple brute-force routability checker. Then it'll be straight forward to compare the results with the more efficient but bug-prone version. | 17:26 |
| benreynwar | mithro: It's also be nice to double-check whether a simple routability checker is fast enough for real routing graphs. | 17:27 |
| mithro | benreynwar: well, I hope not to have to run it very frequently | 17:28 |
| mithro | daveshah: R77C63 == Row 77, Column 63? - PLC2 == tile type? | 17:34 |
| daveshah | mithro: R77C63 is the lattice tile name (which is at minimum a position as you see), and indeed PLC2 is the type | 17:34 |
| daveshah | sometimes the tile name will have a prefix too | 17:35 |
| mithro | arc -- PIP? | 17:35 |
| daveshah | yes, arc is the lattice word for pip | 17:35 |
| mithro | daveshah: Does ECP5 have bidir and uni dir switches like the ice40? | 17:36 |
| daveshah | mithro: everything is unidir in ECP5 | 17:36 |
| daveshah | all muxes | 17:36 |
| mithro | kem_: Where did you get to with carry stuff in again? I know you told at the last vpr meeting but I've forgotten :-P | 20:22 |
| kem_ | mithro: Still slogging through it. Turns out the pack pattern support we had was pretty fragile and did not generalize easily to multi-fanout/tree-patterns instead of strict chains :( | 20:25 |
| mithro | kem_: :-/ | 20:26 |
| kem_ | mithro: The current status is that I can detect multi-fanout patterns in the architecture, and group the atoms/netlist primitives into the appropriate molecules. | 20:28 |
| kem_ | mithro: The part that I'm still working yet is enhancing the packing algorithm itself to support placing a molecule with multi-fanout connections within a cluster. | 20:29 |
| mithro | kem_: I'm actually very impressed with the catch library you are using for C++ unit tests | 21:05 |
| kem_ | mithro: I've tried a couple different frameworks on various projects, and this seems the best so far. | 21:14 |
| mithro | kem_: I'm obviously used to gtest/gmock | 21:14 |
| kem_ | mithro: Makes sense. | 21:15 |
| kem_ | mithro: VTR doesn't really have many unit tests yet so we'll see how it goes. Most of the code was written before unit testing was really a thing. | 21:16 |
| mithro | kem_: Yeah :-) | 21:16 |
| mithro | jhol / daveshah: The -nodffe flag is to prevent yosys from generating flipflops which don't pack nicely together? | 21:38 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
