[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 #19 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to tpearson from comment #17)

> OK, so as I understand things you'll pull the bits you want for now, and
> when that's done I'll go back and verify the overall clock trees etc. for
> DRAM?

no, i said no: [EDIT: no, i have to get on with the linux bring-up]

as in: i was going to, then decided against it.

> There's one rather obvious option that hasn't been applied here either --
> what about simply paramaterizing the DRAM clock names at module
> instantation?

this is precisely what DomainRenamer is designed exactly not to
need you to have to do.  everything can be added to one domain
(e.g. sync) followed by, at instantiation time, the *renaming*
of that domain to another domain, as the *instantiator* sees fit.

this is why we have this:

    drs = DomainRenamer{'sync': 'dramsync'}
    self.ddrphy = drs(ECP5DDRPHY(ddr_pins, sys_clk_freq=clk_freq))

what that is doing is taking absolutely everything that is
    "m.d.sync +="
and dropping it instead into:
    "m.d.dramsync"

and the only reason everything works at the moment is because, back
in ECP5CRG, this is done:

    "m.d.comb += ClockSignal("dramsync").eq(ClockSignal("sync"))


DomainRenamer() is what makes the global/search/replace "m.d.sync"
with "m.d.memory" (or anything else) completely redundant.

it can be done, instead, with:

    drs = DomainRenamer({"sync": "memory"})


>  That's basically what I am doing for the WBASyncBridge clock
> domain connections.

that's different, that's at the level that's controlling the renames.

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