<whitequark>
actually, there *is* a use case for CSR banks, although not for the same reasons as oMigen
<_whitenotifier>
[nmigen-boards] Fatsie commented on pull request #34: Added default reset signal - https://git.io/Je0xk
plonk has quit [Changing host]
plonk has joined #m-labs
<whitequark>
with the current design, if you have 100 registers in some peripheral, then in the hierarchy, there would be 400 ports in the module corresponding to this peripheral
<whitequark>
this is ugly, and makes hierarchical resource consumption analysis less useful, and makes using nmigen peripherals outside of nmigen impractical
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<_whitenotifier>
[nmigen-boards] whitequark commented on pull request #34: Added default reset signal - https://git.io/Je0xq
<_whitenotifier>
[m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Je0xm
<_whitenotifier>
[m-labs/nmigen-boards] Fatsie bc07491 - [breaking-change] Atlys: use reset button as reset
Stormwind_mobile has joined #m-labs
harryho has quit [Remote host closed the connection]
<_whitenotifier>
[m-labs/nmigen-soc] whitequark pushed 3 commits to master [+0/-0/±7] https://git.io/Je0xQ
<_whitenotifier>
[m-labs/nmigen-soc] whitequark 5520e0d - csr.bus: split CSRMultiplexer to CSRInterface+CSRDecoder.
<_whitenotifier>
[m-labs/nmigen-soc] whitequark d8f5c4c - csr.bus: drop CSR prefix from class names.
<_whitenotifier>
[m-labs/nmigen-soc] whitequark c4b340e - csr.bus: use proper enum instead of ad-hoc string enumeration.
<rjo>
whitequark : do you mean how to organize the address space of a bunch of csrs/peripherals?
<whitequark>
rjo: yes, and which API to use for composing peripherals / buses / bus bridges
<rjo>
I also think that banks are useful to organize the memory map. E.g. predict addresses for repeated peripherals. And they simplify the address matching logic.
<whitequark>
the current scheme (without explicit banking) also provides that by aligning peripherals
<whitequark>
(both of these benefits)
<rjo>
Yes. Aligning is a better word.
<whitequark>
and if not for hierarchical designs, I would have kept it. but I think it is not good enough if we want nice hierarchical designs.
<mtrbot-ml>
[mattermost] <harryho> @sb10q, whitequark: I'm making some changes to the latest code I pushed to my code, particularly `CSRBank`. I'm proposing that CSRBank is an Elaboratable that has a submodule of CSRMultiplexer, and a list of CSRRegister abstractions. While the mux reads/writes data in units of `data_width`, the register abstractions control which individual bits is allowed to read/written and put <message clipped>
<whitequark>
harryho: mattermost clipped your message
<mtrbot-ml>
[mattermost] <harryho> ...While the mux reads/writes data in units of `data_width`, the register abstractions control which individual bits is allowed to read/written and put/get the accessible data onto/from the right place for the mux to latch.
<mtrbot-ml>
[mattermost] <harryho> @sb10q, whitequark: I'm making some changes to the latest code I pushed to my code, particularly `CSRBank`. I'm proposing that CSRBank is an Elaboratable that has a submodule of CSRMultiplexer, and a list of CSRRegister abstractions.
<mtrbot-ml>
[mattermost] <harryho> Hmm, maybe CSRBank doesn't have to be Elaboratable at all!
<whitequark>
harryho: I'm not sure I understand your proposal
<whitequark>
ok so, first, please take a look at my latest changes
<mtrbot-ml>
[mattermost] <harryho> Will do
<whitequark>
regarding register abstractions, I purposefully split the logic that splits registers into data_width sized chunks into a separate interface
<whitequark>
let me explain the architecture I have in mind
<whitequark>
so let's consider an UART peripheral
<whitequark>
it would have three CSR registers: baud rate (rw field), status (r field), and event/interrupt (r_c1 field)
<whitequark>
the hierarchy would look something like this:
<whitequark>
the UARTPeripheral would export five ports, essentially the csr.Interface of the csr.Decoder
<whitequark>
the CSRDecoder would have three csr.Element ports, one per register, with the exact register width, and would handle chunking and shadow registers
<whitequark>
each register would take care of using the strobes and such to implement semantics of each individual field they have
<whitequark>
that said, it's not necessarily the best possible one, so I'm open to suggestions
<mtrbot-ml>
[mattermost] <harryho> Thanks. I'm on the bus on my way back home so I haven't read your code in full yet.
<mtrbot-ml>
[mattermost] <harryho> But an Element is a port for a register, right? Then for individual fields within a reg, a separate module would be needed to handle the actual data to read/write? Caz probably your bus won't read/write one field at a time, right?
<whitequark>
yes.
<mtrbot-ml>
[mattermost] <harryho> Yea, ok so I made such a module in the DSL already. I suppose that should be moved to bus.py instead, is that correct?
<whitequark>
I think it should stay in dsl, csr.bus deals with everything that isn't related to fields
<whitequark>
I'm currently working on memory maps, and I'll comment more precisely once that's done
<adamgreig>
i'm trying to use https://github.com/m-labs/nmigen/issues/236#issuecomment-541436683 to simulate a positive and negative clock domain thing, but having the domainrenamer rename both domains to sync is causing the "assert domain.name not in self.domains" in Fragment.add_domains to trigger: "AssertionError: assert 'sync' not in OrderedDict([('sync', ..."
<adamgreig>
any ideas?
<adamgreig>
error goes away if i only rename one or the other domain, but then of course only one or the other domain clock is driven
<whitequark>
you can't rename both domains to sync
<whitequark>
oh, wait
<whitequark>
nevermind, I misunderstood. can you post the backtrace?
<whitequark>
rjo: I arrived at a design where every interface (eg csr.Interface, wishbone.Interface, etc) will hold a MemoryMap describing it
<whitequark>
then, any sort of arbiter, crossbar, bridge will by definition have access to the memory map, since they all already have access to the interface.
Stormwind_mobile has joined #m-labs
kuldeep has joined #m-labs
lkcl has joined #m-labs
<rjo>
With the "slave" side of the interface defining that memory map? And the the CSRs themselves would end up being described by that map as well, with the map carrying the entire information?
<whitequark>
1) yes 2) not quite
<whitequark>
the memory map only describes resources at the data bus granularity. from the perspective of the memory map, a CSR is an opaque aligned chunk of bits.
<whitequark>
I expect that modules like: accessor generators, documentation generators, SVD exporters, and so on, would traverse the memory map, discover all resources they know how to work with, and process them
<whitequark>
third-party libraries could just as well add their own resource types, if they so wish.
<rjo>
ok. the resources are linked through and can be inspected via the memory map?
<whitequark>
yep
<_whitenotifier>
[m-labs/nmigen-soc] whitequark pushed 3 commits to master [+3/-0/±7] https://git.io/JeEm2