Monday, 2018-06-11

*** tpb has joined #vtr-dev00:00
*** q3k has quit IRC00:55
*** q3k has joined #vtr-dev01:41
*** ZipCPU_ has joined #vtr-dev03:17
*** ZipCPU has quit IRC03:19
mithromorning everyone13:26
daveshahmithro: hey13:30
mithrodaveshah: I finally understand the INIT value for LUTs13:31
mithrodaveshah: So, is the SB_LUT4.LUT_INIT address 0 first or address 1 first?13:33
daveshahaddress 0 first13:34
daveshahthis isn't BASIC :P13:34
mithrodaveshah: Is the MSB address 0?13:35
daveshahno, LSB is address 013:35
mithrodaveshah: Okay -- but in verilog MSB is first right?   4'b1000 == 1 in the MSB position13:36
daveshahyeap13:37
mithrodaveshah: And in the BLIF the MSB is first bit?13:42
daveshahnot sure, you'll have to check the blif specs13:42
mithrodaveshah: I'm pretty sure clifford made that extension to blif up?13:43
daveshahrun a test then, I think you're right13:44
mithrodaveshah: Do you know if there is a way to stop yosys rotating the inputs to the LUT?13:44
mithrodaveshah: Or ABC I guess?13:45
daveshahThis is not how ABC or Yosys works. Neither is "rotating" the LUT, nor as a LUT directly inferred by that statement13:46
mithrodaveshah: 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] 013:50
tpbTitle: symbiflow-arch-defs/lut.v at 4mcmaster · mithro/symbiflow-arch-defs · GitHub (at github.com)13:50
mithroOpps13:50
mithro.names I[1] O        1 113:51
mithrowhich looks right...13:51
daveshahyep13:52
mithrodaveshah: Which ends up with13:55
mithrohttps://www.irccloud.com/pastebin/lcVfnurY/13:56
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)13:56
mithrokem_: In the .net file <port specification is the first value in the list in[0] or in[3] ?14:01
mithrohttps://www.irccloud.com/pastebin/02KEaSFc/14:03
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)14:03
mithrothat looks wrong?14:04
mithrohttps://www.irccloud.com/pastebin/wGerLnqz/14:06
tpbTitle: 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
mithroI think that "lut out = out = 16'b0100000000000000" should be "lut out = out = 16'b1000000000000000" right?14:26
mithrooh wait14:30
mithro0000 == 0, 0001 == 1 -- .LUT_MASK(16'b0000000000000010) - while SB_INIT(16'b0100000000000000)14:32
mithroSo this looks wrong16:46
mithrohttps://www.irccloud.com/pastebin/TJPPAiE0/16:46
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)16:46
*** digshadow1 has quit IRC17:42
*** digshadow has joined #vtr-dev18:05
mithrodaveshah: As far as I can tell the issue is with this lut19:30
mithrohttps://www.irccloud.com/pastebin/HCt9j1uG/19:30
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)19:30
daveshahmithro: that doesn't look right19:31
mithrodaveshah: why?19:31
daveshahWhat order is it in? if MSB first verilog order, it looks like the function has a dependency on in2 which isn't connected19:32
daveshahBut I may be misunderstanding anyway19:32
daveshahNvm, hlc LUTs were LSB first weren't they19:33
mithrohttps://www.irccloud.com/pastebin/2BFHFfff/19:34
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)19:34
daveshahSo that is MSB first19:35
daveshahI find it odd that the pattern changes at the MSB end, but that won't be reached because in2 is 019:36
daveshahThat's not a problem per se, just an observation19:36
mithrohttps://www.irccloud.com/pastebin/kHKEQqeQ/19:37
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)19:37
mithroassign 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
mithrodaveshah: I'm trying to understand that n30 expression19:41
mithrodaveshah: I made icebox_vlog output it with brackets19:42
mithroassign 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
daveshahNow draw it19:42
mithrodaveshah: ?19:42
daveshahThat's how I'd understand such an expression19:42
mithrodaveshah: If n2==true and n12==true, then the output should be true?19:46
daveshahYeap19:47
mithrodaveshah: This is not happening....19:48
mithrowhen n2==1 and n12==1, n30 == 0....19:48
mithroHrm...19:51
mithroWarning: 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
mithrofound and reported 1 problems.19:51
daveshahThat's weird19:51
daveshahCan't see where that would be coming from, might be a Yosys oddity.19:54
mithroIgnore that19:54
daveshahBTW to rule out Yosys issues, I'd suggest setting up a simulation in Icarus at some point19:56
daveshahJust to be on the safe side19:56
daveshahThis path is well tested being part of arachne's automated tests, so bugs are unlikely however19:56
mithroReplacing $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
mithrodaveshah: Does that mean it replaced n30 with a constant driver?20:00
daveshahLooks like it replaced it with a wire20:01
daveshahYou can use write_verilog after reading it in to see exactly what it came up with though20:01
mithroThe output verilog has20:04
mithro  assign n30 = n21;20:04
mithrodaveshah: But I'm unsure if these nXX values actually match the names from the verilog file?20:05
daveshahmithro: yes, they should do20:06
daveshahHave a look at what the inputs to the LUT ended up ad20:06
daveshah*as20:06
*** digshadow has quit IRC20:07
mithrodaveshah: There are no "luts" in the written verilog file?20:08
mithrobut20:08
mithro  assign n21 = n4 ? (* src = "iceblink//build-ice40-top-routing-virt-HX1K/example_bit.v:727" *) 1'h1 : 1'h0;20:08
daveshahmithro: I was referring to the original lut, obviously there won't be LUTs in the output of that script20:09
daveshahSo that suggests that n21 == n420:09
daveshahThe bigger question is what happened to n2 and n1220:10
daveshahOh, I see, I think they end up as don't cares20:12
daveshahIf you look at the function20:13
mithrodaveshah: Hrm? Why do they end up as don't care?20:19
daveshahA proper look at the LUT function suggests it actually just boils down to =n420:22
daveshahBut I may be wrong20:22
mithrohttps://www.irccloud.com/pastebin/qizwYMNv/20:29
tpbTitle: Snippet | IRCCloud (at www.irccloud.com)20:29
*** digshadow has joined #vtr-dev20:30
mithroWell, I fixed a bug in icetime_vlog.py20:48
mithrodaveshah: https://github.com/cliffordwolf/icestorm/pull/152 -- doesn't fix my bug, but does mean that I get20:52
tpbTitle: icebox: Fix LUT output code. by mithro · Pull Request #152 · cliffordwolf/icestorm · GitHub (at github.com)20:52
mithroassign n30 = /* LUT    7  3  7 */ n4;20:52
*** digshadow has quit IRC21:59
mithrodaveshah: You never going to guess what it was / is.....22:39
mithrodaveshah: vtr was using the lut cascade - which is why that above look up table looks like it uses in_222:43
mithrodaveshah: Because it's from the lut cascade22:43
mithroQED!22:54
mithrodaveshah: https://github.com/cliffordwolf/icestorm/pull/15122:59
tpbTitle: 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!