[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 #18 from tpearson at raptorengineering.com ---
So, backing up to try to de-muddy the waters a bit...

The ECP5 DDR3 controllers require very specific -- and *board-specific* --
clock and reset wiring between various hard IP blocks to function.  If this
wiring is wrong, *best case* you'll get an unroutable design, worst case you'll
get a conditionally stable design that will never work properly for *every*
boot, but will work for some boots.

As an example, here's the Arctic Tern clock wiring.  It's even more complex and
yes it's absolutely mandatory to have it wired that way for *that specific DRAM
configuration* on the board (the Lattice VIP board requires similar clock
trees):

https://github.com/litex-hub/litex-boards/blob/5aab6f01b6d2044cb698e936bff11491f0d52584/litex_boards/targets/rcs_arctic_tern_bmc_card.py#L68

Normally, since the number of global clock routes is very small (IIRC 8 or less
on ECP5), the design would use the slowest clock (a.k.a. "dramsync") that the
board-specific wiring of the DDR3 hard IP generates, thus saving a single
global clock route and avoiding async bridges entirely.

However, I think the fact that we have an async bridge available affords us the
opportunity to move the DDR3 clock generator into its own board-specific module
that is then wired up to the DDR3 controller, similar to how specific RAM
devices are also "paramaterized" via modules.  The caveat is that once that's
done *there is no going back* -- *everything* talking to DDR3 must always go
through the bridge, since it's purposefully been moved off the main synchronous
clock domain.

I can do the changes, but need to know if the above makes sense and you're OK
with the general design.

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