100 Mbit manchester coded signal in FPGA

True, CoolRunner has no DCM or PLL (that's what you meant to say, I
suppose).
When you want to tranmit 100 Mb per second in Manchester code, you
really need a 200 MHz clock, since each data bit uses (potentially) two
level transitions. (or you rely on the 50% clock duty cycle plus an XOR
gate...
Manchester code is wasteful in bandwidth, but easy to implement, and
fairly rugged.
Other schemes, like 8B10B use much lower bandwidth, but are more
sensitive to frequency mismatch between transmitter and receiver.
There are many xtal oscillator manufacturers. Typical telecom
frequencies like 156 or 312 MHz oscillators are readily available, and
are of high quality at a low price, if the frequency suits you.
In that case you can count on extremely good frequency matching between
sender and receiver.
Peter Alfke, Xilinx
================
Michael Dreschmann wrote:
> On 8 Aug 2006 13:52:43 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
>
> >Michael, I thought you wanted to use an FPGA (Virtex-4) for the
> >receiver.
> >Then you can use any oscillator frequency you want, and modify it with
> >the DCM inside the FPGA.
>
> Of course, I'm looking for an oscillator for the transmitting cpld. He
> also needs 100 MHz to generate the data stream but as far as I know
> there is now DCM or PLL in a CoolRunner 2. Or am I wrong?
> On the receiver side power and oscillator is no problem.
> 
> Michael

Antti wrote:
> 
> cpld oscillator shure work, but you still need a resistor across not
> gate in-out
> it want oscillate otherwise. I have spent some time trying to get an
> crystal
> to swing on FPGA pins without external resistor but have not yet
> succeeded.

Interesting target - why is the resistor such a problem ?
There are bigger headaches in FPGA osc than the resistor..

-jg

Michael Dreschmann wrote:

> On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
> 
> 
>>But I prefer a dedicated oscillator, because it uses less power, and
>>uses an internal chip that is optimized for the purpose, and is
>>manufactured by a company with expertise and a single-minded goal. And
>>it hardly costs extra...
> 
> 
> Costs are no problem, it's a university project and not a design for
> production.
> I thought a crystal in combination with the cpld would need less power
> than a dedicated oscillator. Could you give me a hint where to find a
> 100 MHz low power oscialltor working at 2.5V? An external oscillator
> of course would be easier.

100Mhz is tricky space for crystals, as you are also into overtone.

Look at Maxim and Linear - they have a number of SOT23 Oscillators
that are designed to give quite good precisions (for manchester), in 
10-200Mhz ranges.

If you are brave, a LC osc can be built with a CPLD Inverter
( no resistor needed )
- tho at 100Mhz the Tpd is a size-able chunk of half-period.
Start at 10-20Mhz, and lower L/C, to see if 100Mhz is practical.

You can also make a ring-oscillator, using just the PLD delay elements:
this has the lowest precision, but manchester can auto-baud


> An other question concerning power:
> If I have a design that fits exactly in a xc2c64a cpld and I use the
> next bigger one (xc2c128) with the same design how much more would be
> the power consumption (roughly)?

for low power CPLD clocking notes, take a look at this
http://www.altera.com/literature/an/an422.pdf

As often happens with benchmarks, the really usefull info is 
other-other. Here it is the Xilinx/Lattice relative infos - any 
Altera-others info will be carefully  filtered :)

-jg

Antti Lukats wrote:

> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
> news:44D8D028.7080802@xilinx.com...
> 
>>Michael,
>>
>>The use of a CPLD or FPGA inversion is not recommended for a crystal
>>oscillator.
>>
>>The problem is not that it won't work (it often does), it is that it
>>sometimes will not start.  The inversion also comes with a delay that is
>>not something that you can easily model and prove that the oscillator
>>will always start up.
>>
>>Once started, it will oscillate, it is the starting that is sometimes
>>difficult,
>>
>>Austin
> 
> 
> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps 
> and crystal will not oscillate under some conditions?
> 
> It should be 100% a-stable as it can not stay in non-oscillating state.

A more important question is WHICH frequency it oscillates at ! :)
At lower slew rates (not this case), you can get multiple oscillation
effects : At the thresholds, the extreme (excess) gain can give 
parasitic oscillations, or edge-fur, and that's NOT nice on a clock source !

-jg

I would look at the low-power xtal oscillators used in cell phones,
often at 156 MHz. They are a bargain in small size, low power
consumption, and cost. They are made by the millions (or is it billions
by now ?)
Pletronics is one manufacturer, but there are many others.
Peter Alfke

Jim Granville wrote:
> Antti Lukats wrote:
>
> > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
> > news:44D8D028.7080802@xilinx.com...
> >
> >>Michael,
> >>
> >>The use of a CPLD or FPGA inversion is not recommended for a crystal
> >>oscillator.
> >>
> >>The problem is not that it won't work (it often does), it is that it
> >>sometimes will not start.  The inversion also comes with a delay that is
> >>not something that you can easily model and prove that the oscillator
> >>will always start up.
> >>
> >>Once started, it will oscillate, it is the starting that is sometimes
> >>difficult,
> >>
> >>Austin
> >
> >
> > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps
> > and crystal will not oscillate under some conditions?
> >
> > It should be 100% a-stable as it can not stay in non-oscillating state.
>
> A more important question is WHICH frequency it oscillates at ! :)
> At lower slew rates (not this case), you can get multiple oscillation
> effects : At the thresholds, the extreme (excess) gain can give
> parasitic oscillations, or edge-fur, and that's NOT nice on a clock source !
> 
> -jg

Antti Lukats wrote:

> "Austin Lesea" wrote:

>> The use of a CPLD or FPGA inversion is not recommended for a crystal
>> oscillator.

> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2
> caps and crystal will not oscillate under some conditions?


> It should be 100% a-stable as it can not stay in non-oscillating state.


Back in the 1970's, an engineer I was working for decided to save a part
on a design and use a spare 7414 inverter rather than a 7404 inverter as
an oscillator.

A TTL inverter, like the 7404, properly connected, makes a good
oscillator. A 7414, which is a schmitt-trigger inverter, doesn't.

Yes, it would always oscillate.  But only sometimes at the correct
frequency.  More often at the third or fifth harmonic of the crystal.  And
sometimes higher harmonics.

This left me with the idea that a good engineer should make sure that an
oscillator design is a good design before building boards.  Not afterward.


-- 
Phil Hays

On 8 Aug 2006 14:41:13 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>When you want to tranmit 100 Mb per second in Manchester code, you
>really need a 200 MHz clock, since each data bit uses (potentially) two
>level transitions. (or you rely on the 50% clock duty cycle plus an XOR
>gate...

When I simply xor the NRZ data with the clock signal I get spikes
which isn't surprising. So I create two 50 MHz clocks from the 100 MHz
clock that are phase-shifted by 90 degree (by using rising and falling
edge of the 100 MHz clock). Then I invert one of the two clocks
depending of the NRZ data bit. Finally the two 50 MHz clocks (one of
them modulated by the data to send) are xored and I have my manchester
signal. Because now the outputs of two flipflops are xored there is
nearly no time difference between them and the output is fine (my
theory, don't laugh Peter ;) ). Of course the incomming clock must
have a 50% duty cycle.
I haven't tested it in silicon but a Post-Fit simulation with modelsim
shows a very good signal and I hope this is a good sign.

>Manchester code is wasteful in bandwidth, but easy to implement, and
>fairly rugged.

Right, but in our application bandwidth is not a problem at the moment
(optical link). We need to save power and so I try to use the smallest
cpld possible.

Thanks also for the infos of oscillator manufacturers. I'll look
tomorrow, it's time for bed now in germany.. ;)

Michael

Hi,

Thank you all for your help. I think everything is clear to me now.

Michael 

"Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag 
news:pan.2006.08.09.02.22.18.236185@comcast.net...
> Antti Lukats wrote:
>
>> "Austin Lesea" wrote:
>
>>> The use of a CPLD or FPGA inversion is not recommended for a crystal
>>> oscillator.
>
>> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2
>> caps and crystal will not oscillate under some conditions?
>
>
>> It should be 100% a-stable as it can not stay in non-oscillating state.
>
>
> Back in the 1970's, an engineer I was working for decided to save a part
> on a design and use a spare 7414 inverter rather than a 7404 inverter as
> an oscillator.
>
> A TTL inverter, like the 7404, properly connected, makes a good
> oscillator. A 7414, which is a schmitt-trigger inverter, doesn't.
>
> Yes, it would always oscillate.  But only sometimes at the correct
> frequency.  More often at the third or fifth harmonic of the crystal.  And
> sometimes higher harmonics.
>
> This left me with the idea that a good engineer should make sure that an
> oscillator design is a good design before building boards.  Not afterward.
>
>
> -- 
> Phil Hays
>
gosh the 7404 and 7414 are totally different chips (in the context of making 
oscillators).
it wasnt much of an engineer who tried crystal osc with 7414.
7414 is good for making RC oscillator with 1 R and 1C (7404 is not)

http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf

and CPLD osc about the same as from above should work.
sure it has to tested to work properly on the correct freq and not harmonics

Antti 

"Antti Lukats" <antti@openchip.org> wrote in message 
news:ebbtvs$dpr$1@online.de...
> "Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag
> and CPLD osc about the same as from above should work.
> sure it has to tested to work properly on the correct freq and not 
> harmonics
>
I'm sure you meant this, but I'll post it anyway. I'd rather say it has to 
be _designed_ to work properly. Trial and error is, as I've found through 
trial and error, a terribly inefficient way to do projects.
Cheers, Syms.