<Vinalon>
So I've been looking at the 'test_memory' file in nmigen-soc trying to figure out how to structure a MemoryMap for bitwise access to registers where the bitfields can have different access and lengths
<Vinalon>
It looks like I'll probably want to set up a 'root' MemoryMap which covers all of the registers, and call 'add_window' with Resources representing each individual register
<Vinalon>
I guess I'm not quite clear on how to make those 'Resource' objects, though; it looks like maybe I can make a _RangeMap and insert each bitfield one by one?
<Vinalon>
And how do the 'Element' objects fit into things, for applying r/w permissions?
<Vinalon>
I think the second approach is probably close to what I want, but I'm not sure about the syntax or alignment or performance.
Vinalon__ has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon__ is now known as Vinalon
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #nmigen
<Vinalon>
It looks like I probably want to use Multiplexers and Interfaces instead of MemoryMaps, with Elements representing the individual bitfields
<Vinalon>
but should I have a Multiplexer representing the entire bus and an Inteface for each individual register, or vice-versa?
<Vinalon>
I guess the Interface should represent the bus since it has the 'data' and 'strobe' signals...and because the Multiplexer class has an Instance member named 'bus' :T
samlittlewood_ has quit [Ping timeout: 240 seconds]
samlittlewood__ has joined #nmigen
<Vinalon>
Okay, it actually looks like Multiplexer classes create their own Interfaces when the MemoryMap associated with them is finalized.
<Vinalon>
but it doesn't look like Multiplexers or Elements can nest. So...is an Element supposed to refer to a register, or a bitfield within a register?
<Vinalon>
alright, I think maybe I got it: an Element should represent an entire register, but I can wrap Elements in modules which implement the fine-grained bitfields, like the MockRegister class in 'test_csr_wishbone.py'
<Vinalon>
I'll try asking again when I have some sane example code along those lines; sorry for thinking aloud.
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
rohitksingh has quit [Ping timeout: 260 seconds]
<whitequark>
Vinalon: currently there is no support at all for fine grained bitfields
<whitequark>
an Element is a single register
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
rohitksingh has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
Asu has joined #nmigen
<zignig>
I just had ny shady neighbor obsereve, we all all in gaol now...
<zignig>
be well, and watch out for all you friends...
Vinalon has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
Vinalon has joined #nmigen
<Vinalon>
okay, thanks - so it sounds like I should use a Multiplexer of Elements.
<Vinalon>
I guess I'll make register class that inherits from Element and Elaboratable then, like this: https://bpaste.net/YGFA
<Vinalon>
by the way, I noticed that Migen has 'readthedocs'-style manual; does nMigen have a way to generate that sort of thing?
<Vinalon>
I ask because the comments for each class are excellent, and they seem to be formatted for it
<Vinalon>
If it doesn't, Sphinx seems to do an okay job for an automated tool; I ran `sphinx-apidoc -F -o docs nmigen` from the repository root
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 264 seconds]
Vinalon has joined #nmigen
<Vinalon>
Well, something like this seems to work okay, if anyone was curious. I'm sure there's a better way to iterate over the addresses, but: https://bpaste.net/LIGA
<Vinalon>
It doesn't account for registers whose functionality can change at runtime, but it's a start
david-sawatzke[m has quit [Ping timeout: 240 seconds]
david-sawatzke[m has joined #nmigen
<whitequark>
Vinalon: there are plans to use sphinx but they aren't currently implemented
<Sarayan>
for documentation?
<whitequark>
yeah
<Sarayan>
yeah, sphinx is nice
<Vinalon>
cool - it seems to generate decent html docs without any changes, but I guess you'd probably want to prune some files like 'test/...' and stuff like that
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 240 seconds]
Vinalon has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
Vinalon has joined #nmigen
XgFgX is now known as XgF
rohitksingh has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
<Degi>
How could I implement something like a SR flip flop (preferably one that resets on rising or falling edge of a clock signal)? Can I just use m.If() statements to set a signal to 1 and 0 for that?
<whitequark>
you can't do that in nMigen
<whitequark>
not only that, but you can't do that in vendor-independent synthesizable Verilog, either!
<whitequark>
(you can express it--sort of--but it's likely to trigger synthesis bugs, and even if it doesn't, timing analysis will not work well on that input)
<Degi>
Hm okay. Then I'll probably implement it in discrete logic I think
<whitequark>
that won't work either
<whitequark>
LUTs aren't glitchless, i.e. their outputs can toggle a few times before they settle on the final value corresponding to their truth table
<whitequark>
this wreaks havoc on logic loops like yours, but doesn't matter for synchronous logic, and toolchains that target synchronous logic (which is to say, almost all modern toolchains, including nMigen and Yosys) happily ignore that issue
<Degi>
Hm I meant discrete logic ICs. I think that might be practical for other reasons too. But good to know that LUTs do that sometimes