| *** tpb has joined #vtr-dev | 00:00 | |
| *** kem_ has quit IRC | 00:27 | |
| *** digshadow has quit IRC | 02:37 | |
| *** digshadow has joined #vtr-dev | 03:03 | |
| jhol | mithro: sorry I missed your message - at the moment I'm working on VPR monday-wednesday until the end of april | 09:36 |
|---|---|---|
| jhol | but I can do discussion other days of the week | 09:36 |
| *** kem_ has joined #vtr-dev | 13:07 | |
| mithro | jhol: okay, thanks for the info | 13:51 |
| mithro | jhol: if I get time today, I'm going to rerog the ice40 stuff so we have both an arch with local tracks in tiles and one without. | 13:52 |
| jhol | ok, can you base that on top of this: https://github.com/jhol/symbiflow-arch-defs/commits/wip-fix-modes | 13:54 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 13:54 |
| jhol | otherwise, there will be a lot of merge conflict evil to fix | 13:54 |
| jhol | hold on... let me give a branch with the not-working changes removed | 13:55 |
| jhol | mithro: here's a version with my restrucuring, but with any of the unfinished mode fixes: https://github.com/jhol/symbiflow-arch-defs/commits/restructure | 13:59 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 13:59 |
| jhol | *without any of the | 13:59 |
| mithro | Okay, did you see my comment about the mode stuff? | 14:03 |
| mithro | jhol: does that add the counter test that you were working on? | 14:03 |
| mithro | jhol: I also realised I disabled carry logic in Yosys when I was last testing the PicoRV32 with vpr | 14:04 |
| jhol | ok - I was wondering how you manager to get it running previously! | 14:05 |
| jhol | just pushed the counter test to the restructure branch | 14:06 |
| jhol | and what was your comment about modes? | 14:06 |
| mithro | 2:13 pm <mithro> jhol: The packer takes into account valid routing -- so if packing a DFF together causes a routing conflict it will reject the packing if I understand correctly? | 14:07 |
| jhol | basically - in the current branch, the arch XML is claiming that each of the DFFs can be configured into modes individually. the reality is that you have to configure them in groups of 8 | 14:08 |
| mithro | kem_: please do correct me if I'm wrong... | 14:08 |
| jhol | so for my 3-bit counter, at the moment it packes a SB_DFF, an SB_DFFE and a SB_DFF into a single tile | 14:09 |
| mithro | jhol: the reason you configure them in groups of 8 is there is hard coded routing which forces them to all be in the same mode? | 14:09 |
| jhol | yeah | 14:10 |
| jhol | http://www.clifford.at/icestorm/bitdocs-1k/tile_2_15.html | 14:10 |
| tpb | Title: Project IceStorm iCE40 HX1K LOGIC Tile (2 15) (at www.clifford.at) | 14:10 |
| jhol | there's one NegClk per tile | 14:10 |
| kem_ | mithro: Yup that is correct. The packer will try to pack a primitive into a cluster, but if it's not routeable it is rejected. So after packing you should only get legally routed clusters. | 14:11 |
| jhol | and there's one mux for lutff_global/cen and lutff_global/s_r | 14:11 |
| mithro | Yeah | 14:12 |
| jhol | this patch makes the change: https://github.com/jhol/symbiflow-arch-defs/commit/eabec0b5a624db89f6206dc83aeac58eb5e18083 | 14:12 |
| tpb | Title: ice40: Made DFF mode apply to the whole tile · jhol/symbiflow-arch-defs@eabec0b · GitHub (at github.com) | 14:12 |
| mithro | jhol: so, if the routing is correct then it shouldn't cluster those FFs together? | 14:12 |
| mithro | Brb | 14:12 |
| jhol | but I didn't iron out all the kings yet | 14:12 |
| jhol | yes | 14:13 |
| mithro | jhol: Okay | 14:16 |
| jhol | also... did you know about the fake clk input to the PLB: https://github.com/jhol/symbiflow-arch-defs/commit/3216c151fe3778dcfb2b46d8caf6c1eecfb9d0e4 | 14:17 |
| tpb | Title: ice40/tiles/plb: Removed spurious clk input · jhol/symbiflow-arch-defs@3216c15 · GitHub (at github.com) | 14:17 |
| mithro | jhol: Looks like you need a rebase... | 14:17 |
| jhol | this patch removes it, but it seems to be necessary to trick VPR into accepting two DFFs in a molecule | 14:17 |
| jhol | did you merge mithro/rr_graph_lib_new to master? | 14:18 |
| mithro | jhol: Yes | 14:18 |
| mithro | jhol: hrm... I'm only seeing one branch on your github repo? | 14:19 |
| mithro | daveshah: ping? I'd like to delete some of your branches which have been merged :-P | 14:19 |
| jhol | this is the one with just the restructuring: https://github.com/jhol/symbiflow-arch-defs/tree/restructure | 14:20 |
| tpb | Title: GitHub - jhol/symbiflow-arch-defs at restructure (at github.com) | 14:20 |
| jhol | this is the one with the fixes for modes | 14:20 |
| daveshah | mithro: sure, feel free | 14:21 |
| mithro | daveshah: Well, you'll need to give me permission to your repo or do it for me :-) | 14:21 |
| daveshah | I'll do it | 14:21 |
| jhol | mithro: here's the rebased restructure branch | 14:23 |
| mithro | Opps -- I have my jhol remote set to SymbiFlow user -- explains why I didn't see your branches :-) | 14:23 |
| jhol | oops | 14:25 |
| daveshah | mithro: deleted all old branches now | 14:27 |
| jhol | mithro: https://github.com/jhol/symbiflow-arch-defs/commits/restructure-rebased | 14:28 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 14:28 |
| mithro | jhol: https://github.com/mithro/symbiflow-arch-defs/tree/restructure-rebase/ice40#lattice--siliconblue-ice40-fpgas | 14:37 |
| tpb | Title: symbiflow-arch-defs/ice40 at restructure-rebase · mithro/symbiflow-arch-defs · GitHub (at github.com) | 14:37 |
| *** digshadow has quit IRC | 16:33 | |
| mithro | jhol: This is the direction I'm heading in -> https://github.com/mithro/symbiflow-arch-defs/tree/restructure-rebase/ice40 | 16:52 |
| tpb | Title: symbiflow-arch-defs/ice40 at restructure-rebase · mithro/symbiflow-arch-defs · GitHub (at github.com) | 16:52 |
| mithro | jhol: Have to go and work on other stuff now, but hopefully will get some time over the weekend | 16:52 |
| jhol | yeah ok -- I'll do some more to it on monday | 16:52 |
| *** digshadow has joined #vtr-dev | 17:04 | |
| mithro | Morning digshadow | 17:06 |
| digshadow | hi mithro | 17:06 |
| mithro | digshadow: Have you pushed your latest changes, I can't seem to find them? | 22:35 |
| digshadow | mithro: I can do a sync | 22:36 |
| digshadow | mithro: spent time reviewing the rr_graph spec today and other stuff | 22:36 |
| digshadow | I know we went over some of this yesterday but | 22:37 |
| digshadow | what is the difference between ipin/opin and source/sink? | 22:37 |
| digshadow | says where "nets begin", can't a net begin on an input pin? | 22:38 |
| mithro | digshadow: As far as I know source/sink refer to pin_classes, while ipin/opin refer to the actually little squares on the edge that are shown on the GUI | 22:38 |
| digshadow | ah | 22:38 |
| digshadow | and you were saying they should be connected together | 22:38 |
| digshadow | so you should have both? | 22:38 |
| mithro | digshadow: I think you are clinging to your preconceived notions that these map to their real world logical english descriptions ;-) | 22:39 |
| digshadow | well | 22:39 |
| mithro | digshadow: There is potentially more information here -> https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/vpr/src/base/netlist.h#L352 | 22:40 |
| tpb | Title: vtr-verilog-to-routing/netlist.h at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 22:40 |
| digshadow | also I got my editor to stop flickering | 22:41 |
| digshadow | anyway looking over the doc | 22:41 |
| mithro | digshadow: Getting the docs found in the vpr files into the online docs is on my todo list | 22:41 |
| digshadow | hmm theres a lot in there | 22:42 |
| digshadow | it might be good to reference this from the other docs as a short term solution | 22:42 |
| digshadow | vpr makes a distinction of an fpga architect vs developer | 22:42 |
| digshadow | but I guess right now they are still tied together somewhat | 22:43 |
| mithro | digshadow: well, in our case they are kind of | 22:45 |
| mithro | digshadow: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/670111a7302c37a21cfb1366a0326dc565b83dcd/vpr/src/base/vpr_types.h#L989-L1005 | 22:45 |
| tpb | Title: vtr-verilog-to-routing/vpr_types.h at 670111a7302c37a21cfb1366a0326dc565b83dcd · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 22:45 |
| digshadow | well because you are bootstramping the ecosystem still a litt | 22:45 |
| digshadow | le | 22:45 |
| digshadow | that distinction may change over time | 22:45 |
| mithro | digshadow: Also https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/14b6a38bc9d091f7e6ac26a8063480c6e0c00f49/vpr/src/route/rr_node.h | 22:46 |
| tpb | Title: vtr-verilog-to-routing/rr_node.h at 14b6a38bc9d091f7e6ac26a8063480c6e0c00f49 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 22:46 |
| mithro | digshadow: My kingdom for more developers! :-P | 22:48 |
| digshadow | it has "ports" in that doc | 22:48 |
| digshadow | does that concept translate to rr_graph? | 22:49 |
| digshadow | also I saw this note about "<INVALID>" not a legal string since it would confuse the xml parser.... | 22:50 |
| digshadow | think you had touched on that before | 22:50 |
| mithro | digshadow: No, ports don't really end up in the rr_graph from what I can understand | 22:51 |
| mithro | digshadow: But do remember that I'm a totally unreliable narrator :-P | 22:53 |
| digshadow | could I be kasyer soze then | 22:53 |
| mithro | digshadow: I think it goes something like "SOURCE --(EDGE)--> OPIN --(EDGE)---> CHANX --(EDGE)--> CHANX --(EDGE)--> IPIN --(EDGE)--> SINK" | 22:54 |
| digshadow | mithro: I think one thing I may have been missing conceptually | 22:54 |
| mithro | And in our case pretty much there is always 1:1 relationship between SOURCE/OPIN and IPIN/SINK | 22:54 |
| digshadow | the rr_graph is used as much for GUI purposes as actual connectivity, is that correct? | 22:54 |
| mithro | digshadow: There is not a nice separation as far as I understand.... | 22:55 |
| digshadow | got it | 22:55 |
| mithro | digshadow: there is also not a great separation between rr_graph format and how things are represented inside vpr internally | 22:56 |
| digshadow | oh yeah on that note | 22:56 |
| mithro | digshadow: The rr_graph format is kind of almost a dump of the memory structures | 22:56 |
| digshadow | re: id matching | 22:57 |
| digshadow | blocks are named | 22:58 |
| digshadow | that must match up with the arch defintiion I take it | 22:58 |
| digshadow | but a lot of the other stuff such as the edges have no bearing to the arch | 22:58 |
| digshadow | so I can choose those as i wish, as long as they are sequential | 22:58 |
| digshadow | however, the pins I'm a little less clear on | 22:58 |
| digshadow | you had your id map thing | 22:59 |
| digshadow | the whole point of that is to preserve the pin numbering, right? | 22:59 |
| mithro | digshadow: No - the id map thing is provide a *useful* name for each node/edge and map them to the incrementing id values | 23:01 |
| digshadow | pins are named in the arch xml and numbered in rr_graph | 23:02 |
| digshadow | how do you map between them | 23:02 |
| digshadow | mind you I haven't finished reading the docs you sent me | 23:02 |
| digshadow | so I can also finish reading those and then we can chjta | 23:02 |
| digshadow | chat | 23:02 |
| mithro | digshadow: That is why we load the existing rr_graph, to find the pin numbering | 23:03 |
| mithro | digshadow: The port_name[pin_num] -> "ptc" numbering mapping doesn't really exist anywhere at the moment | 23:04 |
| mithro | digshadow: That is what my suggestion around changes to the block_type xml is about | 23:05 |
| digshadow | I understand that at a high level, I'm trying to understand how you are working around that | 23:06 |
| mithro | digshadow: https://github.com/mithro/vtr-verilog-to-routing/commit/2f63c539d297d5dd3c4b523bce39adb600534d1f | 23:10 |
| tpb | Title: Temp. · mithro/vtr-verilog-to-routing@2f63c53 · GitHub (at github.com) | 23:10 |
| mithro | digshadow: I was going to work around it by manually adding the names in the same order and having the rr_graph.py library generate the same values | 23:11 |
| mithro | digshadow: IE I was kind of thinking like this | 23:15 |
| mithro | step 1 - load the rr_graph | 23:15 |
| mithro | step 2 - manually populate the names on the block_types that you imported from the rr_graph file | 23:16 |
| mithro | step 3 - create the new rr_graph | 23:16 |
| mithro | digshadow: Did that make any sense :-P | 23:20 |
| digshadow | you are saying that you don't actually need to know which pins they correspond to? | 23:28 |
| mithro | digshadow: You probably want to rebase onto my "restructure-rebase" branch ASAP | 23:28 |
| digshadow | take this example: https://pastebin.com/hy77VDNB | 23:28 |
| tpb | Title: (at pastebin.com) | 23:28 |
| digshadow | with the xml at the bottom | 23:28 |
| digshadow | a good guess is the bottom two inputs are the clock pins | 23:29 |
| digshadow | but this translation is not very obvious | 23:29 |
| digshadow | mithro: what does your patch do | 23:29 |
| mithro | digshadow: I've pulled your xml changes into my branch already | 23:29 |
| mithro | digshadow: It should mostly only affect the ice40 arch | 23:29 |
| digshadow | which branch? | 23:30 |
| digshadow | rebase against master didn't do anything I think | 23:30 |
| mithro | digshadow: You probably want to rebase onto my "restructure-rebase" <<--- branch ASAP | 23:30 |
| digshadow | oops | 23:30 |
| digshadow | there are a lot of conflicts | 23:32 |
| digshadow | what specifically did you want me to grab from that | 23:33 |
| digshadow | conflicts related to jhol patches | 23:33 |
| mithro | digshadow: How did you rebase? | 23:34 |
| mithro | digshadow: "git rebase -i" and make sure only your patches that you want to pull are in the list (delete the other lines) | 23:34 |
| mithro | digshadow: I actually have no idea how the pin names are mapped to indexes if what you are showing me at https://pastebin.com/hy77VDNB is correct | 23:36 |
| tpb | Title: (at pastebin.com) | 23:36 |
| mithro | digshadow: I would have assumed they are allocated in the order they are defined in the arch.xml file | 23:36 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!