Saturday, 2022-12-17

openpowerbot[mattermost] <lkcl> <lkcl> klys, remember i advised not to tackle ClockDomains at the same time as getting something functional? but to do one first and then the other?00:43
openpowerbot[mattermost] <lkcl> <lkcl> plus00:43
openpowerbot[mattermost] <lkcl> <lkcl> i also said that analysis showed that triggering at rising and falling edge was not necessary00:43
openpowerbot[mattermost] <lkcl> <lkcl> and to try to look for a more "normal" definition of a jkff in verilog that uses standard @rising(clk) terminology?00:43
openpowerbot[mattermost] <lkcl> <lkcl> like this one00:43
openpowerbot[mattermost] <lkcl> <lkcl>
openpowerbot[mattermost] <lkcl> <lkcl> and this one00:43
openpowerbot[mattermost] <lkcl> <lkcl>
openpowerbot[mattermost] <lkcl> <lkcl> what you provided was something from some "internal simulator model" likely from a Cell Library00:43
openpowerbot[mattermost] <lkcl> <lkcl> and attempting to implement it by doing posedge and negedge which is entirely unnecessary if you use the more "normal" ways that jkffs are written, will get you into trouble00:43
openpowerbot[mattermost] <lkcl> <lkcl> this youtube video also uses @posedge clk00:43
openpowerbot[mattermost] <lkcl> <lkcl>
openpowerbot[mattermost] <lkcl> <lkcl> go back to the version from when we last talked.00:43
openpowerbot[mattermost] <lkcl> <lkcl> remove these00:43
openpowerbot[mattermost] <lkcl> <lkcl>       self.posck = ClockDomain("pos", local=True)00:43
openpowerbot[mattermost] <lkcl> <lkcl>       #^ vinalon tried not to00:44
openpowerbot[mattermost] <lkcl> <lkcl>       self.negck = ClockDomain("neg", local=True, clk_edge="neg")00:44
openpowerbot[mattermost] <lkcl> <lkcl> and this00:44
openpowerbot[mattermost] <lkcl> <lkcl> = self.negck00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #^ #04:38:23< lkcl> looking more closely, you *might* have to create a neg-edge domain00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #negck.clk = m.d.sync.clk00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #^ impossible, see whitequark/vinalon link00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #neg.rst = m.d.sync.rst00:44
openpowerbot[mattermost] <lkcl> <lkcl> and this00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #if platform != None:00:44
openpowerbot[mattermost] <lkcl> <lkcl>       #   platform.create_missing_domain("sync", reset_sig=self.clk)00:44
openpowerbot[mattermost] <lkcl> <lkcl>       m.d.sync += [00:44
openpowerbot[mattermost] <lkcl> <lkcl>          self.negck.clk.eq(self.posck.clk)00:44
openpowerbot[mattermost] <lkcl> <lkcl>       ]00:44
openpowerbot[mattermost] <lkcl> all of those are asking for trouble attempting to tackle advanced nmigen concepts as a very first attempt, and you will get frustrated and overwhelmed very quickly00:45
openpowerbot[mattermost] <lkcl> plus they are simply not even necessary if you use the "normal" @ posedge(clk) definition00:45
klysall right; one question: is the term @posedge even valid in nmigen?00:57
klysI don't think I've encountered any Cell Library; just mostly docs and stackoverflow answers00:59
klysyea seems to be working.01:10
klysnow how to get verilog output01:10
klysfigured that out too (0006)05:56
openpowerbot[mattermost] <lkcl> klys: @posedge is automatically created for you based on the fact that you used a ClockDomain which, by default, has been created for you (called "sync")06:16
openpowerbot[mattermost] <lkcl> you do not need to explicitly create it06:16
openpowerbot[mattermost] <lkcl> whenever you do "m.d.sync += some_nmigen_AST_expression"06:16
openpowerbot[mattermost] <lkcl> you *are* adding that AST expression *to* @ posedge(the_clock_behind_the_domain_named_sync)06:17
openpowerbot[mattermost] <lkcl> this is all entirely handled for you precisely so that you do not need to know about writing verilog @ posedge (bullshit) all over the shop06:17
openpowerbot[mattermost] <lkcl> you should  have discovered this by now, by examining the verilog output06:18
klysyes I have just recently found the verilog output06:18
openpowerbot[mattermost] <lkcl> and finding that use of m.d.sync *automatically* resulted in @ posedge(clk) being inserted into the verilog output06:18
openpowerbot[mattermost] <lkcl> the counter example (unmodified) is a good one to try for that06:18
openpowerbot[mattermost] <lkcl> you'll also see06:18
openpowerbot[mattermost] <lkcl> (excellent)06:18
openpowerbot[mattermost] <lkcl> that the "if rst" nonsense is also taken care of06:19
klysI find that the counter example is one I used, not well documented, and probably the only one there06:19
openpowerbot[mattermost] <lkcl> by default all Signals have a reset of zero06:19
openpowerbot[mattermost] <lkcl> yes i know - none of them are06:19
openpowerbot[mattermost] <lkcl> it's assumed by the example authors that you are capable of self-deductive learning06:20
openpowerbot[mattermost] <lkcl> which is how they came before i took over as the Legally Authorised Maintainer of nmigen under Trademark License by M-Labs06:20
klysthe thing about examining _bus to learn about clock domains is that it inherits from so many things06:20
openpowerbot[mattermost] <lkcl> now you see why i said "stick to small examples" :)06:21
openpowerbot[mattermost] <lkcl> it's a little overwhelming initially06:21
openpowerbot[mattermost] <lkcl> but actually makes sense very quickly.06:21
klyswell now I have a "small example."  were you able to try it?06:22
openpowerbot[mattermost] <lkcl> within 2-3 weeks esp. if you already know verilog i'd expect you to absorb it pretty rapidly06:22
openpowerbot[mattermost] <lkcl> not at 4-6 am, no :)06:22
klysokay that's fine06:22
openpowerbot[mattermost] <lkcl> although it occurred to me that it would be really nice to submit as an example06:23
klysyou're welcome to06:23
openpowerbot[mattermost] <lkcl> ok - do email it to me (with a note saying you're happy for it to be under the 2-clause BSD license)
klyspm me your email if you'd like06:24
openpowerbot[mattermost] <lkcl> luke.leighton@gmail.com06:24
klysthank you06:25
openpowerbot[mattermost] <lkcl> btw unlike verilog, nmigen is 100% deterministic output06:27
openpowerbot[mattermost] <lkcl> how to use modules would be the next recommended step - that's when you get to join things together (just like in verilog modules)06:28
openpowerbot[mattermost] <lkcl> got it. from a hilariously-named person i'd normally sent straaiiight to spam :)06:30
openpowerbot[mattermost] <lkcl> thx klys06:31
klyskeep in mind I may still be working on it to make the verilog output more concise if possible.06:31
openpowerbot[mattermost] <lkcl> no totally. i'll likely sparsify it (to fit the style of the examples) but also split out into a with the bench() because it's good practice06:32
openpowerbot[mattermost] <lkcl> ha you took the print() thing to heart :)06:33
klysyeah before I did that I want' real sure what yield meant, though I understand now that yields one clock cycle.06:33
openpowerbot[mattermost] <lkcl> warning/caveat, that "practical pragmatic debug hack" does drive other python purists nuts :)06:33
openpowerbot[mattermost] <lkcl> yyyeess...06:33
openpowerbot[mattermost] <lkcl> yield *on its own* means "one clock cycle"06:34
openpowerbot[mattermost] <lkcl> but you can also do yield Tick() - i think06:34
openpowerbot[mattermost] <lkcl> yield Delay(nnnn_nanoseconds)06:34
openpowerbot[mattermost] <lkcl> and a few other things i can't recall immediately06:35
klysalso I don't think the flip flop is purely a JK style flip-flop necessarily because it waits for both inputs to be reset before it outputs the result.06:35
openpowerbot[mattermost] <lkcl> the default yield of None is *interpreted* to mean "please move the simulation on by one clock cycle in the sync domain"06:36
klysmakes sense06:36
openpowerbot[mattermost] <lkcl> yes, this is unavoidable, and if you look at those verilog examples i found online, they "suffer" from the exact same "flaw"06:36
klysnormally if you set J high K high you get reverse polarity, if it's a J/K master-slave flip flop then that happens on the trailing edge.06:38
openpowerbot[mattermost] <lkcl> ....06:38
klysthis is from a generic concept of JK flip flop found in schematics06:38
openpowerbot[mattermost] <lkcl> yyeahh... that _is_ what you'd use a @negedge(clk) domain for06:39
openpowerbot[mattermost] <lkcl> the c4m-jtag code however, you actually don't ever connect it to the sync domain at all06:40
klysif that is too much I'd recommend tabling it again.  I have access to verilog now and that means I could make something more complex06:40
openpowerbot[mattermost] <lkcl> it's intended to be externally driven literally by the external JTAG CLK line06:40
klyswell that irc link with whitequark explains how you can't use sync for pos-edge06:40
openpowerbot[mattermost] <lkcl> waggled by openocd (etc)06:40
klysand c4m-jtag creates a pos-edge ClockDomain() also06:41
openpowerbot[mattermost] <lkcl> sync is already pre-set-up for you06:41
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:35
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc09:50
*** ghostmansd <ghostmansd!> has joined #libre-soc10:29
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:30
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:31
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC11:03
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc11:42
ghostmansdlkcl, it appears that we dropped /crm specifier. Is it correct?12:00
ghostmansdSame for /mrr specifier.12:01
ghostmansdI vaguely recall that there was some decision related to all mapreduce, but the code does not reflect it.12:01
ghostmansdYou know, this is a big problem that you keep refactoring it, whilst I try to keep all the code around in sync.12:02
ghostmansdCould you please put these activities on hold at least for a while?12:02
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC12:18
ghostmansdOK, I found that it's not eliminated completely. Sigh of relief.12:51
ghostmansdI'll dig into it in details later.12:51
ghostmansdStill, this /pi change, along with stride mode for ld/st idx, etc., etc.12:52
ghostmansdPlease think of keeping it intact at least for a while.12:52
*** ghostmansd <ghostmansd!> has quit IRC12:57
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc12:59
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:31
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:31
*** Guest1478 <Guest1478!~Guest14@> has joined #libre-soc16:36
*** Guest1497 <Guest1497!~Guest14@> has joined #libre-soc16:37
*** yambo <yambo!~yambo@> has quit IRC16:40
*** yambo <yambo!> has joined #libre-soc16:42
lkclghostmansd[m], let me check16:44
lkclmrr - map-reduce-reverse, no definitely not16:45
lkclreverse-gear is extremely important but is *only* possible using /mrr16:49
lkcl /crm is gone from the spec, so needs removing from sv/trans/svp64.py16:49
lkcli did pause for you a few months back.16:50
lkclthe specification has to progress, so no, it'll not be possible to cease all work on it16:50
lkclhowever i am only going to really start again some time mid-january16:51
lkclthe reason is: we absolutely cannot go to the ISA WG with an incomplete, incorrect, or simply plain unworkable spec16:53
lkclceasing all work on the spec is such a show-stopper that it's not going to be possible.16:54
lkclsv/trans/ is therefore the fastest - canonical - way to get iterative testing of that spec16:54
lkclbinutils takes a back seat as a second priority.16:55
lkclsv/trans/ *has* to be fast to develop/use/modify as it's what i use to validate that the spec is correct, in a rapid fashion.16:56
lkclbtw about PowerOp: my feeling is that create_pdecode() and class PowerDecoder need a rewrite/replacement, providing the exact same API17:07
lkclthat's a fairly hefty task as it is absolutely critical to absolutely everything, so should get a substantial budget17:08
*** Guest1497 <Guest1497!~Guest14@> has quit IRC17:22
ghostmansd[m]Yeah the reason why I brought this topic was exactly CRM18:02
ghostmansd[m]Then I thought all remap is gone, but that was wrong18:02
ghostmansd[m]I hope I'll complete assembly to mid-January, but this is just a hope18:03
ghostmansd[m]Ok, I understand your considerations, thanks for sharing and explaining!18:03
lkclthere's some RFPs that need writing (one early one), and also some planning (the MoUs for the 2 EUR 100k Grants), which can kinda push things back a little19:03
lkclalthough it cannot be a lot because i need to get some EUR in.19:03
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC20:24
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc20:24
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC20:47
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc20:48
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC21:12
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc21:13
*** octavius <octavius!> has joined #libre-soc21:44
octaviuslkcl, been looking at the pipelines and noticed that the arithmetic pipeline is called ALU in the soc repo (fu/alu/). Strictly speaking, isn't this incorrect since this pipeline doesn't have logical ops?21:45
*** octavius <octavius!> has quit IRC22:20

Generated by 2.17.1 by Marius Gedminas - find it at!