Sunday, 2018-05-06

*** tpb has joined #vtr-dev00:00
mithrodigshadow: See
tpbTitle: symbiflow-arch-defs/ at ice40-test · mithro/symbiflow-arch-defs · GitHub (at
mithrodigshadow: You need to add
tpbTitle: symbiflow-arch-defs/ at ice40-test · mithro/symbiflow-arch-defs · GitHub (at
mithroBasically, it generates a new id for the node but then doesn't actually set the ID on the XML object00:02
digshadowjhol, daveshah:
tpbTitle: ice40_function_routing_mirrored.png - Google Drive (at
digshadowI'm trying to understand how icebox represents routing vs buffer04:59
digshadowbuffer is defined as bi-directional, yet these entries can appear twice in the database (see example). Should I treat the entries as unidirectional? Or do I need to de-duplicate them?05:00
digshadowNote chart is from
tpbTitle: Project IceStorm iCE40 HX1K LOGIC Tile (1 1) (at
digshadowmithro: fyi I have the switches in06:14
digshadower pin edges06:15
daveshahdigshadow: icebox does not to my knowledge automatically create two arcs in both directions for routing06:21
daveshahSo you should treat as bidirectional06:21
daveshahI think the example you found is just an artefact of Lattice's architecture06:21
daveshahWhere there happen to be two equivalent switches06:21
digshadowHmm okay, I will handle that case then06:22
digshadowdaveshah: btw in case it wasn't clear from above message, I'm just fixing a few buts06:23
digshadowbut I more or less have a complete fabric loaded in06:23
daveshahdigshadow: Awesome!06:23
digshadowmithro: heading out for the night07:47
digshadowthis is where I am07:47
tpbTitle: long_pin_io.png - Google Drive (at
digshadowI was taking a look at some of the odd pin connections, I'm not necessarily convinced that those are wrong, but they are a bit odd07:48
digshadowif you have any insight on those I'd be curious07:48
digshadowthat is, the outputs seem to be directly connected to the right neighbors maybe07:48
digshadowon the logic tiles07:48
digshadowI/O tiles look reasonable, so maybe its fine07:48
digshadowin any case, the design is reporting as unroutable07:48
daveshahI can take a look today07:49
digshadowa general quick look I thought the design looked like it has a lot of connectivity, but I didn't investigate specifically07:49
daveshahThe logic tiles do have neighbor connections07:49
digshadowits somewhat difficult to understand the pins since it selected a lot of other stuff07:49
digshadowdaveshah: yeah but I don't see other neighbor connections, but maybe thats a GUI limitation07:49
digshadowI didn't look into it in detail07:49
digshadowdaveshah: anyway I've pushed what I have so far if you want to take a look07:50
digshadowthere is definitely something resembling the routing fabric at least07:50
digshadowto be clear, I've only tested with 38407:50
digshadow~/symbiflow-arch-defs/tests$ make wire.patched.disp ARCH=ice40 DEVICE_TYPE=top-routing-virt VPR=~/bin/vpr  07:51
digshadowspecifically is the command I'm running07:51
digshadowwhere the vpr command is my branch with the pin name stuff07:52
digshadowI'll be back in half hour or so07:52
daveshahThanks, I'll take a peek07:52
*** digshadow has quit IRC07:58
*** digshadow has joined #vtr-dev08:15
digshadowdaveshah: back08:16
daveshahAfraid I'm no further than you are08:16
daveshahLooks routable to me too...08:16
daveshahswitch_id possibly looks wrong in the rr_graph?08:17
digshadowoh hmm08:17
digshadowit would be good to double check a lot of that08:17
digshadowYeah very good point08:17
digshadowso the switch IDs are currently generated in the python code I think08:17
digshadowbut they may need to match the arch.xml08:18
digshadowhowever, as long as the switch IDs were in range, maybe it wouldn't matter?08:18
digshadowdefinitely something to look at though08:18
daveshahit looked possibly like all the edges were "configurable="0"" in the rr_graph08:20
daveshahwhich could be a problem?08:20
daveshahOK this is interesting08:26
daveshahIf I make switch ID 0 configurable, it actually routes08:26
daveshahif I try and use the "proper" switch IDs, VPR segfaults...08:26
daveshahdigshadow: to get something routing, just change the line adding switch 0 to08:27
daveshah`    _switch_delayless = g.ids.add_switch('__vpr_delayless_switch__', buffered=1, configurable=1, stype='mux')`08:27
digshadowah interesting. Maybe I added that incorrectly then08:33
digshadowI think that is a special internal thing, although I didn't look at it in detail08:33
digshadowthats cool though...sounds like we have something that possibly routed08:33
digshadowFYI I didn't touch a lot of the global clock stuff08:33
daveshahI suppose the next step is to integrate jhol's HLC stuff08:34
daveshahI'm not sure whether what I did is OK, or makes too much stuff configurable though08:34
daveshahI would like to use proper switch IDs, but I can't get that to work, so I don't know...08:35
digshadowyeah I'll review it in more detail tomorrow, but it sounds like it is related to switches08:35
digshadowto be clear08:35
digshadowproper means you are using them from arch.xml?08:35
digshadowas generated in the original rr_graph?08:35
daveshahno, leaving 0s alone and using 1 for routing and 2 for buffers08:36
daveshahit seems as soon as you give anything a switch ID that isn't 0 it segfaults08:36
daveshahso the solution for now is making switch 0 configurable08:36
digshadow                <switch id="2" type="mux" name="__vpr_delayless_switch__" buffered="1" configurable="1">08:42
digshadowis in my ./build/ice40/LP384/wire.rr_graph.xml08:42
digshadowif thats switch ID 2 in the generated XML and you use it like that it still crashes?08:43
digshadow(I don't have things setup to try right now)08:43
digshadowgenerated XML => the icebox based rr_graph08:43
digshadowgoing to sleep, will take a look tomorrow08:46
daveshahit becomes switch 0 in the generated things08:47
digshadowright, I'm propsing to create the switches to match the original08:47
digshadowI'm suspecting that it must be preserved08:47
daveshahYeah I'll try that and let you know what happens08:48
daveshahIt seems that it's not to do with IDs, regardless of how IDs are assigned, the only switch that works is __vpr_delayless_switch__09:29
daveshahUsing any other switch seems to segfault VPR09:29
*** digshadow has quit IRC10:52
*** digshadow has joined #vtr-dev10:52
*** elms has quit IRC13:54
*** elms has joined #vtr-dev13:54
jholdigshadow, mithro: how goes it?18:06
digshadowjhol: you saw we sort of got something PnR'd in the fabric last night18:59
digshadowI'm not feeling super great today, haven't looked at it yet...19:00
*** ZipCPU has quit IRC19:10
*** ZipCPU_ has joined #vtr-dev19:10
*** ZipCPU has joined #vtr-dev19:12
*** ZipCPU_ has quit IRC19:15
jholdigshadow: do you think the demo is in with a shot?19:31
digshadowjhol: if we are able to do the simple wire demo, honestly I'd be happy19:32
digshadowI haven't tried processing the result to see if it generates a bitstream19:32
jholwell if you integrate the HLC branches in VPR and SymbiFlow arch defs, you'll get a bit steamy for sure19:34
jholjust won't have any span buffers :)19:34
daveshahjhol: if you want to get PnR working (sort of at least), take digshadow's SymbiFlow code and change configurable=0 to configurable=1 here
tpbTitle: symbiflow-arch-defs/ at a8f723f450c80e5182b4b148f8a28cc927a0c2a1 · mcmasterg/symbiflow-arch-defs · GitHub (at
jholdaveshah, digshadow: I've got the whole day t ok morrow to work on it, so I think that would the best thing. I'm not likely to get much done tonight, but if the rr_graph is in good shape, I'll see what I can cook up with it19:40
jholdigshadow: if you're happy for me to look at it, can you leave me some detailed info on how to pick up your stuff?19:44
mithrodigshadow: Hey19:46
mithrojhol: Morning19:48
jholmithro: hi19:48
mithrojhol: Just seeing what digshadow got to last night will have to run away shortly however19:51
mithrojhol: You should be able to go into the tests directory and run "make ARCH=ice40 DEVICE_TYPE=top-routing-virt ROUTE_CHAN_WIDTH=100 wire.patched.disp"19:52
mithrodaveshah: You were mentioning something about the switches?19:58
daveshahmithro: yeah19:58
daveshahdigshadow's rr_graph wasn't routing19:58
mithroCurrently the arch def has19:59
daveshahThis is because all edges used switch ID 0 (the VPR delay less switch) which was set to not configurable19:59
tpbTitle: Snippet | IRCCloud (at
daveshahI can get the rr_graph to route by making that switch configurable19:59
daveshahBut using any other switch for the edges causes vpr to segfault19:59
mithroWhich seems to end up with20:00
tpbTitle: Snippet | IRCCloud (at
daveshahYeah, I played about with the switch naming, numbering and ordering in the rr_graph file20:00
mithrolooks like all the edges have a "switch_id='0'" ?20:00
daveshahYeah exactly20:00
daveshahThe problem is it segfaults whenever switch_id is set to a switch other than the VPR delay less one20:01
daveshahThe solution to get the rr_graph routing was to keep them all on that switch, and make that switch configurable20:01
daveshah9:33 pm <daveshah> jhol: if you want to get PnR working (sort of at least), take digshadow's SymbiFlow code and change configurable=0 to configurable=1 here
tpbTitle: symbiflow-arch-defs/ at a8f723f450c80e5182b4b148f8a28cc927a0c2a1 · mcmasterg/symbiflow-arch-defs · GitHub (at
daveshahThat is how I got digshadow's rr_graph to route20:02
daveshahThe only risk with that approach is that it might make too much stuff configurable20:02
daveshahBut right now I think it's OK20:02
mithrodaveshah: Okay20:03
mithroYeah - just got a segfault here when I changed that too20:04
daveshahmithro: I did also play about quickly to see what happened with jhol's HLC writer using digshadow's rr_graph20:04
daveshahNo routing was output, but it didn't crash or anything20:04
daveshahmithro: you mean changing the switch ID, or changing configurable only (only the former should segfault)20:05
mithrodaveshah: Switch ID20:05
daveshahmithro: OK, that's what I expect. Good to confirm20:06
daveshahBut as I say I think that's not a big issue for now, just using __vpr_delayless_switch__ should be fine20:06
mithrodaveshah: I'm not getting successful routing?20:06
daveshahEven after changing configurable?20:06
mithroI see -- digshadow is rewriting the switches section20:07
daveshahYou have to change configurable in the Python script20:07
digshadowmithro: right, I think looking back I should have left switches alone20:08
*** digshadow has quit IRC21:57
*** digshadow has joined #vtr-dev21:58
*** digshadow has quit IRC22:37

Generated by 2.13.1 by Marius Gedminas - find it at!