[time-nuts] FreeBSD, NetBSD, or Minix-III?

Hal Murray hmurray at megapathdsl.net
Mon May 18 04:15:22 UTC 2009


> Why not add a hardware latch with a fixed delay to read. That is the
> delay controls the latch function after the counter is static as well
> as the interrupt. Then reset the latch buffer on the last read. We
> have a fixed hardware delay plus a software delay to allow for but
> eliminate some of the variability. And reduce the failed read due to
> software delay. Now a second interrupt / read will indicate delays
> greater than the tick rate if our OS has interrupts that are off
> greater than the tick rate minus the delay of the latch. Our choice
> would be to slow the tick rate or reduce the interrupts off blind time
> if we have many failed reads where the tick is more than one. The idea
> would be to reduce the error to a rare event. This problem is like the
> meta stable problem discussed here before so perhaps the fixes are the
> same. 

I don't understand what you are trying to describe.

There are two separate problems.  One is reading 64 bits.  The other is 
metastability.

Metastability is simple.   Lets assume we have 2 clocks.  The PCI clock is 33 
MHz.  The external good-timing clock is 10 MHz.

Since 10 is slower than 33, the simple way to do things is to toggle a FF 
with the 10 MHz clock and send that through a synchronizer to the 33 MHz 
domain.  Each time that FF changes, we know a tick has happened so we bump 
the counter by 1 clock tick at 10 MHz.  That's just a clock enable on the 
register adding 100 (ns) to itself.  (assuming the register counts ns)  This 
is simple and clean.  The disadvantage is that the clock has slightly lower 
resolution than what might be posible.

The other way is do the counting with the 10 MHz clock, perhaps after PLLing 
it up to 100 MHz.  Now, to read the clock, you send a signal from the PCI 
domain through a synchronizer to the external clock domain.  That copies the 
counter to a holding register, sends a "ready" signal back through a 
synchronizer to the PCI domain so the PCI logic which has been stalled can 
read the stable copy.  This is classic 4-way handshake.  You can speed things 
up by "knowing" (by design) that X will happen within Y clock cycles, so you 
only have to count to Y rather than wait for the ACK to get ack.

Another approach is to use a small FIFO.  In this context, FIFO means magic 
that solves metastability, and small means as small as you can get away with 
to minimize latency.  Again, lets assume the PCI clock is 33 MHz and the 
external clock is 10 MHz PLLed up to 100 MHz.  The PCI would read samples 
from the FIFO and add them to its counter.  The external side would write 
samples into the FIFO.  Each sample would represent the number of ns to add 
to the counter.  Since 100 is bigger than 33, the FIFO will normally be full. 
 So the send side can't write a constant 10 each cycle.  It has to collect 
those 10s in a register.  When the FIFO has room, it writes that register 
into the FIFO and resets it to the 10 for this cycle.  With 33 MHz and 100 
MHz, the FIFO would contain samples of 30 and 40.

I think there is a simple/sneaky way to build that FIFO.  It needs 2 or 4 
registers.  I don't remember the trick.  I might be able to work it out.


The other problem is how to read a 64 bit register when the hardware only 
supports reading 32 bit  chunks.

I think you either have to:

  fFx the hardware (or get new hardware) so it can do 64 bit atomic reads.

  Read the halves separately and put things together with the tricks we have 
been discussing.  That only works if you know something about the data, for 
example that the whole register is a counter and the high bits only change 
slowly.

  Read one half and put the other half into a holding register where you can 
read it later.  If you only have 1 holding register, then you have to 
restrict things to only 1 context is doing the reads at a time.  Otherwise 
somebody else will come along during an interrupt or reschedule and read 
things.  Then when you get to run again you read their copy of the holding 
register rather than yours.  You can have multiple holding registers, but 
then you have to allocate 1 to each context that needs it.


I don't see how a "hardware latch with a fixed delay" is going to help and/or 
what you have in mind.  Perhaps you wanted to have the right value of other 
half ready when the second read happened?  The problem with that is that the 
timing on PCI isn't predictable so a fixed delay won't work.  So you need a 
holding register triggered by logic rather than a fixed delay.


  


-- 
These are my opinions, not necessarily my employer's.  I hate spam.






More information about the time-nuts mailing list