Yes hardware, the fixed delay is triggered by the input clock and would delay the sample and latch of the counter when it is stable. The problem I was trying to solve is latching the counter while it is changing. The latch is to save the sample value for as long as needed for it to be read by the computer.
I need to go back and read what you are trying to measure with your clock. Is it internal to the computer or an external event ? I was thinking you were counting pulse per second not 10 MHz with your counter but if the event is external to the computer it should also control the latch, that is only latch if the counter is stable and the external event is true. Not sure what you would do with 64 bit data at a 10MHz or 100MHz rate other than a FIFO buffer. This is sounding more like a better fit for a real time operating system plus some hardware if you really need a high data rate. Sorry I'm totally confused now. Stanley ----- Original Message ---- From: Hal Murray <[email protected]> To: Discussion of precise time and frequency measurement <[email protected]> Sent: Sunday, May 17, 2009 11:15:22 PM Subject: Re: [time-nuts] FreeBSD, NetBSD, or Minix-III? > 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. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
