| *** tpb has joined #vtr-dev | 00:00 | |
| mithro | digshadow: See https://github.com/mithro/symbiflow-arch-defs/blob/ice40-test/utils/lib/rr_graph/graph.py#L1093-L1119 | 00:02 |
|---|---|---|
| tpb | Title: symbiflow-arch-defs/graph.py at ice40-test · mithro/symbiflow-arch-defs · GitHub (at github.com) | 00:02 |
| mithro | digshadow: You need to add https://github.com/mithro/symbiflow-arch-defs/blob/ice40-test/utils/lib/rr_graph/graph.py#L1100 | 00:02 |
| tpb | Title: symbiflow-arch-defs/graph.py at ice40-test · mithro/symbiflow-arch-defs · GitHub (at github.com) | 00:02 |
| mithro | Basically, it generates a new id for the node but then doesn't actually set the ID on the XML object | 00:02 |
| digshadow | jhol, daveshah: https://drive.google.com/file/d/17md09c9rSoocj70h3e466lzndTMvUJnf/view?usp=sharing | 04:59 |
| tpb | Title: ice40_function_routing_mirrored.png - Google Drive (at drive.google.com) | 04:59 |
| digshadow | I'm trying to understand how icebox represents routing vs buffer | 04:59 |
| digshadow | buffer 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 |
| digshadow | Note chart is from http://www.clifford.at/icestorm/bitdocs-1k/tile_1_1.html | 05:01 |
| tpb | Title: Project IceStorm iCE40 HX1K LOGIC Tile (1 1) (at www.clifford.at) | 05:01 |
| digshadow | mithro: fyi I have the switches in | 06:14 |
| digshadow | er pin edges | 06:15 |
| daveshah | digshadow: icebox does not to my knowledge automatically create two arcs in both directions for routing | 06:21 |
| daveshah | So you should treat as bidirectional | 06:21 |
| daveshah | I think the example you found is just an artefact of Lattice's architecture | 06:21 |
| daveshah | Where there happen to be two equivalent switches | 06:21 |
| digshadow | Hmm okay, I will handle that case then | 06:22 |
| digshadow | daveshah: btw in case it wasn't clear from above message, I'm just fixing a few buts | 06:23 |
| digshadow | but I more or less have a complete fabric loaded in | 06:23 |
| digshadow | bugs | 06:23 |
| daveshah | digshadow: Awesome! | 06:23 |
| digshadow | mithro: heading out for the night | 07:47 |
| digshadow | this is where I am | 07:47 |
| digshadow | https://drive.google.com/file/d/13WoYzVqi3ITV6Q_eDQFPOn7-4S10679h/view?usp=sharing | 07:47 |
| tpb | Title: long_pin_io.png - Google Drive (at drive.google.com) | 07:47 |
| digshadow | I 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 odd | 07:48 |
| digshadow | if you have any insight on those I'd be curious | 07:48 |
| digshadow | that is, the outputs seem to be directly connected to the right neighbors maybe | 07:48 |
| digshadow | on the logic tiles | 07:48 |
| digshadow | I/O tiles look reasonable, so maybe its fine | 07:48 |
| digshadow | in any case, the design is reporting as unroutable | 07:48 |
| daveshah | I can take a look today | 07:49 |
| digshadow | a general quick look I thought the design looked like it has a lot of connectivity, but I didn't investigate specifically | 07:49 |
| daveshah | The logic tiles do have neighbor connections | 07:49 |
| digshadow | its somewhat difficult to understand the pins since it selected a lot of other stuff | 07:49 |
| digshadow | daveshah: yeah but I don't see other neighbor connections, but maybe thats a GUI limitation | 07:49 |
| digshadow | I didn't look into it in detail | 07:49 |
| digshadow | daveshah: anyway I've pushed what I have so far if you want to take a look | 07:50 |
| digshadow | there is definitely something resembling the routing fabric at least | 07:50 |
| digshadow | to be clear, I've only tested with 384 | 07:50 |
| digshadow | ~/symbiflow-arch-defs/tests$ make wire.patched.disp ARCH=ice40 DEVICE_TYPE=top-routing-virt VPR=~/bin/vpr | 07:51 |
| digshadow | specifically is the command I'm running | 07:51 |
| digshadow | where the vpr command is my branch with the pin name stuff | 07:52 |
| digshadow | I'll be back in half hour or so | 07:52 |
| daveshah | Thanks, I'll take a peek | 07:52 |
| *** digshadow has quit IRC | 07:58 | |
| *** digshadow has joined #vtr-dev | 08:15 | |
| digshadow | daveshah: back | 08:16 |
| daveshah | Afraid I'm no further than you are | 08:16 |
| daveshah | Looks routable to me too... | 08:16 |
| digshadow | :( | 08:16 |
| daveshah | switch_id possibly looks wrong in the rr_graph? | 08:17 |
| digshadow | oh hmm | 08:17 |
| digshadow | it would be good to double check a lot of that | 08:17 |
| digshadow | Yeah very good point | 08:17 |
| digshadow | so the switch IDs are currently generated in the python code I think | 08:17 |
| digshadow | but they may need to match the arch.xml | 08:18 |
| digshadow | however, as long as the switch IDs were in range, maybe it wouldn't matter? | 08:18 |
| digshadow | definitely something to look at though | 08:18 |
| daveshah | it looked possibly like all the edges were "configurable="0"" in the rr_graph | 08:20 |
| daveshah | which could be a problem? | 08:20 |
| daveshah | OK this is interesting | 08:26 |
| daveshah | If I make switch ID 0 configurable, it actually routes | 08:26 |
| daveshah | if I try and use the "proper" switch IDs, VPR segfaults... | 08:26 |
| daveshah | digshadow: to get something routing, just change the line adding switch 0 to | 08:27 |
| daveshah | ` _switch_delayless = g.ids.add_switch('__vpr_delayless_switch__', buffered=1, configurable=1, stype='mux')` | 08:27 |
| digshadow | ah interesting. Maybe I added that incorrectly then | 08:33 |
| digshadow | I think that is a special internal thing, although I didn't look at it in detail | 08:33 |
| digshadow | thats cool though...sounds like we have something that possibly routed | 08:33 |
| digshadow | FYI I didn't touch a lot of the global clock stuff | 08:33 |
| daveshah | I suppose the next step is to integrate jhol's HLC stuff | 08:34 |
| daveshah | I'm not sure whether what I did is OK, or makes too much stuff configurable though | 08:34 |
| daveshah | I would like to use proper switch IDs, but I can't get that to work, so I don't know... | 08:35 |
| digshadow | yeah I'll review it in more detail tomorrow, but it sounds like it is related to switches | 08:35 |
| digshadow | to be clear | 08:35 |
| digshadow | proper means you are using them from arch.xml? | 08:35 |
| digshadow | as generated in the original rr_graph? | 08:35 |
| daveshah | no, leaving 0s alone and using 1 for routing and 2 for buffers | 08:36 |
| daveshah | it seems as soon as you give anything a switch ID that isn't 0 it segfaults | 08:36 |
| daveshah | so the solution for now is making switch 0 configurable | 08:36 |
| digshadow | so | 08:42 |
| digshadow | <switch id="2" type="mux" name="__vpr_delayless_switch__" buffered="1" configurable="1"> | 08:42 |
| digshadow | is in my ./build/ice40/LP384/wire.rr_graph.xml | 08:42 |
| digshadow | if 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 |
| digshadow | generated XML => the icebox based rr_graph | 08:43 |
| digshadow | going to sleep, will take a look tomorrow | 08:46 |
| daveshah | it becomes switch 0 in the generated things | 08:47 |
| digshadow | right, I'm propsing to create the switches to match the original | 08:47 |
| digshadow | I'm suspecting that it must be preserved | 08:47 |
| daveshah | Yeah I'll try that and let you know what happens | 08:48 |
| daveshah | It 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 |
| daveshah | Using any other switch seems to segfault VPR | 09:29 |
| *** digshadow has quit IRC | 10:52 | |
| *** digshadow has joined #vtr-dev | 10:52 | |
| *** elms has quit IRC | 13:54 | |
| *** elms has joined #vtr-dev | 13:54 | |
| jhol | digshadow, mithro: how goes it? | 18:06 |
| digshadow | jhol: you saw we sort of got something PnR'd in the fabric last night | 18:59 |
| digshadow | I'm not feeling super great today, haven't looked at it yet... | 19:00 |
| *** ZipCPU has quit IRC | 19:10 | |
| *** ZipCPU_ has joined #vtr-dev | 19:10 | |
| *** ZipCPU has joined #vtr-dev | 19:12 | |
| *** ZipCPU_ has quit IRC | 19:15 | |
| jhol | digshadow: do you think the demo is in with a shot? | 19:31 |
| digshadow | jhol: if we are able to do the simple wire demo, honestly I'd be happy | 19:32 |
| digshadow | I haven't tried processing the result to see if it generates a bitstream | 19:32 |
| jhol | well if you integrate the HLC branches in VPR and SymbiFlow arch defs, you'll get a bit steamy for sure | 19:34 |
| jhol | just won't have any span buffers :) | 19:34 |
| 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 https://github.com/mcmasterg/symbiflow-arch-defs/blob/a8f723f450c80e5182b4b148f8a28cc927a0c2a1/ice40/utils/icebox_rr_graph_import.py#L788 | 19:37 |
| tpb | Title: symbiflow-arch-defs/icebox_rr_graph_import.py at a8f723f450c80e5182b4b148f8a28cc927a0c2a1 · mcmasterg/symbiflow-arch-defs · GitHub (at github.com) | 19:37 |
| jhol | daveshah, 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 it | 19:40 |
| jhol | digshadow: 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 |
| mithro | Morning | 19:46 |
| mithro | digshadow: Hey | 19:46 |
| mithro | jhol: Morning | 19:48 |
| jhol | mithro: hi | 19:48 |
| mithro | jhol: Just seeing what digshadow got to last night will have to run away shortly however | 19:51 |
| mithro | jhol: 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 |
| mithro | daveshah: You were mentioning something about the switches? | 19:58 |
| daveshah | mithro: yeah | 19:58 |
| daveshah | digshadow's rr_graph wasn't routing | 19:58 |
| mithro | Currently the arch def has | 19:59 |
| daveshah | This is because all edges used switch ID 0 (the VPR delay less switch) which was set to not configurable | 19:59 |
| mithro | https://www.irccloud.com/pastebin/34qOY3AB/ | 19:59 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:59 |
| daveshah | I can get the rr_graph to route by making that switch configurable | 19:59 |
| daveshah | But using any other switch for the edges causes vpr to segfault | 19:59 |
| mithro | Which seems to end up with | 20:00 |
| mithro | https://www.irccloud.com/pastebin/yn48RTHc/ | 20:00 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 20:00 |
| daveshah | Yeah, I played about with the switch naming, numbering and ordering in the rr_graph file | 20:00 |
| mithro | looks like all the edges have a "switch_id='0'" ? | 20:00 |
| daveshah | Yeah exactly | 20:00 |
| daveshah | The problem is it segfaults whenever switch_id is set to a switch other than the VPR delay less one | 20:01 |
| daveshah | The solution to get the rr_graph routing was to keep them all on that switch, and make that switch configurable | 20:01 |
| daveshah | 9: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 https://github.com/mcmasterg/symbiflow-arch-defs/blob/a8f723f450c80e5182b4b148f8a28cc927a0c2a1/ice40/utils/icebox_rr_graph_import.py#L788 | 20:02 |
| tpb | Title: symbiflow-arch-defs/icebox_rr_graph_import.py at a8f723f450c80e5182b4b148f8a28cc927a0c2a1 · mcmasterg/symbiflow-arch-defs · GitHub (at github.com) | 20:02 |
| daveshah | That is how I got digshadow's rr_graph to route | 20:02 |
| daveshah | The only risk with that approach is that it might make too much stuff configurable | 20:02 |
| daveshah | But right now I think it's OK | 20:02 |
| mithro | daveshah: Okay | 20:03 |
| mithro | Yeah - just got a segfault here when I changed that too | 20:04 |
| daveshah | mithro: I did also play about quickly to see what happened with jhol's HLC writer using digshadow's rr_graph | 20:04 |
| daveshah | No routing was output, but it didn't crash or anything | 20:04 |
| daveshah | mithro: you mean changing the switch ID, or changing configurable only (only the former should segfault) | 20:05 |
| mithro | daveshah: Switch ID | 20:05 |
| daveshah | mithro: OK, that's what I expect. Good to confirm | 20:06 |
| daveshah | But as I say I think that's not a big issue for now, just using __vpr_delayless_switch__ should be fine | 20:06 |
| mithro | daveshah: I'm not getting successful routing? | 20:06 |
| daveshah | Even after changing configurable? | 20:06 |
| mithro | Oh | 20:07 |
| mithro | I see -- digshadow is rewriting the switches section | 20:07 |
| daveshah | Yeah | 20:07 |
| daveshah | You have to change configurable in the Python script | 20:07 |
| digshadow | mithro: right, I think looking back I should have left switches alone | 20:08 |
| *** digshadow has quit IRC | 21:57 | |
| *** digshadow has joined #vtr-dev | 21:58 | |
| *** digshadow has quit IRC | 22:37 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!