| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has joined #vtr-dev | 01:10 | |
| mithro | kem_: so, I should be able to use --gen_post_synthesis_netlist to check logical equivalence? | 01:50 |
|---|---|---|
| kem_ | mithro: Yep, we use ABC to do LEC in our regression tests | 01:52 |
| kem_ | mithro: See for instance: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/vtr_flow/tasks/regression_tests/vtr_reg_strong/strong_func_formal_flow/config/config.txt | 01:52 |
| tpb | Title: vtr-verilog-to-routing/config.txt at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 01:52 |
| mithro | kem_: I'm trying to figure out why my output .hlc file is not logically equivalent to my input | 01:53 |
| kem_ | mithro: Since we do regression test it VPR's output *should* be correct | 01:53 |
| kem_ | mithro: But probably worth verifying on your architecture/circuit combination | 01:54 |
| kem_ | mithro: Just to be safe :) | 01:54 |
| mithro | kem_: I'm pretty sure it is something in my hlc output code -- but can't find it... | 01:54 |
| mithro | kem_: So am double checking everything else :-P | 01:54 |
| mithro | kem_: Is there a way to get the blif after packing? | 01:56 |
| kem_ | mithro: --gen_post_synthesis_netlist on should dump blif and verilog | 01:57 |
| mithro | kem_: So when using --gen_post_synthesis_netlist I get "Message: Primitive 'SB_LUT4' not recognized by netlist writer" | 01:57 |
| kem_ | mithro: Ah, it probably only supports the standard BLIF plus some of VTR's standard primitives | 01:59 |
| mithro | kem_: Yeah -- it doesn't seem to support black boxes? | 02:00 |
| kem_ | mithro: It supports a hard-coded list of blackboxes... but not blackboxes in general | 02:00 |
| mithro | kem_: Is there a way to set the gen_post_synthesis_netlist format? | 02:01 |
| kem_ | mithro: It always dumps BLIF, Verilog and an SDF | 02:02 |
| kem_ | mithro: something like top_post_synthesis.blif, top_post_synthesis.v, top_post_synthesis.sdf | 02:02 |
| mithro | kem_: It kind of looks like it would be trivial to support arbitrary black boxes? | 02:02 |
| kem_ | mithro: it wouldn't be too hard | 02:03 |
| mithro | You already seem to have " return std::make_shared<BlackBoxInst>(type_name, inst_name, params, input_port_conns, output_port_conns, timing_arcs, ports_tsu, ports_tcq);" | 02:03 |
| kem_ | mithro: Yeah, there is a BlackBoxInst class but it's the code which sets up all the parameters which is type specific | 02:04 |
| mithro | kem_: Yeah -- it's looping over all the inputs / outputs it and setting up those structures? | 02:05 |
| kem_ | mithro: Yep, but some of the primitives (for the verilog representation I think) also need to configure some parameters which are type specific | 02:06 |
| kem_ | mithro: It may be possible to write generic code which uses VPR's internal data structures (e.g. t_model, from the <model> section of the architecture) to handle arbitrary simple black boxes | 02:07 |
| mithro | kem_: Okay | 02:07 |
| kem_ | mithro: provided they don't have special-case behaviour | 02:07 |
| mithro | kem_: Well, that seemed to work... | 02:16 |
| mithro | https://www.irccloud.com/pastebin/aShm4OPP/ | 02:20 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 02:20 |
| mithro | kem_: -- even passes yosys logical equivalence check! :-P | 02:27 |
| kem_ | mithro: Nice! | 02:28 |
| mithro | kem_: No timing information however.... | 02:30 |
| kem_ | mithro: Yeah, I think the timing info is special case stuff in the current code. | 02:31 |
| mithro | kem_: Ahh - yosys doesn't like your vtr_flow/primitives.v file | 02:32 |
| kem_ | mithro: At the time I re-wrote the netlist writer code we didn't have the timing arcs specified in the <models>, so I think its hard coded. It could likely be generalized now that we do require it to be specified. | 02:33 |
| kem_ | mithro: The primitives.v has some funky stuff like specify blocks in there for SDF back annotation... | 02:33 |
| mithro | kem_: Yeah | 02:34 |
| mithro | kem_: Hrm, it doesn't like the top_post_synthesis.v | 02:41 |
| kem_ | mithro: Last time I tried it, it worked with Modelsim | 02:46 |
| kem_ | mithro: I'm off, have a good night! | 02:47 |
| mithro | kem_: The .blif seems to work... | 02:47 |
| mithro | kem_: You too! | 02:47 |
| mithro | kem_: Ahh the verilog code isn't connecting the clocks to the SB_DFF objects... | 02:48 |
| mithro | kem_: Well, the verilog is logically equivalent in some cases it seems... | 03:33 |
| mithro | kem_: and the blif seems logically equivalent all the time.... | 03:34 |
| daveshah | mithro: still around? | 06:25 |
| daveshah | The reason for the blif/eblif difference is you go through abc again before making the eblif | 06:27 |
| daveshah | Based on the synth script in the tests ice40 Makefile | 06:28 |
| mithro | daveshah: yeah, I figured that one out | 18:34 |
| mithro | daveshah: I'm very confused why the blif version passes logical equivalence but verilog doesn't | 19:27 |
| daveshah | mithro: load the blif into yosys, run write_verilog and compare | 19:28 |
| mithro | daveshah: it's weird that the circuit fails check when I use SB_LUT4 provided by yosys and post pnr verilog output -- but it works when I use SB_LUT4 provided by yosys and post pnr blif output | 19:45 |
| daveshah | mithro: you should be able to follow the outputs backwards until you see a difference | 19:46 |
| daveshah | The yosys show command might help, but I think write_verilog will be best | 19:46 |
| mithro | daveshah: but it appears the SB_LUT4 provided by yosys with post pnr verilog output doesn't work at all | 19:47 |
| daveshah | Post an example? | 19:47 |
| mithro | daveshah: but if I use the unlut version it works | 19:47 |
| daveshah | Probably passing parameters wrong | 19:47 |
| mithro | daveshah: Yeah - that is what I think | 19:48 |
| daveshah | mithro: what does your verilog look like? In top_post_synthesis.v I'm seeing LUT_K not SB_LUT4 | 19:50 |
| mithro | daveshah: https://paste.ubuntu.com/p/NBjg2Qqpcc/ | 19:50 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 19:50 |
| daveshah | mithro: .LUT_INIT(0111111110000000) is the base10 integer 0111111110000000 I think :P | 19:51 |
| mithro | daveshah: replace the "YOSYS_SCRIPT ?= synth_ice40 -nocarry; ice40_opt -unlut; abc -lut 4;" line with "YOSYS_SCRIPT ?= synth_ice40 -nocarry;" in ice40.mk | 19:51 |
| daveshah | should be 16'b0111111110000000 | 19:52 |
| mithro | daveshah: doah | 19:54 |
| mithro | daveshah: Any idea how do I tell is a param coming in from the blif is a binary string? | 19:54 |
| daveshah | afaik it always is | 19:54 |
| daveshah | unless its a string | 19:55 |
| mithro | daveshah: it works \o/ | 19:56 |
| daveshah | mithro: yay! | 19:57 |
| mithro | https://www.irccloud.com/pastebin/RD3xsizl/ | 19:57 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:57 |
| mithro | daveshah: So - did you know how I can convert that SB_INIT parameter into something that hlc accepts? | 20:03 |
| daveshah | mithro: wasn't that what your icestorm pr was about? | 20:11 |
| mithro | daveshah: That allows it to accept a full 16'b value | 20:12 |
| daveshah | mithro: surely that should be the same as the LUT_INIT value then? | 20:12 |
| mithro | daveshah: yes - but I don't know how to extend it from 4'b0110 to 16'b -- do I pad with zeros at front or back or ? | 20:13 |
| daveshah | mithro: it's no different from any other numeric value | 20:13 |
| daveshah | Pad at the front | 20:13 |
| daveshah | In the LUT_INIT form, anyway | 20:14 |
| *** digshadow has quit IRC | 22:50 | |
| *** digshadow1 has joined #vtr-dev | 22:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!