View Single Post
Old August 11th, 2016   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

It would depend on which tests are failing. For example, some of the tests are looking at corner cases that will never happen in the real world and are mostly intended to test error handling in the responder. Other tests are critical and will have an impact on system operation if they can't pass. If you're comfortable posting a summary of what failed, we may be able to offer a more detailed response.

The automated test suites are great for testing protocol-level issues; For testing the bytes on the wire. In my experience though, most of the problems with splitters (and other inline devices) have to do with timing and error-handling, not protocol. For example, how does the splitter react when something responds too quickly or too slowly? How does it handle noise on the line or a response that happens when it's not expecting it? What do you do with a break that's interrupted by a 500ns wide pulse in the middle, or a responder that responds to broadcasts? When do you give up on a partial response: Do you enforce the Inter-Slot time, the Total Packet time, or both? Are the line drivers on every port enabled (and disabled) at the proper times?

To test for these issues, it usually requires a mis-behaving responder and a lot of time with an oscilloscope.
ericthegeek is offline   Reply With Quote