Monday, 2021-11-29

lkclcesar, sorted;a=commitdiff;h=a320531e88165ae7f5074d583854c5907b6f442910:26
lkcli'm amazed that was the only one in "general" cases10:27
lkclthe NIA was being advanced ahead of the list of instructions.  something needs to be done about that.10:28
lkclNIA was being set to 16 (because 12+4=16)10:28
lkclbut then branch asked it to jump back to 4...10:28
lkclbut of course NIA is being read before that change takes place10:29
lkclby saying "instruction is busy" the delays reading NIA until it's been set to 4...10:29
lkcland then of course it goes, "oh, this PC, 4, is still within the program, let's continue"10:29
cesarFor my part, I'm planning how to get the FSMs in TestIssuer into shape.10:31
lkclbranch tests work too, dang.10:32
lkcldo feel free to totally cut SVP64 entirely from a copy first, to save time10:33
lkclthe priority is the in-order core: if TestIssuer lags somewhat, as long as it works it's fine.10:33
lkcly'know what? i'm just going to run the entire test suite to see if it works10:33
lkclFOSDEM2022 CfP new VLSI devroom is open!
lkclwoo! dang! a pass!12:16
octaviusHello, been awhile. How do I push a submodule? In my case I'm trying to update in pinmux submodule within the soc directory. Do I have to specify something other than "origin master"?13:51
lkclok so whilst technically it's possible to do, generally you do this instead:14:07
lkcl* check out the module separately as its own repo14:07
lkcl* edit the separate module14:07
lkcl* commit the separate module14:07
lkcl* go to the repository that has the submodule14:07
octaviusOk, so edit only using pinmux repo separately, then execute inside the greater soc repo14:07
lkcl* do git pull14:08
lkcl* do "git submodule update --init --recursive"14:08
lkcl* do "git commit" *ONLY* of the submodule14:08
lkclyes to the 1st bit14:08
lkclbut sort-of-not-really for the 2nd14:08
octaviusWhy the "--init --recursive" flags? Doesn't the submodule repo exist already?14:08
lkclthe reason is because: having copied code *into* pinmux, the code you are working on requires no modifications to soc14:09
lkcl(or, shouldn't)14:09
lkcldon't know, don't care, it's one of those "voodoo magic incantations" :)14:09
octaviusOk, will do that then14:10
lkcllots of things in computing are like that14:10
lkclunderstanding is... deferred, shall we say14:10
octaviusYep, I got that much X'D14:10
lkclwhich is an attitude that saves a... vast amount of "but whyyyyyyy" as well as massive distraction :)14:10
lkclwhat i recommend is: do a unit test that has *absolutely nothing to do with boundary scan at all*14:11
lkclchange Blinker (particularly count) so that it is "easy to test in a deterministic way".14:11
lkclshove some input on uart tx, oh look it comes out on uart rx.14:12
octaviusOk, I think the jtag_sim is running, but I'm getting KeyError because the test is trying to access non-existing signals. I was thinking of changing those to what's shown on the yosys diagram14:12
lkclshove some stuff on GPIO1, oh look it changes ... say... GPIo2 one clock later14:12
lkclforget that for now14:12
lkclthere are about four unknowns here14:13
octaviusOk, forget all the existing stuff, do a simple test, got it14:13
lkcl... yes.14:13
lkclthen when that simple test is working, you can go, "hmm if i change the boundary scan, It Doesn't Work (tm)"14:13
lkclwhere you can then go, "But I Had The Simple Test Working Therefore Logically I Can Deduce That The Error Must Be in Boundary Scan"14:14
lkclbut if you don't have the simple test working first, you have *no idea* if it was the simple test or the BS.14:14
octaviuswhich means I can get rid of all the extra modules like SRAM?14:15
lkclfeel free to alter Blinker to do whatever-it-is-you-need14:15
lkcland you'll see that i added an option to JTAG to set the wb width to None.14:15
octaviusOk. I'm guessing that normal JTAG module always expects to operate with WB memory attached?14:16
lkclwhen you get to it i recommend using the non-networked version of jtag client/server14:16
lkclno it doesn't14:16
lkclbut, focus on the simple test first14:17
lkcli suggest disconnecting the GPIO from count, but at least using sync on the GPIO inter-connections14:17
lkclup to you, but basically, you want to be able to do:14:18
lkcl"if i set these inputs, i know from the way that the code is bleedin obvious, that the outputs should beeee... X"14:18
lkcland always X14:18
lkclby having "count" in the mix, that's not true14:18
lkclbecause "count" is internal14:18
octaviusMakes sense14:19
octaviusFor the simple test, can I git rid of everything between lines 335 and 367?;a=blob;f=src/spec/;h=a2f1c5c5959d321999ae1bbdf861d414dd5c01a1;hb=a61fe0517a767c5c0985ef8b7d8482c2a1e12a4414:22
octaviusOr does the ASICPlatform() object and build() have to stay?14:23
lkclset it to "if False:"15:02
lkclwhich is a good prototyping way of having "useful stuff" around that you don't have to waste time putting back in15:03
octaviusAnd what about the generator function TypeError I have, did you see that?
lkclsim.add_sync_process(wrap(jtag_srv(top))) #? jtag server15:22
lkclput those back, you'll need them later.15:22
lkcltry to get out of the habit of deleting code for the sake of it, when all you are doing is:15:22
lkcla) removing use-case examples that show you what you need to copy15:22
lkcl2) making more work for yourself when you know it has to be put back in later15:23
lkclif you had left the code in, you would have noticed the difference between:15:23
lkclsim.add_sync_process(wrap(jtag_srv(top))) #? jtag server15:23
octaviusSo the wrap() function is important?15:23
lkclthat is a question that is easily answered by trying it and seeing what happens15:24
octaviusFrom the error, I guess wrap makes it a generator function15:24
lkclthe less you change "because it may or may not look obvious", the less there is to go "wrong"15:24
lkclyou do not have to do quotes everything yourself quotes15:25
lkclthat way lies a world of pain15:25
lkclstart from an *existing known good unit test* that "works"15:25
lkcluse it verbatim15:25
lkcland only then remove one thing from it15:25
lkclyou did two things.15:25
octaviusBut I thought you wanted me to make a basic unit test from scratch?15:25
lkclyes but not by forcing yourself to write *from* scratch15:26
lkclwithout leveraging some other known-good, known-working, existing code15:26
lkclalways always always work from something that has been written by someone else and is known to work15:26
octaviusSo should I use jtag_srv?15:26
lkclwhatever, just find something that works and use it15:27
lkclone of cesar's multicompunit tests15:27
lkclthere are hundreds of unit tests to work from as a base and copy: you absolutely do not need to abandon all that work and force yourself to completely ignore it and try to "make your life harder for some unknown reason"15:28
lkclmake the stepping stones as small as possible15:28
lkcland increment as fast as possible15:28
lkclthat way you will make inexplicably rapid progress15:29
lkclunlike me who has just realised i screwed up15:30
lkclbut at least have realised that, sigh15:30
octaviuswhere can I find cesar's multicompunit tests? soc repo?15:31
lkcl1 sec15:32
lkclooo just found a nasty bug15:50
lkcli tried switching off regport number reduction15:51
lkcl(the FSM TestIssuer ran with a single read port and a single write port on the Integer regfile)15:51
lkclso that we did not have absolutely massive regfile port proliferation15:51
lkcli just tested out the 4R2W scenario (instead of 1R1W)15:52
lkclfailed. no obvious reason15:52
lkclthen i realised that the for-loops constructing the write-hazard bitvector protections were not *themselves* using "regfile ports" any more15:53
lkclbut instead are using an SRLatch (which only has one set and one clear port)15:53
lkclINT.o protection and INT.o2 (second write port) use the *exact same SRLatch set/get* to indicate an outstanding write is expected15:54
lkclwhich meant that in the construction of the code, the INT.o tried to update the SRLatch set/get15:54
lkcland then INT.o2 *overwrote* that15:54
lkcldestroying the write-hazard protection for INT.o in the process15:55
lkclthis is extremely lucky to have found that in such an obvious way15:55
lkclrather than something horribly obscure such as XER (which has 3 write ports) and is not very common15:55
lkclanyway: fixed it by merging the set/clr requests at a higher level15:56
lkcloctavius: you're currently trying to get access to local variables, expecting them to magically exist inside the Blinker() instance17:14
lkclwithout actually ever adding them to Blinker() to make them accessible17:14
lkcllocal variables inside a function are local for very good reason17:15
lkclplus, you are expecting that nmigen Signal() names should also magically be made available publicly inside the instance17:15
lkcli'll put some comments in for you17:15
octaviusAh, so Blinker doesn't have any ports, and thus the test can't drive anything?17:16
lkclbasically correct.17:19
lkclyou cannot magically expect things to appear that you - or some other function - has not *explicitly* added17:19
lkclpython does not work that way17:19
lkcldo a "git pull" you will see the technique i used to find out what is going on17:20
lkcli ran the test *five times*, each time adding more exploratory "print" statements17:20
lkclif you had asked me, i would not have been able to tell you what was in the object17:20
lkclbut the "print dir(top)" statement showed me, "oh look, it doesn't have a gpio member"17:21
lkcltherefore, first, i added one17:21
lkclthen, next, i had absolutely no idea what was *in* that gpio object.17:21
lkclbut the "print dir(top.gpio)" statement showed me17:21
lkcletc etc.17:21
lkclrepeat repeat repeat repeat17:21
lkclexplore explore explore explore17:21
lkcldo that rapidly and unhesitatingly17:22
lkclquickly drill down to what you want to find17:22
lkclif there was a nicey lovey all-over-it-with-a-mousey clickey GUI explorer around17:23
lkclyou could have used that to see the entire tree-view of the Blinker() instance17:23
lkclbut it would still not have helped you initially because you hadn't actually added the gpio resource *to* the Blinker instance17:24
lkcltherefore gpio was not part of the public API of Blinker()17:24
lkclyou get the idea17:24
lkcloctavius, what nmigen does inside Simulation() is nothing that you are "permitted" direct access to17:28
lkclthe function named elaborate() is called *by* Simulation()17:29
lkclyou have not called it yourself, therefore you are *not* getting direct access to the Module (m) returned *by* the Blinker.elaborate() function17:29
lkclthat module contains all the nmigen AST.. *and you do not have access to it*17:30
lkclyou can see the results of its operation (through gtkwave)17:30
lkclbut you cannot manipulate it directly or even get at it17:30
lkclinstead, we have to deploy a trick17:30
lkclinside Blinker.elaborate(), where the GPIO resource is obtained,17:31
lkclmake that gpio Record a *member of Blinker*.17:31
lkclthen, once Simulation() has called the Blinker instance's elaborate() function17:31
lkcloh look!17:31
lkcla gpio instance magically appears!17:31
*** mepy_ is now known as mepy21:57

Generated by 2.17.1 by Marius Gedminas - find it at!