| *** tpb has joined #vtr-dev | 00:00 | |
| jhol | that's weird - carry chains aren't working | 07:53 |
|---|---|---|
| jhol | it's decided to spread the FFs in random order between two PLBs | 07:54 |
| daveshah | Is there actually a SB_CARRY pb_type and model defined? | 08:31 |
| daveshah | Assuming this is ice40 | 08:31 |
| daveshah | Looks like there is one - just didn't see it | 08:34 |
| jhol | there is one define, and it looks like it's correct | 09:25 |
| jhol | there's a more significant issue: the <mode> tags are wrapped around the lutff, but they should be wrapped around the whole tile | 09:26 |
| jhol | you can't individually configure each cell to take set/reset, enable, clock/inv clk etc. | 09:28 |
| jhol | only all 8 cells in a tile | 09:28 |
| jhol | here's the BLIF for a 3-bit counter: https://pastebin.com/fwX8JZns | 09:28 |
| tpb | Title: # Generated by Yosys 0.7+554 (git sha1 617c60ce, clang 4.0.1-6 -fPIC -Os) .mo - Pastebin.com (at pastebin.com) | 09:28 |
| jhol | yoysys decided to map it to a SB_DFF, a SB_DFFE, and a SB_DFF (why?) - which warrants two tiles | 09:29 |
| jhol | at the moment VPR thinks it can put them all in one | 09:29 |
| mithro | Morning | 17:36 |
| mithro | jhol: I'm not sure about your "can't individually configure each cell to take set/reset, enable, clock/inv clk etc" bit? | 17:38 |
| jhol | mithro: morning! - I checked it - I'm pretty sure it's true | 17:39 |
| mithro | jhol: Let me take a look at the description, it may be the case that things still work | 17:39 |
| jhol | for 2 reasons 1- see page "2-2" of the DS1040 datasheet | 17:39 |
| jhol | also... http://www.clifford.at/icestorm/bitdocs-1k/tile_4_15.html | 17:40 |
| tpb | Title: Project IceStorm iCE40 HX1K LOGIC Tile (4 15) (at www.clifford.at) | 17:40 |
| mithro | bblr | 17:40 |
| jhol | at least NegClk is a single flag shared with the whole tile in the bit docs | 17:42 |
| jhol | for 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 think | 17:45 |
| jhol | same with lutff_globals/s_r | 17:45 |
| jhol | yup - that's correct - one clk, cen, s_r config for the whole tile | 17:47 |
| jhol | so 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 includes | 17:49 |
| digshadow | mithro: so looking over things some more, think I had a misunderstaning about the current state of htings | 18:13 |
| digshadow | things | 18:13 |
| digshadow | to 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 |
| digshadow | and then add the real interconnect to the rr_graph based off of the icebox stuff | 18:14 |
| digshadow | that was under the assumption that the tile layout was correct as I saw that it listed DEVICE=HX1K | 18:14 |
| digshadow | but this is actually a test layout, which means I can't do a real import | 18:14 |
| digshadow | are you expecting me to write a proper grid or is that something jhol is working on? | 18:15 |
| digshadow | hmm wait | 18:17 |
| digshadow | I think I may just be pointing at something smaller | 18:17 |
| digshadow | yup were good | 18:21 |
| daveshah | I'm pretty sure CEN and SR can be enabled or disabled per channel, but the signal if used is shared | 18:24 |
| jhol | digshadow: the grid will be correct coming in from the rr_graph | 18:40 |
| jhol | -- except that it will have a ring of empty blocks around it | 18:41 |
| jhol | daveshah: 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: http://www.clifford.at/icestorm/bitdocs-1k/tile_4_15.html | 18:44 |
| tpb | Title: Project IceStorm iCE40 HX1K LOGIC Tile (4 15) (at www.clifford.at) | 18:44 |
| jhol | digshadow: with the node rr_graph, the intra-tile nodes+links should be 100% correct | 18:47 |
| jhol | the inter-tile nodes should be possible to specify correctly - just not the links | 18:47 |
| jhol | --- in other words, the VPR architecture XML is rich enough to completely describe how tiles are wired up | 18:48 |
| jhol | that includes everything from the LUTFFs out to the local tracks | 18:49 |
| jhol | the architecture XML capabilities gets a bit fishy when it comes to the spans and neighbour tracks | 18:50 |
| jhol | I will still try and get these modelled as closely as I can, because otherwise the packer would set the router up to fail | 18:50 |
| jhol | also the arch XML is fishy in regard to the global nets, in the injectors to the global nets IIRC | 18:51 |
| jhol | *and the injectors | 18:51 |
| jhol | so 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 not | 18:54 |
| jhol | I'm working on something else thursday/friday, back on this project next monday | 18:54 |
| jhol | I will be contactable the whole time if you need to have a chat | 18:55 |
| jhol | -- there's a slim chance I can get you a current rr_graph today. that might help you on your way | 18:55 |
| jhol | ...though beware, as I debug the Architecture XML, there might be changes | 18:56 |
| daveshah | jhol: Yep, my mistake, see here: http://www.clifford.at/icestorm/logic_tile.html | 19:00 |
| tpb | Title: Project IceStorm LOGIC Tile Documentation (at www.clifford.at) | 19:00 |
| jhol | daveshah: no it's good having people probe what I'm saying, makes me checks things | 19:04 |
| mithro | digshadow: There are multiple "device" configs in the file IIRC | 19:24 |
| mithro | digshadow: Some are small for testing | 19:24 |
| mithro | digshadow: Some are real | 19:24 |
| digshadow | mithro: its something else | 19:24 |
| mithro | digshadow: Also, I could have screwed up the tilegrid or temporarily deleted some of it :-) | 19:25 |
| jhol | the HX1K one is correct | 19:26 |
| jhol | -- well... the pads are all there | 19:26 |
| mithro | digshadow: Do you mean these -> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/devices/ice40-virt/arch.xml#L36-L93 ? | 19:26 |
| tpb | Title: symbiflow-arch-defs/arch.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 19:27 |
| jhol | the ice4 and HX0K are missing left+right pads, unless you use my unpub | 19:27 |
| digshadow | mithro: yes | 19:27 |
| jhol | digshadow: the PAD tiles should all be BLK_BB-VPR_PAD | 19:27 |
| jhol | I've got a patch for that | 19:27 |
| digshadow | mithro: 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 back | 19:28 |
| jhol | digshadow: I'll publish my branch soon. it's a bit tidier | 19:28 |
| mithro | jhol: them being BLK_BB-VPR_PAD is a temporary thing until the PIO model is good / works -> https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/ice40/tiles | 19:28 |
| tpb | Title: symbiflow-arch-defs/ice40/tiles at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 19:28 |
| jhol | mithro: that makes sense... the PIOs seem very underdeveloped | 19:29 |
| jhol | I'll get on that soon | 19:29 |
| mithro | digshadow: Sadly no, decided I needed to get to bed before midnight yesterday | 19:29 |
| mithro | jhol: I think we can mostly leave the PIOs until later? | 19:30 |
| jhol | hope so | 19:31 |
| jhol | at the moment I'm trying to get a 3-bit carry chain to work | 19:31 |
| mithro | jhol: Oh - I can explain about the carry chain on the vpr side of things | 19:32 |
| jhol | molecules | 19:32 |
| mithro | jhol: Is it packing the atoms into molecules correctly? | 19:32 |
| mithro | jhol: See the "Port Override Example: Carry Chains" here -> http://vtr-verilog-to-routing.readthedocs.io/en/latest/arch/reference.html#tag-pb-type-fc_override | 19:33 |
| tpb | Title: Architecture Reference Verilog-to-Routing 8.0.0-dev documentation (at vtr-verilog-to-routing.readthedocs.io) | 19:33 |
| jhol | no it's busted... but the atecedent problem is that yosys implemented the chain with a SR_DFF+SR_DFFE+SR_DFF, which is wrong | 19:33 |
| jhol | -- the whole tile has to be SR_DFF or SR_DFFE | 19:34 |
| jhol | hence me working on fixing the modes | 19:34 |
| mithro | jhol: And the "Special Case:" at http://vtr-verilog-to-routing.readthedocs.io/en/latest/arch/reference.html#tag-interconnect-pack_pattern | 19:34 |
| tpb | Title: Architecture Reference Verilog-to-Routing 8.0.0-dev documentation (at vtr-verilog-to-routing.readthedocs.io) | 19:34 |
| mithro | jhol: 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 |
| jhol | yes i saw that | 19:35 |
| jhol | why not? the packer will pack incompatible DFFs together if it isn't fixed | 19:35 |
| jhol | here's my work-in-progress changes to fix the modes: https://github.com/jhol/symbiflow-arch-defs/commits/wip-fix-modes | 20:00 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 20:00 |
| jhol | though this version now crashes VPR - I think because I messed up the *molecular structure* | 20:01 |
| mithro | jhol: 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-dev | 23:24 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!