Re: Embedded clocks



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?


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 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.


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


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.

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

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.


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.

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.

.



Relevant Pages

  • Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
    ... It's a *classic* case of an interface that tries to do everything under ... No argument here -- just about everything related to signals is stupidly ... Conceptually, struct sigevent ... messages queues, not just timers. ...
    (Linux-Kernel)
  • Re: Xilinx, MIG, UCF: timing constraints for DDR2 DRAM
    ... address signals to be retimed and they could therefore not be packed into an ... interface, generated with the Xilinx Memory Interface Generator. ... What is the best way to define setup/hold times for the I/O pads? ... A and the DRAM clocks CK) ...
    (comp.arch.fpga)
  • Re: [take24 0/6] kevent: Generic event handling mechanism.
    ... Event notification is not dropped - thread was awakened, kernel task is ... since it will not be copied into signal mask. ... Avoiding these callbacks would help reducing the kernel interface, ... queue where currently signals would be sent et voilà. ...
    (Linux-Kernel)
  • Re: [OT] Crazy idea: Design open-source graphics chip - DONE
    ... 24bit Standard VGA interface ... Separate VSYNC/HSYNC and combined CSYNC synchronization signals ...
    (Linux-Kernel)
  • Re: [patch 14/22] pollfs: pollable futex
    ... I thought you were talking about the poll/epoll interface in general, ... We cannot change that cost. ... AIO, that is included in your blob interface, but why? ... The 20 lines AIO patch I posted, simply signals to an eventfd when the ...
    (Linux-Kernel)