[time-nuts] DMTD to MMTD

Bruce Griffiths bruce.griffiths at xtra.co.nz
Fri Feb 19 03:51:19 UTC 2010


The Blackfin DSPs run at 400MHz or more and can execute several 
instructions per clock cycle.
They also have 2 bit wide synchronous serial ports with internal FIFOs 
and auto chained DMA buffer data transfer hardware.
There's also a synchronous parallel interface with internal FIFO and 
auto chained DMA buffer data transfer hardware.

The only question is what's the maximum rate at which the processor can 
count and tag bit transitions.

Some of these chips also have a built in 100MBPS Ethernet interface 
(sans transformers).
A UART is also available.

Probably overkill for the application but if one has an unused one lying 
around.....

Bruce

Bob Camp wrote:
> Hi
>
> Anything over 100 MHz should do the trick. On a machine with a full OS on it that kind of sustained I/O would be tough to do un-interupted.
>
> Now, doing a 32 bit shift register externally and clocking in a word at 100 / 32 MHz - not quite as hard.
>
> Bob
>
>
> On Feb 18, 2010, at 9:54 PM, Bruce Griffiths wrote:
>
>    
>> Magnus Danielson wrote:
>>      
>>> Bruce Griffiths wrote:
>>>        
>>>> 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.
>>>>          
>>> With your clarifying comment yes... because it is until now that you have clarified the merit of the flag system, lowered implementation complexity vs. lowered signalling capacity.
>>>
>>>        
>>>>> 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.
>>>>          
>>> But it produces more data, which was what I was commenting on. Indeed it is very simple to implement, but it's a complexity which is still on the low-end.
>>>
>>> So, finally you made the point of the merit of the approach in such a way that it became clear to me why you have maintained that standpoint.
>>>
>>> Cheers,
>>> Magnus
>>>
>>>
>>>        
>> One can always reduce the data sent to the PC by removing redundant information, or increase it by Ascii coding of channels and slope polarities.
>> In general in the absence of significant constraints either method will work, they just have different tradeoffs.
>>
>> Its tempting to see if one can just synchronously clock the synchronised ZCD output signals directly into a processor and derive the timestamps entirely in software.
>> The only question being what is the maximum clock frequency at which this can be done without missing any ZCD transitions.
>> A Blackfin DSP for example should be able to do this with a maximum ZCD sampling clock frequency of at least 50MHz.
>>
>> Bruce
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>      
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>    






More information about the Time-nuts_lists.febo.com mailing list