Saturday, 2021-11-13

ghostmansd[m]lkcl: I'd rather prefer NLnet to finally come out and at least say "sorry, we've been busy, but we remember we promised the grants in the beginning of November, here are new expectations and the money will be on your account by this date" and so on. :-)06:17
ghostmansd[m]I don't actually like how it turns out, it's already been more than two months since the first RFP. And I don't want to write some e-mails again, because, well, that was the part of the job which 3mdeb promised to do.06:21
Chips4Makers[m]Regarding JTAG. The standard is IEEE 1149.1, the standard is normally behind paywall but a little searching should allow to find a version on-line.10:50
Chips4Makers[m]Luke is right the c4m-jtag should allow to add IO in the scan chain without needing to bother about muxing etc.; e.g. just connecting up the signal for the IO and for the core.10:50
Chips4Makers[m]By default almost signals should be put in the scan chain. There may be a few exceptions like the clock. Putting the clock not in the scan chain should allow to use JTAG boundary scan to set input to the core and then do clock cycle stepping independently of the scan chain.10:50
Chips4Makers[m]Driving the signals for core through boundary scan is not well tested so that may be good material for some unit testing.10:50
Chips4Makers[m]One nice addition to c4m-jtag would be to have a BSDL ( file generated from the boundary scan. I could add this as a task under NGI Pointer if nobody else wants to take up this part.10:53
lkclghostmansd[m], i know, it's a unique situation, just bad timing, that the Accountant is getting concerned at the addition of new people because of the length of time for this project12:32
lkclevery new person should be added to the Memorandum of Understanding, and he's obviously getting nervous at the possibility of an EU Grant Auditor asking what the bloody hell's going on12:32
lkclMichiel's got a solution: a "single entity" (named, "Libre-SOC Team") is added to each Memorandum of Understanding.12:34
lkclthis is a one-off, one-time addition [it's the constant changing of the MoU which is making the Accountant nervous]12:34
lkclfollowed by a *separate* document - one that they do not then have to notify the European Union Grant Auditors - containing a list of all Libre-SOC team members12:35
lkclafter that happens we won't have any issues because there will not be constant modifications to the *actual contract* with the Horizon 2020 Program Grant Auditors12:35
lkclbasically, it's in hand, and it's my responsibility - you (or 3mdeb) don't need to write to NLnet about this12:36
lkclnormally, RfPs they say take 2-3 weeks, but sometimes it's like 2 days.12:41
lkclChips4Makers[m], yeah that looks like a nice addition. auto-generation into BSDL would help aid in understanding what the python code does, when it's used12:45
lkcla bit like how yosys "show top" can aid in understanding of nmigen12:45
kylellkcl, interesting yet understandable given the audit angle and how they want to mitigate risk in that regard12:49
lkclyehyeh. we ran under the "threshold of annoyance of the Accountant" for some considerable time12:50
ghostmansd[m]lkcl: OK, got it, hopefully this topic will be closed soon :-)12:55
octaviusLot's of different disciplines covered in this project eh? Engineering, management, finance, etc. hehehe13:28
lkcloctavius, frickin tell me about it.  all of it public14:00
lkclmental amount of responsibility14:00
lkclghostmansd[m], they totally get it (and the fast-approaching deadlines) - and they're good at their word. hence why i suggested some BTC as a deposit.  we've something like... around USD 5,000 in donated Decred, which programmerjake converted to BTC14:02
ghostmansd[m]BTC has some downsides, including possible issues on legal side. I'm not sure tax office here has even the slightest idea of wtf BTC is. :-)14:06
lkclok scratch that one14:20
lkclyou don't need the hassle :)14:20
octaviuslkcl, I think I have a better grasp at the task now. As for UARTResource etc., would these be new classes that I need to create?14:21
lkcli'd suggest just cut/paste using what's in nmigen_boards14:24
lkcland drastically cut it back - remove everything optional.  about 5 lines.14:25
octaviuswill do14:25
lkclit's a function not a class14:25
octaviusYeah, it just looked weird there14:25
lkclthe idea here is not that this will be the final code, but to create an iterative startingpoint for at least "what the bloody hell's going on"14:26
octaviususually I assume it's a class if it's capitalised14:26
lkclthat appears to be a hardware developer convention14:26
lkclbreaking standard python and standard software programming practices14:26
octaviusmy initial confusion was trying to bodge something, where's we're making a new thing instead (although based on previous work)14:26
octaviushehehe yeah14:26
lkclwell, i always look for a way to bodge something which leverages "other stuff" if you know what i mean14:27
octaviusThat's what engineering's about eh?14:27
lkclbtw i just realised, for the bank "ganging", the information is missing from the JSON file14:29
octaviusWhat's ganging?14:29
lkclSDMMC, ULPI, and SDRAM all have one single direction-enable14:30
lkclfor a bank of pins14:30
lkcl"ganged" is a word from the Audio industry14:31
lkclthe "gang" acts in unison.14:31
octaviusAh, so sharing the bus?14:31
lkcltherefore, DIR will change... no14:31
lkclDIR will change the DIRection of *all* D0..D714:31
lkclone direction for D014:31
lkclone direction for D114:32
lkclone direction for D114:32
octaviusAh, so for the slave to communicate, the master (SoC) must change the DIR14:32
lkclok, so the data bus (whether it be ULPI, SDRAM, SDMMC or RGMII) is bi-directional, yes?14:34
lkcland there are 4 to 64 pins on it14:34
lkcl4 for SDMMC, ULPI and RGMII, but up to 64 on SDRAM14:34
lkclwho controls the direction?14:35
lkclif there are 64 data pins, do you need 64 data *direction* pins, as well?14:35
lkclobviously, somebody has to control the direction (the master is often chosen because it's easier)14:36
lkcland, if you added another 64 direction pins, that's a waste of IO pads.14:36
lkcltherefore, you have **ONE** direction pin14:36
lkclcontrolling a **BANK** of data pins directions14:36
lkcltherefore, by definition, the data bank is "ganged" together with a single DIR pin controlling the direction of the *entire* bank of data pins14:37
lkclso that information - which pin is the "ganged direction pin" - is missing from the JSON output14:38
lkclline 2814:38
lkclcan't pick it up14:38
lkcland can't set the direction14:38
lkcli'll sort that out14:39
lkcli added a debug string so you can see how to run/test it15:11
lkclso those 20-30 lines shooouuld be obvious how to seque into youuur 20-30 lines15:11
lkclonce you have a dummy function which blats out a list of Resource()s15:12
lkclusing that function is a one-line-drop-in-replacement.  should be15:13
octaviusSo far I've been working in pinmux repo on my host system, separate from the rest of the chip. To use your function, I need to got into one of my soc schroot and update the repos?15:15
octaviusI haven't setup an ssh on the schroot (I guess I could just copy the private key)15:15
octaviusAlso, in your dummy_pinset() example, you use Resource function for the GPIO. Is this the Resource from nmigen?;a=blob;f=nmigen/build/;h=3b445f6808b156d0e8fac7153f0201e9956fc8ec;hb=HEAD#l17915:22
octaviusI'm guessing not as you mentioned UARTResource etc. are functions, but nmigen-boards doesn't define a Resource function15:23
lkclwell, this is one of the things that's a f*****g nuisance about hardware engineers: they completely fail to understand and appreciate the critical importance of *not* using wildcard imports15:41
lkcllook at line 1 of nmigen-boards UARTResource15:42
lkclis it obvious - at all - what that line does?15:42
lkclfrom import *15:42
lkcldo you know what is in
lkclbecause i don't15:42
lkcllet's go and hunt for it and find out what's in it, eh?15:42
lkclah ohhh lookeee15:43
lkclit's yet another f****g time-wasting set of f*****g wildcard imports15:43
lkclwhere if any one of those objects imported happens to have the exact same name, it f***s you over by using the last one, not the one listed earlier.15:44
lkcloh look.  fiiiinally, after several minutes, we've been able, through a LOT of pissing about, to *deduce* that must be using Pins, Resource and Subsignal15:45
octaviusYeah, I agree with you there. After joining libre-soc I started to question the sanity of anyone using wildcards15:45
lkcli have spoken to nmigen developers about it: they disregarded my advice and how difficult it makes things.15:46
lkcli have spoken to the lambdasoc developers: they disregarded my input15:46
lkcli have spoken to the litex developers: they disregarded my input15:47
octaviusI guess the idea is too deeply ingrained?15:47
lkclevery single hardware engineer for every single migen and nmigen project has absolutely no desire to solve this because they are too focussed on "their small project".15:47
lkclit's fine.... *for them*... because they work with the codebase that *they* develop, every single day.15:48
lkcltherefore, they know the entire codebase15:48
octaviusAnd no one is expected to touch it15:48
lkcl"so why the hell don't you"15:48
lkclit's a matter of a complete lack of empathy15:48
lkclas *hardware* engineers they've simply not been trained in Software Engineering maintenance techniques15:49
lkclwhich are ingrained into Libre/OpenSource developers/maintainers through either training, or a series of painful experiences15:49
lkclunfortunately, the user-base isn't large enough - yet - to have crossed the "threshold of pain"15:50
lkclso, unfortunately, we have to put up with their mess.15:50
octaviusAnyway, let's get away from this depressing tangent for now. I'm guessing you don't know what Resource() is (or where)?15:51
lkcli do... it's from
lkcl"<lkcl> oh look.  fiiiinally, after several minutes, we've been able, through a LOT of pissing about, to *deduce* that must be using Pins, Resource and Subsignal"16:07
lkclline 179. class Resource16:08
lkclbasically you can do exactly the same as this16:08
lkclline 716:08
octaviusAh ok16:09
lkclbasically, in small steps, i'm introducing you to the concept of abstraction16:09
lkclif this were databases, i would use the term "4th normalise form"16:09
lkclso if you write a simple dummy_resources function which *explicitly* returns the list of Resources()16:10
lkcl(not using anything from soc, at all)16:10
lkcl*then* you will be able to relate that to the (new) get_pinspec_resources() function very easily16:11
octaviuslet's hope so XD16:11
octaviusYour example of UARTResource has the name "uart" as the first arg, followed by instance number and the then tx/rx pins16:13
octaviusthe nmigen boards uses (*args, rx, tx,....)16:14
octaviusWhat does *args mean in python context?16:14
lkcl*args means, "all non-default arguments not explicitly given a name previously"16:15
lkcl(as a tuple)16:16
lkcl**kwargs means, "all non-given-keyword arguments"  (kw - keyword)16:16
lkclit's a very useful - but computationally expensive - trick which allows you to write versatile code16:17
lkcllike, Cat(*args)16:17
lkclyou can then pass in Cat(sig1, sig2, sig3,...... sig1099837)16:18
lkcland they will all end up as a tuple in: the-one-single-variable-known-by-the-name, "args"16:18
lkclkwargs is things like fred(keyword1="hello", keyword2="bye")16:19
octaviusbso kwarg is basically a dictionary?16:19
lkcland if fred is "def fred(**kwargs): print(kwargs)"16:19
lkclyou get the output of:16:19
lkcl{"keyword1": "hello", "keyword2": "bye"}16:19
lkclthe conversion to tuple (and dict) is what makes it very expensive16:19
lkclbut, this (nmigen) is a compiler: we don't care [at least, not that much]16:20
octaviusSo what's the difference **kwargs and a dict argument?16:20
lkcldef fred(kwargs) basically16:20
lkclyou *have* to construct the arguments as a dictionary.16:20
lkclyou *cannot* call fred(kw1="hello", kw2="goodbye")16:21
lkclyou *HAVE* to call it as:16:21
octaviusAh, the ** unpacking operator converts a variable number of args into one dictionary?16:21
lkclwhich is an (expensive) weirdness16:21
lkclit's a variant of c varargs, basically16:21
lkcl*args ==> c varargs16:22
lkcl**kwargs ==> c++ sort-of-named-version-of-varargs16:22
lkclso is tied very closely to the internals of the python interpreter, obviously.16:22
octaviusSo with definition:16:24
octaviusUARTResource(*args, rx, tx, conn=None, attrs=None, role=None)16:24
octaviusAnd instance:16:24
octaviusUARTResource("uart", 0, tx=..., rx=..)16:24
octaviusThe "uart", 0 will be part of *args, and thus converted to a tuple?16:24
lkclnotice how it's passed on to
lkcl*args, ...)16:26
lkclso yeeees, it could be eeeither "uart"16:26
lkclor 0/1/2/316:26
lkclor "uart", 0/1/2/316:26
lkcland you, as the *developer* of that function, UARTResource, have declared:16:27
octaviusBut it won't matter until resolves it16:27
lkcl"whatever the hell does, we just blindly pass arguments through"16:27
lkclproviding UARTResource with the *exact* same API as...
lkclbut, in this case, you do actually need to know :)16:27
lkclbecause you won't be using UARTResource in this way16:28
lkclyou'll be bypassing it16:28
lkcland creating the call to directly16:28
lkclso it should not be16:28
lkcl   return*args)16:28
lkclbecause there won't be an args tuple16:28
octaviusAh, I'm just using this abstraction as an aid then?16:29
lkclonly a name ("uart") and _maybe_ a number16:29
lkclyes, you're using UARTResource as an aide to understanding of
lkclbtw you should at this point have at least 6 xterms open on-screen and left permanently open16:29
lkcleach with a file in it16:30
lkclthat should not be closed after accessing it, because in 5-10 mins time, you will only have to open it again in order to read the function16:30
octaviusAnd should I be working in a schroot with all the soc files available?16:31
lkcli'm not17:23
lkclbut then i haven't updated my laptop since debian/testing was roughly-equal-to debian/1017:23
lkcl(and can't!)17:23
lkcli'm actually now setting up chroots for some standard programs instead!17:24
lkcltake that not as an explicit answer, but as a learning experience to make up your own mind :)17:26
octaviusHahaha, thanks!17:39
octaviuslkcl, thanks for adding the nmigen block. I'll play with it in a little bit19:04
lkclit was much more of a pain in the ass than i was expecting, but slowly, by examining LatticePlatform and others, the pieces can be extracted19:40
lkclfirst thing, to get a sync domain, i notice in Platform.create_missing_domain() that default_clk and default_rst have to exist19:40
lkclthese should19:41
lkclreally be picked up from resource "sys" (from the pinmux spec file)19:41
lkclbut for now let's just hardcode them to "clk" and "rst" just like in verilog19:41
lkcla resource named "clk" is expected to exist, sigh19:43
lkcldone, works great19:46
octaviuslkcl, had a read through the changes and tried to run the code, I'm getting an AttributeError in regards to "layout" (used in the get_* methods of the DummyPlatform)22:15
octaviusOk, used wrong nmigen version22:36
octaviusThanks for the help today luke. Tomorrow I'll try to get a break (been quite busy with more than just libre-soc), however I may play around with c4m-jtag if I have an hour or two. On monday I'll start looking at migrating what we need from the (I can at least somewhat grasp what we need to do XD)22:40
lkcldone already, that bit22:56
lkcl(git pull)22:56
octaviusSo the latest version runs with no issues for me22:56
lkcldone for the night. you can take over tomorrow morning if you're about22:56
lkclit got complicated, i'll make some notes22:57
octaviusIt certainly did :)22:57
octaviusSure, I'll catch with you later, although I'll try to take a break for most of tomorrow.22:58

Generated by 2.17.1 by Marius Gedminas - find it at!