Tuesday, 2021-11-30

*** mepy <mepy!~mepy@151.53.203.32> has quit IRC00:02
*** xiews <xiews!~wxie@2409:891f:1840:6bc:8432:e8e7:442a:a578> has joined #libre-soc00:34
*** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC00:49
*** xiews <xiews!~wxie@2409:891f:1840:6bc:8432:e8e7:442a:a578> has quit IRC00:55
*** xiews <xiews!~wxie@2409:891f:1840:6bc:8432:e8e7:442a:a578> has joined #libre-soc00:56
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:01
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC01:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:19
*** xiews <xiews!~wxie@2409:891f:1840:6bc:8432:e8e7:442a:a578> has quit IRC01:22
*** xiews <xiews!~wxie@124.77.91.17> has joined #libre-soc01:23
programmerjakejust finished a meeting with my brother and the rest of redshift to explain in more detail what libre-soc would likely want, I invited them to attend the tuesday meeting02:47
*** xiews <xiews!~wxie@124.77.91.17> has quit IRC04:30
*** xiews <xiews!~wxie@2409:891e:6a20:1b04:1850:796d:98a5:3fef> has joined #libre-soc04:31
*** xiews <xiews!~wxie@2409:891e:6a20:1b04:1850:796d:98a5:3fef> has quit IRC05:02
*** xiews <xiews!~wxie@124.77.91.17> has joined #libre-soc05:05
*** xiews <xiews!~wxie@124.77.91.17> has quit IRC07:37
*** xiews <xiews!~wxie@124.77.91.17> has joined #libre-soc07:38
*** openpowerbot <openpowerbot!~openpower@94-226-186-169.access.telenet.be> has quit IRC08:05
*** openpowerbot <openpowerbot!~openpower@94-226-186-169.access.telenet.be> has joined #libre-soc08:18
*** mepy <mepy!~mepy@151.53.203.32> has joined #libre-soc08:50
*** octavius <octavius!~octavius@164.183.115.87.dyn.plus.net> has joined #libre-soc09:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC09:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc09:17
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC09:21
*** octavius <octavius!~octavius@164.183.115.87.dyn.plus.net> has quit IRC09:39
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc09:49
lkclah good idea09:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC09:54
lkcli have four project plans that need completing (four sets of milestones)09:54
*** xiews <xiews!~wxie@124.77.91.17> has quit IRC10:23
*** xiews <xiews!~wxie@2409:891e:6a20:1b04:6dce:d8e:b0e5:8b8d> has joined #libre-soc10:26
*** mepy <mepy!~mepy@151.53.203.32> has quit IRC10:50
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc10:58
*** mepy <mepy!~mepy@151.73.29.35> has joined #libre-soc11:30
lkclcesar, i have test_core.py semi-operational again, it can push one instruction into core right after another, and am now tracking down errors found because of that12:01
lkclas i suspected there's a write-after-write bug.  even just one clock delay between instructions is enough to "fix" it12:06
lkcland it's fixed! very simple, read the write-hazard bitvector non-delayed output. it's combinatorial so i thought there might be a problem, but it's ok12:10
* lkcl running some longer tests12:11
*** xiews <xiews!~wxie@2409:891e:6a20:1b04:6dce:d8e:b0e5:8b8d> has quit IRC12:18
*** xiews <xiews!~wxie@101.93.21.97> has joined #libre-soc12:19
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc13:02
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC13:04
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC13:05
lkclno errors on Testissuer after fixing the waw, hooray13:19
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc13:21
lkclurr but a "waiting" error when one other FU is busy. sigh.13:25
*** octavius <octavius!~octavius@164.183.115.87.dyn.plus.net> has joined #libre-soc13:25
*** ghostmansd <ghostmansd!~kvirc@154.236.189.52> has joined #libre-soc13:31
*** xiews <xiews!~wxie@101.93.21.97> has quit IRC13:52
lkclooo that's a nasty one: the only reason that instructions are working is because the *external decoder* is holding them valid for 2 cycles14:01
lkclso instruction 2 gets *instruction 1*'s register details.14:01
lkcleek14:01
lkclor, it's more subtle than that: i have latches on the register *numbers*.... but not whether the registers are valid / in-use for that instruction14:02
lkclthis only showed up when doing a mul followed by an addi14:02
lkclmul has 2 registers14:02
lkcladdi *only one*14:02
*** xiews <xiews!~wxie@101.93.21.97> has joined #libre-soc14:03
*** ghostmansd <ghostmansd!~kvirc@154.236.189.52> has quit IRC14:16
*** mepy <mepy!~mepy@151.73.29.35> has quit IRC14:25
*** mepy <mepy!~mepy@151.53.198.189> has joined #libre-soc14:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC14:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc14:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC15:20
*** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc15:22
*** xiews <xiews!~wxie@101.93.21.97> has quit IRC15:24
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC17:07
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc17:21
lkcloctavius, moornin. did the stuff about grabbing the dictionary-of-io-pads make any sense?17:52
lkcl(we can go over it this evening)17:52
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc18:02
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC19:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc19:11
octaviusHi lkcl, sorry for the late reply. I think some of it did make sense yeah. By using the same trick you used with the uart, I can drive the input part of the gpio:19:18
octaviusgpios_pad = top.jtag.resource_table_pads[('gpio', 0)]19:18
octaviusyield gpios_pad.gpio3.i.eq(0)19:18
octaviusHowever what I don't get, is that when skipping the Blinker elaboration (by setting no_jtag_connect to True), I lose some GPIO signals (gpio 3 is completely missing) from the .vcd outpu19:22
octaviusoutput19:22
lkclno problem19:23
lkclexcellent!19:23
lkclyes, this is an automatic feature of nmigen.19:23
lkclanything that is completely unused is removed entirely19:23
octaviusDoes it prune unused signals? Ah19:23
lkcland because nothing... yes19:23
octaviusHahahah19:24
lkclthat's why i wired up gpio1/2 to "at least something"19:24
octaviusAh I see19:24
octaviusI guess I could add a register or something19:25
lkclthat's what count is19:25
octaviusOh yeah19:25
lkclbut, count is driven internally19:25
lkclwhich means: you can't control what's on the outputs based on the inputs, you have to know where "count" is as well19:26
lkclwhich is a pain19:26
octaviusBut I could connect the count register to o/oe of all gpios, and then manipulate the inputs from the pad side. That should prevent pruning, right?19:28
lkclyes it would19:28
octaviusWould require extending the count size, but that's one parameter19:28
lkclbut you'd still not be able to have deterministic output based on the inputs *only*19:29
lkcla way to fix that:19:29
lkcl1) remove count.eq(count+1)19:29
lkcl2) rename count to gpio_19:29
lkclgpio_test and set it to length 419:29
lkcl3) add a gpio_oe_test of length 419:30
lkcland put:19:30
*** ghostmansd <ghostmansd!~kvirc@154.236.189.42> has joined #libre-soc19:30
lkclcomb += gpio0.i.eq(gpio_test[0])19:30
lkclcomb += gpio1.i.eq(gpio_test[1])19:30
lkclcomb += gpio2.i.eq(gpio_test[2])19:30
lkclcomb += gpio3.i.eq(gpio_test[3])19:31
lkcland similarly for gpio_oe_test19:31
lkclsorry19:31
octaviusAh ok, and have gpio_test be a public attribute (port) that the sim will then manipulate19:31
lkclcomb += gpio0.o.eq(gpio_test[0])19:31
lkclyeeeees19:31
lkclnow you're getting it19:31
octaviusIn a nice little for loop ;)19:31
lkclif you wanted to get fancy, you could do:19:31
lkclcomb += gpio0.o.eq(gpio_test[0] ^ gpio0.i)19:31
lkclcomb += gpio1.o.eq(gpio_test[1] ^ gpio1.i)19:31
lkclcomb += gpio2.o.eq(gpio_test[2] ^ gpio2.i)19:32
lkclcomb += gpio3.o.eq(gpio_test[3] ^ gpio3.i)19:32
octaviusooo, xor'ing19:32
octaviusbut why?19:32
lkcland that way you have a way to test the inputs as well19:32
lkclyou can then do19:32
lkclyield jtag_resource_pads[("gpio", 0)].gpio_0.i.eq(1)19:33
lkcland test that gpio_o.o also then equals 119:33
lkclbut if you then *also* set gpio_test[0] equal to 1,19:33
lkclthen gpio_o.o should flip to 019:33
lkcland you've just neatly tested gpio inputs *and* outputs19:34
octaviusok19:34
lkclbut19:34
lkclhang on...19:34
lkclerm...19:34
lkclthe output is actually going to depend on whether oe is enabled, isn't it.19:34
octaviusno19:35
lkclif you set gpio_oe_test[0] equal to 119:35
octaviusBecause these are just signals19:35
octaviusthere's no I/O pad logic, right?19:35
lkclthen yield jtag_resource_pads[("gpio", 0)].gpio_0.o should return the value19:35
lkclah you used the "disable jtag IO pads" boolean flag?19:35
lkclyou set no_jtag_connect=True ?19:36
octaviusno I haven't, that flag prevents me from setting the gpio o/oe signals::19:37
octaviusyield top.gpio.gpio2.o.eq(1)19:37
lkclthat's why i said: use the jtag_resources_pads.19:37
octaviusAs in, the vcd file doesn't show the o/oe transitions19:37
octaviussure, then I'll keep the JTAG in19:37
lkcli explained that already: you're trying to "tap in" to the middle of a chain-of-connections19:38
lkcland because this is a Simulation() not actual physical wires19:38
lkclthe Simulation propagates values from one combinatorial signal to the next (through the eq() settings)19:38
lkcland of course your random-value-in-the-middle-of-a-chain gets completely destroyed19:39
lkclyou have to change the *end* of the chain19:39
lkcland that end-of-chain is: in the jtag_resource_pads{} data structures19:39
octaviusSo ONLY the *pad* end of the chain (where the inputs would be controlled) reside in jtag_resource_pads?19:41
lkcland where the outputs can be read, yes.19:42
octaviusYes, that too19:42
lkclstrictly speaking self.uart and self.gpio should not even be in Blinker()19:43
octaviusSo the sim should also read back outputs from So ONLY the *pad* end of the chain (where the inputs would be controlled) reside in jtag_resource_pads and use some asserts to check the values match19:43
octaviusWhere should they be? XD19:43
octaviusCrap, pasted wrong thing sorry19:43
octaviusSo the sim should also read back outputs from jtag_resource_pads and use some asserts to check the values match19:44
lkclyes.19:44
lkclaccording to what *you* expect the internal behaviour of Blinker() to be19:45
lkclwhich *you* design19:45
lkcland therefore understand19:45
lkcland have a model in *your* head of how it works19:45
lkcltherefore you can predict - in advance - what the outputs *should* be... based on what inputs *you* set19:46
octaviusyep19:46
lkclhence why i said not to involve "count" in that because then it is too complex to predict or determine what the outputs are supposed to be19:46
octaviussure19:47
lkcl*you* control it - make it - so that it is easy and obvious19:47
lkclthis is not rocket science: the purpose here is to test the JTAG pads19:47
lkclif Blinker() is too complex on its own it simply gets in the way19:47
octaviusindeed19:48
octaviusThanks luke, I'll get on with it19:51
lkcl:)19:52
*** octavius <octavius!~octavius@164.183.115.87.dyn.plus.net> has quit IRC20:25
*** ghostmansd <ghostmansd!~kvirc@154.236.189.42> has quit IRC20:38
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has quit IRC20:54
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@154.236.189.53> has joined #libre-soc20:56
*** octavius <octavius!~octavius@164.183.115.87.dyn.plus.net> has joined #libre-soc21:37
programmerjakemeeting in 8min21:52
lkcltoshywoshy, rsc sadoon_albader[m jn Veera[m] ^22:02
*** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC23:16

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!