Friday, 2018-05-04

*** tpb has joined #vtr-dev00:00
digshadowjhol: FYI I was in the process of doing some rewrites00:04
digshadowwhich I've just finished00:04
digshadowassuming I don't hit a blocker, I'm hoping to have the locals + spans up tonight00:04
digshadowat a minimum00:04
digshadowmithro: 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 LUTs00:20
digshadowoh hmm wait sec00:24
tpbTitle: symbiflow-arch-defs/ntemplate.N384.fixed_layout.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
digshadowits just hte ocmment thats wrong00:28
digshadowmithro: fyi I (loosely) merged in your don't-clear-segments thing, I ran into it myself01:41
digshadowI saved an rr_graph that should have spans but VPR is complaining with a somewhat obscure assert, looking into it01:42
tpbTitle: rr_graph: overhanging track causes assertion failure · Issue #339 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
*** digshadow has quit IRC04:34
*** digshadow has joined #vtr-dev04:52
*** jhol has quit IRC05:19
*** jhol` has joined #vtr-dev05:19
*** jhol` is now known as jhol07:03
*** digshadow has quit IRC07:07
*** digshadow has joined #vtr-dev07:17
jholmithro, digshadow: how goes it?15:42
digshadowjhol: you saw the ticket? the ice40 fabric was partially loaded in and then ran into a vpr issue16:08
digshadowI'm going to implement a workaround today16:08
digshadowalthough maybe we'll also hear back from kem_16:08
jholyeah I saw some of that16:08
jholI've been trying you branch and I get a buffer overrun relating the CHANX/Y array16:09
digshadowoops looks like I have a copy paste error on the ticket16:09
jholdigshadow: also, I noticed that the python script throws an assertion if you include the changes I've made to the PLBs16:09
jhol-- correction: the PIOs16:09
digshadowjhol: do you have a rebased branch with my changes + yours?16:12
digshadowif so I'll grab that today16:12
jholdigshadow: 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 branch16:12
jhol(first time using the git worktree command today - really handy function)16:13
digshadowhmm never heard of that command16:14
digshadowto be clear, you got the error in the python code, not vpr right16:14
jholfor the PIO changes I got an assertion16:14
jholif I revert out all the PIO patches, the assertion goes away16:14
digshadowthe assertion is in vpr C++ or my python?16:15
jhola python assertion16:15
digshadowdo you have it handy by chance?16:15
jhol-- then if I give that rr_graph - with the reverted PIOS - to VPR, it crashes VPR16:15
jholsure... 1-sec16:15
digshadowif you have the xml handy  too I can try it maybe later and/or instructions how to generate it16:16
jholso the instruction is, checkout the github master branch of symbiflow-arch-defs16:18
jholthen go into the tests/ directory, and run this make command:16:19
jholmake ARCH=ice40 DEVICE_TYPE=tile-routing-virt DEVICE=HX1K VPR_ARGS='--write_rr_graph wire.rr_graph.xml' counter.echo16:19
jholI then created a symbolic link in my other worktree so that the rr_graph script loads wire.rr_graph.xml in the other directory16:20
digshadowgot it16:22
digshadowFWIW I'm testing mostly with the 38416:23
digshadowdo you believe that will work as well?16:23
jholhmmm... I think it might work ok16:24
jholit might work - I was just targeting the HX1K,16:24
jholbecause that's going to be the board you use for a demo - or no?16:25
digshadowpossibly, but there are so many nodes and such that debugging the routing on a smaller device is much easier16:26
jholfair enough16:26
jholok... so let me try with the 38416:26
digshadowI even went so far to try to add the t4 test device to icebox, but my quick attempt didn't work16:27
jholyeah I saw that - didn't have the code though, so I hacked it back out again16:27
jholso in general what's the status of what you've got?16:28
jholgot one day left to finish this off - I've got a few hours this evening16:29
jholare we still shooting for a demo of some kind?16:29
digshadowmithro: would like a demo16:29
digshadowThe plan is to try to get the spans + local routing in16:29
digshadowat a mininmum16:30
digshadowwhich would allow routing a simple design16:30
digshadowI need to do something to work around the vpr issue, but it shouldn't be too bad16:30
digshadowI believe adding the edges will be pretty straightforward16:30
jholso I was wondering if it's enough just to do the SPAN12s16:31
digshadowspan4 vs span12 I think isn't much difference16:31
digshadowthe channels are already being generated from the icebox database16:31
jholbecause they're are long enough to connect the pins to the buffers without needing to have any buffers along the way16:31
digshadowI'm just choosing to drop most of them right now16:31
digshadowbut sure, I'll keep that in mind16:31
jhol-- if the pin was horizontal or vertical to the PLB, there would be no need for buffers16:31
digshadowdid you get the error?16:33
digshadowI think you were trying to look that up16:33
jholwhich error?16:33
digshadowthe assertion failure16:33
digshadowI don't have my desktop with me, so I can't easily run your branch right now16:33
jholyeah with the PIOs included I get an assertion16:34
digshadowdo you have the message handy?16:34
jholhowever... if you revert the PIO patches with the branch I will provide in a second, the assertion goes away16:34
jhol-- I'll get the assertion for you16:34
digshadowif you have the adding net/node messages I think you are a little behind as those aren't printed by default anymore16:35
digshadow(I might not have pushed out though)16:36
jholok - I was running off mcmasterg/rr_graph_lib16:36
jholI wondered if there was any new stuff I was missing16:36
digshadowanyway, its complaining that it got a duplicated (block, pin) tuple16:36
digshadowwhen it was trying to figure out which side the pins are on16:36
digshadowwill keep in mind16:37
jholhmm ok.... maybe there's a problem in the arch XML16:37
digshadowpotentially but heh I don't have super high confidence in that code either :P16:38
jholanyway... I'm happy to work for a while into the evening local time, if you guys still believe we have a shot at a demo16:38
digshadowas 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 node16:38
digshadowto get the demo working, we will likely have to do some work over the weekend16:39
digshadowwe have an event today we need to go to for example16:39
jholwith my stuff, I'm just putting the finishing touches to the DFF16:39
jholI could possibly do a bit over the weekend, though I need to take care of various other things16:39
digshadowwell sounds like the main thing is if we have some questions to run by you16:40
digshadowif you are availible for irc/e-mail/we that would be helpful16:40
jholsure... or video call, also16:40
jholalso - maybe something mithro could do: figure out what the situation is with the pin-constraint file16:41
jholbecause otherwise you're LED output will be assigned a random pin16:42
digshadowah? I wasn't aware of that16:42
digshadowI take it you looked into it and aren't sure whats going on?16:42
jholI didn't try yet, because I don't care about the pin assignments16:43
jholif it's really hard, we could make a custom layout with all the pins we don't want deleted16:44
digshadowah okay16:44
digshadowto clarify then16:44
digshadownothing is known to be broken, its just that nobody has tried it?16:44
daveshahIf there's anything I can usefully do over the weekend to help with the demo, please feel free to ping me16:45
jholdaveshah: awesome!16:45
digshadowdaveshah: it might be helpful to have a smaller than lp384 device in icebox16:46
jholdaveshah: you might be interested to know my conclusion: HLC is absolutely unsuitable for inclusion in VPR code16:46
digshadowif you were willing to take a look at that16:46
daveshahdigshadow: yeah, it should be doable, I can probably get something done tomorrow morning16:49
daveshahjhol: good to know, at least we've worked that out16:49
digshadowdaveshah: ideally something that just had all the tile variation, and nothing else, in a non-square  aspect ratio16:50
digshadowie a logic area of maybe 3x4?16:50
digshadowI guess thats not too much smaller16:50
digshadowI was trying to do a 2x316:50
daveshahdigshadow: what problem were you hitting?16:51
digshadowI basically tried to copy some of the 384 stuff, I got some error though about bitstream had duplicate bit or something like that16:51
digshadowcorrection, I think my test was for a 2x2 logic area (the t4 device)16:52
digshadowlooking back, I should have probably just modified the lp384 create function16:53
daveshahdigshadow: yeah, that sounds like the way to do16:54
daveshahIt shouldn't be too hard, most of the stuff that takes time (colbufs, ierens, global inputs) for a real device can probably be ignoree16:54
jholif we want to do a counter, we need some way of getting the clock signal into glb_netwk_016:56
jholwelll... step back a bit...16:57
jholwe'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 tiles16:58
jholso we basically have to hard-code the in-tile routing for the clock input16:59
digshadowah? I was not aware of that17:00
digshadowto be clear, the other routing is not necessarily problematic17:00
digshadowits just that I have it commented out for now and am prioritizing spans17:00
digshadowthey may "just work"17:00
jholwell for starters you could a LUT demo without any clocks17:01
jholI think that should be the first priority17:01
daveshahjhol: 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
daveshahThen you can just set all the column buffer bits17:01
digshadowjhol: FWIW I was testing with wire to start with17:01
digshadowFYI I'm heading out soon, I might not be available again for 6 hours or so17:03
jholdigshadow: ok... then I'll summarise in an email17:03
jholdaveshah: ok! - and I think we can hard-code the network config in the HLC17:03
daveshahjhol: yeah, exactly17:03
*** digshadow has quit IRC17:09
daveshahjhol, digshadow: I have added a 2x3 device to icebox that's valid enough to generate a chipdb here:
tpbTitle: icestorm/ at tiny_ice40 · daveshah1/icestorm · GitHub (at
jhol- thanks17:21
daveshahno problem17:23
daveshahI hope this works with your scripts, but the fact it builds a chipdb means its successfully generating a routing graph17:23
*** digshadow has joined #vtr-dev17:46
benreynwarWhat's the demo you all are working on?17:49
jholbenreynwar: getting some hello world of the ice40 with VPR18:00
*** digshadow has quit IRC18:04
benreynwarjhol:  Cool.  Are you presenting on it somewhere?18:15
jholI'm not no, I'm just helping, and I can't say much about it - much as I'd like to18:16
benreynwarAh, no worries!  I'll look forward to knowing when it's not secret anymore :).18:18
*** digshadow has joined #vtr-dev18:35
*** digshadow has quit IRC21:36
jholdigshadow, mithro: ok... so I think everything necessary is done on my side, except the span buffers21:37
jholhere is my latest HLC output showing a 3-bit counter routed for the HX1K:
jhol-- I've been doing most of my testing with the 1k21:38
jholthis HLC output now supports the DFFs21: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 those21:41
jholalso because VPR can't handle muxing the CLK input, the clock is hard-coded to glb_netwk_021:42
jholas 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 sed21:43
jholto test the HLC output, you will need the following branches:21:44
tpbTitle: Commits · jhol/symbiflow-arch-defs · GitHub (at
tpbTitle: Commits · jhol/vtr-verilog-to-routing · GitHub (at
tpbTitle: Commits · jhol/icestorm · GitHub (at
jholyou will also need a git-master build of yosys for the -nodffe option21:44
jholto make an HLC output...21:45
jholfirst build the architecture XML21:45
jholthen go into tests21:45
jholmake ARCH=ice40 DEVICE_TYPE=tile-routing-virt DEVICE=HX1K counter.echo21:47
jholright 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
jholyou will find the output file in symbiflow-arch-defs/tests/build/ice40/HX1K/top.hlc21:48
jholnow in my branch of icestorm, run /path/to/top.hlc > top.asc21:49
jholif all goes well, you'll get an ASC file out ready for binary encoding with icebox21:50
jholalso it can be helpful to run the ASC file back through and sanity check21:50 as far I'm concerned there's two issues left...21:51
jhol1. sorting out the rr_graph, and implementing the span buffers in the HLC (- though is it possible to do without them?)21:52
jhol2. 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 way21:53 mithro, digshadow - gentlemen: good luck! I believe in you21:54
*** digshadow has joined #vtr-dev23:41
digshadowback for a bit23:58

Generated by 2.13.1 by Marius Gedminas - find it at!