Thursday, 2018-05-24

*** tpb has joined #vtr-dev00:00
*** digshadow has joined #vtr-dev00:01
*** digshadow has quit IRC01:09
*** digshadow has joined #vtr-dev01:16
*** vtrbot has quit IRC01:46
*** digshadow has quit IRC04:00
*** kem_ has quit IRC04:03
mithrodigshadow: https://www.irccloud.com/pastebin/W0HxAm6V/04:04
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)04:04
mithrodaveshah/ jhol: ^04:04
*** digshadow has joined #vtr-dev04:19
mithrohttps://www.irccloud.com/pastebin/f7pHOt17/04:46
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)04:46
mithroNeed to fix the tile type...04:47
*** ZipCPU has quit IRC08:00
*** ZipCPU has joined #vtr-dev08:05
*** digshadow has quit IRC08:46
*** digshadow has joined #vtr-dev08:51
*** vtrbot has joined #vtr-dev12:34
*** kem_ has joined #vtr-dev12:54
mithromorning everyone17:17
mithrokem_: ping?17:17
mithrojhol: ping?17:17
mithrodaveshah: ping? :-P17:17
mithrokem_: Had a chance to look at the pass_gate stuff at all?17:18
daveshahmithro: hi17:26
mithrodaveshah: How goes things?17:26
mithrodaveshah: It would be good to get someone else to start reproducing the ice40 stuff17:26
daveshahmithro: yes, can try and take a look tomorrow17:27
mithrodaveshah: That would be good17:27
daveshahIt looks like you're having trouble getting names for some things?17:27
mithrodaveshah: Not hugely17:28
mithrodaveshah: I was having issues with invalid route existing17:29
daveshahI see17:29
daveshahWhat was the pass_gate stuff?17:31
*** digshadow has quit IRC17:57
*** awygle is now known as aygle19:16
*** aygle is now known as awygle19:20
jholmithro: hi!19:46
mithrojhol: Hi! - I've been working on the HLC output19:46
jholyeah - I saw you making progress19:46
mithrojhol: I had a bunch of questions19:49
jholsure - go right ahead!19:49
mithrojhol: Why were you flipping the y coordinates?19:49
jholbecause of you ice40 coordinate diagram vs. the diagram in icestorm19:49
mithrojhol: Oh?19:50
mithrojhol: which diagram?19:50
jholhttp://www.clifford.at/icestorm/bitdocs-1k/19:50
tpbTitle: Project IceStorm iCE40 HX1K Overview (at www.clifford.at)19:50
jholyour diagram is bottom-up IIRC19:50
jholand I think VPR is bottom-up in general, right?19:51
mithrojhol: That diagram is bottom up as well?19:51
jholugh you're right19:51
jholok... that's a mistake19:51
mithrookay19:52
mithrojhol: I was wondering why _write_hlc_pin_name is so complicated?19:54
jholwell it's a kind of hack19:56
jholbut basically I'm using the pin-type prefix information to control the wire traversal that the code uses19:56
mithrojhol: Shouldn't it just be able to use the names in the pb_type ?19:56
jholwell you have to make them exactly match icebox19:57
jholwhich isn't always easy19:57
jholit works if you look at the naming in the tile-routing-pb19:57
mithrotile or top?19:57
jholtile - I did all my development with tile19:58
jholhttp://www.clifford.at/icestorm/bitdocs-1k/tile_8_16.html19:58
tpbTitle: Project IceStorm iCE40 HX1K LOGIC Tile (8 16) (at www.clifford.at)19:58
jholif you look at some of the net names, it's quite tricky to convert the naming so that it consistently matches icebox19:59
jhollocal_g3_{0,1,2,3,4,5,6,7} being an example19:59
jhollutff_{0,1,2,3,4,5,6,7}/in_2 being another19:59
jholso I somewhat abused the block-type prefixes so it kinda works19:59
mithro - lutff_{0,1,2,3,4,5,6,7}_in[2]20:00
mithroor?20:00
mithro lutf[0].in[2] ?20:00
jholwell in icebox it's lutff_0_in220:00
jholin VPR it's going to be something like BEL-??_LUTFF.in[2]20:01
jhol-- or whatever it was20:01
jholsorry - it's "lutff_0/in2" in icebox20:02
jholthe bad thing about this hacky conversion is that it's hacky20:03
jholthe good thing is that I didn't have to write any conversion tables in C++20:03
jholby setting up the block and pin names in the XML just right, it's possible to translate the nomenclature to the correct icebox format20:04
mithrojhol: Yeah, the idea is that you set up the block/pin names correctly and the code shouldn't need to know anything special about the icebox names?20:05
jholexactly, but the problem is that there's a bit of a rift to bridge20:06
jholso in the symbiflow arch-defs, because of VPR design issues, the cells are a bit convoluted20:06
jholin the real world, each tile has 8 cells containing 1x LUTFF and 1x DFF20:07
mithrojhol: The idea behind these functions -> https://github.com/mithro/vtr-verilog-to-routing/blob/fasm/vpr/src/util/fasm.cpp#L116-L15520:07
tpbTitle: vtr-verilog-to-routing/fasm.cpp at fasm · mithro/vtr-verilog-to-routing · GitHub (at github.com)20:07
jholsorry: 1x LUT and 1x DFF20:07
jholbut in symbiflow-arch-defs there's 1 set of 8-cells for the LUTs and then a <mode> wrapper containing 8-DFFs20:08
jholand it has to be this way because the FFs stay constant regardless of DFF modes20:08
jholso the XML contains a lot of extraneous pb_types, pins and direct links that are needed just to represent the ice40 in a way that make VPR not crash20:09
jholso the HLC code I wrote skips over fake things until it encounters things that are annotated in such as way as to indicate that they represent something real20:10
mithrojhol: Yeah - that is why there are BLK_IG20:14
jholyes, that one came in handy20:15
jholI abused some of the other type name prefixes20:15
jhol-- I recomend you play with the tile-routing version to see it in action. you will see it generating something reasonable20:16
mithrojhol: It would be good to get you to repo some of the stuff I have done20:16
jholsure20:16
jholthough it mgiht be a while before I get to it20:16
jholdo you have a HLC file from arachne-pnr to compare your output to?20:17
mithroyes20:20
jholcool ok20:21
mithro        auto &element_lines = (*elements_.insert(20:26
mithro            std::make_pair(std::to_string(cell), std::vector<std::string>())).first).second;20:26
mithrojhol: Why is this a cell + vector of strings?20:27
jholso if you look at the HLC format, it wraps the cell config in an inner set of curly brackets20:28
jholit's probably just about possible to write out the cells in 1-pass, but I wasn't sure that would be the case, so I put the element lines into this table which gets written out in close_tile()20:30
jholnot that std::map::insert means insert_new_element_or_return_existing_element20:30
jhol*note that...20:31
mithrojhol: What is "collect_chain" about?20:41
jholvery simple c++ ;)20:41
jholso basically...20:42
jholin visit_all_impl -> process_ports -> process_route, we make a big list of links between nodes in the cell20:43
jholcollect_chain starts at a pin and iterates down or up the chain of links until it gets to the end of a chain of links20:45
jholit is written in with that convoluted C++ because it can go down or up the links, and I didn't want to copy-paste code20:45
jholit iterates a long a chain of links greedily making chains, and removing any links from the the list so they are no restated later20:46
jholso for example, the links_ table will have some random connections: C->E C->D A->B B->C20:47
jholcollect_chain will with the argument of tip=D and up=true, A->B->C->D20:47
jholthen on the second with tip=E and up=true, it will return a chain C->E20:48
jholthis is useful because in HLC you can write a chain of multiple links on one line20:49
*** digshadow has joined #vtr-dev22:03

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!