[time-nuts] DMTD to MMTD

Bruce Griffiths bruce.griffiths at xtra.co.nz
Thu Feb 18 12:28:24 UTC 2010


Magnus Danielson wrote:
> Bruce Griffiths wrote:
>> Lux, Jim (337C) wrote:
>>>> -----Original Message-----
>>>> From: time-nuts-bounces at febo.com 
>>>> [mailto:time-nuts-bounces at febo.com] On Behalf Of Bruce Griffiths
>>>> Sent: Wednesday, February 17, 2010 2:10 PM
>>>> To: Discussion of precise time and frequency measurement
>>>> Subject: Re: [time-nuts] DMTD to MMTD
>>>>
>>>> The latest version actually records time stamps from a continuously
>>>> running counter clocked at some at a constant frequency (100Mhz??)for
>>>> all channels simultaneously.
>>>> They may use a flag bit for each for each channel to indicate to which
>>>> channel or channels the zero crossing time stamp belongs.
>>> Simpler than that.. it grabs 20 bit numbers and shoves them out in 
>>> ASCII over a com port with an indication of which channel it was for.
>>> The FPGA has a 20 bit free running counter at 100 MHz. When an input 
>>> changes state, it latches the counter, and shoves it out along with 
>>> the channel number.  They use an offset frequency>100 Hz so that you 
>>> don't have to disambiguate the counter rollovers. (20 bits rolls 
>>> over every 10+milliseconds counting at 100 MHz)
>>>
>>> I don't know if there's a FIFO in front of the UART (e.g. what if 
>>> you get simultaneous zero crossings).. but I would expect there is.
>>>
>>> The "hard work" is in the zero crossing detector ahead of the FPGA. 
>>> (and perhaps in the latching of the ZCD inputs into the FPGA).
>>>
>>> Given how long ago it was made, that FPGA isn't a huge one.
>>>
>> Using 8 flag bits (one per channel) together with the associated time 
>> stamp is a little more efficient and very easy to do and it doesn't 
>> require a FIFO to ensure that simultaneous zero crossings aren't missed.
>
> It doesn't help at all for this application. The 8 channels is more 
> likely to be spread out and as Jim pointed out, the next bin is 
> sufficient for needing a unique time-stamp. The flag-solution is less 
> efficient (8 bits rather than 3) and the FIFO need is always there, 
> but may be implemented in various ways. For the flag system to be 
> efficient, a high probability for the same time-bins to be used needs 
> to exist, and a high resolution system can expect to actually see 
> noise spread out the channels over the time-bins.
>
Depending on the system constraints it may be the difference between 
being able to do implement it or not.
> A DMTD systems have a low rate of events per channel, but the nominal 
> distance of events for each channel is fairly long, worst-case burst 
> is when all channels time-stamps. For a 100 Hz beating and 100 MHz 
> clock, the nominal rate of rise/fall events is 200 Hz or 5 ms. Letting 
> the locked value stay put for at least 4 ms. If all channels could be 
> emptied within these 4 ms (just another way of saying that it has 
> enough transport capacity) then a fairly simple schedule system can 
> loop through the channels to find a new sample to transmit.
>
> I think the re-occurring flag system should be put to rest, it doesn't 
> contribute and is a red herring, at least for this application.
>
Nonsense, it requires simpler logic and for a device with limited 
internal connection/routing capability and a large number of channels 
the data path interconnections may be simpler and easier to route. It 
may also run with a higher clock frequency.

It should even be possible to impement in a relatively small CPLD albeit 
with an external FIFO or equivalent (eg a PPI port on a Blackfin DSP).
Each additional channels requires one input pin, one output pin, a 2 bit 
synchroniser and a 1 bit wider data path and little else.

> Cheers,
> Magnus
>
Bruce




More information about the time-nuts mailing list