Embedded clocks

I, and maybe Jim, assumed that you have a more powerful master and multiple slaves, which you scan. Then it is easier and cheaper to use just some SMD resistor and capacitor than an oscillator, which is reliable with the one wire bus, if you provide one exact clock from a master.

How fast do you need to communicate? Maybe you can do all with a CPLD, but with the HCS08 you have a tested 100 kbps I2C bus integrated (and up to 1 mbps with reduced bus loading) and it is easier to program a microcontroller than a FPGA (I've programmed it in an other project with a C compiler).

The 32 kbyte Flash single unit price is $8.81, which is more than twice as expensive as the 64 macro cell CPLD XC9572XL-10VQG64C, but you don't need any more external components, if you need A/D converters and the precision of the internal oscillator is good enough for your application.

But after taking a look at the CPLDs from Xilinx, maybe this is a good idea, too. I didn't know that they have integrated Flash, so you need only some external RC component for the clock. Is a CPLD big enough for a CPU core? This would be the ideal combination: high-speed tasks implemented in VHDL and complex tasks implemented with an integrated CPU.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

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

build them both, and count the macrocells :)

UARTs need (commonly) /16 resettable counter on RX, and a /16 non resetable counter on TX, plus the byte buffers in both directions.

So that's at least 8 macrocells running higher than the bit-rate, plus appx 4 more do do the framing, vs 3-4 for PWM bus.

PWM Osc is gated-monostable type at 4x bit rate - so power is lower. A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect

Simulating all this is not that easy, on today's tools, which are designed for a master-clock approach.

CPLDs have no problems with speed, but the host speed may be a stumbling block. Philips talked about 3.4MHz i2c, but nothing seems to have hit the streets. I see they now have a FM+ spec, which is high drive i2c, at 1MBd, also well within CPLD's reach.

i2c Address info can be compile-time-coded into CPLDs, to save pins and macrocell resource.

SPI can work with 3 wires, if that helps.

How many IO's do you need, on how many addresses ?

Do they need dataDirection register control, and read-back, or are simpler fixed OUT and IN acceptable ?

64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.

-jg

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.

A PWM bit level signal still has to do all the higher level stuff of counting the bits in a word etc. So if there is an savings, it would be very little.

The host would be another CPLD. The "host" has to take in two SPI running near 100 kHz and four discrete signals. I have no info on how the SPI data is framed. I2C is done in bytes, but my understanding is that SPI has no defined protocol, it really is a non-standard standard. I will have to get more info on how the SPI busses are being used before I can decide if this will even work.

I could put an address on the SPI bus like I2C does it. I can't recall at the moment why I felt it would need a fourth pin. I think because of flagging which of the two SPI ports was running at that moment. But that can be encoded in the data stream so I guess it could leave a pin free.

I don't understand. Do you mean the discrete signals?

No, just four outputs. They are triggers with timing information, but I don't know how precise they need to be.

You did not account for the two SPI ports that are being multiplexed. Without more info on the protocol on the SPI ports, I can't count FFs. But each one will need a buffer since the link will have to run much faster than either of the two SPI ports. Also I don't even know if this will work since SPI is full duplex, IIRC. As you shift out data read data is coming back, right? Or is it still half duplex with the read data and write data never happening at the same time? I would not be able to buffer words and do full duplex. That sounds incompatible to me.

you get state change or no state change to represent a bit, therfore some time limit has to be placed on the stream to get data flow.

a delta sigma stream can be filtered at any fast rate and represent many levels

the data rate will be limited by various factors.

a virtual grey code could be set up

with no -max to +max

when in the middle two states, either up or down is possible,

one option says clock 0, and one says clock 1

when on the outer two states, then eventually move into one of the middle states. as you can not loop peak to peak

cheers

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 )

Again, it depends on your yardstick. When you are working with 32 Macrocell CPLDs, as I do often, a saving of 8 macrocells can be very important.

I thought this was a multi-slave plus master problem - you seem to be talking only about the master above - what are the slaves ?

SPI works like the simplest 8 bit shift registers, so it is duplex capable.

Most SPI memories, work in half-duplex - they read the address info, while floating SerialOUT, and then ignore SerialIN, while driving serial out (if doing a read).

If you have to slave to two separate SPI streams, that you have little control over, that could get complex very quickly.

-jg

SPI is a spec in search of itself. There are some variants to it. For a decent overview of the different types, you could look at the interface specs on this device I use

(Look at the microport section).

One of the issues I ran into on the original Motorola implementation was that the last data bit (lsb) was only valid for half a bit time - so I had to generate a quadrature clock. (That was in the early 90s).

As you are doing it for yourself, you have no such limitation. SPI can run at up to 4Mb/s on commercial parts, and I see no reason a CPLD could not handle that.

Cheers

PeteS

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

I agree, but I am not sure there is any savings. Both methods have to do the same work in framing bits and words so I don't see where the savings would come in. That would require a more detailed analysis or design. I suppose the one wire protocol might be able to have more commonality between the rx and tx, but a half duplex uart could likely do the same thing.

There are other considerations. If I can clearly show that a one-wire approach would work and fit the part while a uart design would not, that would be clear evidence. But I am currently working (the emphasis on *currently*) in a very political environment where being right is no guarantee of being "right". If a more "trusted" designer decided that he was uncomfortable with the one-wire approach it would be gone regardless of the facts.

I think I explained what I was building, but it may be scattered over several different posts. The "thing" I am trying to figure out is in essense a multiplexer and demultiplexer of several signals. There are two interfaces that need to be brought out through a cable. The connector is virtually out of pins and we don't want to make it larger. Each interface has an SPI port with a CE since it drives multiple slaves running at lowish rates. The interface also has two discrete signals which are mostly for timing of control. The SPI port is used to send setup commands and the discrete signals say "do it now". We have added four pins to the connector before remembering that the interface for each was a total of 6 pins and that we actually needed two ports. Is it unlikely that we can add a total of 12 pins to the connnector. So we need a mux.

The SPI ports can not be multiplexed together in the simple way since they have separate masters that are not synchronized. So to multiplex this will require capturing the data from both ports and muxing it at a higher speed along with the discrete signals. I am limited by not knowing the format of the data on the SPI busses.

It just occured to me that I really don't need to know the format of the data if I just treat the signals as arbitrary data streams. I can sample them at high enough rates that the timing information is not significantly distorted and send them across in a very, very simple scheme. I can sample each one in a round-robin manner at say 1 MHz for a total clock rate of 10 MHz (10 signals in one direction, 2 in the other). This interface would need a clock, datain, dataout and frame sync. That will fill the four pins, but would also be flexible enough that other discrete signals could be added with a small increase in frequency.

One BIG advantage to doing it this way is that the latency is no more than 2 clock cycles or 0.2 uS. I am also very confident that it could be done in a 32 cell CPLD. The slave would be clocked by the interface, so it does not need a crystal or other timing device. The master can be a bit more complex since it is inside the unit, but likely a ~10 MHz clock can be provided. The only remaining issue is finding a CPLD that is low power and can be made tolerant of the external signals. I would hate to have to buffer all 16 signals in the cable.

Yes, that is the part that has me concerned. But by explaining it to you, I think I have figured out the best way to approach this. We'll see if I can get the multiplexer to fit in terms of power and any other constraints that pop up later.

Thanks for listening and offering your advice.

If you can use one of the small CPLD/FPGA parts with a DLL/PLL (e.g. MachXO) at the far end, you should be able to press the {D|P}LL into service for clock recovery using a specially constructed waveform.

There was thread last year about sending bidirectional data over a SATA cable without needing a CDR at the far end where I suggested a clock phase modulation scheme:

- send a clock with fixed rising edges and +/-90 degree phase modulation of the falling edges

- divide by two to strip the phase modulation -> clean ref. clk

- double then phase shift for a mid-period sample clock

If the {D|P}LL phase detector & ctl logic only uses leading edges, and doesn't mind the wild duty cycle swings, you could skip the divide-by-2 and double steps.

I haven't tried that out yet, but I don't see any fundamental problems with it ( other than wasting BW vs. other modulation schemes. )

Brian

Thanks for the ideas. I was not aware of the MACHXO parts. They are suprizingly dense and cheap. Web pricing at Atmel for the 256 LUT part is around $5 in moderate quantities.

I assume I would need a 2x clock to generate the 90 degree skewing of the trailing edge or even a 4x clock if I don't want to play tricks with using opposite phases clocking FFs.

This could work and would only use two pins, one in each direction. But the device itself would be pushing the boundary of what I would like to use. The smallest part is 256 LUTs and the smallest package is a 100 pin Chip Scale BGA at 8x8 mm. There is one universal truth in FPGAs and CPLDs; if you have a lot of IO, you will have a lot of logic and if you have a lot of logic you will have a lot of IO. They don't put large deivces in low pin count packages, ever!

The power consumption of the MACHXO is a bit high. I don't have an exact number, but the standby current starts at 14 mA. But this is not out of the ballpark and I will keep the idea in mind since it can use half the pins of the other approach I have in mind.

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

If you use Sync related direction control ( see SPI memories ), you can share/common the datain/dataout : eg the first 12 clocks are one way, the last 4 are the other way, in a simple 16 clock frame, with spare room )

-jg

If you can afford 2 more CPLD pins, Peter described it for an FPGA, but should work for CPLD:

I'm curious:

1) how well does that circuit scale up in frequency, 2) what your frequency needs are?

As described, using 470K resistors, the power for that 3 pin RC oscillator looks miniscule. Add a little more gating, you can even shut it off, and re-start time doesn't look much more than half a clock period.

RC Osc power is not just resistor power; a significant amount is the linear-region Icc from the pin buffers that are not square wave driven.

Restart time is instant, but you do need to watch the start(idle) values as the first half cycle time can differ from the others, as the circuit changes from rest state, to the ping-pong oscillation cycles.

With 3 terminal Osc's, you should also design the Pinout/PCB, so the 'linear' node is adajcent to the positive acting pin(cap), and not the negative acting pin. eg a good pinout is : GND RC Cap+ Res-

-jg

The ATF15xx and Coolrunner II are no gos because of the dual voltages required. Also the ATF parts only come in the relatively huge TQFP44 packages which are four times larger than the csBGA of the Coolrunner parts. I can make a schmitt trigger easily enough with a couple of resistors and an output pin.

How about some details on the RC oscillator? I have not seen a 3 pin oscillator before.

What we need is a CPLD like the Freescale RS08, or the SiLabs C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :) [ ATF1502BE draws 2.3uA, but needs two rails.... ]

Yes, I have already mentioned to Atmel that TQFP44 is large in today's designs....

One Pin : Bidirectional pin, Open Collector, Res Pullup, Swings between Schmitt VthP and VthN - Tolerance is that of Hyst Band. Duty cycle is narrow. Hard to gate, as CAP is never 0V. Can VCO modulate.

Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups, Swings from GND to VthP, Nominally 50% duty cycle. Gates very well Can VCO modulate.

Two Pin B : One IP, one OP, Classic HC14 Osc, single Rfb, and Cap, Swings VthP to VthN, Duty cycle is nominally 50%, Poor VCO modulation.

Three Pin: One IP and 2 OPs. (See 4060, 4541 et al) Positive feedback to a CAP, negative feedback via resistor, with optional overshoot resistor from CAP to IP pin. Needs layout to have +ve FB next to RC IP pin. Has nominal immunity to pin thresholds, and some PSRR, poor VCO modulation.

Gives lowest Icc, as the signal spends least time in high current IP regions.

Simplest form, is a non-inverter, followed by inverter (order matters).

Can have latches added, to 'de-fur' and can be gated with a little care.

See the other link in this thread

This is a 3 termal RC osc, with a SR latch.

-jg

1) (Jim) Do you have a more precise quantifier than "significant"?

To be clear, I'll be referring to Peter's circuit (I can't post one myself, and am too lazy right now to attempt ASCII artwork). Let's call the top resistor Rc, since it charges the Cap, and call the bottom one Rs, since it feeds a Sense pin. This simple circuit brings a nice collection of subtleties with it:..

There are roughly three regions of operation (six, it's a symmetric circuit, let's look at just after switching C to ground): A) Immediately after switching , C has pushed Rs to VCC/2 below ground, and C is charging through both Rc (via the inverted output pin) and and Rs (via the sense pin protection diode). B) Some time later, the sense pin protection diode is no longer fwd biased, and C is charging through Rc only. Rs serves only to connect C to the sense pin (I'll assume that frequency is low enough that sense pin capacitance can be ignored). C) Sense pin reaches linear region, starts causing Icc current draw, in addition to the charging current Rc.

I hadn't thought much about FPGA input structure before this. I had generally assumed, unlike logic buffers such as 'ALVC245 and the like, whose totem-pole inputs can consume enough power near threshold to destroy themselves, that newer multistandard FPGA inputs were more like a comparator, and not subject to damage, or even very much increase in current when near threshold. There are no warnings in the datasheet...certainly no "Icc current vs. input voltage" chart to indicate that near threshold operation is of concern..

2) Can anyone say anything about Icc vs. input level for either FPGAs or, eg. CoolRunnrer PLDs?

Of course charging starts immediately, I meant the time from enable to the 1st threshold crossing at the sense pin. I was wrong in saying "more" than half a clock period. The first half period should be shorter than periods that follow, because C only has to charge from ground to threshold, while in later half periods, C charges from ~VCC/2 below ground to threshold.

For a good example graph, look at the data of the 74LVC14A, Fig 9 on my copy.

Here, you'll see the classic double peaks of a Schmitt transfer. Non-Schmitts are worse: Similar skirts, but with a single, higher peak.

There can be variations in the peaks, and skirt shapes.

A two terminal Osc will trace the 'butterfly' between the peaks, and so average 4mA Icc on this device. A three terminal osc is appx 25-30% of that.

I'm not sure about damage, but certainly the 4mA linear region of the LVC14a example, might play havoc with someones uA power budget.

Modern FPGAs are pretty poor low power devices, so you'll likely just get a shrug from their vendors, but some CPLDs are sub 20uA, and so this can be important. It _should_ be in the uA CPLD data sheets.

I have to smile at the MAX II low power marketing spin, where they REMOVE the power, to claim 'low power', and add many discrete components to do this. Remember Resistor-Transistor Logic ?

It is not hard to measure this, especially once you understand the basic shape, and the peak(s) you are looking for. You do need to have a low voltage drop across the current sense.

-jg

Hi Brian, Neat. I guess a problem could be that the signal has some data dependent DC component. But 8B10B coding fixes that. Cheers, Syms.

The Coolrunner XPLA3 parts are pretty good. Other than not having schmitt trigger inputs, what don't you like about them?

If I understand correctly, this circuit would generate a sawtooth on the cap with a very short low drive time on the output.

I don't get this one at all. I looked up the 4046 but all descriptions I could find treat the VCO as a black box. I am guessing that the two pins are driven with opposite polarity and the cap is grounded at one end or the other all the time. So it would be charged like the one pin approach and then discharged like the one pin approach. So this is a pair of the one pin drivers to give you 50/50 duty cycle?

This seems simple. Any issues with startup? Does it need FFs anywhere to make it work without noise? I would think that the lack of schmitt trigger inputs would require a FF.

This one I know.

This one is clear. Thanks.