Wednesday, 2018-04-11

*** tpb has joined #vtr-dev00:00
jholthat's weird - carry chains aren't working07:53
jholit's decided to spread the FFs in random order between two PLBs07:54
daveshahIs there actually a SB_CARRY pb_type and model defined?08:31
daveshahAssuming this is ice4008:31
daveshahLooks like there is one - just didn't see it08:34
jholthere is one define, and it looks like it's correct09:25
jholthere's a more significant issue: the <mode> tags are wrapped around the lutff, but they should be wrapped around the whole tile09:26
jholyou can't individually configure each cell to take set/reset, enable, clock/inv clk etc.09:28
jholonly all 8 cells in a tile09:28
jholhere's the BLIF for a 3-bit counter:
tpbTitle: # Generated by Yosys 0.7+554 (git sha1 617c60ce, clang 4.0.1-6 -fPIC -Os) .mo - (at
jholyoysys decided to map it to a SB_DFF, a SB_DFFE, and a SB_DFF (why?) - which warrants two tiles09:29
jholat the moment VPR thinks it can put them all in one09:29
mithrojhol: I'm not sure about your "can't individually configure each cell to take set/reset, enable, clock/inv clk etc" bit?17:38
jholmithro: morning! - I checked it - I'm pretty sure it's true17:39
mithrojhol: Let me take a look at the description, it may be the case that things still work17:39
jholfor 2 reasons 1- see page "2-2" of the DS1040 datasheet17:39
tpbTitle: Project IceStorm iCE40 HX1K LOGIC Tile (4 15) (at
jholat least NegClk is a single flag shared with the whole tile in the bit docs17:42
jholfor lutff_global/cen, there's the buffers that select the input, but not there's one mode where no cen input is selected i.e. always enabled - I would think17:45
jholsame with lutff_globals/s_r17:45
jholyup - that's correct - one clk, cen, s_r  config for the whole tile17:47
jholso I've been moving the <mode> tags out to higher levels of the PLB, but this entails lots of restructuring, and lots of duplicated XML which I've been factoring into includes17:49
digshadowmithro: so looking over things some more, think I had a misunderstaning about the current state of htings18:13
digshadowto be clear, the proposal is to take your graph library to import the base tile layout from a generated rr_graph file (ie using make wire.rr_graph.xml)18:13
digshadowand then add the real interconnect to the rr_graph based off of the icebox stuff18:14
digshadowthat was under the assumption that the tile layout was correct as I saw that it listed DEVICE=HX1K18:14
digshadowbut this is actually a test layout, which means I can't do a real import18:14
digshadoware you expecting me to write a proper grid or is that something jhol is working on?18:15
digshadowhmm wait18:17
digshadowI think I may just be pointing at something smaller18:17
digshadowyup were good18:21
daveshahI'm pretty sure CEN and SR can be enabled or disabled per channel, but the signal if used is shared18:24
jholdigshadow: the grid will be correct coming in from the rr_graph18:40
jhol-- except that it will have a ring of empty blocks around it18:41
jholdaveshah: I could be wrong, but that doesn't accord with what I see in DS1040 page 2-2, and in the tile docs, I only see flags to mux CEN and SR at the tile level, nothing at the cell level:
tpbTitle: Project IceStorm iCE40 HX1K LOGIC Tile (4 15) (at
jholdigshadow: with the node rr_graph, the intra-tile nodes+links should be 100% correct18:47
jholthe inter-tile nodes should be possible to specify correctly - just not the links18:47
jhol--- in other words, the VPR architecture XML is rich enough to completely describe how tiles are wired up18:48
jholthat includes everything from the LUTFFs out to the local tracks18:49
jholthe architecture XML capabilities gets a bit fishy when it comes to the spans and neighbour tracks18:50
jholI will still try and get these modelled as closely as I can, because otherwise the packer would set the router up to fail18:50
jholalso the arch XML is fishy in regard to the global nets, in the injectors to the global nets IIRC18:51
jhol*and the injectors18:51
jholso my sense is that you want to keeps the mods to the rr_graph as minimal as possible - carry through any parts of the graph that are trustworthy, but rewrite parts that are not18:54
jholI'm working on something else thursday/friday, back on this project next monday18:54
jholI will be contactable the whole time if you need to have a chat18:55
jhol-- there's a slim chance I can get you a current rr_graph today. that might help you on your way18:55
jhol...though beware, as I debug the Architecture XML, there might be changes18:56
daveshahjhol: Yep, my mistake, see here:
tpbTitle: Project IceStorm LOGIC Tile Documentation (at
jholdaveshah: no it's good having people probe what I'm saying, makes me checks things19:04
mithrodigshadow: There are multiple "device" configs in the file IIRC19:24
mithrodigshadow: Some are small for testing19:24
mithrodigshadow: Some are real19:24
digshadowmithro: its something else19:24
mithrodigshadow: Also, I could have screwed up the tilegrid or temporarily deleted some of it :-)19:25
jholthe HX1K one is correct19:26
jhol-- well... the pads are all there19:26
mithrodigshadow: Do you mean these -> ?19:26
tpbTitle: symbiflow-arch-defs/arch.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
jholthe ice4 and HX0K are missing left+right pads, unless you use my unpub19:27
digshadowmithro: yes19:27
jholdigshadow: the PAD tiles should all be BLK_BB-VPR_PAD19:27
jholI've got a patch for that19:27
digshadowmithro: I take it you haven't gotten to cleaning up your code for master?19:28
jhol--- in earlier versions there was a distinction between LR and TB pads, I might be bringing that back19:28
jholdigshadow: I'll publish my branch soon. it's a bit tidier19:28
mithrojhol: them being BLK_BB-VPR_PAD is a temporary thing until the PIO model is good / works ->
tpbTitle: symbiflow-arch-defs/ice40/tiles at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
jholmithro: that makes sense... the PIOs seem very underdeveloped19:29
jholI'll get on that soon19:29
mithrodigshadow: Sadly no, decided I needed to get to bed before midnight yesterday19:29
mithrojhol: I think we can mostly leave the PIOs until later?19:30
jholhope so19:31
jholat the moment I'm trying to get a 3-bit carry chain to work19:31
mithrojhol: Oh - I can explain about the carry chain on the vpr side of things19:32
mithrojhol: Is it packing the atoms into molecules correctly?19:32
mithrojhol: See the "Port Override Example: Carry Chains" here ->
tpbTitle: Architecture Reference Verilog-to-Routing 8.0.0-dev documentation (at
jholno it's busted... but the atecedent problem is that yosys implemented the chain with a SR_DFF+SR_DFFE+SR_DFF, which is wrong19:33
jhol-- the whole tile has to be SR_DFF or SR_DFFE19:34
jholhence me working on fixing the modes19:34
mithrojhol: And the "Special Case:" at
tpbTitle: Architecture Reference Verilog-to-Routing 8.0.0-dev documentation (at
mithrojhol: I have to run now - but I'm pretty sure you don't need to fix the modes the way you are doing...19:35
jholyes i saw that19:35
jholwhy not? the packer will pack incompatible DFFs together if it isn't fixed19:35
jholhere's my work-in-progress changes to fix the modes:
tpbTitle: Commits · jhol/symbiflow-arch-defs · GitHub (at
jholthough this version now crashes VPR - I think because I messed up the *molecular structure*20:01
mithrojhol: The packer takes into account valid routing -- so if packing a DFF together causes a routing conflict it will reject the packing if I understand correctly?21:16
*** elms has joined #vtr-dev23:24

Generated by 2.13.1 by Marius Gedminas - find it at!