Wednesday, 2021-11-10

sadoon_albader[mfwiw I was hearing you fine till we left heh00:02
* cesar is looking at the Yosys output of logic generated by the Pipeline API.10:40
cesar... before, and after synthesis.10:41
* cesar is hoping Yosys will manage to simplify the FIFOs.10:46
cesarIt boils down to one register for data, and one for valid/ready, maybe a mux.10:46
cesarIf not registering the output of the stage, no additional logic should be needed, just wiring i_valid to o_valid, and i_ready to o_ready...10:49
lkclyes, basically11:16
lkclcesar, there are actually a number of different pipeline "mixins". some have single-entry buffers (allowing one clock cycle of previous stages to at least continue), some cause stalling to ripple immediately (combinatorially) through the whole chain11:29
lkclthere's even a full-on FIFO one which can be set to an arbitrary number of entries, and can even do combinatorial bypass (get at the first entry on the exact same clock cycle as it's being put in)11:30
cesarThis one, with an one entry FIFO and the combinatorial bypass, should be equivalent to the "skid buffer" of ZipCPU, I think.11:36
cesarThe one with a multi-entry FIFO should be useful where the producer and consumer are bursty, where bursts of o_valid and i_ready do not overlap in time.11:39
cesar(a Queue, basically)11:40
lkclyes, and a Queue is exactly what it is based on, from a port of chisel.util.Queue, then some variable-name aliases added to make it comply with the nmigen FIFOInterface API11:42
lkclwhich is kinda cool11:42
lkcland, also, means that if ever we need a pipeline that crosses over two domains, ASyncFifo could be used11:42
lkclwhich is pretty hilarious11:42
lkclthe default one used at the moment, in order not to have double the number of register latches, is SimpleHandshake.11:43
lkclthat basically connects up... what is it... n_i_ready to p.o_valid i think... combinatorially11:45
lkclwhich effectively makes the entire chain right throughout all pipeline stages a single "stall" condition11:45
lkclwhich is fine11:45
lkclcesar, ok so the rules - which took a hell of a long time to work out - are:15:03
lkcl* you must raise p.o_ready when you can accept input on the NEXT cycle.15:03
lkcl* when p.i_valid is valid, you MUST capture the incoming data, on that cycle15:04
lkcl* you must only set n.o_valid when your outgoing data is valid BUT15:04
lkcl* you can only consider it safe to have been send if, when you set n.o_valid, the n.i_ready was also set HI15:05
lkcln.o_valid must only be set for one cycle for each data, when n_i_ready is also HI at the time it is sent15:06
lkclso you _can_ leave n.o_valid HI indefinitely, AS LONG AS n.i_ready is LO15:07
lkclit's basically wishbone protocol, back-to-back one master with one slave15:08
lkclin pipeline mode15:08
octaviusIn parallel with pinmux, I've been looking at Robert's 6800 nmigen tutorial series, first time I learned the Python has a type checker library bodged in XD
lkclyes. sounded great in theory, esp. when python2 was slower and cython had to be created which of course requires static type information in order to compile to a fast implementation15:38
octaviusIs it actually a bad idea then?15:38
lkclwhen deployed in anger as a system-wide ubiquitous requirement it is just a f*****g nuisance15:39
lkclinterferes, prevents, and prohibits, the use of Liskov Substitution Principle15:39
lkclincreases line length15:39
lkclincreases number of lines of code15:39
lkclreduces readability15:39
lkclreduces clarity15:39
lkclwastes time of readers15:40
lkclhinders readers15:40
lkclincreases the size of a function declaration to a degree that massively reduces clarity, often to the point of pushing the function off of a single page15:41
lkclcausing the reader to have to page-down, page-up, page-down, page-up15:41
programmerjakei find that type annotations increase clarity15:41
programmerjakeso ymmv15:41
lkclthere do exist cases where it is useful: Staf Verhaegen uses it to good effect in FlexLib.15:42
lkclbut he does not have functions with 10+ arguments15:42
octaviusIt seems to me like someone was missing strict typing, and instead of using a different lang, added it to python15:42
lkclwhich is where types *really* get in the way15:42
lkclbasically... yes15:43
octaviusAh ok, small num of args makes sense15:43
lkclwhere the whole f*****g point of python is precisely that you *do not* require types in order for the code to be executable15:43
lkclyeah.  if you have between one and three arguments, it might fit (just) onto a single line "def fn(x: int, y: str, z: some_data_struct):"15:44
lkcltypes are inferred, and bloody obvious, at the point at which a local variable is created.15:45
lkcldeclaring that type wastes the reader's time and interferes with LSP in later adaptation of the code, where the type has to be either removed15:45
lkclsome completely f*****g useless "base class" created15:46
programmerjakewell, imho having type annotations precisely tells you, the reader, what the code's author expected you to pass in, usually doc strings are incomplete or not specific enough to tell you what types the function was designed to work with15:46
lkclwhose sole exclusive purpose and existence is to waste programmer time writing it15:46
programmerjakewell, that's what the Union type is for...15:46
lkclprogrammerjake, that is a direct violation of Liskov Substitution Principle.15:46
lkclwhich is another waste of time, even having to waste time thinking "err frick, this *might* be used LSP later, errr frick, i have to create a Union"15:47
programmerjakeno, it's not, having type annotations doesn't prevent you from passing something similar to a function15:47
lkcl"oh s*** i forgot to add a type, my code doesn't work, it bombs out"15:47
lkclpython != c, python != c++, python != NEOther_strongly_typed_language15:48
programmerjakeyou realize that the type annotations are *unchecked* by design, right?15:48
lkcl"what types the function was designed to work with" - the whole point *is* not to declare them *at all*.15:49
lkcland thus are an even bigger waste of time15:49
lkclthe entire point of python is that you *do not* restrict (or even bother to declare, in any way) what the types are.15:49
lkclthis allows LSP to be deployed (later), and saves time15:49
lkcleverything about python is to get the most compact high-efficiency bang-per-buck15:50
lkcl(the least number of lines of code to do a job)15:50
lkcltypes *fundamentally* violate that principle15:50
programmerjakewell, the whole point of type annotations are so you don't have to read the full source code of functions in order to know how to call them. that massively saves time15:50
lkclwasting characters to declare information that is fundamentally useless15:51
lkclif that function is more compact and smaller, *precisely because* there is less of it, that is not a burden15:51
lkclwhere "there is less of it" precisely because the function and its declaration fit into less screen-space, and do not require the reader to waste time page-up-page-down-page-up-page-down15:52
octaviusPerhaps the argument for Python jake, is that with compact syntax, you *will* be able to read a lot of source code, thus not needing to duplicate redundant summary information?15:53
programmerjakeyou want to read all 10k lines of some library multiple times (cuz just once isn't enough to figure it all out) just to know how to call a function!? sounds like a total time sink to me15:53
lkclthe invasion of types approximately triples and in some cases quadruples the code size15:53
lkcli open up the functions needed on-demand in a second (or third, or fourth) window.15:53
lkclwhich is why the rule exists to respect an 80 char limit15:54
lkclso that i (personally) can get 12 xterms on a screen15:54
programmerjakei found that it increases code size by about 5%, but increases understandability by a factor of >2 imho15:54
lkcland for people in other countries with less resources, they can get 3-4 terminals on-screen side-by-side15:54
programmerjakeimho, if your function needs 10 arguments, your doing something wrong15:55
lkcli was exaggerating, but you get the general idea15:55
kylelFolks like to morph their language of choice into something it isn't15:57
programmerjakeyeah, i get your point, but reject it as impractical cuz no one but the original author has the time to read and thoroughly understand every line of code in a project just to know how to call some top-level function15:57
lkcli don't have a problem with navigating large (unknown) code-bases that are entirely devoid of types15:58
lkcli use ctags, work from the top-level of the directory (ctags -R), then press ctrl-] on the function / keyword15:58
lkclif there are multiple matches, :tn navigates through them.15:58
lkclif i really have to, i actually print out the entire codebase on paper: enscript -O can be made to fit 3 columns in small enough fonts15:59
lkcland then literally sit there going through the entire lot, in a couple of hours15:59
lkclthen having done that, i have a general / vague idea of everything, and "hmm i vaguely remember seeing that before" is enough to get me to track it down16:00
programmerjakethe way I see it, python type annotations are a form of structured docs, describing what the functions were written to expect the inputs to behave like. basically, that info should always be there, just that it's put somewhere other than the doc string cuz that allows tools to read/understand it16:00
programmerjakei use vscode which allows you to see the type information by hovering over any identifier16:02
lkclindeed.  this is lack of experience in reading python.  it is natural for a python programmer to _infer_ the type, and to read surrounding context as to what an instance does, based on its name, its instantiation, and the functions it uses.16:03
programmerjakeone key to go to the exact definition(s), resolved according to python's semantics16:03
lkclthis is achievable with ctags as well.16:03
lkclctags has understood python source for 20 years16:04
programmerjakewell, just reading the surrounding context doesn't necessarily give you the correct answer, that's what knowing the expected type is for.16:08
programmerjakealso, many names used in libre-soc are too short to know what they mean without extensive experience...names are supposed to tell the reader what your doing, not confuse them16:10
lkclultimately, though, and i am a bit embarrassed about this: it's my responsibility to read everything, and understand everything, as the lead project architect16:11
lkcland if there's stuff that irritates the crap out of me and makes it difficult for me to read the code, then that, well, basically, has to take precedence16:11
programmerjakewell, imho that's not sustainable...eventually we will have enough code that it's impossible for any one person to keep fully in their head16:12
lkclif there was someone else fulfilling the role, who loved types, it would be a different matter16:12
programmerjakeyeah, i recognize that, hence why I'm ok with removing type annotations16:13
lkcli'm quite happy up to about a million lines.  beyond that... mmm...16:13
lkclwe're about 15-20% the way towards that16:14
programmerjakethe other part is that people who want to contribute also have to become familiar with the api, which is often very poorly documented...type annotations in key places would go a long way16:15
tplatenInserting a comb += Display("MMUTEST: pi.msr_pr=%i",oper_r.msr[MSR.PR]) confirmed that this signals is always 0 in my testcase18:18
lkcltplaten, can you commit that18:19
lkcli am just adding MSR to fu/ldst/pipe_data.py18:19
tplatennow I pushed18:20
lkclalways helps :)18:23
lkclok it's working18:23
lkclMMUTEST: initial_msr= 1638418:23
lkcltplaten, git pull18:24
lkclindex c2d8a43c..fc0546a9 10064418:24
lkcl--- a/src/soc/fu/ldst/pipe_data.py18:24
lkcl+++ b/src/soc/fu/ldst/pipe_data.py18:24
lkcl+               ('STATE', 'msr', '0:63'),  # MSR18:24
lkclthat was easy :)18:24
lkclremember, whitespace.18:26
lkcli changed MMUTEST: to LDSTCompUnit: (because it's in LDSTCompUnit that the Display is used)18:27
lkclnuts.  i need to patch in $Display18:28
tplatenpi.msr_pr=0 is still after a git pull in soc18:31
lkclyes just managed to get the $Display working...18:36
* lkcl checking18:36
lkcladded a printout of oper_r.msr to the $Display18:37
lkcltck, tck, tck...18:38
lkclmsr needs adding to the gtkw18:40
lkclerrrm... ermermerm... not sure if it's being set at all18:46
lkclMSR is zero going into the HDL18:46
lkclnope.  being totally ignored in test_runner.py18:47
lkcllet's try...18:50
lkcl+++ b/src/soc/simple/test/test_runner.py18:50
lkcl@@ -176,6 +176,7 @@ class HDLRunner(StateRunner):18:50
lkcl         yield from setup_regs(pdecode2, core, self.test)18:50
lkcl+        yield core.state.msr.eq(self.test.msr)18:50
lkclmmm that buggered things up completely :)18:51
* lkcl trying printing out to see the initial value18:52
lkclthat'll be because of a syntax err doh18:53
lkcltplaten, almost there18:53
tplatenI had produced a syntax error today too, It took me about 5 minutes to find out.18:55
lkclok that's interesting, initial_msr is not properly reset to zero after each simulation run18:55
lkclbut hey18:55
lkclohh hang on, the MSR has to go into the STATE regfile. doh18:56
lkclnearly there18:58
lkcleyy!  core.msr is now 0x400019:01
lkclok so that's est19:01
lkclnow to see where else it gets to19:02
lkclit shouuuld get copied over... to....19:03
lkclyes! it's copied over into oper_r.msr19:03
lkclah! yes!  it's there19:04
lkcltplaten, git pull19:04
lkclalso on openpower-isa19:06
lkclso you get the two new gtkw debug pieces19:06
lkclokaay top.issuer.core.ldst_req_virt_mode is getting set to 119:21
lkclas is top.issure.core.ldst_r_virt_mode19:21
tplatenI've done a git pull19:40
tplatenconfirmed I see a LDSTCompUnit: oper_r.msr 4000 pi.msr_pr=119:41
lkclam just adding some initial data into reg 1019:41
lkcl+++ b/src/soc/simple/test/test_issuer_mmu.py19:42
lkcl@@ -107,6 +107,7 @@ class MMUTestCase(TestAccumulatorBase):19:42
lkcl         initial_regs[2] = 0x345619:42
lkcl         initial_regs[3] = 0x432119:42
lkcl         initial_regs[4] = 0x654319:42
lkcl+        initial_regs[10] = 0xfe19:42
lkclotherwise it's storing a zero19:42
lkclok! store_data is now 0xfe19:42
lkclbloody 'ellfire that actually went through to the dcache wishbone bus!19:44
lkcladdr 0x68a, wb_in_data  0x00fe0000000019:44
lkcltplaten, it's "making some noises" that look about right. amazingly19:55
lkclnot completely working though, but hey19:55
tplatenI'll continue tomorrow20:04
*** tplaten <tplaten!> has left #libre-soc20:04
octaviuslkcl, is there an OpenPOWER call today?21:03
lkcloctavius, no, it's bi-weekly21:03
octaviusAh ok21:03

Generated by 2.17.1 by Marius Gedminas - find it at!