Woes of Protocol Validation

Inevitable long hours of testing, designing a prototype, taking down measurements, logging of reports, debugging unexpected results, and of course, racing behind the clock– a very familiar picture to every Validation engineer!  

Integral, Important and Inevitable 

Validation is one of the most critical aspects which decides the success and longevity of a product in the market. This is especially true in the case of products having Digital Protocols interfaces such as I2C, MIPI I3C ®, UART, and SPI protocols. Validation holds as much relevance as the efforts put in designing them.

The following reasons substantiate this: 

       1.Validation ensures the interoperability of the product with other devices in the market. 

       2. Helps us understand the threshold limits of various parameters of the device. 

      3. Captures the bugs that might have been missed during design verification. 

      4. Identifies the behaviour of the device at corner cases which can be rectified accordingly. 

Validation- The Conventional Style 

Traditionally validation is done by building the emulator in one of the below forms  

        – Using FPGA/Off–the–shelf tools available for communication needs 

        – Using High Cost ATEs

In each case, the results are captured, analyzed and reports are generated. 

However, these workflows come with a lot of pain points making them tedious, not to mention the amount of time that they consume. The following section highlights some key aspects of why validating in conventional methods is laborious. 

• Design- For every protocol variant that must be validated, the Validation engineer must read through the protocol specifications manually and then proceed to designing the hardware and software, bearing in mind the corresponding specs. Both activities have to be dealt with care, for it is these data that form the base for the rest of the entire process. 
  

• Test Execution- He/she must execute all the validation tests such as spikes/glitches, measure bus timing parameters, bus voltage levels for each product that is validated. For each test performed, the engineer must take the effort of updating the settings, and run the test using a number of buttons and mouse clicks. Furthermore, these settings must be updated by the engineer each time! As a result, engineers spend a lot of time in running tests and collection of data. 
  

• Validating over a range– Moving forward, these tests must be executed over different ranges of PVT (Pressure-Voltage–Temperature), again accumulating the burden on the Validation engineer Hence this results in repetition of the same set of tests over various combinations of PVT, leading to a large consumption of time. With these tests, however, many test cases and corner cases cannot be validated properly, thus posing a great threat to the performance of the device when released into the market.

• Measurements– Measurement of test data is quite a difficult task for a Validation engineer. Data such as fall time, rise time, voltage, frequency etc. are displayed on an oscilloscope which are noted down manually.

However manual measurements lead to practical difficulties and errors. To note down the measured value, the Validation engineer must  

–  zoom in to investigate the values

–  set the correct axes, channels, or cursors before logging values 

– cross check if noted readings are correct 

– ensure accurate measurements 

All of these put a great amount of strain on the eyes, at the same time leading to errors. Efficiency is still not guaranteed when such activities are executed by humans, taking a toll on the final performance of the product. 

• Report Generation– is the next big challenge. Each of these measured values must be logged into reports, again manually. These are then mapped to the required specifications, leaving numerous possibilities for errors and woes! 
  

• Debugging- The greatest task that looms over a Validation engineer is the task of Debugging. Being flooded with numbers, values, and a number of test results, Debugging obviously becomes arduous. The Failure Test cases must be re-executed, thus going all over the cycle of test->measurement->logging->report->debugging.
   
• TIME- All these tasks take up a whopping 3-5 weeks of effort, greatly squeezing and putting your RTM at stake. 
  

Adding ATEs to the pain-point bandwagon 

There is no less trouble while using ATEs, 

• Technical Expertise- Validation using ATEs requires a deep amount technical expertise in the ATE platform, which is not a common ability of Validation engineers on a large scale. 
• Increased Effort- involves an intense technical effort for data captures and developing digital patterns. 
• NOT user-friendly– The UI interface might not be easily operable by all Validation engineers  
• costly- ATEs are quite expensive, making it unaffordable to some Validation groups. 
  

Light at the end of the tunnel! 

Given these numerous handicaps and challenges, Validation engineers look for solutions that can ease their Protocol Validation process. Not only must the Solution reduce the manual efforts during the validation process, but also be accurate and user-friendly. A solution that can test, log reports and aid in an easier debug would be the perfect choice for every Validation engineer.  

Well, if this is the picture in your mind too, then maybe we can help….