| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has quit IRC | 02:32 | |
| *** digshadow has joined #vtr-dev | 03:01 | |
| digshadow | jhol: https://github.com/SymbiFlow/prjxray/tree/master/tools/test_data | 04:48 |
|---|---|---|
| tpb | Title: prjxray/tools/test_data at master · SymbiFlow/prjxray · GitHub (at github.com) | 04:48 |
| digshadow | btw has some .fasm files | 04:48 |
| digshadow | mithro: approved PR | 04:50 |
| jhol | mithro, digshadow: I've decided to do the serialization with the HLC format | 07:45 |
| jhol | here is an example: https://paste2.org/HIy5LZaZ | 07:45 |
| jhol | it is a human readable textual description of the tile config | 07:46 |
| jhol | icestorm has a converter for this format: https://github.com/cliffordwolf/icestorm/blob/master/icebox/icebox_hlc2asc.py | 07:46 |
| tpb | Title: icestorm/icebox_hlc2asc.py at master · cliffordwolf/icestorm · GitHub (at github.com) | 07:46 |
| jhol | so I'm going to take mithro's fasm walker, and rewrite it to emit HLC | 07:47 |
| digshadow | jhol: what is HLC used by? | 07:50 |
| digshadow | or is that clifford format | 07:50 |
| jhol | I don't know- i think it's a custom format for icebox | 07:50 |
| jhol | it doesn't need to be the long term serialization format | 07:51 |
| jhol | but given the time constraints it seems to be sensible to do it this way, because this way I only need to write a serializer, no deserializer | 07:51 |
| daveshah | HLC was a GSoC project last year IIRC | 08:03 |
| daveshah | I don't think anyone has used it for anything practical yet | 08:03 |
| daveshah | It might be the fastest way to something practical | 08:04 |
| jhol | daveshah: thanks | 08:07 |
| digshadow | jhol: if you are going for something quick, wouldn't json be quicker? | 08:11 |
| digshadow | eh I guess if the other end is there, maybe | 08:11 |
| digshadow | anyway I don't have a strong opinion | 08:11 |
| digshadow | roll with whatever you think is best I'd say | 08:12 |
| jhol | yeah - that's my thought about it | 08:12 |
| daveshah | my only concern with HLC would be how well tested it is | 08:49 |
| daveshah | there is no HLC support for the 5k yet, but this is something I can add in the long term | 08:49 |
| jhol | I think there's no consensus about what a proper IR should be, or even what the requirements are for one | 08:51 |
| jhol | -- so doing something obviously incomplete like this will prompt us to figure what a better solution will look like | 08:52 |
| daveshah | Yes, definitely | 08:54 |
| daveshah | Currently there is a spectrum of extremes | 08:54 |
| jhol | really you want something that can additional metadata e.g. the verilog net names | 08:54 |
| daveshah | The arachne-pnr ASC format supports that | 08:54 |
| jhol | the problem with ASC is that it's packed up already, so you have to write a tile packer into the PnR tool | 08:55 |
| daveshah | Using `.sym <icebox net number> <user_friendly name>` | 08:55 |
| daveshah | Sure | 08:55 |
| daveshah | But the symbol idea could be reused | 08:55 |
| daveshah | In FASM etc | 08:55 |
| jhol | sure | 08:55 |
| daveshah | Not using an icebox net number but a segment name, etc | 08:55 |
| jhol | I've been trying to find any example FASM files | 08:56 |
| jhol | do you have any on your hard disk lying around? | 08:56 |
| daveshah | Never done any FASM stuff, sorry | 08:56 |
| jhol | no worries | 08:56 |
| daveshah | I doubt there's more than what's in the prjxray repo really | 08:56 |
| daveshah | Given it's 7-series only it's only seem limited use | 08:56 |
| mithro | Morning | 13:09 |
| mithro | hey jhol / daveshah | 13:10 |
| mithro | jhol: fine to use HLC if it makes sense | 13:15 |
| *** daveshah has quit IRC | 15:11 | |
| *** daveshah has joined #vtr-dev | 15:11 | |
| *** digshadow-c has quit IRC | 15:13 | |
| *** digshadow-c has joined #vtr-dev | 15:13 | |
| *** digshadow has quit IRC | 17:00 | |
| *** digshadow has joined #vtr-dev | 17:45 | |
| mithro | kem_: Was that architecture definition useful? | 17:51 |
| kem_ | mithro: Yes, I was able to reproduce the issue and I'm now looking at how best to fix it | 17:52 |
| mithro | kem_: Great! | 17:59 |
| mithro | jhol: Got any updates we need to merge? | 18:00 |
| digshadow | jhol: I thought I linked you some yesterday | 18:07 |
| digshadow | did you not see those | 18:07 |
| digshadow | https://github.com/SymbiFlow/prjxray/tree/master/tools/test_data | 18:07 |
| tpb | Title: prjxray/tools/test_data at master · SymbiFlow/prjxray · GitHub (at github.com) | 18:07 |
| digshadow | there are .fasm files checked in there | 18:08 |
| digshadow | they are basically just key value pairs | 18:08 |
| digshadow | one for each configurable thing in the FPGA | 18:08 |
| digshadow | in ASCII format | 18:08 |
| digshadow | there are some tools that disassemble a bitstream if you wanted something bigger | 18:08 |
| digshadow | but I think that will give you the idea | 18:08 |
| jhol | :) - thanks! | 18:29 |
| mithro | jhol: What is the best way to give your plb stuff a go? | 19:35 |
| jhol | mithro: make ARCH=ice40 DEVICE_TYPE=tile-routing-virt DEVICE=test4 VPR_ARGS='--disp on' counter.echo | 19:59 |
| jhol | in the tests/ directory | 20:00 |
| jhol | big_xor.echo will get through to the end | 20:00 |
| jhol | with --disp on, you'll get the GUI and you can play around with the layout at different stages through the design | 20:00 |
| mithro | jhol: Looking at your interconnect - you seem to have put the I[3] mux on the I[2] pin? | 20:10 |
| mithro | Each LUT i has four input wires lutff_i/in_0 to lutff_i/in_3. Input lutff_i/in_3 can be configured to be driven by the carry output of the previous logic cell, or by carry_in_mux in case of i=0. Input lutff_i/in_2 can be configured to be driven by the output of the previous LUT for i>0 (LUT cascade). | 20:13 |
| mithro | oh, I see what you have done | 20:15 |
| mithro | kem_: How does vtr deal with constant generators? | 21:08 |
| kem_ | mithro: VPR can detect constant generators from LUTs | 21:23 |
| kem_ | mithro: It can also inferr them from blackboxes in a couple cases: | 21:23 |
| mithro | kem_: Is there a way to "create" a constant generator? | 21:23 |
| kem_ | mithro: A LUT with no input is the simplest way | 21:24 |
| mithro | kem_: Okay - just a pb_type with the .names property but no inputs? | 21:24 |
| kem_ | mithro: Actually, a .names in the netlist which has no inputs | 21:25 |
| kem_ | mithro: You can set the output to 1 or 0 as the single value in the truth-table | 21:25 |
| mithro | kem_: Oh, I meant how do I represent a "constant generator" in the vpr architecture? | 21:25 |
| kem_ | mithro: Ah that's a different matter | 21:26 |
| kem_ | mithro: Currently that is something we don't model | 21:26 |
| kem_ | mithro: Although see https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/163 | 21:26 |
| tpb | Title: Improve support for contant generators · Issue #163 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 21:26 |
| mithro | kem_: A lot of these architectures have a "constant generator" attached to the carry chain which can create a constant zero/constant one | 21:26 |
| kem_ | mithro: That issue outlines what needs to be done to model constants | 21:27 |
| mithro | kem_: An alternative to having tieable="vcc,gnd" might be just a pb_type primitive which can generate a constant signal and a mux? | 21:28 |
| kem_ | mithro: Yes, in fact you could probably do that now, by just making a .names pb_type with no input pins | 21:29 |
| kem_ | mithro: So only constant generators could be mapped into it | 21:29 |
| mithro | kem_: That is what I was about to try | 21:29 |
| mithro | I assume that vpr will probably complain about the fact it should be swept away? | 21:30 |
| kem_ | mithro: Probably, but there should be options to turn the actual sweeping off | 21:30 |
| mithro | Yeap | 21:30 |
| kem_ | mithro: Another thing to watch out for is that your input netlist may need to 'explode' the constant net into unique 2-pin net with a single driver and sink (otherwise some of the carry-chains wouldn't have a dedicated constant generator to map in) | 21:31 |
| mithro | kem_: Okay | 21:32 |
| mithro | kem_: Have you seen an error like this before; | 21:56 |
| mithro | https://www.irccloud.com/pastebin/Kpg83cuT/ | 21:56 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 21:56 |
| mithro | kem_: Not doing anything strange here -- the rr_graph is being generated by vpr | 21:57 |
| kem_ | mithro: I think that means that the generated routing is disconnected (i.e. it is not possible to connect 964 to 512 in the architecture | 21:57 |
| kem_ | mithro: If it's a VPR rr graph then that means somethings gone wrong in the router | 21:58 |
| kem_ | mithro: Can you file a bug? | 21:58 |
| mithro | kem_: Yeap, it is all generated by VPR -- will check master first | 21:58 |
| kem_ | mithro: Thanks | 21:59 |
| mithro | kem_: This feels a little bit familiar last time I tried to test BI_DIR stuff :-P | 22:00 |
| kem_ | mithro: We mostly focus on single-driver routing these days, so our regression coverage of bi-dir is more limited. It's certainly possible there is a bi-dir bug not covered our regression tests. | 22:02 |
| mithro | kem_: Yeah | 22:04 |
| kem_ | mithro: I expect Artix uses uni-dir, does ice40 use bi-dir? | 22:05 |
| mithro | kem_: It has some bi-dir tracks | 22:06 |
| mithro | kem_: Is it worth trying to minimize it first? Or is that error message useful enough with a reasonable complicated arch definition? | 22:07 |
| kem_ | mithro: If it's a simple netlist then it's probably OK as is | 22:08 |
| mithro | kem_: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/331 | 22:16 |
| tpb | Title: "found non-adjacent segments" in rr_graph when using bidirectional tracks · Issue #331 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 22:16 |
| mithro | kem_: Damn users huh? Always finding bugs :-P | 22:17 |
| kem_ | mithro: More like helpful testers :) | 22:17 |
| digshadow | mithro: FYI I've rebased my stuff to master | 22:23 |
| mithro | digshadow: Is it worth opening a pull request so I can start looking at it? | 22:26 |
| digshadow | mithro: I suppose as WIP | 22:27 |
| digshadow | since things aren't fully working yet | 22:28 |
| digshadow | although I tend to push to branches a lot | 22:28 |
| digshadow | which will give you a bunch of e-mails... | 22:29 |
| mithro | digshadow: Don't worry about me getting too many emails :-) | 22:29 |
| digshadow | also I think I've gained a level of git mastery from working that out | 22:31 |
| digshadow | as a small note, I dumped any changes related to ice40 | 22:32 |
| digshadow | mithro: opened | 22:45 |
| digshadow | https://github.com/SymbiFlow/symbiflow-arch-defs/pull/94 | 22:46 |
| tpb | Title: WIP rr graph lib by mcmasterg · Pull Request #94 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 22:46 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!