| programmerjake | just 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 meeting | 02:47 |
|---|---|---|
| lkcl | ah good idea | 09:53 |
| lkcl | i have four project plans that need completing (four sets of milestones) | 09:54 |
| lkcl | cesar, 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 that | 12:01 |
| lkcl | as i suspected there's a write-after-write bug. even just one clock delay between instructions is enough to "fix" it | 12:06 |
| lkcl | and 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 ok | 12:10 |
| * lkcl running some longer tests | 12:11 | |
| lkcl | no errors on Testissuer after fixing the waw, hooray | 13:19 |
| lkcl | urr but a "waiting" error when one other FU is busy. sigh. | 13:25 |
| lkcl | ooo that's a nasty one: the only reason that instructions are working is because the *external decoder* is holding them valid for 2 cycles | 14:01 |
| lkcl | so instruction 2 gets *instruction 1*'s register details. | 14:01 |
| lkcl | eek | 14:01 |
| lkcl | or, it's more subtle than that: i have latches on the register *numbers*.... but not whether the registers are valid / in-use for that instruction | 14:02 |
| lkcl | this only showed up when doing a mul followed by an addi | 14:02 |
| lkcl | mul has 2 registers | 14:02 |
| lkcl | addi *only one* | 14:02 |
| lkcl | octavius, 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 |
| octavius | Hi 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 |
| octavius | gpios_pad = top.jtag.resource_table_pads[('gpio', 0)] | 19:18 |
| octavius | yield gpios_pad.gpio3.i.eq(0) | 19:18 |
| octavius | However 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 outpu | 19:22 |
| octavius | output | 19:22 |
| lkcl | no problem | 19:23 |
| lkcl | excellent! | 19:23 |
| lkcl | yes, this is an automatic feature of nmigen. | 19:23 |
| lkcl | anything that is completely unused is removed entirely | 19:23 |
| octavius | Does it prune unused signals? Ah | 19:23 |
| lkcl | and because nothing... yes | 19:23 |
| octavius | Hahahah | 19:24 |
| lkcl | that's why i wired up gpio1/2 to "at least something" | 19:24 |
| octavius | Ah I see | 19:24 |
| octavius | I guess I could add a register or something | 19:25 |
| lkcl | that's what count is | 19:25 |
| octavius | Oh yeah | 19:25 |
| lkcl | but, count is driven internally | 19:25 |
| lkcl | which means: you can't control what's on the outputs based on the inputs, you have to know where "count" is as well | 19:26 |
| lkcl | which is a pain | 19:26 |
| octavius | But 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 |
| lkcl | yes it would | 19:28 |
| octavius | Would require extending the count size, but that's one parameter | 19:28 |
| lkcl | but you'd still not be able to have deterministic output based on the inputs *only* | 19:29 |
| lkcl | a way to fix that: | 19:29 |
| lkcl | 1) remove count.eq(count+1) | 19:29 |
| lkcl | 2) rename count to gpio_ | 19:29 |
| lkcl | gpio_test and set it to length 4 | 19:29 |
| lkcl | 3) add a gpio_oe_test of length 4 | 19:30 |
| lkcl | and put: | 19:30 |
| lkcl | comb += gpio0.i.eq(gpio_test[0]) | 19:30 |
| lkcl | comb += gpio1.i.eq(gpio_test[1]) | 19:30 |
| lkcl | comb += gpio2.i.eq(gpio_test[2]) | 19:30 |
| lkcl | comb += gpio3.i.eq(gpio_test[3]) | 19:31 |
| lkcl | and similarly for gpio_oe_test | 19:31 |
| lkcl | sorry | 19:31 |
| octavius | Ah ok, and have gpio_test be a public attribute (port) that the sim will then manipulate | 19:31 |
| lkcl | comb += gpio0.o.eq(gpio_test[0]) | 19:31 |
| lkcl | yeeeees | 19:31 |
| lkcl | now you're getting it | 19:31 |
| octavius | In a nice little for loop ;) | 19:31 |
| lkcl | if you wanted to get fancy, you could do: | 19:31 |
| lkcl | comb += gpio0.o.eq(gpio_test[0] ^ gpio0.i) | 19:31 |
| lkcl | comb += gpio1.o.eq(gpio_test[1] ^ gpio1.i) | 19:31 |
| lkcl | comb += gpio2.o.eq(gpio_test[2] ^ gpio2.i) | 19:32 |
| lkcl | comb += gpio3.o.eq(gpio_test[3] ^ gpio3.i) | 19:32 |
| octavius | ooo, xor'ing | 19:32 |
| octavius | but why? | 19:32 |
| lkcl | and that way you have a way to test the inputs as well | 19:32 |
| lkcl | you can then do | 19:32 |
| lkcl | yield jtag_resource_pads[("gpio", 0)].gpio_0.i.eq(1) | 19:33 |
| lkcl | and test that gpio_o.o also then equals 1 | 19:33 |
| lkcl | but if you then *also* set gpio_test[0] equal to 1, | 19:33 |
| lkcl | then gpio_o.o should flip to 0 | 19:33 |
| lkcl | and you've just neatly tested gpio inputs *and* outputs | 19:34 |
| octavius | ok | 19:34 |
| lkcl | but | 19:34 |
| lkcl | hang on... | 19:34 |
| lkcl | erm... | 19:34 |
| lkcl | the output is actually going to depend on whether oe is enabled, isn't it. | 19:34 |
| octavius | no | 19:35 |
| lkcl | if you set gpio_oe_test[0] equal to 1 | 19:35 |
| octavius | Because these are just signals | 19:35 |
| octavius | there's no I/O pad logic, right? | 19:35 |
| lkcl | then yield jtag_resource_pads[("gpio", 0)].gpio_0.o should return the value | 19:35 |
| lkcl | ah you used the "disable jtag IO pads" boolean flag? | 19:35 |
| lkcl | you set no_jtag_connect=True ? | 19:36 |
| octavius | no I haven't, that flag prevents me from setting the gpio o/oe signals:: | 19:37 |
| octavius | yield top.gpio.gpio2.o.eq(1) | 19:37 |
| lkcl | that's why i said: use the jtag_resources_pads. | 19:37 |
| octavius | As in, the vcd file doesn't show the o/oe transitions | 19:37 |
| octavius | sure, then I'll keep the JTAG in | 19:37 |
| lkcl | i explained that already: you're trying to "tap in" to the middle of a chain-of-connections | 19:38 |
| lkcl | and because this is a Simulation() not actual physical wires | 19:38 |
| lkcl | the Simulation propagates values from one combinatorial signal to the next (through the eq() settings) | 19:38 |
| lkcl | and of course your random-value-in-the-middle-of-a-chain gets completely destroyed | 19:39 |
| lkcl | you have to change the *end* of the chain | 19:39 |
| lkcl | and that end-of-chain is: in the jtag_resource_pads{} data structures | 19:39 |
| octavius | So ONLY the *pad* end of the chain (where the inputs would be controlled) reside in jtag_resource_pads? | 19:41 |
| lkcl | and where the outputs can be read, yes. | 19:42 |
| octavius | Yes, that too | 19:42 |
| lkcl | strictly speaking self.uart and self.gpio should not even be in Blinker() | 19:43 |
| octavius | So 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 match | 19:43 |
| octavius | Where should they be? XD | 19:43 |
| octavius | Crap, pasted wrong thing sorry | 19:43 |
| octavius | So the sim should also read back outputs from jtag_resource_pads and use some asserts to check the values match | 19:44 |
| lkcl | yes. | 19:44 |
| lkcl | according to what *you* expect the internal behaviour of Blinker() to be | 19:45 |
| lkcl | which *you* design | 19:45 |
| lkcl | and therefore understand | 19:45 |
| lkcl | and have a model in *your* head of how it works | 19:45 |
| lkcl | therefore you can predict - in advance - what the outputs *should* be... based on what inputs *you* set | 19:46 |
| octavius | yep | 19:46 |
| lkcl | hence 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 be | 19:46 |
| octavius | sure | 19:47 |
| lkcl | *you* control it - make it - so that it is easy and obvious | 19:47 |
| lkcl | this is not rocket science: the purpose here is to test the JTAG pads | 19:47 |
| lkcl | if Blinker() is too complex on its own it simply gets in the way | 19:47 |
| octavius | indeed | 19:48 |
| octavius | Thanks luke, I'll get on with it | 19:51 |
| lkcl | :) | 19:52 |
| programmerjake | meeting in 8min | 21:52 |
| lkcl | toshywoshy, 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/!