[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 #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Staf Verhaegen from comment #21)
> A little over a week ago me, Dimitri and Marie-Minerve from LIP6 had a call
> to discuss the PLL design for the Libre-SoC. We propose to only use power of
> two for the division in the PLL so just flip-flops can be used for it. See
> also https://en.wikipedia.org/wiki/Frequency_divider This is what we propose
> for the pin-out o the PLL:
> 
> * The refclk signal is the external clock signal.
> * One external signal vcodiv that selects between having the VCO oscillating
> at 16x or 8x the reference clock.
> * Two signals clksel to select between four signals to use for the SoC
> clock: the reference clock (e.g. bypass PLL), VCO/2, VCO/4 and VCO/8.
> * One external digital output VCOd16 that is VCO/16
> * One analog output, likely the voltage for VCO.
> * Current design has not lock signal, Dimitri will see if he can provide
> that. If so it will also be an external digital output.

if this can actually be the actual pinouts of the PLL rather than part of
the nmigen-based digital core, great.

we will be trusting that the PLL bypass is functional.


> Dimitri will see if he can tune the PLL so there is a factor of two between
> the maximum and minimum oscillation frequency of the VCO. This way one could
> in theory reach any clock frequency for the SoC between fVCOmax/2 and
> fVCOmin/8 by playing with frequency of reference clock and the clock
> division.

this would be great.

i am going to create a "fake" (dummy) PLL which can be replaced by you (Staf)
or you (Jean-Paul) at the verilog / gate / layout level.

the "fake" PLL passes through the external reference clock directly to the
PLL output so as to provide a means to test... something.

i will be absolutely honest and say that, after the warnings about clock
trees that you gave, Staf, i would greatly prefer that the core not be linked
to the PLL at all (a stand-alone test unit).

however that would leave us without an opportunity to try testing the layout at
higher frequencies.


i'm therefore willing to take that risk if Jean-Paul is happy with the
implications, which i assume would be as follows:

* that the external clock would *ONLY* go to the PLL (not as a Clock Tree)
* that the PLL *output* is done as a Clock (H) Tree.

if this is correct then the PLL should be positioned right next to where the
external clock comes in.

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