| sadoon_albader[m | fwiw I was hearing you fine till we left heh | 00: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 | |
| cesar | It boils down to one register for data, and one for valid/ready, maybe a mux. | 10:46 |
| cesar | (should) | 10:47 |
| cesar | If 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 |
| lkcl | yes, basically | 11:16 |
| lkcl | cesar, 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 chain | 11:29 |
| lkcl | there'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 |
| cesar | This one, with an one entry FIFO and the combinatorial bypass, should be equivalent to the "skid buffer" of ZipCPU, I think. | 11:36 |
| cesar | The 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 |
| lkcl | yes, 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 API | 11:42 |
| lkcl | which is kinda cool | 11:42 |
| lkcl | and, also, means that if ever we need a pipeline that crosses over two domains, ASyncFifo could be used | 11:42 |
| lkcl | which is pretty hilarious | 11:42 |
| lkcl | the default one used at the moment, in order not to have double the number of register latches, is SimpleHandshake. | 11:43 |
| lkcl | that basically connects up... what is it... n_i_ready to p.o_valid i think... combinatorially | 11:45 |
| lkcl | which effectively makes the entire chain right throughout all pipeline stages a single "stall" condition | 11:45 |
| lkcl | which is fine | 11:45 |
| lkcl | cesar, 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 cycle | 15:04 |
| lkcl | * you must only set n.o_valid when your outgoing data is valid BUT | 15: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 HI | 15:05 |
| lkcl | n.o_valid must only be set for one cycle for each data, when n_i_ready is also HI at the time it is sent | 15:06 |
| lkcl | so you _can_ leave n.o_valid HI indefinitely, AS LONG AS n.i_ready is LO | 15:07 |
| lkcl | it's basically wishbone protocol, back-to-back one master with one slave | 15:08 |
| lkcl | in pipeline mode | 15:08 |
| octavius | In 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 https://docs.python.org/3.7/library/typing.html?highlight=type%20annotation | 15:37 |
| lkcl | yes. 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 implementation | 15:38 |
| octavius | Is it actually a bad idea then? | 15:38 |
| lkcl | when deployed in anger as a system-wide ubiquitous requirement it is just a f*****g nuisance | 15:39 |
| lkcl | interferes, prevents, and prohibits, the use of Liskov Substitution Principle | 15:39 |
| lkcl | increases line length | 15:39 |
| lkcl | increases number of lines of code | 15:39 |
| lkcl | reduces readability | 15:39 |
| lkcl | reduces clarity | 15:39 |
| lkcl | wastes time of readers | 15:40 |
| lkcl | hinders readers | 15:40 |
| lkcl | increases 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 page | 15:41 |
| lkcl | causing the reader to have to page-down, page-up, page-down, page-up | 15:41 |
| programmerjake | i find that type annotations increase clarity | 15:41 |
| programmerjake | so ymmv | 15:41 |
| lkcl | there do exist cases where it is useful: Staf Verhaegen uses it to good effect in FlexLib. | 15:42 |
| lkcl | but he does not have functions with 10+ arguments | 15:42 |
| octavius | It seems to me like someone was missing strict typing, and instead of using a different lang, added it to python | 15:42 |
| lkcl | which is where types *really* get in the way | 15:42 |
| lkcl | basically... yes | 15:43 |
| octavius | Ah ok, small num of args makes sense | 15:43 |
| lkcl | where the whole f*****g point of python is precisely that you *do not* require types in order for the code to be executable | 15:43 |
| lkcl | yeah. 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 |
| octavius | yeah | 15:44 |
| lkcl | types are inferred, and bloody obvious, at the point at which a local variable is created. | 15:45 |
| lkcl | declaring that type wastes the reader's time and interferes with LSP in later adaptation of the code, where the type has to be either removed | 15:45 |
| lkcl | or | 15:45 |
| lkcl | worse | 15:45 |
| lkcl | some completely f*****g useless "base class" created | 15:46 |
| programmerjake | well, 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 with | 15:46 |
| lkcl | whose sole exclusive purpose and existence is to waste programmer time writing it | 15:46 |
| programmerjake | well, that's what the Union type is for... | 15:46 |
| lkcl | programmerjake, that is a direct violation of Liskov Substitution Principle. | 15:46 |
| lkcl | which 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 |
| programmerjake | no, it's not, having type annotations doesn't prevent you from passing something similar to a function | 15:47 |
| lkcl | "oh s*** i forgot to add a type, my code doesn't work, it bombs out" | 15:47 |
| lkcl | utter | 15:47 |
| lkcl | complete | 15:47 |
| lkcl | waste | 15:47 |
| lkcl | of | 15:47 |
| lkcl | time | 15:47 |
| lkcl | python != c, python != c++, python != NEOther_strongly_typed_language | 15:48 |
| programmerjake | you 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 |
| lkcl | and thus are an even bigger waste of time | 15:49 |
| lkcl | the entire point of python is that you *do not* restrict (or even bother to declare, in any way) what the types are. | 15:49 |
| lkcl | this allows LSP to be deployed (later), and saves time | 15:49 |
| lkcl | everything about python is to get the most compact high-efficiency bang-per-buck | 15:50 |
| lkcl | (the least number of lines of code to do a job) | 15:50 |
| lkcl | types *fundamentally* violate that principle | 15:50 |
| programmerjake | well, 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 time | 15:50 |
| lkcl | wasting characters to declare information that is fundamentally useless | 15:51 |
| lkcl | if that function is more compact and smaller, *precisely because* there is less of it, that is not a burden | 15:51 |
| lkcl | where "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-down | 15:52 |
| lkcl | yeh? | 15:52 |
| octavius | Perhaps 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 |
| programmerjake | you 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 me | 15:53 |
| lkcl | the invasion of types approximately triples and in some cases quadruples the code size | 15:53 |
| lkcl | i open up the functions needed on-demand in a second (or third, or fourth) window. | 15:53 |
| lkcl | which is why the rule exists to respect an 80 char limit | 15:54 |
| lkcl | so that i (personally) can get 12 xterms on a screen | 15:54 |
| programmerjake | i found that it increases code size by about 5%, but increases understandability by a factor of >2 imho | 15:54 |
| lkcl | and for people in other countries with less resources, they can get 3-4 terminals on-screen side-by-side | 15:54 |
| programmerjake | imho, if your function needs 10 arguments, your doing something wrong | 15:55 |
| lkcl | i was exaggerating, but you get the general idea | 15:55 |
| kylel | Folks like to morph their language of choice into something it isn't | 15:57 |
| programmerjake | yeah, 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 function | 15:57 |
| lkcl | i don't have a problem with navigating large (unknown) code-bases that are entirely devoid of types | 15:58 |
| lkcl | i use ctags, work from the top-level of the directory (ctags -R), then press ctrl-] on the function / keyword | 15:58 |
| lkcl | if there are multiple matches, :tn navigates through them. | 15:58 |
| lkcl | if 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 fonts | 15:59 |
| lkcl | and then literally sit there going through the entire lot, in a couple of hours | 15:59 |
| lkcl | then 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 down | 16:00 |
| programmerjake | the 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 it | 16:00 |
| programmerjake | i use vscode which allows you to see the type information by hovering over any identifier | 16:02 |
| lkcl | indeed. 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 |
| programmerjake | one key to go to the exact definition(s), resolved according to python's semantics | 16:03 |
| lkcl | this is achievable with ctags as well. | 16:03 |
| lkcl | ctrl-] | 16:03 |
| lkcl | ctags has understood python source for 20 years | 16:04 |
| programmerjake | well, just reading the surrounding context doesn't necessarily give you the correct answer, that's what knowing the expected type is for. | 16:08 |
| programmerjake | also, 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 them | 16:10 |
| lkcl | ultimately, though, and i am a bit embarrassed about this: it's my responsibility to read everything, and understand everything, as the lead project architect | 16:11 |
| lkcl | and 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 precedence | 16:11 |
| programmerjake | well, imho that's not sustainable...eventually we will have enough code that it's impossible for any one person to keep fully in their head | 16:12 |
| lkcl | if there was someone else fulfilling the role, who loved types, it would be a different matter | 16:12 |
| programmerjake | yeah, i recognize that, hence why I'm ok with removing type annotations | 16:13 |
| lkcl | i'm quite happy up to about a million lines. beyond that... mmm... | 16:13 |
| lkcl | we're about 15-20% the way towards that | 16:14 |
| programmerjake | the 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 way | 16:15 |
| tplaten | Inserting a comb += Display("MMUTEST: pi.msr_pr=%i",oper_r.msr[MSR.PR]) confirmed that this signals is always 0 in my testcase | 18:18 |
| lkcl | tplaten, can you commit that | 18:19 |
| lkcl | i am just adding MSR to fu/ldst/pipe_data.py | 18:19 |
| tplaten | done | 18:20 |
| lkcl | star | 18:20 |
| tplaten | now I pushed | 18:20 |
| lkcl | always helps :) | 18:23 |
| lkcl | ok it's working | 18:23 |
| lkcl | MMUTEST: initial_msr= 16384 | 18:23 |
| lkcl | tplaten, git pull | 18:24 |
| lkcl | index c2d8a43c..fc0546a9 100644 | 18:24 |
| lkcl | --- a/src/soc/fu/ldst/pipe_data.py | 18:24 |
| lkcl | +++ b/src/soc/fu/ldst/pipe_data.py | 18:24 |
| lkcl | + ('STATE', 'msr', '0:63'), # MSR | 18:24 |
| lkcl | that was easy :) | 18:24 |
| lkcl | remember, whitespace. | 18:26 |
| lkcl | i changed MMUTEST: to LDSTCompUnit: (because it's in LDSTCompUnit that the Display is used) | 18:27 |
| lkcl | nuts. i need to patch in $Display | 18:28 |
| tplaten | pi.msr_pr=0 is still after a git pull in soc | 18:31 |
| lkcl | yes just managed to get the $Display working... | 18:36 |
| * lkcl checking | 18:36 | |
| lkcl | added a printout of oper_r.msr to the $Display | 18:37 |
| lkcl | tck, tck, tck... | 18:38 |
| lkcl | msr needs adding to the gtkw | 18:40 |
| lkcl | errrm... ermermerm... not sure if it's being set at all | 18:46 |
| lkcl | MSR is zero going into the HDL | 18:46 |
| lkcl | nope. being totally ignored in test_runner.py | 18:47 |
| lkcl | let's try... | 18:50 |
| lkcl | +++ b/src/soc/simple/test/test_runner.py | 18: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 |
| lkcl | mmm that buggered things up completely :) | 18:51 |
| * lkcl trying printing out to see the initial value | 18:52 | |
| lkcl | that'll be because of a syntax err doh | 18:53 |
| lkcl | tplaten, almost there | 18:53 |
| tplaten | I had produced a syntax error today too, It took me about 5 minutes to find out. | 18:55 |
| lkcl | ok that's interesting, initial_msr is not properly reset to zero after each simulation run | 18:55 |
| lkcl | but hey | 18:55 |
| lkcl | ohh hang on, the MSR has to go into the STATE regfile. doh | 18:56 |
| lkcl | nearly there | 18:58 |
| lkcl | eyy! core.msr is now 0x4000 | 19:01 |
| lkcl | ok so that's est | 19:01 |
| lkcl | set | 19:01 |
| lkcl | now to see where else it gets to | 19:02 |
| lkcl | it shouuuld get copied over... to.... | 19:03 |
| lkcl | yes! it's copied over into oper_r.msr | 19:03 |
| lkcl | ah! yes! it's there | 19:04 |
| lkcl | tplaten, git pull | 19:04 |
| lkcl | also on openpower-isa | 19:06 |
| lkcl | so you get the two new gtkw debug pieces | 19:06 |
| lkcl | okaay top.issuer.core.ldst_req_virt_mode is getting set to 1 | 19:21 |
| lkcl | as is top.issure.core.ldst_r_virt_mode | 19:21 |
| tplaten | I've done a git pull | 19:40 |
| tplaten | confirmed I see a LDSTCompUnit: oper_r.msr 4000 pi.msr_pr=1 | 19:41 |
| lkcl | am just adding some initial data into reg 10 | 19:41 |
| lkcl | +++ b/src/soc/simple/test/test_issuer_mmu.py | 19:42 |
| lkcl | @@ -107,6 +107,7 @@ class MMUTestCase(TestAccumulatorBase): | 19:42 |
| lkcl | initial_regs[2] = 0x3456 | 19:42 |
| lkcl | initial_regs[3] = 0x4321 | 19:42 |
| lkcl | initial_regs[4] = 0x6543 | 19:42 |
| lkcl | + initial_regs[10] = 0xfe | 19:42 |
| lkcl | otherwise it's storing a zero | 19:42 |
| lkcl | ok! store_data is now 0xfe | 19:42 |
| lkcl | bloody 'ellfire that actually went through to the dcache wishbone bus! | 19:44 |
| lkcl | addr 0x68a, wb_in_data 0x00fe00000000 | 19:44 |
| lkcl | tplaten, it's "making some noises" that look about right. amazingly | 19:55 |
| lkcl | not completely working though, but hey | 19:55 |
| tplaten | I'll continue tomorrow | 20:04 |
| *** tplaten <tplaten!~isengaara@55d4d890.access.ecotel.net> has left #libre-soc | 20:04 | |
| octavius | lkcl, is there an OpenPOWER call today? | 21:03 |
| lkcl | octavius, no, it's bi-weekly | 21:03 |
| octavius | Ah ok | 21:03 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!