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-boun...@febo.com [mailto:time-nuts-boun...@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
