Re: Embedded clocks

rickman wrote:
Jim Granville wrote:

rickman wrote:


Jim Granville wrote:


anything better than RC, has starting time issues, so usually runs
all the time, and that has power penalties.


RC is not even an oscillator without other componets so it really is
not a solution. I can get an oscillator that runs on 1 mA of current,
costs under $0.50 and has plenty of accuracy to do any of the above
protocols. So async serial is ok. One in and one out.

RC osc would use the CPLD - not sure what 'other components' you mean.

If you are happy with 1mA and 50c, then that's fine.

I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
at a cost of a few cents. ( and appx 50uA at 1MHz )


How do you get a CPLD to reliably oscillate with an RC?

Choose one with Schmitt pin options (also important if you want to try i2c, where the slow edges will mess with non-schmitt CPLDs ).

That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices.

You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins,
the better the precision, and less it depends on the thresholds.

The numbers I gave are for ATF1502BE.

-jg

.

Relevant Pages

  • Re: 100 Mbit manchester coded signal in FPGA
    ... The use of a CPLD or FPGA inversion is not recommended for a crystal ... not something that you can easily model and prove that the oscillator ...
    (comp.arch.fpga)
  • Re: 100 Mbit manchester coded signal in FPGA
    ... Antti Lukats wrote: ... The use of a CPLD or FPGA inversion is not recommended for a crystal ... not something that you can easily model and prove that the oscillator ...
    (comp.arch.fpga)
  • Re: 100 Mbit manchester coded signal in FPGA
    ... The use of a CPLD or FPGA inversion is not recommended for a crystal ... not something that you can easily model and prove that the oscillator ... Antti ...
    (comp.arch.fpga)