| 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> plus | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> i also said that analysis showed that triggering at rising and falling edge was not necessary | 00: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 one | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> http://programmedgeek.blogspot.com/2014/05/verilog-code-for-j-k-flip-flop.html | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> and this one | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> https://www.edaplayground.com/x/qMU | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> what you provided was something from some "internal simulator model" likely from a Cell Library | 00: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 trouble | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> this youtube video also uses @posedge clk | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> https://www.youtube.com/watch?v=kTWEXZPg0mA | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> go back to the version from when we last talked. | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> remove these | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> self.posck = ClockDomain("pos", local=True) | 00:43 |
| openpowerbot | [mattermost] <lkcl> <lkcl> #^ https://freenode.irclog.whitequark.org/nmigen/2020-03-29 vinalon tried not to | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> self.negck = ClockDomain("neg", local=True, clk_edge="neg") | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> and this | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> m.domains.neg = self.negck | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> #^ #04:38:23< lkcl> looking more closely, you *might* have to create a neg-edge domain | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> #negck.clk = m.d.sync.clk | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> #^ impossible, see whitequark/vinalon link | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> #neg.rst = m.d.sync.rst | 00:44 |
| openpowerbot | [mattermost] <lkcl> <lkcl> and this | 00: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 quickly | 00:45 |
| openpowerbot | [mattermost] <lkcl> plus they are simply not even necessary if you use the "normal" @ posedge(clk) definition | 00:45 |
| klys | all right; one question: is the term @posedge even valid in nmigen? | 00:57 |
| klys | I don't think I've encountered any Cell Library; just mostly docs and stackoverflow answers | 00:59 |
| klys | yea http://show.ing.me/verilog/jkff-0005-15dec2022.py.txt seems to be working. | 01:10 |
| klys | now how to get verilog output | 01:10 |
| klys | figured 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 it | 06: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 shop | 06:17 |
| openpowerbot | [mattermost] <lkcl> you should have discovered this by now, by examining the verilog output | 06:18 |
| klys | yes I have just recently found the verilog output | 06:18 |
| openpowerbot | [mattermost] <lkcl> and finding that use of m.d.sync *automatically* resulted in @ posedge(clk) being inserted into the verilog output | 06:18 |
| openpowerbot | [mattermost] <lkcl> the counter example (unmodified) is a good one to try for that | 06:18 |
| openpowerbot | [mattermost] <lkcl> you'll also see | 06:18 |
| openpowerbot | [mattermost] <lkcl> (excellent) | 06:18 |
| openpowerbot | [mattermost] <lkcl> that the "if rst" nonsense is also taken care of | 06:19 |
| klys | I find that the counter example is one I used, not well documented, and probably the only one there | 06:19 |
| openpowerbot | [mattermost] <lkcl> by default all Signals have a reset of zero | 06:19 |
| openpowerbot | [mattermost] <lkcl> yes i know - none of them are | 06:19 |
| openpowerbot | [mattermost] <lkcl> it's assumed by the example authors that you are capable of self-deductive learning | 06: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-Labs | 06:20 |
| klys | the thing about examining _bus to learn about clock domains is that it inherits from so many things | 06:20 |
| openpowerbot | [mattermost] <lkcl> now you see why i said "stick to small examples" :) | 06:21 |
| openpowerbot | [mattermost] <lkcl> it's a little overwhelming initially | 06:21 |
| openpowerbot | [mattermost] <lkcl> but actually makes sense very quickly. | 06:21 |
| klys | well 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 rapidly | 06:22 |
| openpowerbot | [mattermost] <lkcl> not at 4-6 am, no :) | 06:22 |
| klys | okay that's fine | 06:22 |
| openpowerbot | [mattermost] <lkcl> although it occurred to me that it would be really nice to submit as an example | 06:23 |
| klys | you're welcome to | 06: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) https://gitlab.com/nmigen/nmigen/-/blob/master/LICENSE.txt | 06:24 |
| klys | pm me your email if you'd like | 06:24 |
| openpowerbot | [mattermost] <lkcl> luke.leighton@gmail.com | 06:24 |
| klys | thank you | 06:25 |
| openpowerbot | [mattermost] <lkcl> btw unlike verilog, nmigen is 100% deterministic output | 06: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 |
| klys | sent. | 06:29 |
| openpowerbot | [mattermost] <lkcl> got it. from a hilariously-named person i'd normally sent straaiiight to spam :) | 06:30 |
| openpowerbot | [mattermost] <lkcl> thx klys | 06:31 |
| klys | yw. | 06:31 |
| klys | keep 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 test_jkk.py with the bench() because it's good practice | 06:32 |
| openpowerbot | [mattermost] <lkcl> ha you took the print() thing to heart :) | 06:33 |
| klys | yeah 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 think | 06:34 |
| openpowerbot | [mattermost] <lkcl> yield Delay(nnnn_nanoseconds) | 06:34 |
| openpowerbot | [mattermost] <lkcl> and a few other things i can't recall immediately | 06:35 |
| klys | also 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 |
| klys | makes sense | 06: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 |
| klys | normally 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 |
| klys | this is from a generic concept of JK flip flop found in schematics | 06:38 |
| openpowerbot | [mattermost] <lkcl> yyeahh... that _is_ what you'd use a @negedge(clk) domain for | 06:39 |
| openpowerbot | [mattermost] <lkcl> the c4m-jtag code however, you actually don't ever connect it to the sync domain at all | 06:40 |
| klys | if that is too much I'd recommend tabling it again. I have access to verilog now and that means I could make something more complex | 06:40 |
| openpowerbot | [mattermost] <lkcl> it's intended to be externally driven literally by the external JTAG CLK line | 06:40 |
| klys | well that irc link with whitequark explains how you can't use sync for pos-edge | 06:40 |
| openpowerbot | [mattermost] <lkcl> waggled by openocd (etc) | 06:40 |
| klys | and c4m-jtag creates a pos-edge ClockDomain() also | 06:41 |
| openpowerbot | [mattermost] <lkcl> sync is already pre-set-up for you | 06:41 |
| klys | right | 06:41 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 09:50 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:42 | |
| ghostmansd | lkcl, it appears that we dropped /crm specifier. Is it correct? | 12:00 |
| ghostmansd | Same for /mrr specifier. | 12:01 |
| ghostmansd | I vaguely recall that there was some decision related to all mapreduce, but the code does not reflect it. | 12:01 |
| ghostmansd | You know, this is a big problem that you keep refactoring it, whilst I try to keep all the code around in sync. | 12:02 |
| ghostmansd | Could you please put these activities on hold at least for a while? | 12:02 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:18 | |
| ghostmansd | OK, I found that it's not eliminated completely. Sigh of relief. | 12:51 |
| ghostmansd | I'll dig into it in details later. | 12:51 |
| ghostmansd | Still, this /pi change, along with stride mode for ld/st idx, etc., etc. | 12:52 |
| ghostmansd | Please think of keeping it intact at least for a while. | 12:52 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 12:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:10 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.235> has joined #libre-soc | 13:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.235> has quit IRC | 13:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.123> has joined #libre-soc | 13:31 | |
| *** Guest1478 <Guest1478!~Guest14@84.232.150.169> has joined #libre-soc | 16:36 | |
| *** Guest1497 <Guest1497!~Guest14@84.232.150.169> has joined #libre-soc | 16:37 | |
| *** yambo <yambo!~yambo@69.145.120.113> has quit IRC | 16:40 | |
| *** yambo <yambo!~yambo@069-145-120-113.biz.spectrum.com> has joined #libre-soc | 16:42 | |
| lkcl | ghostmansd[m], let me check | 16:44 |
| lkcl | mrr - map-reduce-reverse, no definitely not | 16:45 |
| lkcl | reverse-gear is extremely important but is *only* possible using /mrr | 16:49 |
| lkcl | /crm is gone from the spec, so needs removing from sv/trans/svp64.py | 16:49 |
| lkcl | i did pause for you a few months back. | 16:50 |
| lkcl | the specification has to progress, so no, it'll not be possible to cease all work on it | 16:50 |
| lkcl | however i am only going to really start again some time mid-january | 16:51 |
| lkcl | estimated | 16:51 |
| lkcl | the reason is: we absolutely cannot go to the ISA WG with an incomplete, incorrect, or simply plain unworkable spec | 16:53 |
| lkcl | ceasing all work on the spec is such a show-stopper that it's not going to be possible. | 16:54 |
| lkcl | sv/trans/svp64.py is therefore the fastest - canonical - way to get iterative testing of that spec | 16:54 |
| lkcl | binutils takes a back seat as a second priority. | 16:55 |
| lkcl | sv/trans/svp64.py *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 |
| lkcl | btw about PowerOp: my feeling is that create_pdecode() and class PowerDecoder need a rewrite/replacement, providing the exact same API | 17:07 |
| lkcl | that's a fairly hefty task as it is absolutely critical to absolutely everything, so should get a substantial budget | 17:08 |
| *** Guest1497 <Guest1497!~Guest14@84.232.150.169> has quit IRC | 17:22 | |
| ghostmansd[m] | Yeah the reason why I brought this topic was exactly CRM | 18:02 |
| ghostmansd[m] | Then I thought all remap is gone, but that was wrong | 18:02 |
| ghostmansd[m] | I hope I'll complete assembly to mid-January, but this is just a hope | 18:03 |
| ghostmansd[m] | Ok, I understand your considerations, thanks for sharing and explaining! | 18:03 |
| lkcl | there'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 little | 19:03 |
| lkcl | although it cannot be a lot because i need to get some EUR in. | 19:03 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.123> has quit IRC | 20:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.152> has joined #libre-soc | 20:48 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.152> has quit IRC | 21:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:13 | |
| *** octavius <octavius!~octavius@92.40.169.164.threembb.co.uk> has joined #libre-soc | 21:44 | |
| octavius | lkcl, 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!~octavius@92.40.169.164.threembb.co.uk> has quit IRC | 22:20 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!