[Libre-soc-bugs] [Bug 806] Nest should be able to run at different clock rate than main CPU

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=806

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to tpearson from comment #5)
> Gotcha.
> 
> Bear in mind DRAM isn't the only peripheral that benefits from a clock boost
> -- for example Tercel has a maximum SPI speed of 1/2 the Wishbone bus clock,
> and the Flash devices we use on nearly all of the POWER products and many of
> the ECP5 boards can actually run at 100MHz SPI clock...

i know: the problem is that most wishbone peripherals are only WB 3 (classic)
compliant. you *cannot* connect WB 3 (classic) to WB 4 (pipeline, with stall)
together without doing the "stall=stb&~ack" trick.

unfortunately (i checked), the alex forencich async-wb-bridge is *WB 3*
compliant *only*.  no, burst-mode is *not* the same as "WB4 pipeline" mode.

neither is GRAM, or uart16550, or tercel, or in fact anything at all that
i've been able to find!!

not litex, not nmigen-soc (until i fixed it), nothing.  they're *all* WB 3
(classic) compliant (or in the case of nmigen-soc, broken until i fixed it)

paul designed microwatt i/d-cache to be WB 4.0 compliant pipelined.
that means you either *have* to connect it downstream to WB 4.0 compliant
(pipelined, w/stall) or you have to "fake" it with the stall=stb&~ack trick.

but, the other way round is *not* possible - WB3 classic master can *not* be
connected to WB 4.0 pipeline slave.  and unfortunately, the AsyncWBBridge
is WB3-classic-master to WB-classic-slave.

this is the root cause of the problems that you're seeing.

the "solution" is to move the AsyncWBBridge to directly in front of the
GRAM controller.

it will need to have a wb.Interface Record that does contain a "stall"
signal on the slave side, which is then "faked" just like the way that
drambone.bus.stall is currently faked:

 521  # grrr, same problem with drambone: not WB4-pipe compliant
 522  comb += drambone.bus.stall.eq(drambone.bus.cyc & ~drambone.bus.ack)

that then needs to be REMOVED because now the AsyncWBBridge (which is
WB 3 classic only) will be connected to *drambone* which is *also*
WB 3 classic only.

if you think of it in terms of putting ASyncWBBridge into the actual
gram controller itself (presenting the exact same interface), then
the ls2.py code does not change (at all) except for the clock domains.

(In reply to tpearson from comment #6)

> I still want us to stop thinking of the CPU and fabric all running at the
> same clock speed -- any real-world ASIC will not have that "feature"...

i know.  however that will require AsyncWBBridge to be upgraded to
add "stall" signalling, because of above: once something drops down
to WB 3 classic you cannot go back "up" to WB 4 pipeline mode.

to use AsyncWBBridge as it stands, it would be necessary to propagate
the "stall=stb&~ack" trick right the way up to I-Cache and D-Cache,
instantly halving transfer speeds.

> I can move the arbiter after the downconverters, but I'll probably end up
> creating a couple of different peripheral clock domains because both Tercel
> and the DRAM controller can use the higher clock speeds for higher bandwidth.

tercel will need its own separate ASyncWBBridge for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.