<mithro>
whitequark: It would be good to join #litex - xobs has a bunch of questions about how maybe to do enums + Records document generation that could take inspiration from boneless and other stuff you are doing
<whitequark>
isn't xobs here too?
<xobs>
Hi
<mithro>
Yes, but the conversation started over in #litex regarding documenting CSR register bit fields...
<whitequark>
in fact in nMigen you can define a Record purely in your own code using UserValue
<whitequark>
one question is how exactly should documentation be possible to retrieve
<whitequark>
for example, if each CSR is a class, should it be possible to do this just by grabbing the class itself, without an instance?
<xobs>
My plan was to iterate through all DReg objects instantiated, then generate wavedrom `reg` plots and tables containing all of the bitfields.
<whitequark>
or conversely, would you want to generate CSR layouts based on design parameters, so you'd need to instaitate the entire design to generate the docs?
<whitequark>
thinking about this, the latter approach does sound more useful to me
<xobs>
No, I don't think that's very interesting. Grabbing the class itself should get you the Python documentation on how to instantiate the class. The documentation really only makes sense once it's instnatiated in a design.
<whitequark>
agree
<whitequark>
should CSRs have nesting, or should their layout be completely flat?
<xobs>
Litex already generates a header file as part of the build process. I could see it generating a rst as well.
<xobs>
Litex has a two-tier system, which seems to almost be what you see in most reference manuals, where each CSR bank has multiple registers.
<whitequark>
I mean the CSR bits
<whitequark>
Records are nested.
<whitequark>
your suggestion does not appear to support nesting
<whitequark>
reusing Records somehow would mean dealing with nesting
<whitequark>
so that's one argument against it that I see
<xobs>
I'm not sure how you'd document that, or what implications that would have.
<whitequark>
then I think building your own instead of reusing Records is fine
<xobs>
Alright. And you say nmigen-soc is going to gain something akin to CSRs?
<whitequark>
certainly. CSRs and other interconnect are what nmigen-soc is for.
<xobs>
That's good news!
<whitequark>
are you primarily looking into working with migen or nmigen?
<xobs>
I'm working with migen right now, because as I understand it nmigen isn't ready for general use yet.
<whitequark>
I'd like to encourage you to use nmigen
<xobs>
Thanks, I'll have a look.
<whitequark>
the basic HDL is stable, the library features will see a bit of churn but no radically breaking changes
<whitequark>
just a few renames that are trivial to adjust your code for
<xobs>
One thing I'm concerned about is simulation. Right now I use cocotb for simulation, because it's really fast with iverilog.
<whitequark>
mithro has talked with me about cocotb
<xobs>
How likely is it to get something like that into nmigen?
<whitequark>
already done.
<xobs>
Oh yay! That solves that problem.
<whitequark>
as for cocotb, I have some reservations about it, but I would tentatively consider adding first-class support for it
<whitequark>
the goal for 0.2 is improvements in the simulation
<xobs>
Right now I just take the `top.v` and point cocotb at that. It makes things like simulation super nice.
<whitequark>
well, one problem that needs to be solved is bidirectional mapping between Verilog names and nMigen signals
<whitequark>
it's essentially just plumbing, but it needs to be done
<xobs>
That's a challenge, yeah. Most of the names in migen make some sense, though sometimes they grow not-so-useful names like "fsm".
<whitequark>
nMigen already has this information, it only needs to be exposed from the backend
proteusguy has quit [Remote host closed the connection]
<harryho>
whitequark: So I moved some parts of CSR from oMigen to nMigen, haven't tested it out yet. It's obviously not the final product but please feel free to take a look at my repo, especially the comments I added. Thanks! https://git.m-labs.hk/harry/nmigen-soc/src/branch/csr/nmigen_soc/csr.py
<whitequark>
harryho: I think there's a missing step
<whitequark>
namely, just porting old code without considering why it's there and which problem it solves isn't always the best way
<whitequark>
at the first glance I see a few issues with code either, but the problem is more that I think we should start with a design, not just some code
<whitequark>
some examples:
<whitequark>
1) xobs has some very reasonable suggestions in regards to generating documentation from CSRs
<whitequark>
2) I'm not sure if CSRs should be elaboratables at all
<whitequark>
a CSR is a storage element; which exact protocol is used to access it is a matter decided by the bus master (the CPU, usually), not the CSR itself
<whitequark>
3) AutoCSR seems like something we maybe should get rid of completely
mumptai_ has quit [Remote host closed the connection]
<harryho>
whitequark: Thank you very much for the detailed response. Your advice is very valuable especially the point about finding all the pre-existing problems. So would you say the best approach in hunting for these problems is to look for all the issues on GitHub and/or try running some simple CSR examples to test out each of these CSR classes? I appreciate your advice and I will get back to work on this tomorrow.
<whitequark>
harryho: I'm currently writing down the criticism of the existing CSR design that I remember offhand as an issue in the GH nmigen-soc repo
<whitequark>
I will also list some suggestions I'm thinking of
harryho has quit [Remote host closed the connection]
<mithro>
xobs: I think Ewen was working on fixing the fsm naming issue
<xobs>
mithro: for omigen? I remember there was an open bug on it somewhere, but I've just learned to live with it. Nice to know it's fixed in nmigen, though!
<mithro>
Yes
<mithro>
We should poke him
<mithro>
He had everything figured out I think
<mithro>
This was in context of the gtk wave output
<xobs>
I like gtkwave output. That + sigrok is amazing.
_florent_ has joined #m-labs
mauz555 has joined #m-labs
X-Scale has joined #m-labs
<mtrbot-ml>
[mattermost] <sb10q> whitequark: what is the issue with AutoCSR?
<mtrbot-ml>
[mattermost] <sb10q> And another thing: accessing arrays of the same device
<whitequark>
sb: re AutoCSR: it does some introspection magic, right?
<mtrbot-ml>
[mattermost] <sb10q> This is supported in misoc already (and used in artiq) but a bit dirty
<mtrbot-ml>
[mattermost] <sb10q> it does some simple introspection, not much magic
<whitequark>
yeah but it seems easier to make everything explicit via CSRBank
<whitequark>
since we need it anyway
<whitequark>
there'll be properties shared across the entire bank, at least the docs
<mtrbot-ml>
[mattermost] <sb10q> How explicit?
<whitequark>
there's an example in my comment
<mtrbot-ml>
[mattermost] <sb10q> Okay, that looks similar to the "introspection magic"
<mtrbot-ml>
[mattermost] <sb10q> But then we can get rid of DUID, which is nice
<whitequark>
no, it's completely explicit via __setattr_
<mtrbot-ml>
[mattermost] <sb10q> Since we intercept the setattr call which happens in order
<whitequark>
i.e. there's no attribute enumeration going on
<mtrbot-ml>
[mattermost] <sb10q> well setattr is just as magic as introspection
<whitequark>
the benefit is that your properties work like usual
<whitequark>
I'm actually thinking that what would make more sense is something like
<whitequark>
with CSRBank("uart") as self.csrs:
<whitequark>
with self.csrs.register("baud"):
<mtrbot-ml>
[mattermost] <sb10q> Then how do you access the baud CSR value?
<whitequark>
self.csrs.baud
<whitequark>
or even something like
<whitequark>
with CSRBank("uart") as self.csrs:
<whitequark>
with self.csrs.register("baud") as self.csr_baud:
<mtrbot-ml>
[mattermost] <sb10q> What do you put in the body of the with csrs.register?
<whitequark>
with self.csr_baud.field("divisor", 24) as self.csr_baud_divisor:
<whitequark>
I'm going to look at a few different variants, this isn't final
<whitequark>
but this gives you an idea of what I'm going for
<mtrbot-ml>
[mattermost] <sb10q> what goes after "with"?
<mtrbot-ml>
[mattermost] <sb10q> Why does it need to be a context manager?
<whitequark>
hm, probably doesn't. let's rephrase
<whitequark>
I'm thinking about defining CSRs using some kind of builder syntax
<whitequark>
it makes sense to do it with a context manager if there's state managed by the builder
<whitequark>
what I'm trying to avoid specifically is a loop over the attributes of an elaboratable
<whitequark>
any solution that doesn't do that is fine by me, provided it's also good on its own terms
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
<davidc__>
whitequark: I took a read through the nMigen CSR design issue. In your second comment you mentioned that the CPU should be responsible for gathering CSRs and instantiating the bus structure. I think a CPU-centric gather/connect pattern could be problematic for designs with multiple potential CSR bus masters
<davidc__>
(ex: internal softcore for runtime operation + etherbone bridge for debugging)
<whitequark>
davidc__: right, I'm not saying this should be *strictly* delegated to CPUs
<whitequark>
I'm more saying that in a common SoC design where the CPU drives CSRs, the CSR bus should be "whatever is most convenient for CPU"
<whitequark>
maybe the CPU has AXI natively, then the CSRs should be on AXI
<whitequark>
more generally
<whitequark>
this highlights the need to co-ordinate CSR addresses between potentially multiple bus masters
<davidc__>
I think I generally agree with that (use what makes sense). I just didn't want to see something get baked in that was inconvenient for multiple bus masters
<davidc__>
(because I use that a lot)
<whitequark>
feel free to comment, summarizing the above
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #202: Add Value.match(...), an operator with the same semantics as Case(...) - https://git.io/JemTk
<_whitenotifier>
[nmigen] whitequark commented on issue #202: Add Value.match(...), an operator with the same semantics as Case(...) - https://git.io/JemT3
mauz555 has quit [Remote host closed the connection]
lkcl has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
mauz555 has quit [Remote host closed the connection]
lkcl has joined #m-labs
mauz555 has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<mtrbot-ml>
[mattermost] <cjbe> @rjo did you ever manage to get the ITM working on Stabilizer? From a brief search there seem to be some oddities in the STM32h7x3 ITM core. At the moment I can't get anything out of the SWO pin.
mauz555_ has joined #m-labs
mauz555 has quit [Ping timeout: 246 seconds]
mauz555_ has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
<_whitenotifier>
[smoltcp] cjbe opened issue #305: panic decoding DHCP domain name server option - https://git.io/JemOM
kernlbob_ has joined #m-labs
<kernlbob_>
I am back with another beginner question.