| 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 (https://en.wikipedia.org/wiki/Boundary_scan_description_language) 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 |
| lkcl | ghostmansd[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 project | 12:32 |
| lkcl | every 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 on | 12:32 |
| lkcl | Michiel's got a solution: a "single entity" (named, "Libre-SOC Team") is added to each Memorandum of Understanding. | 12:34 |
| lkcl | this is a one-off, one-time addition [it's the constant changing of the MoU which is making the Accountant nervous] | 12:34 |
| lkcl | followed 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 members | 12:35 |
| lkcl | after 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 Auditors | 12:35 |
| lkcl | basically, it's in hand, and it's my responsibility - you (or 3mdeb) don't need to write to NLnet about this | 12:36 |
| lkcl | normally, RfPs they say take 2-3 weeks, but sometimes it's like 2 days. | 12:41 |
| lkcl | Chips4Makers[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 used | 12:45 |
| lkcl | a bit like how yosys "show top" can aid in understanding of nmigen | 12:45 |
| kylel | lkcl, interesting yet understandable given the audit angle and how they want to mitigate risk in that regard | 12:49 |
| lkcl | yehyeh. we ran under the "threshold of annoyance of the Accountant" for some considerable time | 12:50 |
| ghostmansd[m] | lkcl: OK, got it, hopefully this topic will be closed soon :-) | 12:55 |
| octavius | Lot's of different disciplines covered in this project eh? Engineering, management, finance, etc. hehehe | 13:28 |
| lkcl | octavius, frickin tell me about it. all of it public | 14:00 |
| lkcl | mental amount of responsibility | 14:00 |
| lkcl | ghostmansd[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 BTC | 14: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 |
| lkcl | :) | 14:19 |
| lkcl | ok scratch that one | 14:20 |
| lkcl | you don't need the hassle :) | 14:20 |
| octavius | lkcl, 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 |
| lkcl | i'd suggest just cut/paste using what's in nmigen_boards | 14:24 |
| lkcl | https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/resources/interface.py#L10 | 14:25 |
| lkcl | and drastically cut it back - remove everything optional. about 5 lines. | 14:25 |
| octavius | Thanks | 14:25 |
| octavius | will do | 14:25 |
| lkcl | it's a function not a class | 14:25 |
| octavius | Yeah, it just looked weird there | 14:25 |
| lkcl | the 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 |
| octavius | usually I assume it's a class if it's capitalised | 14:26 |
| octavius | sure | 14:26 |
| lkcl | yehyeh | 14:26 |
| lkcl | that appears to be a hardware developer convention | 14:26 |
| lkcl | breaking standard python and standard software programming practices | 14:26 |
| octavius | my initial confusion was trying to bodge something, where's we're making a new thing instead (although based on previous work) | 14:26 |
| octavius | hehehe yeah | 14:26 |
| lkcl | well, i always look for a way to bodge something which leverages "other stuff" if you know what i mean | 14:27 |
| octavius | That's what engineering's about eh? | 14:27 |
| lkcl | :) | 14:28 |
| lkcl | btw i just realised, for the bank "ganging", the information is missing from the JSON file | 14:29 |
| octavius | What's ganging? | 14:29 |
| lkcl | SDMMC, ULPI, and SDRAM all have one single direction-enable | 14:30 |
| lkcl | for a bank of pins | 14:30 |
| lkcl | "ganged" is a word from the Audio industry | 14:31 |
| lkcl | the "gang" acts in unison. | 14:31 |
| octavius | Ah, so sharing the bus? | 14:31 |
| lkcl | therefore, DIR will change... no | 14:31 |
| lkcl | no | 14:31 |
| lkcl | DIR will change the DIRection of *all* D0..D7 | 14:31 |
| lkcl | not | 14:31 |
| lkcl | one direction for D0 | 14:31 |
| lkcl | one direction for D1 | 14:32 |
| lkcl | one direction for D1 | 14:32 |
| lkcl | ... | 14:32 |
| lkcl | ... | 14:32 |
| lkcl | D7 | 14:32 |
| octavius | Ah, so for the slave to communicate, the master (SoC) must change the DIR | 14:32 |
| lkcl | ok, so the data bus (whether it be ULPI, SDRAM, SDMMC or RGMII) is bi-directional, yes? | 14:34 |
| octavius | Yeah | 14:34 |
| lkcl | and there are 4 to 64 pins on it | 14:34 |
| lkcl | 4 for SDMMC, ULPI and RGMII, but up to 64 on SDRAM | 14:34 |
| lkcl | who controls the direction? | 14:35 |
| lkcl | and | 14:35 |
| lkcl | if there are 64 data pins, do you need 64 data *direction* pins, as well? | 14:35 |
| lkcl | obviously, somebody has to control the direction (the master is often chosen because it's easier) | 14:36 |
| lkcl | and, if you added another 64 direction pins, that's a waste of IO pads. | 14:36 |
| lkcl | therefore, you have **ONE** direction pin | 14:36 |
| lkcl | controlling a **BANK** of data pins directions | 14:36 |
| lkcl | therefore, by definition, the data bank is "ganged" together with a single DIR pin controlling the direction of the *entire* bank of data pins | 14:37 |
| lkcl | so that information - which pin is the "ganged direction pin" - is missing from the JSON output | 14:38 |
| lkcl | line 28 | 14:38 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/config/pinouts.py;h=03cfa974b957f654512d8ff204ce1262ce7d632f;hb=df423ac698b5acd63260e4751569c7621d950d35#l28 | 14:38 |
| lkcl | can't pick it up | 14:38 |
| lkcl | and can't set the direction | 14:38 |
| lkcl | i'll sort that out | 14:39 |
| lkcl | octavius, https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=d8e253b468cc30d064acd2402e22959c0607cd5e | 15:09 |
| lkcl | i added a debug string so you can see how to run/test it | 15:11 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=e3e78916215f947cf229f884df11bef7435f7d58 | 15:11 |
| lkcl | so those 20-30 lines shooouuld be obvious how to seque into youuur 20-30 lines | 15:11 |
| lkcl | once you have a dummy function which blats out a list of Resource()s | 15:12 |
| lkcl | using that function is a one-line-drop-in-replacement. should be | 15:13 |
| octavius | So 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 |
| octavius | I haven't setup an ssh on the schroot (I guess I could just copy the private key) | 15:15 |
| octavius | Also, in your dummy_pinset() example, you use Resource function for the GPIO. Is this the Resource from nmigen? https://git.libre-soc.org/?p=nmigen.git;a=blob;f=nmigen/build/dsl.py;h=3b445f6808b156d0e8fac7153f0201e9956fc8ec;hb=HEAD#l179 | 15:22 |
| octavius | I'm guessing not as you mentioned UARTResource etc. are functions, but nmigen-boards doesn't define a Resource function | 15:23 |
| lkcl | well, 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 imports | 15:41 |
| lkcl | look at line 1 of nmigen-boards UARTResource | 15:42 |
| lkcl | https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/resources/interface.py | 15:42 |
| lkcl | is it obvious - at all - what that line does? | 15:42 |
| lkcl | from nmigen.build import * | 15:42 |
| lkcl | do you know what is in nmigen.build? | 15:42 |
| lkcl | because i don't | 15:42 |
| lkcl | let's go and hunt for it and find out what's in it, eh? | 15:42 |
| lkcl | ah ohhh lookeee | 15:43 |
| lkcl | https://git.libre-soc.org/?p=nmigen.git;a=blob;f=nmigen/build/__init__.py;h=c4bc9f3dbc18a080b6e5ce2b51c6fe79aaeaf054;hb=e88d283ed30448ed5fe3ba264e3e56b48f2a4982 | 15:43 |
| lkcl | it's yet another f****g time-wasting set of f*****g wildcard imports | 15:43 |
| lkcl | where 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 |
| lkcl | https://git.libre-soc.org/?p=nmigen.git;a=blob;f=nmigen/build/dsl.py;hb=HEAD | 15:44 |
| lkcl | oh look. fiiiinally, after several minutes, we've been able, through a LOT of pissing about, to *deduce* that interface.py must be using nmigen.build.dsl Pins, Resource and Subsignal | 15:45 |
| octavius | Yeah, I agree with you there. After joining libre-soc I started to question the sanity of anyone using wildcards | 15:45 |
| lkcl | i have spoken to nmigen developers about it: they disregarded my advice and how difficult it makes things. | 15:46 |
| lkcl | i have spoken to the lambdasoc developers: they disregarded my input | 15:46 |
| lkcl | i have spoken to the litex developers: they disregarded my input | 15:47 |
| octavius | I guess the idea is too deeply ingrained? | 15:47 |
| lkcl | every 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 |
| lkcl | it's fine.... *for them*... because they work with the codebase that *they* develop, every single day. | 15:48 |
| lkcl | therefore, they know the entire codebase | 15:48 |
| octavius | And no one is expected to touch it | 15:48 |
| octavius | ? | 15:48 |
| lkcl | "so why the hell don't you" | 15:48 |
| lkcl | it's a matter of a complete lack of empathy | 15:48 |
| lkcl | as *hardware* engineers they've simply not been trained in Software Engineering maintenance techniques | 15:49 |
| lkcl | which are ingrained into Libre/OpenSource developers/maintainers through either training, or a series of painful experiences | 15:49 |
| lkcl | unfortunately, the user-base isn't large enough - yet - to have crossed the "threshold of pain" | 15:50 |
| lkcl | so, unfortunately, we have to put up with their mess. | 15:50 |
| lkcl | sigh | 15:50 |
| octavius | Anyway, let's get away from this depressing tangent for now. I'm guessing you don't know what Resource() is (or where)? | 15:51 |
| lkcl | :) | 16:07 |
| lkcl | i do... it's from nmigen.build.dsl | 16:07 |
| lkcl | "<lkcl> oh look. fiiiinally, after several minutes, we've been able, through a LOT of pissing about, to *deduce* that interface.py must be using nmigen.build.dsl Pins, Resource and Subsignal" | 16:07 |
| lkcl | https://git.libre-soc.org/?p=nmigen.git;a=blob;f=nmigen/build/dsl.py;hb=HEAD#l179 | 16:08 |
| lkcl | line 179. class Resource | 16:08 |
| lkcl | basically you can do exactly the same as this | 16:08 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/config/pinouts.py;h=95129b1999e733b44c5f46c265d9b1c478c4a8f4;hb=e3e78916215f947cf229f884df11bef7435f7d58#l7 | 16:08 |
| lkcl | line 7 | 16:08 |
| octavius | Ah ok | 16:09 |
| lkcl | basically, in small steps, i'm introducing you to the concept of abstraction | 16:09 |
| lkcl | if this were databases, i would use the term "4th normalise form" | 16:09 |
| lkcl | so 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 easily | 16:11 |
| octavius | let's hope so XD | 16:11 |
| lkcl | :) | 16:12 |
| octavius | Your example of UARTResource has the name "uart" as the first arg, followed by instance number and the then tx/rx pins | 16:13 |
| octavius | the nmigen boards uses (*args, rx, tx,....) | 16:14 |
| octavius | What 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 |
| lkcl | https://realpython.com/python-kwargs-and-args/ | 16:16 |
| lkcl | it's a very useful - but computationally expensive - trick which allows you to write versatile code | 16:17 |
| lkcl | like, Cat(*args) | 16:17 |
| lkcl | you can then pass in Cat(sig1, sig2, sig3,...... sig1099837) | 16:18 |
| octavius | ok | 16:18 |
| lkcl | and they will all end up as a tuple in: the-one-single-variable-known-by-the-name, "args" | 16:18 |
| lkcl | kwargs is things like fred(keyword1="hello", keyword2="bye") | 16:19 |
| octavius | bso kwarg is basically a dictionary? | 16:19 |
| lkcl | and if fred is "def fred(**kwargs): print(kwargs)" | 16:19 |
| lkcl | you get the output of: | 16:19 |
| lkcl | {"keyword1": "hello", "keyword2": "bye"} | 16:19 |
| lkcl | yes. | 16:19 |
| lkcl | the conversion to tuple (and dict) is what makes it very expensive | 16:19 |
| lkcl | CPU-wise | 16:19 |
| lkcl | but, this (nmigen) is a compiler: we don't care [at least, not that much] | 16:20 |
| octavius | So what's the difference **kwargs and a dict argument? | 16:20 |
| lkcl | def fred(kwargs) basically | 16:20 |
| lkcl | you *have* to construct the arguments as a dictionary. | 16:20 |
| lkcl | you *cannot* call fred(kw1="hello", kw2="goodbye") | 16:21 |
| lkcl | you *HAVE* to call it as: | 16:21 |
| octavius | Ah, the ** unpacking operator converts a variable number of args into one dictionary? | 16:21 |
| lkcl | fred({"kw1"....}) | 16:21 |
| lkcl | yes | 16:21 |
| octavius | ok | 16:21 |
| lkcl | which is an (expensive) weirdness | 16:21 |
| lkcl | it's a variant of c varargs, basically | 16:21 |
| octavius | ok | 16:22 |
| lkcl | *args ==> c varargs | 16:22 |
| lkcl | **kwargs ==> c++ sort-of-named-version-of-varargs | 16:22 |
| lkcl | so is tied very closely to the internals of the python interpreter, obviously. | 16:22 |
| octavius | So with definition: | 16:24 |
| octavius | UARTResource(*args, rx, tx, conn=None, attrs=None, role=None) | 16:24 |
| octavius | And instance: | 16:24 |
| octavius | UARTResource("uart", 0, tx=..., rx=..) | 16:24 |
| octavius | The "uart", 0 will be part of *args, and thus converted to a tuple? | 16:24 |
| lkcl | notice how it's passed on to Resource.family()? | 16:25 |
| lkcl | UARTResource(*args) | 16:26 |
| lkcl | ..> | 16:26 |
| lkcl | Resource.family(*args, ...) | 16:26 |
| octavius | Ah | 16:26 |
| lkcl | so yeeees, it could be eeeither "uart" | 16:26 |
| lkcl | or 0/1/2/3 | 16:26 |
| lkcl | or "uart", 0/1/2/3 | 16:26 |
| lkcl | and you, as the *developer* of that function, UARTResource, have declared: | 16:27 |
| octavius | But it won't matter until Resource.family resolves it | 16:27 |
| lkcl | "whatever the hell Resource.family() does, we just blindly pass arguments through" | 16:27 |
| octavius | hahaha | 16:27 |
| lkcl | thus | 16:27 |
| lkcl | providing UARTResource with the *exact* same API as... Resource.family() | 16:27 |
| lkcl | ta-daaa | 16:27 |
| lkcl | but, in this case, you do actually need to know :) | 16:27 |
| lkcl | because you won't be using UARTResource in this way | 16:28 |
| lkcl | you'll be bypassing it | 16:28 |
| lkcl | and creating the call to Resource.family() directly | 16:28 |
| lkcl | so it should not be | 16:28 |
| lkcl | return Resource.family(*args) | 16:28 |
| lkcl | because there won't be an args tuple | 16:28 |
| octavius | Ah, I'm just using this abstraction as an aid then? | 16:29 |
| lkcl | only a name ("uart") and _maybe_ a number | 16:29 |
| lkcl | yes, you're using UARTResource as an aide to understanding of Resource.family() | 16:29 |
| lkcl | btw you should at this point have at least 6 xterms open on-screen and left permanently open | 16:29 |
| lkcl | each with a file in it | 16:30 |
| lkcl | that 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 function | 16:30 |
| octavius | And should I be working in a schroot with all the soc files available? | 16:31 |
| lkcl | i'm not | 17:23 |
| lkcl | but then i haven't updated my laptop since debian/testing was roughly-equal-to debian/10 | 17:23 |
| lkcl | (and can't!) | 17:23 |
| lkcl | i'm actually now setting up chroots for some standard programs instead! | 17:24 |
| lkcl | take that not as an explicit answer, but as a learning experience to make up your own mind :) | 17:26 |
| octavius | Hahaha, thanks! | 17:39 |
| octavius | lkcl, thanks for adding the nmigen block. I'll play with it in a little bit | 19:04 |
| lkcl | it was much more of a pain in the ass than i was expecting, but slowly, by examining LatticePlatform and others, the pieces can be extracted | 19:40 |
| lkcl | first thing, to get a sync domain, i notice in Platform.create_missing_domain() that default_clk and default_rst have to exist | 19:40 |
| lkcl | these should | 19:41 |
| lkcl | really be picked up from resource "sys" (from the pinmux spec file) | 19:41 |
| lkcl | but for now let's just hardcode them to "clk" and "rst" just like in verilog | 19:41 |
| lkcl | h | 19:42 |
| lkcl | hmmm | 19:42 |
| lkcl | a resource named "clk" is expected to exist, sigh | 19:43 |
| lkcl | done, works great | 19:46 |
| octavius | lkcl, 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 |
| octavius | Ok, used wrong nmigen version | 22:36 |
| octavius | Thanks 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 jtag.py (I can at least somewhat grasp what we need to do XD) | 22:40 |
| lkcl | done already, that bit | 22:56 |
| lkcl | (git pull) | 22:56 |
| octavius | So the latest version runs with no issues for me | 22:56 |
| lkcl | done for the night. you can take over tomorrow morning if you're about | 22:56 |
| lkcl | great | 22:57 |
| lkcl | it got complicated, i'll make some notes | 22:57 |
| octavius | It certainly did :) | 22:57 |
| octavius | Sure, I'll catch with you later, although I'll try to take a break for most of tomorrow. | 22:58 |
| octavius | gn | 22:58 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!