| *** tpb has joined #vtr-dev | 00:00 | |
| digshadow | mithro: I need to change the connections, but I got a generated rr_graph to load | 00:45 |
|---|---|---|
| mithro | digshadow: \o/ | 01:21 |
| mithro | digshadow: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/100 | 02:33 |
| tpb | Title: testarch: Adding a testarch with a longline in it. by mithro · Pull Request #100 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 02:33 |
| mithro | digshadow: That pull request is interesting because it has a "longline" in it which is a segment which is suppose to be connected to every tile in the device.. | 02:46 |
| digshadow | mithro: I think the bigger question is, when you say "request review" do you want an honest review | 02:47 |
| digshadow | or are you using it more as an FYI | 02:47 |
| mithro | digshadow: More as a "check I haven't done something really stupid" type thing :-) | 02:47 |
| digshadow | I'm doing a super cursory look for general feel, but I'm not checking connections | 02:48 |
| digshadow | mithro: I have a reasonably reduced test case for the floating rr_graph arrow thing | 02:56 |
| digshadow | I'll create a ticket for review | 02:56 |
| digshadow | actually I think I know the real issue | 02:57 |
| digshadow | sec let me verify... | 02:57 |
| digshadow | yeah | 02:57 |
| digshadow | it occurs when you connect between directional tracks | 02:58 |
| digshadow | and you are connecting to a direction that doesn't make sense | 02:58 |
| digshadow | it extrapolates where to draw based on the channel direction, not where the connection actually is | 02:58 |
| digshadow | ideally the rr_graph parser would reject an rr_graph containing these | 02:59 |
| mithro | digshadow: I'm unsure what should be rejected, we might want some weird connects :-P | 03:09 |
| digshadow | mithro: we can discuss it on the ticket | 03:13 |
| digshadow | almost have it ready | 03:13 |
| digshadow | https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/335 | 03:15 |
| tpb | Title: rr_graph reader: review unexpected channel direction edges · Issue #335 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 03:15 |
| mithro | kem_: Just rediscovered https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/246 | 03:20 |
| tpb | Title: Invalid RR Graph constructed when pass_gate switches used · Issue #246 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 03:20 |
| digshadow | mithro: is it legal to swap pin sides in the rr_graph vs the source xml | 04:17 |
| digshadow | ie the reference xml says its on the left, but I output it to the right | 04:17 |
| digshadow | think not | 04:19 |
| mithro | No idea? | 04:20 |
| digshadow | I just tried a simpler case and it gave a message | 04:20 |
| digshadow | sec | 04:20 |
| digshadow | draw_pin_to_chan_edge: Assertion 'grid_type->pinloc[grid_tile.width_offset][grid_tile.height_offset][pin_rr.side()][pin_rr.pin_num()]' failed (Pin coordinates should match block type pin locations). | 04:20 |
| digshadow | the other error I'm getting is more obscure, but I think its related | 04:21 |
| digshadow | mithro: this means that add_pins_for_block() is context sensitive to the original layout | 04:21 |
| mithro | digshadow: I'm not sure I understand? | 05:41 |
| *** digshadow has quit IRC | 06:07 | |
| *** digshadow has joined #vtr-dev | 06:25 | |
| *** digshadow has quit IRC | 07:48 | |
| *** digshadow has joined #vtr-dev | 08:05 | |
| mithro | Morning! | 15:00 |
| mithro | hey jhol - how do things go? | 15:00 |
| jhol | things going alright - working on HLC | 15:02 |
| mithro | jhol: How is it going, I had a quick look at your changes and they looked pretty sensible as far as I could tell | 15:02 |
| jhol | cool cool | 15:02 |
| jhol | can't get much further with the routing without the rr_graph, though the output isn't too far off the mark, and I think the machinery isn't too bad | 15:02 |
| jhol | so I'm just putting in the LUT truth tables | 15:03 |
| mithro | jhol: So, we should be able to generate a design which is just a single PLB? | 15:33 |
| mithro | (and use icestorm for the fabric routing?) | 15:34 |
| mithro | jhol: BTW If you don't say my nick, then it is likely I'll miss you saying things here... | 15:35 |
| jhol | mithro: yeah - we're getting there, but there's no span wires until I can run VPR with the rr_graph | 15:46 |
| jhol | also the PIO needs some basic implementation in the arch XML - this will be needed for the place-and-route, and the HLC converter will use the existing machinery to write out the PIO config | 15:48 |
| jhol | also I havn't handled the DFFs yet | 15:48 |
| jhol | so there's a bunch of things to take care of before the output is working | 15:48 |
| jhol | https://paste2.org/6pUFMH4f | 15:59 |
| jhol | if you squint a bit, it's beginning to resemble the target: https://paste2.org/HIy5LZaZ | 16:00 |
| mithro | jhol: I started a PIO implementation... | 16:31 |
| mithro | I wonder what happened to it... | 16:31 |
| digshadow | mithro: btw not sure if I mentioned | 17:09 |
| digshadow | where things stand right now is that I can add IPIN/SINk type nodes | 17:10 |
| digshadow | but when I add an OPIN/SOURCE VPR crashes | 17:10 |
| digshadow | thought I had it handy... | 17:11 |
| digshadow | jhol: noted you are getting near blocked, hmm | 17:18 |
| *** digshadow has quit IRC | 17:55 | |
| jhol | mithro: you did have a PIO tile that got deleted in the great rework of a couple of weeks ago | 18:12 |
| jhol | I'll dig it back up | 18:12 |
| jhol | mithor: I'm going to focus on the PIO, because I think if I can get an rr_graph, then with these two things and everything I have, we're close to being able to do a LUT demo | 18:13 |
| jhol | which is the closest thing we have to a hello world | 18:13 |
| jhol | beyond that, getting the DFF up and running shouldn't be so far, but at least we have something to show if we run out of time | 18:14 |
| daveshah | For now when doing IO I would keep it simple and just treat them as plain inputs or outputs | 18:20 |
| daveshah | The IO register and DDR can always come later - e.g. arachne-pnr still doesn't automatically pack IO registers | 18:20 |
| jhol | sure - nothing fancy, but we do need to get the structure a bit closer - each PIO tile has 2x pads for example | 18:21 |
| daveshah | Yeah, of course | 18:21 |
| daveshah | You'll also need to deal with the naming change between IO tile nets and logic tile nets | 18:22 |
| daveshah | Also beware that the span4s in IO tiles go "around the corner" if using IO close to the corner | 18:22 |
| jhol | that's a problem for digshadow-c :) | 18:23 |
| jhol | -- hopefully we can do without span-wires on PIOs for now | 18:23 |
| jhol | hmm.. well actually I don't know | 18:24 |
| jhol | but hopefully there's something that will work | 18:24 |
| daveshah | Yeah, span wires between IO aren't needed | 18:25 |
| daveshah | Span wires from IO to fabric would probably be useful, but even then I think not strictly speaking needed | 18:25 |
| daveshah | As you can use the neighbour connections | 18:25 |
| daveshah | All the things like the corners are in icebox anyway, so just creating a routing graph from icebox should be OK | 18:26 |
| jhol | mithro: ok... I'm out of time for today, bit the PIO is coming along. all the inner pb_types are in. bit of work to do at the tile level still | 20:39 |
| jhol | I'm out on Monday, and half of Tuesday, but I'll be back on the project after that | 20:40 |
| *** digshadow has joined #vtr-dev | 21:21 | |
| digshadow | jhol: FYI I was able to pnr on some small generated rr graphs | 23:00 |
| digshadow | working on cleanup + scaling a bit now | 23:00 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!