<_whitenotifier>
[nmigen] RobertBaruch commented on issue #260: Simple memory doesn't seem to work with a simple Cover statement? - https://git.io/JeuTA
<_whitenotifier>
[nmigen] RobertBaruch closed issue #260: Simple memory doesn't seem to work with a simple Cover statement? - https://git.io/JeuTH
proteusguy has quit [Quit: Leaving]
proteusguy has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
Getorix has joined #m-labs
harryho has joined #m-labs
<_whitenotifier>
[nmigen] RobertBaruch opened issue #261: Const Record value? - https://git.io/JeuI4
<_whitenotifier>
[nmigen] whitequark commented on issue #261: Const Record value? - https://git.io/JeuIE
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #261: Const Record value? - https://git.io/JeuIH
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #261: Const Record value? - https://git.io/JeuIb
<mtrbot-ml>
[mattermost] <harryho> @astro Hi, do you still need my help to reset?
<_whitenotifier>
[nmigen] whitequark commented on issue #261: Const Record value? - https://git.io/JeuIN
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #261: Const Record value? - https://git.io/JeuIp
<_whitenotifier>
[nmigen] whitequark commented on issue #261: Const Record value? - https://git.io/JeuIj
<_whitenotifier>
[nmigen] whitequark commented on issue #261: Const Record value? - https://git.io/JeuLT
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #261: Const Record value? - https://git.io/JeuLL
<_whitenotifier>
[nmigen] whitequark commented on issue #261: Const Record value? - https://git.io/JeuLq
<harryho>
whitequark: Thanks a lot for the latest code on nmigen-soc! For MemoryMap.Decoder::decode_address(), I wonder if one useful usage would be interconnecting the CPU bus with a WB bus?
<whitequark>
harryho: the entire MemoryMap exists for the benefit of CPUs addressing peripherals
<whitequark>
decode_address' primary purpose is debugging, I think
<whitequark>
at least, I am not sure where someone would often use it, since most of the time, you want to "pre-generate" accessors and such
<harryho>
Could you explain what you mean by pre-generating accessors?
attie has joined #m-labs
<whitequark>
you define peripherals inside nMigen, and e.g. if you're using C in your SoC, you generate header files that have things like "#define UART_BASE 0x40001000; #define UART_REG_DATA 0x0001; #define UART_REG_CONTROL 0x0002; UART_BIT_CONTROL_RTSCTS 0b1" and so on
<whitequark>
(just an artificial example, the real headers would be much less crude)
<whitequark>
this means using MemoryMap.all_resources()
<whitequark>
.find_resource() and .decode_address() are provided mainly for completeness
<whitequark>
but of course I am sure someone will have an use case that needs them
<whitequark>
harryho: btw, could you help me out with the Wishbone stuff? there are three main things left. first, as you can see in Decoder, I added some code to match bus granularity. however, if I were to add Arbiter too, that code would be duplicated there, which is inefficient and hard to test.
attie has quit [Ping timeout: 240 seconds]
<whitequark>
it would be good to split Decoder (in current master) into Decoder + Adapter, where Decoder would do something much simpler (and you could use Direction to connect everything with less code than now, too), and Adapter would do the granularity conversion stuff
<whitequark>
in the future (and if someone is interested in pipelined Wishbone), Adapter should also take care of STALL, see Wishbone B4 5.1 and 5.2.1
<whitequark>
second, it would be more elegant if MemoryMap itself stored both the *bus* placed at some memory address (the physical representation; CSRElement, WishboneInterface, and so on), and the *target* (the logical representation; CSRRegister, MemoryMap, and so on)
<whitequark>
a good way to do this would be to add two more dicts like `self._window_buses` and then yield them from `resources` and `windows` together with `resource` and `window`
<whitequark>
third, after that, adding Arbiter would be nice, too
<harryho>
What about implementing round robin scheduling for the CPU to read data from peripherals? Related to the Arbiter+Decoder you're talking about?
<whitequark>
right, so I was thinking that could be made a bit more generic
<whitequark>
first, instead of waiting until the request clears to proceed inside RoundRobin, Arbiter could simply use EnableInserter to disable the scheduler when it's not needed
<whitequark>
second, we could define an interface for schedulers, where Arbiter.add would accept a **kwargs argument and pass it to the scheduler, along with the request (in this case, cyc) signal, so that you could do something like
<whitequark>
in this case, it's harder to have request and grant signals in the scheduler depend on the connection count, since you don't know it in the constructor
<whitequark>
so the scheduler interface could be something like `grant = scheduler.add(request, **options)`, accepting and returning a 1-bit signal the scheduler would book-keep internally
<whitequark>
and we could place them e.g. in nmigen_soc.scheduler to make it reusabel.
<harryho>
I see. In your mind, what should the priority be? DSL, improving MemoryMap, Adapter, adopting features in WB B4 but not B3, Arbiter, Scheduler...
<whitequark>
improving MemoryMap is more or less necessary for merging the DSL
<whitequark>
WB B4 is probably not important since as rjo says WB is essentially a legacy bus, if we get the bare minimum of it to work, great
<whitequark>
so let's just not bother with B4, only keep in mind that features from it exists (e.g. handle existence of STALL but don't try to do anything clever about it)
<whitequark>
Adapter, Arbiter and Scheduler are important for many real-world applications, and not much work anyway
<harryho>
OK
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<rjo>
whitequark: is there anybody implementing/using WB B4 bursts in Migen/MiSoC?
<whitequark>
rjo: AFAICT no part of MiSoC was written with WB B4 in mind at all
<whitequark>
no traces of stall
<whitequark>
I actually wrote the relevant B4 adapter code (classic to pipelined and vice versa) and then stashed it before adding any tests since it seemed like it might just rot.
<whitequark>
also, their suggestion in 5.1 doesn't handle abnormal cycle termination and it's not obvious how that should happen
<ZirconiumX>
whitequark / rjo: hope you don't mind me asking for the sake of learning, but what makes WB "legacy" in this context? Is it fundamentally outdated, or unmaintained or something?
<whitequark>
sb000: they implement port priority that way
<whitequark>
by serializing writes
<whitequark>
well, not just port priority, they implement two ports with one that way
<whitequark>
but as a side effect, writes to the same cell always have a defined outcome, defined by priority.
X-Scale has joined #m-labs
Stormwind_mobile has joined #m-labs
<rjo>
ZirconiumX: from what I can see, axi/axilite/axistream/amba/custom is just more fashionable nowadays. there is a lot of overlap between the core functionality of WB and axilite though so transitioning is not that complicated. and WB was always this opencores thing (or "silicore" apparently) that xilinx/altera didn't really embrace that much
<whitequark>
it's also just not very good
<whitequark>
the specification is pointlessly verbose and at the same time omits many details you'd rather see defined
<whitequark>
axistream is much more elegant than using wishbone in most cases as well
<ZirconiumX>
Okay, thank you
<ZirconiumX>
I'll have to study the AXI Lite spec then.
Stormwind_mobile has quit [Ping timeout: 250 seconds]
Stormwind_mobile has joined #m-labs
sb000 has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 265 seconds]
Stormwind_mobile has quit [Ping timeout: 240 seconds]
X-Scale has joined #m-labs
Stormwind_mobile has joined #m-labs
attie has quit [Ping timeout: 265 seconds]
attie has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 250 seconds]
Stormwind_mobile has joined #m-labs
lkcl has joined #m-labs
Getorix has quit [Ping timeout: 265 seconds]
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
attie has quit [Ping timeout: 276 seconds]
mumptai has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 245 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #m-labs
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
mumptai has quit [Quit: Verlassend]
<Astro-_>
@sb10q @harryho I need that zc706 reset. there is still the issue that there is no nSRST signal.
<Astro-_>
with the cora z7 I usually press the button labeled nSRST in this situation :)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
lkcl has quit [Ping timeout: 252 seconds]
<mtrbot-ml>
[mattermost] <harryho> @astro I'll check when I come back, by 9.30am hkt
Stormwind_mobile has quit [Remote host closed the connection]
<zignig>
I am having issues getting 2 clock domains working in nmigen, i'm getting the clk16 request twice and I'm not sure what is going wrong.
<zignig>
on a similar note, If the Max clock for a design is not fast enought (48Mhz for USB in this case) , is there a way to find _which_ part of the design is causing the slowness ?
<whitequark>
zignig: you're assigning a domain called "slow" to m.domains.sync. because of the current design, the name "slow" takes priority, and the rest of nmigen acts as if there's no "sync".
<whitequark>
i'll fix that later
<whitequark>
but you need to actually call the domain "sync"