Tuesday, 2021-11-30

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
lkclah good idea09:53
lkcli have four project plans that need completing (four sets of milestones)09:54
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
lkclno errors on Testissuer after fixing the waw, hooray13:19
lkclurr but a "waiting" error when one other FU is busy. sigh.13:25
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
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
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
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
lkclno problem19: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
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
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
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
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
lkclhang on...19:34
lkclthe output is actually going to depend on whether oe is enabled, isn't it.19:34
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
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
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
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
octaviusThanks luke, I'll get on with it19:51
programmerjakemeeting in 8min21:52
lkcltoshywoshy, rsc sadoon_albader[m jn Veera[m] ^22:02

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