[Libre-soc-bugs] [Bug 155] a PLL is needed for the SoC

[bugzilla-daemon at libre-soc.org]

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

--- Comment #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Staf Verhaegen from comment #19)
> (In reply to Luke Kenneth Casson Leighton from comment #18)
> > this is what i propose:
> > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/clock/select.py;hb=HEAD
> 
> I think you generate a circular dependency here. 

i do not believe so (happy to be shown otherwise).  bear in mind:  "sync"
domain is intended to be the 300mhz PLL and would be set up externally
as:

     m.submodule.csel = DomainRenamer("pll300mhzdomain")(ClockSelect())

externally it becomes the responsibility of the parent not to screw up
by e.g. creating an external circular dependency.

* the clk_sel_i wires are intended to go *DIRECTLY* out on to ASIC pins.
  not even set by anything, not in any chip memory - nothing:  i mean
  DIRECTLY out.

* likewise pll_48_o is intended to be put directly out of the ASIC onto
  a pin.

* likewise clk_24_i is intended to be a direct input onto a pin, for connecting
  to a 24 mhz digital clock.


> You should not have the
> configuration register be synchronous to the clock that is generated by this
> PLL.


these are combinatorially set:

        comb += clkgen[SYS_CLK].eq(self.clk_24_i) # 1st is external 24mhz
        comb += clkgen[ZERO].eq(0) # LOW (use with ONE for direct driving)
        comb += clkgen[ONE].eq(1) # HI

in the 300mhz PLL sync domain,counter and clkgen are only set from either
clkgen or counter, example:

        sync += clkgen[PLL2].eq(~clkgen[PLL2]) # half PLL rate

and finally the outputs are set combinatorially, from clkgen:

        comb += self.core_clk_o.eq(clkgen[self.clk_sel_i])

what _is_ a problem though is that if clk_sel_i is set in the middle of
any given clock-pulse you will get one weird spike (uneven rising time
vs falling time).

as a test chip i am not going to worry about that.


> > thoughts?
> 
> It was always in the plan (in my head) to be able to bypass the PLL.

ah ok, likewise, i didn't vocalise it :)

> Other
> configuration options I would not specify as hard specs but let it come from
> the  PLL design. Only supporting power of two clock division is most natural
> as it allows to use just only flipflops for it, otherwise extra logic needs
> to be inserted in the PLL feedback loop.

this isn't intended for association - in any way - with the actual PLL.
it's specifically not intended for connection back to - or any feedback
of any kind - to the actual PLL.

i anticipate (expect) that the PLL would generate one frequency and
one frequency only: a stable 300 mhz output and no other frequency.
(give-or-take a bit: actually 12x 24mhz).

now, if the *PLL* has feedback to create that stable 300mhz clock, great.
and if there happen to be stable "taps" off of the internal digital divider
inside the PLL, that's really great, it will save having to do flip-flops.


> Also the division of the clock could also be made programmable through JTAG
> so no extra pins are needed.

mmmm... i like the principle: it does make me nervous connecting unknown
blocks together though.  simple as it is, if the JTAG HDL goes wrong,
we can't test the PLL.

*reading* from the PLL (having some sort of JTAG-readable counters that
trigger from different taps on the PLL) that's a different matter.

or even just "a counter" then set the external clock source (from the
3 clk_sel_i pins), read that on JTAG and if it goes faster @ 300mhz than
when clk_sel_i is set to 300 rather than 48mhz, you know the PLL's good.


> I don't think this has to be frozen at the moment for the current design
> delivery as that does not include the PLL yet. We should have a meeting
> somewhere mid October to finalize the package and pin allocation.

ok.  answer under different bugreport.
https://bugs.libre-soc.org/show_bug.cgi?id=508

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