[libre-riscv-dev] [Bug 155] a PLL is needed for the SoC

[libre-riscv-dev] [Bug 155] a PLL is needed for the SoC

[bugzilla-daemon]

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

--- Comment #13 from Dimitri Galayko <dimitri.galayko@lip6.fr> ---
Dear all, I'm following the discussion by mail with Luke. There is a need to
create a "open-source" and generic PLL with the following specifications: 

Technology: TSMC 180 nm
Input: 24 MHz XTAL
Output Frequency: ~300 MHz (~x12), with fractional intermediate frequencies x2,
x3, x4, x5, x6. A double of the frequency needs to be generated, in order to
have a 300 MHz well-balanced 1 and 0 phases. 

Goal : to include to October tape-out
Power: TBD -- the whole chip is expected to consume 3 watts 
Jitter specifications : TBD 

I believe that an all-digital PLL can be a good first approach, if the design
needs to be “generic”. The most critical and difficult block is the digitally
controlled oscillator, which defines greatly the performances of the whole. 

We have a multiple experience of design of all-digital PLLs, whose basic blocks
(mainly DCO and phase detector) have been inspired from the work (done in 65 nm
CMOS)
**Tierno, Jose A., Alexander V. Rylyakov, and Daniel J. Friedman. "A wide power
supply range, wide tuning range, all static CMOS all digital PLL in 65 nm SOI."
IEEE Journal of Solid-State Circuits 43.1 (2008): 42-51. **
A detailed report on what have been done in my team is available in the PhD
report (in english, available on the web)
**Shan, Chuan. Générateur distribué d'horloge pour puces globalement et
localement synchrones de grande taille. Diss. Paris 6, 2014.** 

The advantage of this approach is a compatibility with the digital design flow,
all blocks belong to the digital electronics (even if some of them require a
custom sizing). I believe that this is well suitable for the goal of a
“generic” design flow. After that, it is possible that the performances will
not be satisfactory in 180 nm (mainly the power consumption), I have some idea
about possible alternative. 

My first simulations in a 180 nm technology (not TSMC, but equivalent) shows
that a 8 bits DCO may ensure a 600 MHz output frequency for all corners with a
resolution able to provide a reasonably good jitter performance, with the power
consumption of ~5mW.  

So, regarding the specifications, the most important point determining the
overall architecture is : 
-- Jitter 
-- power consumption. 

Is there any idea about what is expected for these two specifications ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 155] a PLL is needed for the SoC

[bugzilla-daemon]

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

--- Comment #14 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Dimitri Galayko from comment #13)
> Dear all, I'm following the discussion by mail with Luke. There is a need to
> create a "open-source" and generic PLL with the following specifications: 
> 
> Technology: TSMC 180 nm
> Input: 24 MHz XTAL
> Output Frequency: ~300 MHz (~x12), with fractional intermediate frequencies
> x2, x3, x4, x5, x6.

as taps, this would be very helpful, so as to be able to do further
counter-dividers to create a wide frequency range for peripherals.

> A double of the frequency needs to be generated, in
> order to have a 300 MHz well-balanced 1 and 0 phases. 

interesting.  600mhz in 180nm.

> My first simulations in a 180 nm technology (not TSMC, but equivalent) shows
> that a 8 bits DCO may ensure a 600 MHz output frequency for all corners with
> a resolution able to provide a reasonably good jitter performance, with the
> power consumption of ~5mW.  

this sounds perfectly reasonable.

> So, regarding the specifications, the most important point determining the
> overall architecture is : 
> -- Jitter 
> -- power consumption. 
> 
> Is there any idea about what is expected for these two specifications ?

5mW is perfectly acceptable.  we do not have enough experience to say if jitter
is an issue, and for this first chip, being a noncritical test chip, if it is
unstable due to jitter we simply run tests at a slower speed, incrementally,
until it is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 155] a PLL is needed for the SoC

[bugzilla-daemon]

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

--- Comment #15 from Staf Verhaegen <staf@fibraservi.eu> ---
> Input: 24 MHz XTAL

AFAIK there is no crystal oscillator IP available for this project so I assumed
the input clock would be CMOS.

> So, regarding the specifications, the most important point determining the
> overall architecture is : 
> -- Jitter 

For a digital circuit jitter of the clock eats in the timing budget, the 
critical has to be fast enough to have result for the smallest clock cycle due
to jitter.
Analog/mixed-signal blocks will have their requirement on jitter, like
resolution/bandwidth for an ADC or error rate for SERDES.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 155] a PLL is needed for the SoC

[bugzilla-daemon]

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

--- Comment #16 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Staf Verhaegen from comment #15)
> > Input: 24 MHz XTAL
> 
> AFAIK there is no crystal oscillator IP available for this project so I
> assumed the input clock would be CMOS.

if we do not have all the pieces, yes we will use a CMOS external clock, this
is the fallback.

Professor Galyco, i may not have made it clear: we are not signing any NDAs and
so need *everything* from scratch that would normally be provided by the
Foundry (under NDA).  thank you for raising this, Staf.

did the PLL that you developed also include a XTAL interface?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev