* cesar has to read up on the Pipeline API, it's been a while... | 11:48 | |
* cesar is half-seriously considering additional extensions to the nMigen language: | 12:49 | |
cesar | 1) PipelineSignal: m.d.sync += S.eq(A+B). Every signal has valid/ready, automatically connected. S.valid is true when both A.valid and B.valid is true. | 12:51 |
---|---|---|
cesar | 2. WishboneSignal: m.d.sync += buf.eq(Uart.in). A Wishbone bus read will be performed on Uart.in address and the result deposited in buf. | 12:53 |
cesar | m.d.sync += [B.eq(A), C.eq(B), D.eq(C)], where A,B,C,D are PipelineSignal, would build a buffered pipeline A->B->C->D. | 12:57 |
cesar | .. or m.d.sync += [icache.addr.eq(pc), decode.opcode.eq(icache.data), regfile.ra.addr.eq(decode.instr.ra), regfile.rb.addr.eq(decode.instr.rb), execute.instr.eq(decode.instr), execute.ra.eq(regfile.ra.data), execute.rb.eq(regfile.rb.data), regfile.rt.addr.eq(decode.instr.rt), regfile.rt.data.eq(execute.rt), pc.eq(execute.next_pc)] | 13:28 |
cesar | (where every signal/port is PipelineSignal) | 13:29 |
*** Awoobis is now known as A_Dragon | 13:47 | |
cesar | (just an idea, nothing serious) | 14:57 |
lkcl | actually, you know the best place to do that? | 15:16 |
lkcl | via the new AST abstraction i just added. | 15:16 |
lkcl | cesar, there are a ton of examples on the pipeline API :) the actual functions needed are only 2: ispec and ospec, which create the data structure in and data structure out, respectively | 15:19 |
lkcl | the only reason things are slightly more complicated for the ALUs is because, *on top* of that ridiculously simple API, i then added "regspecs" which *auto-generated* the ispec and ospec based on a separated data structure. | 15:20 |
lkcl | cesar, the completion of Type 1 (AST) and Type 2 (dsl.Module) abstraction that i did about 6 weeks ago means that you *don't have to modify or extend the nmigen language* | 16:32 |
lkcl | at all | 16:32 |
lkcl | as long as the proposed PipelineSignal obeys the "rules" (provides the prerequisite operators, which now includes PipelineSignal.__Cat__, PipelineSignal.__Assign__ etc.) nmigen is abstracted enough to accept that | 16:33 |
lkcl | there is also no reason why "strong typing" should not be added in the same way. | 16:33 |
lkcl | including strong typing for Clock Signals (just as they are done in Bluespec) | 16:34 |
lkcl | and optimisation phases such as merging a series of static-allocated Slice, Part and Cat chains. | 16:35 |
*** kylel1 is now known as kylel | 16:35 | |
cesar | Maybe that (Type 1 and Type 2 abstractions) is what should be sent as an nMigen RFC, not SimdSignal itself. SimdSignal, along with PipelineSignal, WhishboneSignal, Clock Signal typing, etc., could be seen as use cases of that, making a strong argument, and not being just tied to a LibreSOC need. | 16:42 |
lkcl | cesar: it was. however whitequark's "expert consultants" ordered whitequark to reject the entire RFC. | 18:07 |
lkcl | in the process causing whitequark to renege on an agreement made in April. | 18:08 |
lkcl | if whitequark had informed me of the outright rejection at the time rather than leaving it for six months, we could have planned properly | 18:08 |
lkcl | the discussion that whitequark interrupted when i was explaining the RFC was about the abstraction, how to complete it, and the benefits of doing so | 18:09 |
lkcl | i did not get an opportunity to complete those discussions before censorship was enacted approximately 15 hours later. | 18:10 |
lkcl | however, during those discussions, whitequark made it clear that it is a DELIBERATE intention to terminate all and any possibility of the use of Liskov Substitution Principle - abstraction - within nmigen | 18:11 |
lkcl | all possibilities - PipelineSignal, WishboneSignal, PartitionedSignal, typing - are terminated with prejudice and by definition. | 18:12 |
lkcl | this is an *active* choice - made by whitequark - to *define* nmigen language behaviour as being exclusively and solely scalar and in terms of what whitequark says is permitted | 18:12 |
tplaten | I'm currently trying to run unit tests that use soc.simple.test.test_runner.TestRunner and get lots of UnusedElaboratables | 18:12 |
lkcl | all else is prohibited. | 18:12 |
lkcl | tplaten: what exactly are you running | 18:13 |
lkcl | ? | 18:13 |
lkcl | what command? | 18:13 |
tplaten | soc/src/soc/simple/test/test_issuer_dcache.py | 18:13 |
tplaten | I wrote that unit test some month ago | 18:13 |
lkcl | the more serious error is this | 18:14 |
lkcl | soc/src/soc/fu/ldst/loadstore.py:91: DriverConflict: Signal '(sig dar)' is driven from multiple fragments: top.issuer.core.fus, top.issuer.core.l0; hierarchy will be flattened | 18:14 |
lkcl | which means exactly as it says: you've tried to drive dar from more than one location. | 18:15 |
lkcl | you'll need to track that down (git bisect) to find out exactly what modifications you made which cause two separate code locations to try to drive it | 18:15 |
tplaten | Since I never used git bisect before, I first read some tutorials | 18:21 |
* lkcl just doing manual checkouts | 18:21 | |
lkcl | tplaten, put this at the end of partsig.py: | 18:21 |
lkcl | PartitionedSignal = SimdSignal | 18:21 |
lkcl | commit 9c58fe8b3ccce5123f5119d381ecc96f5152c119 | 18:23 |
lkcl | add test_issuer_dcache.py | 18:23 |
lkcl | darn it, have to check out an openpower-isa from that timeperiod as well | 18:24 |
lkcl | Date: Sat Jul 24 13:25:49 2021 +0200 | 18:24 |
lkcl | because DCBZTestCase does not exist | 18:24 |
lkcl | ah because you forgot to add it back then, to test_issuer_dcache.py | 18:24 |
lkcl | that only happened 3 weeks later | 18:27 |
lkcl | commit 63342580f71028d8272cd35cfa038da6e5122937 | 18:27 |
lkcl | add WIP DCBZTestCase | 18:27 |
tplaten | DONE: tplaten, put this at the end of partsig.py: PartitionedSignal = SimdSignal | 18:31 |
lkcl | i'm currently exploring this commit commit 63342580f71028d8272cd35cfa038da6e5122937 | 18:31 |
lkcl | and, sigh, there's an error in the DIV FSM CompUnit, i have no idea why | 18:31 |
lkcl | going to set the units to not have a DIV ALU | 18:32 |
lkcl | found a way to do that | 18:33 |
lkcl | tplaten: https://ftp.libre-soc.org/f | 18:34 |
lkcl | ok: as far back as 592a924f61e97 it looks like there's always been a DriverConflict | 18:36 |
lkcl | i'm going to see if i can get back to before the nmutil rename (ready_o -> o_ready) | 18:37 |
lkcl | commit c17aa78fdd09eeefdb5d34ae5bde81c33fbef7a0 | 18:38 |
tplaten | that looks like an incomplete url | 18:38 |
lkcl | tplaten, it isn't | 18:38 |
lkcl | Date: Tue Aug 24 11:14:24 2021 +0100 | 18:38 |
lkcl | that's a nmutil commit, before the ready_o->o_ready rename | 18:38 |
lkcl | it's me doing "git diff > /tmp/f" followed by "scp /tmp/f libre-soc.org:/var/ftp.libre-soc.org" | 18:40 |
lkcl | still a DriverConflict on commit cb49428fe | 18:40 |
lkcl | nope. | 18:41 |
lkcl | even as far back as the original "add WIP DCBZTestCase" | 18:42 |
lkcl | commit 63342580f7102 | 18:42 |
lkcl | Author: Tobias Platen <tplaten@posteo.de> | 18:42 |
lkcl | Date: Mon Aug 16 20:02:06 2021 +0200 | 18:42 |
lkcl | there have always been DriverConflicts. | 18:42 |
tplaten | and I never noticed when running test code | 18:42 |
lkcl | as in: when you wrote the code, you wrote it with two simultaneous pieces of HDL trying to sync-drive the exact same Signal(s) | 18:43 |
lkcl | that's probably because you didn't output the full error logs to a file | 18:43 |
lkcl | python3 simple/test/test_issuer_dcache.py >& /tmp/f1 | 18:43 |
lkcl | you have to output stderr as well as stdout | 18:43 |
lkcl | or use nohup | 18:43 |
lkcl | nohup python3 simple/test/test_issuer_dcache.py | 18:43 |
lkcl | then check it carefully | 18:44 |
tplaten | No, I do not get that DriverConflict: Signal '(sig dar)' on my machine, I saw there is a commit message 'resolve DriverConflict in TstL0CacheBuffer, really bad hack' from May 1st | 18:55 |
tplaten | But that code looks that there is really a driver conflict | 18:55 |
tplaten | But that is not soc/src/soc/fu/ldst/loadstore.py | 18:58 |
lkcl | tplaten, https://ftp.libre-soc.org/f | 19:05 |
lkcl | problem "goes away" | 19:06 |
tplaten | The value is changed by MicrOp.OP_MTSPR and when an exception happens | 19:06 |
lkcl | meaning, yes, there are two locations where dsisr, dar, priv_mode and real_mode are all set twice | 19:06 |
lkcl | yes. and there should be an "input" value which loadstore.py reads from, rather than try to have it set n an "unauthorised" way. | 19:08 |
lkcl | i think this is down to splitting out the MMU as a separate FSM from microwatt loadstore.vhdl | 19:08 |
lkcl | it is not "exactly as microwatt" | 19:08 |
tplaten | commented out the offending lines, now thinking how to implement this proper | 19:17 |
lkcl | well, it's because we separated l_in.valid case l_in.op from loadstore.py and put it into mmu.py instead | 19:20 |
lkcl | this code | 19:24 |
lkcl | https://github.com/antonblanchard/microwatt/blob/f636bb7c3999d9326a2bd1c6131fc128be2cae24/loadstore1.vhdl#L502 | 19:24 |
lkcl | was moved to fsm.py | 19:24 |
lkcl | but | 19:24 |
lkcl | without some "multiplexing", which, ironically, is just the exact same code, which happens to make sure to set l_in.valid, | 19:25 |
lkcl | you can't do that | 19:25 |
lkcl | so | 19:25 |
lkcl | sigh | 19:25 |
lkcl | those commands have to move to loadstore.py | 19:26 |
lkcl | then fsm.py does "passthrough" to it. | 19:26 |
tplaten | I agree | 19:27 |
lkcl | btw we're following that microwatt commit, f636bb7c | 19:28 |
lkcl | soon after that, paul mackerras did a major update of loadstore, to a 3-stage pipeline. | 19:29 |
lkcl | which we definitely don't want to follow, the code gets horribly complex | 19:29 |
tplaten | Yes, I remember. I have to look at an older version of microwatt | 19:31 |
tplaten | maybe I do a commit in the libre-soc source code pointing to that microwatt version | 19:31 |
lkcl | if you can go ahead and copy the m.Switch(op.insn_type) over to loadstore.py | 19:31 |
lkcl | case l_in.op is | 19:32 |
lkcl | where's that data structure.. | 19:33 |
lkcl | Execute1ToLoadstore1Type | 19:34 |
*** tplaten <tplaten!~isengaara@55d463e2.access.ecotel.net> has left #libre-soc | 19:44 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!