| *** tpb has joined #vtr-dev | 00:00 | |
| digshadow | jhol: FYI I was in the process of doing some rewrites | 00:04 |
|---|---|---|
| digshadow | which I've just finished | 00:04 |
| digshadow | assuming I don't hit a blocker, I'm hoping to have the locals + spans up tonight | 00:04 |
| digshadow | at a minimum | 00:04 |
| digshadow | mithro: FYI I'm adjusting the arch.xml def for LP384. Looks like its 6x8, which checks out for (6 * 8) * 8 luts per PLB => 384 LUTs | 00:20 |
| digshadow | oh hmm wait sec | 00:24 |
| digshadow | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/devices/layouts/N384/ntemplate.N384.fixed_layout.xml | 00:27 |
| tpb | Title: symbiflow-arch-defs/ntemplate.N384.fixed_layout.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 00:27 |
| digshadow | yeah | 00:27 |
| digshadow | its just hte ocmment thats wrong | 00:28 |
| digshadow | mithro: fyi I (loosely) merged in your don't-clear-segments thing, I ran into it myself | 01:41 |
| digshadow | I saved an rr_graph that should have spans but VPR is complaining with a somewhat obscure assert, looking into it | 01:42 |
| digshadow | mithro: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/339 | 04:25 |
| tpb | Title: rr_graph: overhanging track causes assertion failure · Issue #339 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 04:25 |
| *** digshadow has quit IRC | 04:34 | |
| *** digshadow has joined #vtr-dev | 04:52 | |
| *** jhol has quit IRC | 05:19 | |
| *** jhol` has joined #vtr-dev | 05:19 | |
| *** jhol` is now known as jhol | 07:03 | |
| *** digshadow has quit IRC | 07:07 | |
| *** digshadow has joined #vtr-dev | 07:17 | |
| jhol | mithro, digshadow: how goes it? | 15:42 |
| digshadow | jhol: you saw the ticket? the ice40 fabric was partially loaded in and then ran into a vpr issue | 16:08 |
| digshadow | I'm going to implement a workaround today | 16:08 |
| digshadow | although maybe we'll also hear back from kem_ | 16:08 |
| jhol | yeah I saw some of that | 16:08 |
| jhol | I've been trying you branch and I get a buffer overrun relating the CHANX/Y array | 16:09 |
| digshadow | oops looks like I have a copy paste error on the ticket | 16:09 |
| jhol | digshadow: also, I noticed that the python script throws an assertion if you include the changes I've made to the PLBs | 16:09 |
| jhol | -- correction: the PIOs | 16:09 |
| digshadow | jhol: do you have a rebased branch with my changes + yours? | 16:12 |
| digshadow | if so I'll grab that today | 16:12 |
| jhol | digshadow: no I did it with two git worktrees - one pointed at your branch or mithro/ice40-test, and the other pointed at master and my HLC branch | 16:12 |
| digshadow | gotcha | 16:13 |
| jhol | (first time using the git worktree command today - really handy function) | 16:13 |
| digshadow | hmm never heard of that command | 16:14 |
| digshadow | to be clear, you got the error in the python code, not vpr right | 16:14 |
| jhol | for the PIO changes I got an assertion | 16:14 |
| jhol | if I revert out all the PIO patches, the assertion goes away | 16:14 |
| digshadow | the assertion is in vpr C++ or my python? | 16:15 |
| jhol | a python assertion | 16:15 |
| digshadow | do you have it handy by chance? | 16:15 |
| jhol | -- then if I give that rr_graph - with the reverted PIOS - to VPR, it crashes VPR | 16:15 |
| jhol | sure... 1-sec | 16:15 |
| digshadow | if you have the xml handy too I can try it maybe later and/or instructions how to generate it | 16:16 |
| jhol | so the instruction is, checkout the github master branch of symbiflow-arch-defs | 16:18 |
| jhol | then go into the tests/ directory, and run this make command: | 16:19 |
| jhol | make ARCH=ice40 DEVICE_TYPE=tile-routing-virt DEVICE=HX1K VPR_ARGS='--write_rr_graph wire.rr_graph.xml' counter.echo | 16:19 |
| jhol | I then created a symbolic link in my other worktree so that the rr_graph script loads wire.rr_graph.xml in the other directory | 16:20 |
| digshadow | got it | 16:22 |
| digshadow | FWIW I'm testing mostly with the 384 | 16:23 |
| digshadow | do you believe that will work as well? | 16:23 |
| jhol | hmmm... I think it might work ok | 16:24 |
| jhol | it might work - I was just targeting the HX1K, | 16:24 |
| jhol | because that's going to be the board you use for a demo - or no? | 16:25 |
| digshadow | possibly, but there are so many nodes and such that debugging the routing on a smaller device is much easier | 16:26 |
| jhol | fair enough | 16:26 |
| jhol | ok... so let me try with the 384 | 16:26 |
| digshadow | I even went so far to try to add the t4 test device to icebox, but my quick attempt didn't work | 16:27 |
| jhol | yeah I saw that - didn't have the code though, so I hacked it back out again | 16:27 |
| jhol | so in general what's the status of what you've got? | 16:28 |
| jhol | got one day left to finish this off - I've got a few hours this evening | 16:29 |
| jhol | are we still shooting for a demo of some kind? | 16:29 |
| digshadow | mithro: would like a demo | 16:29 |
| digshadow | The plan is to try to get the spans + local routing in | 16:29 |
| digshadow | at a mininmum | 16:30 |
| digshadow | which would allow routing a simple design | 16:30 |
| digshadow | I need to do something to work around the vpr issue, but it shouldn't be too bad | 16:30 |
| jhol | ok... | 16:30 |
| digshadow | I believe adding the edges will be pretty straightforward | 16:30 |
| jhol | so I was wondering if it's enough just to do the SPAN12s | 16:31 |
| digshadow | span4 vs span12 I think isn't much difference | 16:31 |
| digshadow | the channels are already being generated from the icebox database | 16:31 |
| jhol | because they're are long enough to connect the pins to the buffers without needing to have any buffers along the way | 16:31 |
| digshadow | I'm just choosing to drop most of them right now | 16:31 |
| digshadow | but sure, I'll keep that in mind | 16:31 |
| jhol | -- if the pin was horizontal or vertical to the PLB, there would be no need for buffers | 16:31 |
| digshadow | oh | 16:33 |
| digshadow | did you get the error? | 16:33 |
| digshadow | I think you were trying to look that up | 16:33 |
| jhol | which error? | 16:33 |
| digshadow | the assertion failure | 16:33 |
| digshadow | I don't have my desktop with me, so I can't easily run your branch right now | 16:33 |
| jhol | yeah with the PIOs included I get an assertion | 16:34 |
| digshadow | do you have the message handy? | 16:34 |
| jhol | however... if you revert the PIO patches with the branch I will provide in a second, the assertion goes away | 16:34 |
| jhol | -- I'll get the assertion for you | 16:34 |
| jhol | digshadow: https://paste2.org/1EwwH2vm | 16:35 |
| digshadow | if you have the adding net/node messages I think you are a little behind as those aren't printed by default anymore | 16:35 |
| digshadow | fwiw | 16:35 |
| digshadow | (I might not have pushed out though) | 16:36 |
| jhol | ok - I was running off mcmasterg/rr_graph_lib | 16:36 |
| jhol | I wondered if there was any new stuff I was missing | 16:36 |
| digshadow | anyway, its complaining that it got a duplicated (block, pin) tuple | 16:36 |
| digshadow | when it was trying to figure out which side the pins are on | 16:36 |
| digshadow | will keep in mind | 16:37 |
| jhol | hmm ok.... maybe there's a problem in the arch XML | 16:37 |
| digshadow | potentially but heh I don't have super high confidence in that code either :P | 16:38 |
| jhol | anyway... I'm happy to work for a while into the evening local time, if you guys still believe we have a shot at a demo | 16:38 |
| digshadow | as a side note, I'd like to discuss with kem_ about that as I was thinking the pin direction should maybe go on the blocktype instead of the node | 16:38 |
| digshadow | to get the demo working, we will likely have to do some work over the weekend | 16:39 |
| digshadow | we have an event today we need to go to for example | 16:39 |
| jhol | with my stuff, I'm just putting the finishing touches to the DFF | 16:39 |
| jhol | I could possibly do a bit over the weekend, though I need to take care of various other things | 16:39 |
| digshadow | well sounds like the main thing is if we have some questions to run by you | 16:40 |
| digshadow | if you are availible for irc/e-mail/we that would be helpful | 16:40 |
| jhol | sure... or video call, also | 16:40 |
| jhol | also - maybe something mithro could do: figure out what the situation is with the pin-constraint file | 16:41 |
| jhol | because otherwise you're LED output will be assigned a random pin | 16:42 |
| digshadow | ah? I wasn't aware of that | 16:42 |
| digshadow | I take it you looked into it and aren't sure whats going on? | 16:42 |
| jhol | I didn't try yet, because I don't care about the pin assignments | 16:43 |
| jhol | if it's really hard, we could make a custom layout with all the pins we don't want deleted | 16:44 |
| digshadow | ah okay | 16:44 |
| digshadow | to clarify then | 16:44 |
| digshadow | nothing is known to be broken, its just that nobody has tried it? | 16:44 |
| jhol | exactly | 16:44 |
| digshadow | gotcha | 16:44 |
| daveshah | If there's anything I can usefully do over the weekend to help with the demo, please feel free to ping me | 16:45 |
| jhol | daveshah: awesome! | 16:45 |
| digshadow | daveshah: it might be helpful to have a smaller than lp384 device in icebox | 16:46 |
| jhol | daveshah: you might be interested to know my conclusion: HLC is absolutely unsuitable for inclusion in VPR code | 16:46 |
| digshadow | if you were willing to take a look at that | 16:46 |
| daveshah | digshadow: yeah, it should be doable, I can probably get something done tomorrow morning | 16:49 |
| daveshah | jhol: good to know, at least we've worked that out | 16:49 |
| digshadow | daveshah: ideally something that just had all the tile variation, and nothing else, in a non-square aspect ratio | 16:50 |
| digshadow | ie a logic area of maybe 3x4? | 16:50 |
| digshadow | I guess thats not too much smaller | 16:50 |
| digshadow | I was trying to do a 2x3 | 16:50 |
| daveshah | digshadow: what problem were you hitting? | 16:51 |
| digshadow | I basically tried to copy some of the 384 stuff, I got some error though about bitstream had duplicate bit or something like that | 16:51 |
| digshadow | correction, I think my test was for a 2x2 logic area (the t4 device) | 16:52 |
| digshadow | looking back, I should have probably just modified the lp384 create function | 16:53 |
| daveshah | digshadow: yeah, that sounds like the way to do | 16:54 |
| daveshah | It shouldn't be too hard, most of the stuff that takes time (colbufs, ierens, global inputs) for a real device can probably be ignoree | 16:54 |
| daveshah | *ignored | 16:54 |
| jhol | if we want to do a counter, we need some way of getting the clock signal into glb_netwk_0 | 16:56 |
| jhol | welll... step back a bit... | 16:57 |
| jhol | we're in a bit of a bind with the clock inputs to the PLBs, because VPR makes an error, if there is and non-trivial routing of the clock signal in the tiles | 16:58 |
| jhol | so we basically have to hard-code the in-tile routing for the clock input | 16:59 |
| digshadow | ah? I was not aware of that | 17:00 |
| digshadow | to be clear, the other routing is not necessarily problematic | 17:00 |
| digshadow | its just that I have it commented out for now and am prioritizing spans | 17:00 |
| digshadow | they may "just work" | 17:00 |
| jhol | well for starters you could a LUT demo without any clocks | 17:01 |
| jhol | I think that should be the first priority | 17:01 |
| daveshah | jhol: if you use a dedicated global input pin, then you only need to set one bit to connect the pin to the global (padin) | 17:01 |
| daveshah | Then you can just set all the column buffer bits | 17:01 |
| digshadow | jhol: FWIW I was testing with wire to start with | 17:01 |
| digshadow | FYI I'm heading out soon, I might not be available again for 6 hours or so | 17:03 |
| jhol | digshadow: ok... then I'll summarise in an email | 17:03 |
| jhol | daveshah: ok! - and I think we can hard-code the network config in the HLC | 17:03 |
| daveshah | jhol: yeah, exactly | 17:03 |
| *** digshadow has quit IRC | 17:09 | |
| daveshah | jhol, digshadow: I have added a 2x3 device to icebox that's valid enough to generate a chipdb here: https://github.com/daveshah1/icestorm/blob/tiny_ice40/icebox/icebox.py | 17:20 |
| tpb | Title: icestorm/icebox.py at tiny_ice40 · daveshah1/icestorm · GitHub (at github.com) | 17:20 |
| jhol | :) | 17:20 |
| jhol | - thanks | 17:21 |
| daveshah | no problem | 17:23 |
| daveshah | I hope this works with your scripts, but the fact it builds a chipdb means its successfully generating a routing graph | 17:23 |
| *** digshadow has joined #vtr-dev | 17:46 | |
| benreynwar | What's the demo you all are working on? | 17:49 |
| jhol | benreynwar: getting some hello world of the ice40 with VPR | 18:00 |
| *** digshadow has quit IRC | 18:04 | |
| benreynwar | jhol: Cool. Are you presenting on it somewhere? | 18:15 |
| jhol | I'm not no, I'm just helping, and I can't say much about it - much as I'd like to | 18:16 |
| benreynwar | Ah, no worries! I'll look forward to knowing when it's not secret anymore :). | 18:18 |
| *** digshadow has joined #vtr-dev | 18:35 | |
| *** digshadow has quit IRC | 21:36 | |
| jhol | digshadow, mithro: ok... so I think everything necessary is done on my side, except the span buffers | 21:37 |
| jhol | here is my latest HLC output showing a 3-bit counter routed for the HX1K: https://paste2.org/N9xkHPdH | 21:38 |
| jhol | -- I've been doing most of my testing with the 1k | 21:38 |
| jhol | this HLC output now supports the DFFs | 21:40 |
| jhol | -- not that only SB_DFF is supported - no SB_DFF N/E/S/S, so yosys has to be configured to not emit those | 21:41 |
| jhol | also because VPR can't handle muxing the CLK input, the clock is hard-coded to glb_netwk_0 | 21:42 |
| jhol | as daveshah mentioned, it's really simple to route a clock-input pin to the global network with a single bit, so once you decide which pin that will be on the demo board, we can hard-code the global network config into the HLC output - or just hack it in there with sed | 21:43 |
| jhol | to test the HLC output, you will need the following branches: | 21:44 |
| jhol | https://github.com/jhol/symbiflow-arch-defs/commits/hlc-out | 21:44 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 21:44 |
| jhol | https://github.com/jhol/vtr-verilog-to-routing/commits/hlc | 21:44 |
| tpb | Title: Commits · jhol/vtr-verilog-to-routing · GitHub (at github.com) | 21:44 |
| jhol | https://github.com/jhol/icestorm/commits/hlc-work | 21:44 |
| tpb | Title: Commits · jhol/icestorm · GitHub (at github.com) | 21:44 |
| jhol | you will also need a git-master build of yosys for the -nodffe option | 21:44 |
| jhol | to make an HLC output... | 21:45 |
| jhol | first build the architecture XML | 21:45 |
| jhol | then go into tests | 21:45 |
| jhol | make ARCH=ice40 DEVICE_TYPE=tile-routing-virt DEVICE=HX1K counter.echo | 21:47 |
| jhol | right at the end of the stdout spew, you should see this link: "Writing Implementation FASM: top.hlc " | 21:47 |
| jhol | (this command must be run in symbiflow-arch-defs/tests) | 21:48 |
| jhol | you will find the output file in symbiflow-arch-defs/tests/build/ice40/HX1K/top.hlc | 21:48 |
| jhol | now in my branch of icestorm, run icebox_hlc2asc.py /path/to/top.hlc > top.asc | 21:49 |
| jhol | if all goes well, you'll get an ASC file out ready for binary encoding with icebox | 21:50 |
| jhol | also it can be helpful to run the ASC file back through icebox_asc2hlc.py and sanity check | 21:50 |
| jhol | ...so as far I'm concerned there's two issues left... | 21:51 |
| jhol | 1. sorting out the rr_graph, and implementing the span buffers in the HLC (- though is it possible to do without them?) | 21:52 |
| jhol | 2. figure out how to make VPR to pin-constraints (- if this isn't easy, we could make a custom layout with unwanted pins removed, then pick a random seed that makes them come out in the correct order) | 21:52 |
| jhol | -- for tomorrow I'll probably be spending time with the family, but if you need me I can probably fit in a web meeting or IRC discussion if I can help in any way | 21:53 |
| jhol | ...so mithro, digshadow - gentlemen: good luck! I believe in you | 21:54 |
| *** digshadow has joined #vtr-dev | 23:41 | |
| digshadow | back for a bit | 23:58 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!