Dual-frequency quartz oscillator with a FPGA ?
whygee
this is with great emotion that I am designing my first FPGA board.
However, the clock frequency that I desire is only available as
a discrete quartz, not oscillator (and integrated oscillators are more expensive).
And I don't find a dedicated quartz input in the chips I use
(the eval boards all use integrated oscillators).
There is no way I can use the PLL to get the desired frequencies
because the ratio is quite complex and would result in unacceptable drift
(not that it matters now but it's better to do things correctly
from the beginning, and now is the best time since it's a first draft).
So I have to make a quartz oscillator circuit and it would use the
FPGA I/Os. To the best of my knowledge, this is a "simple inverting gate"
with 18pF capacitors to the ground and a series resistor (1K Ohm)
that limits the current in the quartz (I have seen other values as well).
I could use an external single not gate to reduce the chance of
parasitic pickup but I would like to keep the circuit simple now
and drift is more annoying than jitter, since a PLL will generate
higher frequencies and this will be filtered.
In VHDL this amounts to something like
OSC_out <= not( OSC_in ) and OSC_EN;
PLL_in <= OSC_in;
* OSC_out would be in low drive configuration (like 2mA)
with a series resistor.
* OSC_in would be tied to a pin that connects directly to the PLL
and/or the internal clock network.
I also need to select one quartz among 2 as a source for the
base clock. I would like to connect the 2 quartz with a common OSC_in pin,
while each quartz has a dedicated OSC_outX pin.
This is the simplest idea I can find, with a relatively benign
transition mechanism : only the transition signal has to be
synchronised (a couple of D latches), instead of having 2 separate
clocks that must run simultaneously.
It also avoids a 4-register "glitch-free switch"
(see http://www.design-reuse.com/articles/5827/techniques-to-make-clock-switching-glitchfree.html )
and the transition does not create a dramatic phase change.
I even wonder what would happen if the 2 quartz are
temporarily used in parallel (so the new quartz will start up a few
cycles before transition). Note that frequency changes should
not occur often and the frequencies are only 10% apart.
OSC_out1 <= not( OSC_in ) if ( OSC_en1 == '1' ) else 'Z'
OSC_out2 <= not( OSC_in ) if ( OSC_en2 == '1' ) else 'Z'
===> OSC_en1 and OSC_en2 could overlap during a few cycles
Did I miss something ? Do I forget any trap with quartz oscillators
and FPGAs ? Does the routing in the FPGA fabric play a big role
(considering a frequency in the 10MHz range) ? How can I be sure
that the oscillator will start up and switch correctly ?
How many cycles should the frequency overlap last ?
Is there a better method ?
Has anybody done this, and what are the results ?
Thank you for sharing your thoughts,
yg
Antti....@googlemail.com
> and the transition does not create a dramatic phase change.
> I even wonder what would happen if the 2 quartz are
> temporarily used in parallel (so the new quartz will start up a few
> cycles before transition). Note that frequency changes should
> not occur often and the frequencies are only 10% apart.
>
> OSC_out1 <= not( OSC_in ) if ( OSC_en1 == '1' ) else 'Z'
> OSC_out2 <= not( OSC_in ) if ( OSC_en2 == '1' ) else 'Z'
>
> ===> OSC_en1 and OSC_en2 could overlap during a few cycles
>
> Did I miss something ? Do I forget any trap with quartz oscillators
> and FPGAs ? Does the routing in the FPGA fabric play a big role
> (considering a frequency in the 10MHz range) ? How can I be sure
> that the oscillator will start up and switch correctly ?
> How many cycles should the frequency overlap last ?
> Is there a better method ?
> Has anybody done this, and what are the results ?
>
> Thank you for sharing your thoughts,
> yg
>
> --http://ygdes.com/http://yasep.org
I have tried chrystal drive with Xilinx spartan-3A, and failed - it
did not work reliable
- if you look at msgs here, then Xilinx is keep saying it is NOT
DOABLE..
OTOH Lattice say they do this XP devices
so please test the circuit that it really works as reliable as needed
the xilinx oscillator had startup problems, and I never got it
starting
reliable with correct frequency
Antti
Peter Alfke
> and the transition does not create a dramatic phase change.
> I even wonder what would happen if the 2 quartz are
> temporarily used in parallel (so the new quartz will start up a few
> cycles before transition). Note that frequency changes should
> not occur often and the frequencies are only 10% apart.
>
> OSC_out1 <= not( OSC_in ) if ( OSC_en1 == '1' ) else 'Z'
> OSC_out2 <= not( OSC_in ) if ( OSC_en2 == '1' ) else 'Z'
>
> ===> OSC_en1 and OSC_en2 could overlap during a few cycles
>
> Did I miss something ? Do I forget any trap with quartz oscillators
> and FPGAs ? Does the routing in the FPGA fabric play a big role
> (considering a frequency in the 10MHz range) ? How can I be sure
> that the oscillator will start up and switch correctly ?
> How many cycles should the frequency overlap last ?
> Is there a better method ?
> Has anybody done this, and what are the results ?
>
> Thank you for sharing your thoughts,
> yg
>
> --http://ygdes.com/http://yasep.org
To build a reliable xtal oscillator, you need a single-stage inverting
amplifier with moderate gain and moderate roll-off (phase response) at
high frequency.
Using an FPGA input + output loop, you get a multi-stage amplifier
with enormous gain, poor phase response, plus hysteresis.
That does not give you an oscillator that starts reliably under all
circumstances.
Buy a canned oscillator, manufactured by people who know this
business.
Last time we at Xilinx offered a specialized single-stage oscillator-
amplifier was in the XC3000 family, 20 years ago. And it still gave us
headaches under extreme conditions ( 32 kHz, high temp, low temp, etc)
Peter Alfke
Peter Alfke
Antti....@googlemail.com
>
> - Show quoted text -
Peter
the issue is that canned oscillators are not available for all
frequencies,
and sometimes the on chip clock can not be used to generate the
required frequency.
I assume the OP is targetting Actel FPGA not Xilinx part. Well the
basics still apply
so I would also suggest canned oscillator, and
actel PLL can work in frequency dither mode where user circuitry is
connected into
feedback loop, this allows pretty much any frequency to be generated
and switched
on the fly as well
actel app note is for proasic, but it would work on pa3 as well, but a
pin to pin
loopback wire is required because of clock routing restrictions
similar technic was also used by Ken Chapman for S3E, again there is
no
ready made solution for S3A, but after some experiments i have
succeeded
with S3A also. S6 has PLL already... but i think OP needs solution now
and not 2011
Antti
Antti....@googlemail.com
> and the transition does not create a dramatic phase change.
> I even wonder what would happen if the 2 quartz are
> temporarily used in parallel (so the new quartz will start up a few
> cycles before transition). Note that frequency changes should
> not occur often and the frequencies are only 10% apart.
>
> OSC_out1 <= not( OSC_in ) if ( OSC_en1 == '1' ) else 'Z'
> OSC_out2 <= not( OSC_in ) if ( OSC_en2 == '1' ) else 'Z'
>
> ===> OSC_en1 and OSC_en2 could overlap during a few cycles
>
> Did I miss something ? Do I forget any trap with quartz oscillators
> and FPGAs ? Does the routing in the FPGA fabric play a big role
> (considering a frequency in the 10MHz range) ? How can I be sure
> that the oscillator will start up and switch correctly ?
> How many cycles should the frequency overlap last ?
> Is there a better method ?
> Has anybody done this, and what are the results ?
>
> Thank you for sharing your thoughts,
> yg
>
> --http://ygdes.com/http://yasep.org
actel Fusion has crhystal osc support, but only for one chrystal
Antti
-jg
> Did I miss something ? Do I forget any trap with quartz oscillators
> and FPGAs ? Does the routing in the FPGA fabric play a big role
> (considering a frequency in the 10MHz range) ? How can I be sure
> that the oscillator will start up and switch correctly ?
> How many cycles should the frequency overlap last ?
> Is there a better method ?
> Has anybody done this, and what are the results ?
As others have said, unreliable and risky.,
If you want Xtal operation, use something like TinyLogic 74LVC1GX04
crystal oscillator
or, use 74LVC2GU04
Oscillators have a startup time, so you may prefer to run them all the
time, and
switch inside the FPGA.
-jg
Andrew Holme
"whygee" <why...@yg.yg> wrote in message
news:49e90f52$0$21740$7a62...@news.club-internet.fr...
What exact frequencies do you need?
Canned oscillators are made to order by several crystal vendors.
Or, use external single unbuffered CMOS inverter gates e.g. SN74AHC1GU04.
You forgot to mention the feedback resistor which biases the gate into its
linear region. This works best with a single gate, not multiple stages as
you would inevitably have going on and off an FPGA. There's too much gain.
It just can't hold them all at 0.5*VDD. Even if it starts, it may not
oscillate on the crystal frequency!
You did mention the series current limiting resistor, which is a good idea
BTW and 1k is a good ballpark value for this. The feedback resistor can be
220k - 1M. The capacitors are chosen to suit the crystal.
whygee
Antti....@googlemail.com wrote:
> actel Fusion has crhystal osc support, but only for one chrystal
The fusion osc is meant for a 32768Hz Xtal, not the 10MHz range
(I should check though) and I target the A3P125-250 type
(that's much cheaper... and i'll look at the analog stuff later)
> Antti
whygee
Here are some other answers that overlap with other posts.
-jg wrote:
> As others have said, unreliable and risky.,
I was not sure but Peter Alfke gave good arguments why.
I forgot about the gain/phase things...
I have also experienced a reverse situation with a PIC,
which did not work with a canned oscillator, but everything
was fine with a cristal... I still wonder why.
> If you want Xtal operation, use something like TinyLogic 74LVC1GX04
> crystal oscillator or, use 74LVC2GU04
I'm checking this too.
I've also found a working example's schematic using a couple of 74HC14 gates,
two 1M resistors and the usual couple of capacitors...
and I wonder again why a couple of FPGA pins wouldn't work :-/
> Oscillators have a startup time,
I know that this time depends on the capacitors too.
> so you may prefer to run them all the
> time, and switch inside the FPGA.
This means continuous power draw...
even a few mA can matter, not for the proto but in the end... :-/
I'll probably switch to the Igloo family later, too.
It looks like i'll have to choose one fixed frequency
and give up the others, or i'll have to end up with 3 or 4
Xtal operating simultaneously...
Fortunately, FPGAs have integrated PLLs today.
> -jg
John Adair
crystals. If you are worried about the power why not control the
oscillator power with a mosfet and simply turn it off when not in use.
There a lot of the newer MEMS oscillators that don't use mush power
and are physically very small. Spot the 25MHz MEMs oscillator on here
http://www.enterpoint.co.uk/component_replacements/craignell2.html and
that's not the smallest one we are using.
John Adair
Enterpoint Ltd.
whygee
John Adair wrote:
> On cost the new MEMS oscillators very often compete well with crystals.
MEMS oscillators are not as widely available as quartz :-/
> If you are worried about the power why not control the
> oscillator power with a mosfet and simply turn it off when not in use.
In fact i'll keep it constantly on,
and the PLL will derive other / higher frequencies.
for the rest of the system.
> There a lot of the newer MEMS oscillators that don't use mush power
> and are physically very small. Spot the 25MHz MEMs oscillator on here
> http://www.enterpoint.co.uk/component_replacements/craignell2.html and
> that's not the smallest one we are using.
Nice board. My issue though is : is your oscillator available
in 11.2896MHz frequency, and at what cost ? The solution I have
found costs around 0.6€ in small (10-100) quantities.
The can is a bit larger (H49 size) than today's miniature
standards but it's not an issue here.
> John Adair
> Enterpoint Ltd.
David Spencer
> in 11.2896MHz frequency, and at what cost ? The solution I have
> found costs around 0.6€ in small (10-100) quantities.
> The can is a bit larger (H49 size) than today's miniature
> standards but it's not an issue here.
It took me less than 30 seconds on the web to find an oscillator at that
frequency:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ASML-11.2896MHZ-ET-ND
whygee
David Spencer wrote:
> It took me less than 30 seconds on the web to find an oscillator at that frequency:
> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ASML-11.2896MHZ-ET-ND
thank you.
However, I see 2 things :
- no stock available
- quantity by 1000 which is not "prototype-friendly"
Ok, I know, this can change and I can look elsewhere etc.
I think that i'll quit this thread here since
my initial question has been answered previously,
and it's now an uninteresting matter of component sourcing...
regards,
gabor
wrote:
If you want MEMS, go to the Ecliptek page
Here's one with factory stock:
http://www.ecliptek.com/stocksearch/Stock.aspx?Partnumber=EMK33G2H-11.2896M
I've used the 2 x 2.5mm (smallest) version of these and they
work very well and have better vibration tolerance than most
crystal oscillators.
Regards,
Gabor
Brian Drummond
>Hello,
>
>John Adair wrote:
>> On cost the new MEMS oscillators very often compete well with crystals.
>MEMS oscillators are not as widely available as quartz :-/
>Nice board. My issue though is : is your oscillator available
>in 11.2896MHz frequency, and at what cost ?
Heh, thought as much.
The other crystal is 12.288MHz then.
- Brian
-jg
> I've also found a working example's schematic using a couple of 74HC14 gates,
> two 1M resistors and the usual couple of capacitors...
> and I wonder again why a couple of FPGA pins wouldn't work :-/
You can certainly make a FPGA oscillate.
The problem is getting reliable, desired frequency output!.
A common issue with such circuits is 'edge fur' which is high speed
transistion oscillations, near the logic thresholds. Sometimes not
directly visible on a scope, but will show up as double-clocking.
> > so you may prefer to run them all the
> > time, and switch inside the FPGA.
>
> This means continuous power draw...
> even a few mA can matter, not for the proto but in the end... :-/
> I'll probably switch to the Igloo family later, too.
>
> It looks like i'll have to choose one fixed frequency
> and give up the others, or i'll have to end up with 3 or 4
> Xtal operating simultaneously...
> Fortunately, FPGAs have integrated PLLs today.
The cheapest is obviously to use the PLL if you can, but if power
matters, then you also want to avoid a FPGA type oscillator, as they
do
not specify the transistion currents. (Icc vs Vi)
xxU04 gates are a mainstream part, and if you use one inverter as the
oscillator, and then cascade a couple more to square-up the edges, so
you are not driving
the FPGA with a sine-wave.
You then choose a logic family, and Vcc, to give the Icc you need.
10-12MHz is lowish, so you should be able to get lower Icc in a custom
design than from a Module.
You can supply the Vcc from a FPGA port pin, to enable
the oscillator (add a RC to adjust Icc )
-jg
whygee
Now if you have a smart idea about how to switch between them
without a glitch... Oh well, when i'll add a video output,
i'll need yet another oscillator with another frequency :-/
I'm waiting for ecliptek's answer about a sample request.
However, I wonder how i'll be able to solder it in
the first prototypes (i'm not at ease with the hot air gun yet).
I'll have to measure how much it consumes, too. So many questions...
> - Brian
whygee
> On Apr 18, 9:42 pm, whygee <why...@yg.yg> wrote:
>> I've also found a working example's schematic using a couple of 74HC14 gates,
>> two 1M resistors and the usual couple of capacitors...
>> and I wonder again why a couple of FPGA pins wouldn't work :-/
> You can certainly make a FPGA oscillate.
Oh well, what if I tried now and checked the different frequencies
that it can generate ? I'm feeling hacky now... The only limit is that
I have no frequency meter above 20MHz, which is well below what
is theoretically possible...
> The problem is getting reliable, desired frequency output!.
> A common issue with such circuits is 'edge fur' which is high speed
> transistion oscillations, near the logic thresholds. Sometimes not
> directly visible on a scope, but will show up as double-clocking.
I imagine that the pin capacitances will smooth it a bit ?
Oh, if I understand correctly, if it's too smooth,
it can create problems... But in FPGA-land, that should not
be impossible ?...
>> It looks like i'll have to choose one fixed frequency
>> and give up the others, or i'll have to end up with 3 or 4
>> Xtal operating simultaneously...
>> Fortunately, FPGAs have integrated PLLs today.
> The cheapest is obviously to use the PLL if you can, but if power
> matters, then you also want to avoid a FPGA type oscillator, as they
> do not specify the transistion currents. (Icc vs Vi)
An oscillator circuit that I have found uses a single
HC14 (schmitt trigger inverter) gate as oscillator.
The output goes to another digital input, as well as a 1M resistor,
whose other side is tied to a grounded capacitor (100pF), and
the crystal with a 1M resistor in parallel (both go to the HC14 input).
(sorry, i can't find the original location of the PDF)
With this system, the current that goes through 1M must be very small...
Also, concerning your previous point about spurious signals
("edge fur"), I see that the 1M + 100pF network is a low-pass
that should reduce the impact of the "fur"...
Unfortunately, the Actel chips I currently use don't have Schmitt triggers.
However, the latest / newest Actel chips have, including some Igloo,
so the idea may resurface later in the design/development, so I can fall back to
"traditional" methods now. I'll be careful to select ST-capable parts later.
> xxU04 gates are a mainstream part, and if you use one inverter as the
> oscillator, and then cascade a couple more to square-up the edges, so
> you are not driving the FPGA with a sine-wave.
Shouldn't one inverter be enough to square the edges ?
As I re-looked at the 74LVC1GX04 (I had a few samples already)
I remarked that there are 3 inverter gates, this looks like
overkill to me...
> You then choose a logic family, and Vcc, to give the Icc you need.
> 10-12MHz is lowish,
it's on purpose.
> so you should be able to get lower Icc in a custom
> design than from a Module.
This shouldn't be too difficult to verify.
> You can supply the Vcc from a FPGA port pin, to enable
> the oscillator (add a RC to adjust Icc )
I would even use a LC network...
But what about the "enable" input of the canned oscillators ?
Normally, the osc's output is tristated so (taking into account
various capacitances) two oscs should be able to share a single
FPGA input pin (then 2 output pins control the enable pins)...
regards,
-jg
>
> Oh well, what if I tried now and checked the different frequencies
> that it can generate ? I'm feeling hacky now... The only limit is that
> I have no frequency meter above 20MHz, which is well below what
> is theoretically possible...
Set up some simple dividers and scope the outputs, and Freq count,
and look for phase jitter, and erratic jumps...
Don't try and look directly for the edge oscillations.
> I imagine that the pin capacitances will smooth it a bit ?
>
> Oh, if I understand correctly, if it's too smooth,
> it can create problems... But in FPGA-land, that should not
> be impossible ?...
In extreme cases, these transistion oscillations are VERY high, and
I've
seen them disturb UNRELATED logic, due to common mode inductive
effects.
Such things are outside the testing realms of the IC vendors :)
> An oscillator circuit that I have found uses a single
> HC14 (schmitt trigger inverter) gate as oscillator.
> The output goes to another digital input, as well as a 1M resistor,
> whose other side is tied to a grounded capacitor (100pF), and
> the crystal with a 1M resistor in parallel (both go to the HC14 input).
>
> (sorry, i can't find the original location of the PDF)
>
> With this system, the current that goes through 1M must be very small...
> Also, concerning your previous point about spurious signals
> ("edge fur"), I see that the 1M + 100pF network is a low-pass
> that should reduce the impact of the "fur"...
Ah, yes Schmitt-assisted oscillators shift the problem :)
They remove the 'fur' issue, but now you are never sure if the
Schmitt RC-fb, or the Xtal is locking. (unplug the Xtal, and they
usually still oscillate!)
I have had promising looking bench results, that set up a RC schmitt
lower than
the Xtal, and then hope that the Xtal rings enough, to build amplitude
and lock the schmitt freq. We never brave enough to actually ship a
product using this :)
Where a Schmitt Osc _does_ work very well, is in LC mode, so if you
can get Schmitt pin option, (and can tolerate LC precision!), then a
SMD
inductor is by far the lowest cost clocking option.
> Shouldn't one inverter be enough to square the edges ?
> As I re-looked at the 74LVC1GX04 (I had a few samples already)
> I remarked that there are 3 inverter gates, this looks like
> overkill to me...
If you are doing this properly, a schmitt buffer is better, and you
chose
a schmitt with lowest transistion currents (ie lowest Vcc when sine-
driven)
You may trade-off to a single-component, but the unbuffered gates have
low
gain, so a single stage is only 'squarish'.
I like the 3GU04, as they come in many logic families.
It is surprising the tiny logic vendors DON'T make 2G=(1GU04+1G17)
pairing
as that would cover many clocking choices: Xtal/LC/RC 2 Pin & 3 Pin.
I guess they are stuck in legacy-mode...
> > You can supply the Vcc from a FPGA port pin, to enable
> > the oscillator (add a RC to adjust Icc )
>
> I would even use a LC network...
The R drops voltage, and almost runs the part in constant current mode
oscillation.
You can drive Logic short of the rails, and save osc power.
You do need to watch the IP Cell transition current, but usually
around 1V on
the PFET and 0.6V on the Nfet is OK.
>
> But what about the "enable" input of the canned oscillators ?
> Normally, the osc's output is tristated so (taking into account
> various capacitances) two oscs should be able to share a single
> FPGA input pin (then 2 output pins control the enable pins)...
Yes, but what is clocking the FPGA, when both are off ? ;)
-jg
Brian Drummond
>Brian Drummond wrote:
>> On Sat, 18 Apr 2009 15:16:04 +0200, whygee <why...@yg.yg> wrote:
>>> Nice board. My issue though is : is your oscillator available
>>> in 11.2896MHz frequency, and at what cost ?
>> Heh, thought as much.
>> The other crystal is 12.288MHz then.
>good guess :-)
>Now if you have a smart idea about how to switch between them
>without a glitch... Oh well, when i'll add a video output,
>i'll need yet another oscillator with another frequency :-/
I would (a) use external oscillators, as others have suggested, for the same
reasons. I'd be happy with either modules for simplicity, or something amenable
to oscillator use, like 74HCU04 in some flavour, if economics demand it.
If you need a glitch free switch you need both oscillators running at once, and
something like a BUFGMUX or one of Peter Alfke's clever little circuits to
switch between them.
If power or radiated noise was important I'd consider killing the unused osc (if
it's a 74HCU04, connect the input to a tristated FPGA output, or use a diode
switch to reduce stray C), and a state machine to start it; confirm it had
restarted; and then switch over.
Last time I did it I could let the system go silent for a second when switching;
I used diode switches between two crystals on an oscillator in a rather nice
Philips chip (SAA7274, probably no longer made - that other brand didn't seem to
like crystals attached)
Time before that was pure 74LS series...
Incidentally I found I could pull the crystal over about +/-150ppm, and there
was measurably less phase noise (jitter by another name) from a reputable brand
of crystal.
If you're interested to talk more, email...
>I'm waiting for ecliptek's answer about a sample request.
>However, I wonder how i'll be able to solder it in
>the first prototypes (i'm not at ease with the hot air gun yet).
>I'll have to measure how much it consumes, too. So many questions...
Heh. Kapton tape a thermocouple to the top of a board and check out the
temperature profiles you can get with a 2kw Black&Decker hot air paint stripper
applied underneath...
I've mounted these connectors this way (note the power pins down the middle)
http://www.samtec.com/technical_specifications/overview.aspx?series=QTH
but haven't tried the next logical step of BGAs yet.
- Brian
whygee
<an excellent post that I'm not able to fully digest at this time of writing)
>> But what about the "enable" input of the canned oscillators ?
>> Normally, the osc's output is tristated so (taking into account
>> various capacitances) two oscs should be able to share a single
>> FPGA input pin (then 2 output pins control the enable pins)...
> Yes, but what is clocking the FPGA, when both are off ? ;)
that's simple (TM) :
the FPGA is an Actel Flash-based part so the configuration is "live at power-up"
(as the glossy marketing sheets write). The /RESET pin is held down
up to 200ms after the 3.3V rail has settled (with a TPS3908 or equivalent),
so the quartz have enough time to start oscillating.
The "osc_sels" pins are held down by an internal D-FF with a reset input
(with output logic saying that osc_sel1 <= not osc_sel2 ).
During "normal operation", the internal logic can "write" a specific data
('0' or '1') to the DFF (which switches the source clock).
Note that in the case of dual-source clocking in Actel ProASIC3,
the source should come to one pin only (the pin can be selected
from a certain set but all clocks should go there).
It is better to not implement a MUX in the logic fabric
because this could increase the noise, and the I/O are "wired"
(with EEPROM cells) to go to the logic fabric or to the PLL input
(where the clock signal belongs). The "output enable" provided by
canned oscillators is very useful then. I should add small series
resistors at the osc outputs (100 Ohm ?) in case they get accidentally
asserted at the same time (during transition ?).
Also, I'll add pull-down resistors to prevent accidental assertion
of the oscillators during power-up/down, because the FPGA tristates I/Os
when all power supplies are not nominal so no valid
output would be available during some ms...
Well, a single oscillator looks so simple in comparison...
<think></think>
I have maybe found a solution...
Off-topic : what FPGA family provides an internally-generated /RESET signal
to the logic array ? Those that I know require an externel signal...
Now that I think about this, it sounds curious.
This is probably because most chips work with different I/O-cores-whatever voltages,
but then in a Flash-based FPGA at least, one could eventually program
the tripping voltage of a power supply supervisor.
I guess that the Fusion devices are a bit close to this, but the chip
can examine its own power supply with the ADC which means that the core
must be initialised before...
whygee
Brian Drummond wrote:
> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <why...@yg.yg> wrote:
>> Brian Drummond wrote:
>>> The other crystal is 12.288MHz then.
>> good guess :-)
>> Now if you have a smart idea about how to switch between them
>> without a glitch... Oh well, when i'll add a video output,
>> i'll need yet another oscillator with another frequency :-/
> I would (a) use external oscillators, as others have suggested, for the same
> reasons. I'd be happy with either modules for simplicity, or something amenable
> to oscillator use, like 74HCU04 in some flavour, if economics demand it.
Now, for me it makes no difference, only the availability of the required
frequency matters.
Yes I have changed my mind again, with the help of yet another trick :
44100 and 48000 have 300 as common divisor
(and I need 256 times this frequency). (44100/300)*(48000/300)=23520
I'll have to divide this by 149 or 160 to obtain the right frequency.
This can be done by dynamically changing the divider ratios.
The Actel PLL has only 7-bit ratios, that is too short
(128<147). There are additional 5-bit dividers that can post-divide.
Now I have to find a frequency in the 5-15 MHz range that satisfies
all these division needs and PLL osc. ranges.
Oh, and this frequency should be available and not too expensive :-/
And when I multiply 256*300*147*160, I get a frequency of more than 1.8GHz
and the PLL's VCO ranges from 24 to 350MHz :-/
Maybe I'll be able to solve this with 2 PLLs or another trick ?
> If you need a glitch free switch you need both oscillators running at once, and
> something like a BUFGMUX or one of Peter Alfke's clever little circuits to
> switch between them.
I've seen this some time ago, and used it already :
http://www.design-reuse.com/articles/5827/techniques-to-make-clock-switching-glitchfree.html
> Incidentally I found I could pull the crystal over about +/-150ppm, and there
> was measurably less phase noise (jitter by another name) from a reputable brand
> of crystal.
> If you're interested to talk more, email...
that's interesting, though my concern is more about long-term stability.
150ppm of drift can add up to a significant delay after a while,
which will desynchronise the system...
>> I'm waiting for ecliptek's answer about a sample request.
>> However, I wonder how i'll be able to solder it in
>> the first prototypes (i'm not at ease with the hot air gun yet).
> Heh. Kapton tape a thermocouple to the top of a board and check out the
> temperature profiles you can get with a 2kw Black&Decker hot air paint stripper
> applied underneath...
Oh, so that tape I recently purchased will be more useful than I thought :-)
The thermocouple and the paint stripper are also already available.
regards,
Brian Drummond
>Hi !
>
>Brian Drummond wrote:
>> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <why...@yg.yg> wrote:
>>> Brian Drummond wrote:
>>>> The other crystal is 12.288MHz then.
>>> good guess :-)
>Yes I have changed my mind again, with the help of yet another trick :
>44100 and 48000 have 300 as common divisor
>(and I need 256 times this frequency). (44100/300)*(48000/300)=23520
>I'll have to divide this by 149 or 160 to obtain the right frequency.
Sorry, I'd forgotten that one.
It's 147 not 149, or 7*7*3 if you are restricted in ratios...
versus 8*5*4 for 48kHz.
>The Actel PLL has only 7-bit ratios, that is too short
>(128<147).
(Unless you can use their factors as above. Which means 2 PLLs.
>Now I have to find a frequency in the 5-15 MHz range that satisfies
>all these division needs and PLL osc. ranges.
7.056 MHz sound about right? :-)
>Maybe I'll be able to solve this with 2 PLLs or another trick ?
The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to
find a high frequency (but less than 1.8G) that you can divide down to close
approximations to both 12.288 and 11.2896. (I had a program to search for these
once...)
Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
substantially no jitter at the sample rate) use a 200-300MHz osc (standard freq,
standard module) and a phase accumulator to generate 11/12Mhz. This will be
arbitrarily accurate and reloading the phase increment will switch frequency
without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc.
>that's interesting, though my concern is more about long-term stability.
>150ppm of drift can add up to a significant delay after a while,
>which will desynchronise the system...
Long term drift would be at least an order of magnitude less; the pull was
because one mode of operation required a PLL round the crystal to synchronise to
other equipment.
- Brian
Antti....@googlemail.com
1) Actel PLL tolerates customer xx.yy divider clock remover in the
feedback loop, so it can generate almost any frequency - see "pll
clock dither app note"
2) there is dynamic config mode
so you can connect ext freq to 1 pin, and get all the desired
frequencies from single PLL
PS for the clock dither you NEED specific extfb path connecting 2
actual IOs of the FPGA, on PA it was possible in fabric but PA3
requires external loopback, this loopback wire is one of the things we
added on FPGA stamp PCB rev B, just to support the clock dither trick
Antti
whygee
> On Sun, 19 Apr 2009 21:35:12 +0200, whygee <why...@yg.yg> wrote:
>> Yes I have changed my mind again, with the help of yet another trick :
>> 44100 and 48000 have 300 as common divisor
>> (and I need 256 times this frequency). (44100/300)*(48000/300)=23520
>> I'll have to divide this by 149 or 160 to obtain the right frequency.
> Sorry, I'd forgotten that one.
> It's 147 not 149, or 7*7*3 if you are restricted in ratios...
> versus 8*5*4 for 48kHz.
yes, I wrote them all down...
IIRC the 44100Hz sampling rate comes from a storage medium that used
video tapes, they simply reused the same sampling rate when they designed
the CD standard, because there was no other digital recording equipment
that could match the CD quality... So one should find television
frequencies, divisors or factors, no ?
>> The Actel PLL has only 7-bit ratios, that is too short (128<147).
> (Unless you can use their factors as above. Which means 2 PLLs.
I'll look at the recent "Igloo plus" or "Igloo E" that have 2 to 6 PLLs.
Currently (for my first custom board) I keep the usual ProASIC3,
cheaper, available and more-or-less compatible with the successors.
>> Now I have to find a frequency in the 5-15 MHz range that satisfies
>> all these division needs and PLL osc. ranges.
> 7.056 MHz sound about right? :-)
sure :-)
I've seen this frequency when playing with the ratios,
but i did not settle there because I needed another *256 factor.
I'll look more closely to this one...
>> Maybe I'll be able to solve this with 2 PLLs or another trick ?
> The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to
> find a high frequency (but less than 1.8G) that you can divide down to close
> approximations to both 12.288 and 11.2896. (I had a program to search for these
> once...)
hmmm...
If I was OK then I would not bother and use Wolfson or Texas Instruments
chips, they generate "something close enough to the required frequency"
from a 12MHz quartz (that is required by the USB protocol).
I'm not an "audiophile" but I know digital sound enough to know how
to avoid stupid problems later (even when it means that I have to solve
not-so-easy problems now).
> Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
> substantially no jitter at the sample rate)
yes because it is integrated by the *256 oversampling D/A
(and hopefully a PLL ?)
> use a 200-300MHz osc (standard freq,
> standard module) and a phase accumulator to generate 11/12Mhz.
It's going to buuuuurn power :-/
> This will be
> arbitrarily accurate and reloading the phase increment will switch frequency
> without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc.
hmmm... I prefer the PLL idea because it uses special gates, not
those from the fabric. And a phase accumulator needs to work at high speed,
but a standard 32-bit adder in ProASIC3 works generally at 60-70MHz max.
And it eats quite a lot of gates.
thank you for the insight,
whygee
> 1) Actel PLL tolerates customer xx.yy divider clock remover in the
> feedback loop, so it can generate almost any frequency - see "pll
> clock dither app note"
> 2) there is dynamic config mode
yes, I count on this one too :-)
I'll modify my SPI master VHDL code to include the 81-bit
shift register thing.
> so you can connect ext freq to 1 pin, and get all the desired
> frequencies from single PLL
>
> PS for the clock dither you NEED specific extfb path connecting 2
> actual IOs of the FPGA, on PA it was possible in fabric but PA3
> requires external loopback, this loopback wire is one of the things we
> added on FPGA stamp PCB rev B, just to support the clock dither trick
thanks for the tips !
> Antti
glen herrmannsfeldt
> IIRC the 44100Hz sampling rate comes from a storage medium that used
> video tapes, they simply reused the same sampling rate when they designed
> the CD standard, because there was no other digital recording equipment
> that could match the CD quality... So one should find television
> frequencies, divisors or factors, no ?
If I remember the story, it was also so that the video tape
based system could be used to store master tapes for CDs.
My first hard disk, a few years after CDs came out,
was 40MB. Tape was the only medium with enough storage
capacity for a CD master.
-- glen
Brian Drummond
With an oversampling D/A you want the lowest possible jitter on the *256 clock;
the phase accumulator (unless followed by a PLL) is not a good option. You need
identical area under all 256 possible charge packets.
Given that constraint the PLL looks better.
However it might be worth asking where you get the D/A. If you can roll your own
- or even the DSP portion and use the analog portion of a commercial solution -
it would be possible to oversample by either *3,*7,*7 or *4,*5,*8 and generate
both datastreams at the same clock frequency.
But that would require a medium sized Spartan-3 or equivalent; possibly bigger
than you want.
- Brian
Brian Drummond
Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape used by the PCM1600
(1610?). Three samples (per channel) per active line on either 60Hz NTSC or 50Hz
PAL. Since drop-frame NTSC actually ran at 59.94Hz (I believe to hide supply
interference) the American version actually sampled at 44.056 kHz.
But I don't believe any CD players actually followed that particular deviation.
- Brian
glen herrmannsfeldt
(snip, I wrote)
>>If I remember the story, it was also so that the video tape
>>based system could be used to store master tapes for CDs.
>>My first hard disk, a few years after CDs came out,
>>was 40MB. Tape was the only medium with enough storage
>>capacity for a CD master.
> Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape
> used by the PCM1600 (1610?). Three samples (per channel)
> per active line on either 60Hz NTSC or 50Hz PAL.
> Since drop-frame NTSC actually ran at 59.94Hz (I believe
> to hide supply interference) the American version actually
> sampled at 44.056 kHz.
It comes from three constraints, the last one being
the offset between the video and the audio subcarrier.
The first two are an odd number of cycles per line
and per field.
> But I don't believe any CD players actually followed that
> particular deviation.
Well, for NTSC timing, the 59.94 only applies to color
signals (with an active color burst). Black and white
signals would still run at 60Hz. In either case, the recorder
has to synch to the incoming signal. Normally (for TV sets)
in playback, one would synch to the playback signal. I believe
that some players would allow one to supply a source signal
for the player to synch to. That would allow, for example,
combining two video signals.
-- glen
gabor
> -jg wrote:
>
[snip]
> Off-topic : what FPGA family provides an internally-generated /RESET signal
> to the logic array ? Those that I know require an externel signal...
> Now that I think about this, it sounds curious.
> This is probably because most chips work with different I/O-cores-whatever voltages,
> but then in a Flash-based FPGA at least, one could eventually program
> the tripping voltage of a power supply supervisor.
> I guess that the Fusion devices are a bit close to this, but the chip
> can examine its own power supply with the ADC which means that the core
> must be initialised before...
>
> > -jg
>
> yg
>
> --http://ygdes.com/http://yasep.org
Pretty much all SRAM-based FPGA's have internal power-on
reset circuitry to trigger the configuration of the part.
While this reset happens well before the logic is up and
running, the nature of the bitstream load lends itself to
an internal reset in that all of the flip-flops and
(usually) RAM cells are initialized during configuration.
An internal reset can be generated simply by releasing
the logic to a running state. The normal procedure is
to instantiate a short shift register with an initial
value of all 1's (or all 0's for active low logic) and
then shifting in 0's when the chip starts up. The output
of the shift register will therefore start up the
rest of the chip a few clocks after configuration
is complete without the need for an external reset
signal.
Regards,
Gabor
whygee
<snip>
Well... you're right. I'm too architecturally biased...
> The normal procedure is
> to instantiate a short shift register with an initial
> value of all 1's (or all 0's for active low logic) and
> then shifting in 0's when the chip starts up. The output
> of the shift register will therefore start up the
> rest of the chip a few clocks after configuration
> is complete without the need for an external reset
> signal.
Funny...
Long ago, I was in a digital design class in a university.
The teacher was (is ?) a "all state-machine"-guy.
On the first day of the class, he asked the class how to design
a circuit that would receive a serial bitstream and
toggle a bit when it's finished.
I started to describe a system similar to what you just wrote,
and he almost had a fit (well, he was blunt and dismissive).
He went on to describe "his perfect way of doing this"
with high-level stuffs and (for me) some bloat.
For him, "one hot" systems are evil...
I presume that his bias for state machine could come from
his extensive use of PALs (22V10 and the likes)
and I was already well into the FPGA and full-custom world...
Sea-of-gates have (to me) different constraints.
Anyway, I don't remember a case where I had to use
a "state machine formalism". And I try to avoid these cases
anyway because it relies too much on the tools ...
I've already worked with FSM crunching software but a nice
little clean design looks much better to me :-/
(oops now I realise that it could start a flamewar)
> Regards,
> Gabor
Gavin Scott
> >Nice board. My issue though is : is your oscillator available
> >in 11.2896MHz frequency, and at what cost ?
> Heh, thought as much.
> The other crystal is 12.288MHz then.
Curiosity led me to this thread which perhaps might be of interest:
http://www.diyaudio.com/forums/showthread/t-25921.html
G.
whygee
> Curiosity led me to this thread which perhaps might be of interest:
> http://www.diyaudio.com/forums/showthread/t-25921.html
> G.