Quote:
Originally posted by Dave Flowerday
Actually, this is only guaranteed to work if all the data in lines are latched at the same time. We've convinced ourselves that this is not the case. We did have a "data valid" flag last year to guard our data and it did not work. We found it is entirely possible to sense the data valid signal and still have corrupted data at the inputs.
[...]
The only way to overcome that would be to delay after setting the data bits but before setting the valid flag. However, one needs to know how long to delay. If you don't know this number and instead just guess, you can probably get it to be reliable. You can't guarantee it though until you know precisely the time it takes the RC to latch all the digital inputs.
|
Yes, you DO have to delay at least one full RC I/O processor sample set time BOTH before, AND after data changes. That's critical to insure the DV signal is good for the current data. Otherwise, you may see an "old" DV signal, or catch the "new" one too soon.
Good grief though, just how slow IS the RC's I/O subsystem? When it did NOT work for you, how long WERE these delays?
- Delay between DV drop & data change, AND
- Delay between new presented data valid & DV rise
IOW, just how long DOES the RC's I/O processor take to get around all of the I/O leads before "going for seconds"? Anyone have a glimmer of that figure?
Hmmm... That spec is important enough I may just call IFI Tech Support to find it.
- Keith