Friday, 2018-04-13

*** tpb has joined #vtr-dev00:00
*** kem_ has quit IRC00:27
*** digshadow has quit IRC02:37
*** digshadow has joined #vtr-dev03:03
jholmithro: sorry I missed your message - at the moment I'm working on VPR monday-wednesday until the end of april09:36
jholbut I can do discussion other days of the week09:36
*** kem_ has joined #vtr-dev13:07
mithrojhol: okay, thanks for the info13:51
mithrojhol: 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
jholok, can you base that on top of this:
tpbTitle: Commits · jhol/symbiflow-arch-defs · GitHub (at
jholotherwise, there will be a lot of merge conflict evil to fix13:54
jholhold on... let me give a branch with the not-working changes removed13:55
jholmithro: here's a version with my restrucuring, but with any of the unfinished mode fixes:
tpbTitle: Commits · jhol/symbiflow-arch-defs · GitHub (at
jhol*without any of the13:59
mithroOkay, did you see my comment about the mode stuff?14:03
mithrojhol: does that add the counter test that you were working on?14:03
mithrojhol: I also realised I disabled carry logic in Yosys when I was last testing the PicoRV32 with vpr14:04
jholok - I was wondering how you manager to get it running previously!14:05
jholjust pushed the counter test to the restructure branch14:06
jholand what was your comment about modes?14:06
mithro2: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
jholbasically - 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 814:08
mithrokem_: please do correct me if I'm wrong...14:08
jholso for my 3-bit counter, at the moment it packes a SB_DFF, an SB_DFFE and a SB_DFF into a single tile14:09
mithrojhol: 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
tpbTitle: Project IceStorm iCE40 HX1K LOGIC Tile (2 15) (at
jholthere's one NegClk per tile14: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
jholand there's one mux for lutff_global/cen and lutff_global/s_r14:11
jholthis patch makes the change:
tpbTitle: ice40: Made DFF mode apply to the whole tile · jhol/[email protected] · GitHub (at
mithrojhol: so, if the routing is correct then it shouldn't cluster those FFs together?14:12
jholbut I didn't iron out all the kings yet14:12
mithrojhol: Okay14:16
jholalso... did  you know about the fake clk input to the PLB:
tpbTitle: ice40/tiles/plb: Removed spurious clk input · jhol/[email protected] · GitHub (at
mithrojhol: Looks like you need a rebase...14:17
jholthis patch removes it, but it seems to be necessary to trick VPR into accepting two DFFs in a molecule14:17
jholdid you merge mithro/rr_graph_lib_new to master?14:18
mithrojhol: Yes14:18
mithrojhol: hrm... I'm only seeing one branch on your github repo?14:19
mithrodaveshah: ping? I'd like to delete some of your branches which have been merged :-P14:19
jholthis is the one with just the restructuring:
tpbTitle: GitHub - jhol/symbiflow-arch-defs at restructure (at
jholthis is the one with the fixes for modes14:20
daveshahmithro: sure, feel free14:21
mithrodaveshah: Well, you'll need to give me permission to your repo or do it for me :-)14:21
daveshahI'll do it14:21
jholmithro: here's the rebased restructure branch14:23
mithroOpps -- I have my jhol remote set to SymbiFlow user -- explains why I didn't see your branches :-)14:23
daveshahmithro: deleted all old branches now14:27
tpbTitle: Commits · jhol/symbiflow-arch-defs · GitHub (at
tpbTitle: symbiflow-arch-defs/ice40 at restructure-rebase · mithro/symbiflow-arch-defs · GitHub (at
*** digshadow has quit IRC16:33
mithrojhol: This is the direction I'm heading in ->
tpbTitle: symbiflow-arch-defs/ice40 at restructure-rebase · mithro/symbiflow-arch-defs · GitHub (at
mithrojhol: Have to go and work on other stuff now, but hopefully will get some time over the weekend16:52
jholyeah ok -- I'll do some more to it on monday16:52
*** digshadow has joined #vtr-dev17:04
mithroMorning digshadow17:06
digshadowhi mithro17:06
mithrodigshadow: Have you pushed your latest changes, I can't seem to find them?22:35
digshadowmithro: I can do a sync22:36
digshadowmithro: spent time reviewing the rr_graph spec today and other stuff22:36
digshadowI know we went over some of this yesterday but22:37
digshadowwhat is the difference between ipin/opin and source/sink?22:37
digshadowsays where "nets begin", can't a net begin on an input pin?22:38
mithrodigshadow: 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 GUI22:38
digshadowand you were saying they should be connected together22:38
digshadowso you should have both?22:38
mithrodigshadow: I think you are clinging to your preconceived notions that these map to their real world logical english descriptions ;-)22:39
mithrodigshadow: There is potentially more information here ->
tpbTitle: vtr-verilog-to-routing/netlist.h at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
digshadowalso I got my editor to stop flickering22:41
digshadowanyway looking over the doc22:41
mithrodigshadow: Getting the docs found in the vpr files into the online docs is on my todo list22:41
digshadowhmm theres a lot in there22:42
digshadowit might be good to reference this from the other docs as a short term solution22:42
digshadowvpr makes a distinction of an fpga architect vs developer22:42
digshadowbut I guess right now they are still tied together somewhat22:43
mithrodigshadow: well, in our case they are kind of22:45
tpbTitle: vtr-verilog-to-routing/vpr_types.h at 670111a7302c37a21cfb1366a0326dc565b83dcd · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
digshadowwell because you are bootstramping the ecosystem still a litt22:45
digshadowthat distinction may change over time22:45
mithrodigshadow: Also
tpbTitle: vtr-verilog-to-routing/rr_node.h at 14b6a38bc9d091f7e6ac26a8063480c6e0c00f49 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrodigshadow: My kingdom for more developers! :-P22:48
digshadowit has "ports" in that doc22:48
digshadowdoes that concept translate to rr_graph?22:49
digshadowalso I saw this note about "<INVALID>" not a legal string since it would confuse the xml parser....22:50
digshadowthink you had touched on that before22:50
mithrodigshadow: No, ports don't really end up in the rr_graph from what I can understand22:51
mithrodigshadow: But do remember that I'm a totally unreliable narrator :-P22:53
digshadowcould I be kasyer soze then22:53
mithrodigshadow: I think it goes something like "SOURCE --(EDGE)--> OPIN --(EDGE)---> CHANX --(EDGE)--> CHANX --(EDGE)--> IPIN --(EDGE)--> SINK"22:54
digshadowmithro: I think one thing I may have been missing conceptually22:54
mithroAnd in our case pretty much there is always 1:1 relationship between SOURCE/OPIN and IPIN/SINK22:54
digshadowthe rr_graph is used as much for GUI purposes as actual connectivity, is that correct?22:54
mithrodigshadow: There is not a nice separation as far as I understand....22:55
digshadowgot it22:55
mithrodigshadow: there is also not a great separation between rr_graph format and how things are represented inside vpr internally22:56
digshadowoh yeah on that note22:56
mithrodigshadow: The rr_graph format is kind of almost a dump of the memory structures22:56
digshadowre: id matching22:57
digshadowblocks are named22:58
digshadowthat must match up with the arch defintiion I take it22:58
digshadowbut a lot of the other stuff such as the edges have no bearing to the arch22:58
digshadowso I can choose those as i wish, as long as they are sequential22:58
digshadowhowever, the pins I'm a little less clear on22:58
digshadowyou had your id map thing22:59
digshadowthe whole point of that is to preserve the pin numbering, right?22:59
mithrodigshadow: No - the id map thing is provide a *useful* name for each node/edge and map them to the incrementing id values23:01
digshadowpins are named in the arch xml and numbered in rr_graph23:02
digshadowhow do you map between them23:02
digshadowmind you I haven't finished reading the docs you sent me23:02
digshadowso I can also finish reading those and then we can chjta23:02
mithrodigshadow: That is why we load the existing rr_graph, to find the pin numbering23:03
mithrodigshadow: The port_name[pin_num] -> "ptc" numbering mapping doesn't really exist anywhere at the moment23:04
mithrodigshadow: That is what my suggestion around changes to the block_type xml is about23:05
digshadowI understand that at a high level, I'm trying to understand how you are working around that23:06
tpbTitle: Temp. · mithro/[email protected] · GitHub (at
mithrodigshadow: I was going to work around it by manually adding the names in the same order and having the library generate the same values23:11
mithrodigshadow: IE I was kind of thinking like this23:15
mithrostep 1 - load the rr_graph23:15
mithrostep 2 - manually populate the names on the block_types that you imported from the rr_graph file23:16
mithrostep 3 - create the new rr_graph23:16
mithrodigshadow: Did that make any sense :-P23:20
digshadowyou are saying that you don't actually need to know which pins they  correspond to?23:28
mithrodigshadow: You probably want to rebase onto my "restructure-rebase" branch ASAP23:28
digshadowtake this example:
tpbTitle:  (at
digshadowwith the xml at the bottom23:28
digshadowa good guess is the bottom two inputs are the clock pins23:29
digshadowbut this translation is not very obvious23:29
digshadowmithro: what does your patch do23:29
mithrodigshadow: I've pulled your xml changes into my branch already23:29
mithrodigshadow: It should mostly only affect the ice40 arch23:29
digshadowwhich branch?23:30
digshadowrebase against master didn't do anything I think23:30
mithrodigshadow: You probably want to rebase onto my "restructure-rebase" <<--- branch ASAP23:30
digshadowthere are a lot of conflicts23:32
digshadowwhat specifically did you want me to grab from that23:33
digshadowconflicts related to jhol patches23:33
mithrodigshadow: How did you rebase?23:34
mithrodigshadow: "git rebase -i" and make sure only your patches that you want to pull are in the list (delete the other lines)23:34
mithrodigshadow: I actually have no idea how the pin names are mapped to indexes if what you are showing me at is correct23:36
tpbTitle:  (at
mithrodigshadow: I would have assumed they are allocated in the order they are defined in the arch.xml file23:36

Generated by 2.13.1 by Marius Gedminas - find it at!