*** tpb has joined #vtr-dev | 00:00 | |
*** q3k has quit IRC | 00:55 | |
*** q3k has joined #vtr-dev | 01:41 | |
*** ZipCPU_ has joined #vtr-dev | 03:17 | |
*** ZipCPU has quit IRC | 03:19 | |
mithro | morning everyone | 13:26 |
---|---|---|
daveshah | mithro: hey | 13:30 |
mithro | daveshah: I finally understand the INIT value for LUTs | 13:31 |
mithro | daveshah: So, is the SB_LUT4.LUT_INIT address 0 first or address 1 first? | 13:33 |
daveshah | address 0 first | 13:34 |
daveshah | this isn't BASIC :P | 13:34 |
mithro | daveshah: Is the MSB address 0? | 13:35 |
daveshah | no, LSB is address 0 | 13:35 |
mithro | daveshah: Okay -- but in verilog MSB is first right? 4'b1000 == 1 in the MSB position | 13:36 |
daveshah | yeap | 13:37 |
mithro | daveshah: And in the BLIF the MSB is first bit? | 13:42 |
daveshah | not sure, you'll have to check the blif specs | 13:42 |
mithro | daveshah: I'm pretty sure clifford made that extension to blif up? | 13:43 |
daveshah | run a test then, I think you're right | 13:44 |
mithro | daveshah: Do you know if there is a way to stop yosys rotating the inputs to the LUT? | 13:44 |
mithro | daveshah: Or ABC I guess? | 13:45 |
daveshah | This is not how ABC or Yosys works. Neither is "rotating" the LUT, nor as a LUT directly inferred by that statement | 13:46 |
mithro | daveshah: So the verilog at https://github.com/mithro/symbiflow-arch-defs/blob/4mcmaster/tests/ice40/icelut/route-through-in1/lut.v ends up with a ".names I[1] 0 | 13:50 |
tpb | Title: symbiflow-arch-defs/lut.v at 4mcmaster · mithro/symbiflow-arch-defs · GitHub (at github.com) | 13:50 |
mithro | Opps | 13:50 |
mithro | .names I[1] O 1 1 | 13:51 |
mithro | which looks right... | 13:51 |
daveshah | yep | 13:52 |
mithro | daveshah: Which ends up with | 13:55 |
mithro | https://www.irccloud.com/pastebin/lcVfnurY/ | 13:56 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 13:56 |
mithro | kem_: In the .net file <port specification is the first value in the list in[0] or in[3] ? | 14:01 |
mithro | https://www.irccloud.com/pastebin/02KEaSFc/ | 14:03 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 14:03 |
mithro | that looks wrong? | 14:04 |
mithro | https://www.irccloud.com/pastebin/wGerLnqz/ | 14:06 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 14:06 |
kem_ | mithro: I think it is in[0] | 14:10 |
kem_ | mithro: The output looks OK to me. It looks like a buffer-LUT (initial truth table '11'), in the output it gets expanded to 10001 (a 4-LUT since that is what is in the architecture), but the other inputs are left disconnected (__vpr__unconn) | 14:13 |
mithro | I think that "lut out = out = 16'b0100000000000000" should be "lut out = out = 16'b1000000000000000" right? | 14:26 |
mithro | oh wait | 14:30 |
mithro | 0000 == 0, 0001 == 1 -- .LUT_MASK(16'b0000000000000010) - while SB_INIT(16'b0100000000000000) | 14:32 |
mithro | So this looks wrong | 16:46 |
mithro | https://www.irccloud.com/pastebin/TJPPAiE0/ | 16:46 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 16:46 |
*** digshadow1 has quit IRC | 17:42 | |
*** digshadow has joined #vtr-dev | 18:05 | |
mithro | daveshah: As far as I can tell the issue is with this lut | 19:30 |
mithro | https://www.irccloud.com/pastebin/HCt9j1uG/ | 19:30 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:30 |
daveshah | mithro: that doesn't look right | 19:31 |
mithro | daveshah: why? | 19:31 |
daveshah | What order is it in? if MSB first verilog order, it looks like the function has a dependency on in2 which isn't connected | 19:32 |
daveshah | But I may be misunderstanding anyway | 19:32 |
daveshah | Nvm, hlc LUTs were LSB first weren't they | 19:33 |
mithro | https://www.irccloud.com/pastebin/2BFHFfff/ | 19:34 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:34 |
daveshah | So that is MSB first | 19:35 |
daveshah | I find it odd that the pattern changes at the MSB end, but that won't be reached because in2 is 0 | 19:36 |
daveshah | That's not a problem per se, just an observation | 19:36 |
mithro | https://www.irccloud.com/pastebin/kHKEQqeQ/ | 19:37 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:37 |
mithro | assign n30 = /* LUT 7 3 7 */ n2 ? 1'b0 ? n4 ? n12 ? 1'b0 : 1'b1 : n12 ? 1'b1 : 1'b0 : n4 ? 1'b1 : 1'b0 : n4 ? 1'b1 : 1'b0; | 19:40 |
mithro | /* FF 7 3 7 */ always @(posedge clk) if (1'b1) n4 <= 1'b0 ? 1'b0 : n30; | 19:40 |
mithro | daveshah: I'm trying to understand that n30 expression | 19:41 |
mithro | daveshah: I made icebox_vlog output it with brackets | 19:42 |
mithro | assign n30 = /* LUT 7 3 7 */ (n2 ? (1'b0 ? (n4 ? (n12 ? 1'b0 : 1'b1) : (n12 ? 1'b1 : 1'b0)) : (n4 ? 1'b1 : 1'b0)) : (n4 ? 1'b1 : 1'b0)); | 19:42 |
daveshah | Now draw it | 19:42 |
mithro | daveshah: ? | 19:42 |
daveshah | That's how I'd understand such an expression | 19:42 |
mithro | daveshah: If n2==true and n12==true, then the output should be true? | 19:46 |
daveshah | Yeap | 19:47 |
mithro | daveshah: This is not happening.... | 19:48 |
mithro | when n2==1 and n12==1, n30 == 0.... | 19:48 |
mithro | Hrm... | 19:51 |
mithro | Warning: multiple conflicting drivers for top.\n30: | 19:51 |
mithro | port Y[0] of cell $ternary$iceblink//build-ice40-top-routing-virt-HX1K/example_bit.v:756$1390 ($mux) | 19:51 |
mithro | port Y[0] of cell $ternary$iceblink//build-ice40-top-routing-virt-HX1K/example_bit.v:758$1397 ($mux) | 19:51 |
mithro | found and reported 1 problems. | 19:51 |
daveshah | That's weird | 19:51 |
daveshah | Can't see where that would be coming from, might be a Yosys oddity. | 19:54 |
mithro | Ignore that | 19:54 |
daveshah | BTW to rule out Yosys issues, I'd suggest setting up a simulation in Icarus at some point | 19:56 |
daveshah | Just to be on the safe side | 19:56 |
daveshah | This path is well tested being part of arachne's automated tests, so bugs are unlikely however | 19:56 |
mithro | Replacing $mux cell `$ternary$iceblink//build-ice40-top-routing-virt-HX1K/example_bit.v:736$1349' (?) in module `\top' with constant driver `\n30 = \n21'. | 19:58 |
mithro | daveshah: Does that mean it replaced n30 with a constant driver? | 20:00 |
daveshah | Looks like it replaced it with a wire | 20:01 |
daveshah | You can use write_verilog after reading it in to see exactly what it came up with though | 20:01 |
mithro | The output verilog has | 20:04 |
mithro | assign n30 = n21; | 20:04 |
mithro | daveshah: But I'm unsure if these nXX values actually match the names from the verilog file? | 20:05 |
daveshah | mithro: yes, they should do | 20:06 |
daveshah | Have a look at what the inputs to the LUT ended up ad | 20:06 |
daveshah | *as | 20:06 |
*** digshadow has quit IRC | 20:07 | |
mithro | daveshah: There are no "luts" in the written verilog file? | 20:08 |
mithro | but | 20:08 |
mithro | assign n21 = n4 ? (* src = "iceblink//build-ice40-top-routing-virt-HX1K/example_bit.v:727" *) 1'h1 : 1'h0; | 20:08 |
daveshah | mithro: I was referring to the original lut, obviously there won't be LUTs in the output of that script | 20:09 |
daveshah | So that suggests that n21 == n4 | 20:09 |
daveshah | The bigger question is what happened to n2 and n12 | 20:10 |
daveshah | Oh, I see, I think they end up as don't cares | 20:12 |
daveshah | If you look at the function | 20:13 |
mithro | daveshah: Hrm? Why do they end up as don't care? | 20:19 |
daveshah | A proper look at the LUT function suggests it actually just boils down to =n4 | 20:22 |
daveshah | But I may be wrong | 20:22 |
mithro | https://www.irccloud.com/pastebin/qizwYMNv/ | 20:29 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 20:29 |
*** digshadow has joined #vtr-dev | 20:30 | |
mithro | Well, I fixed a bug in icetime_vlog.py | 20:48 |
mithro | daveshah: https://github.com/cliffordwolf/icestorm/pull/152 -- doesn't fix my bug, but does mean that I get | 20:52 |
tpb | Title: icebox: Fix LUT output code. by mithro · Pull Request #152 · cliffordwolf/icestorm · GitHub (at github.com) | 20:52 |
mithro | assign n30 = /* LUT 7 3 7 */ n4; | 20:52 |
*** digshadow has quit IRC | 21:59 | |
mithro | daveshah: You never going to guess what it was / is..... | 22:39 |
mithro | daveshah: vtr was using the lut cascade - which is why that above look up table looks like it uses in_2 | 22:43 |
mithro | daveshah: Because it's from the lut cascade | 22:43 |
mithro | QED! | 22:54 |
mithro | daveshah: https://github.com/cliffordwolf/icestorm/pull/151 | 22:59 |
tpb | Title: icebox_hlc2asc: Allow truth tables to be specified as init string. by mithro · Pull Request #151 · cliffordwolf/icestorm · GitHub (at github.com) | 22:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!