Data collected over a period from 2009 to 2011 from a population of more than 350 engineers involved in embedded system design. Click on stats to read details and comments

The 'challenge' in generating the - specifically digital - inputs of an embedded system comes together with the challenge in analyzing its outputs.

Schematically, setting up a 'test / debug' session for an embedded system starts with the questions:

• How am I going to stimulate the system's inputs? 
• How am I going to observe the system's outputs ?
• How am I going to check if what I observe is correct?
• How am I going to correct detected bugs?
  

Hence, testing and debugging strategy first requires the definition of the infrastructure that will be used 'around' the system under test to place it in a 'stimulus-and-response' scenario.

From the chart above, we can see that a majority of respondents either 'somewhat agree' or 'agree' that the generation of input stimulus is challenging.

In addition, when asked about whether 'generating the inputs' is less, more or equally challenging as 'observing the outputs' of embedded systems, the results vary by system type.

A remarkable result shows that 83% of the respondents find the generation of input equally or more challenging than the observation of the outputs.

At the origin of this finding, respondents mention the lack of available equipment and/or the lack of budget to purchase these. A common practice also reside in using valuable design time to design the source of stimulus, together with the system itself.

Byte Paradigm's flexible & cost-effective digital pattern generator solutions help overcome the 'stimulus challenge'.

Click here to see all our digital pattern generator solutions.

Back to top

This result is important because our respondents also use a wide variety of tools and methodologies to overcome the embedded system testing and debugging challenge. In other words, prototyping and going to real hardware is still a way to speed up testing and debugging, no matter if lots of advanced - and sometimes useful - other EDA and software solutions have appeared on the market today.

In the list of 'other' tools and methodologies, we can find:

• VHDL / Verilog simulation;
• Hardware emulators;
• Software emulators and debuggers (in which case a prototype should be available as well, ...).

What is remarkable is that most of the respondents will use a variety of complementary techniques rather than a 'winner takes it all' strategy to test and debug its embedded system.

In this environment, making a 'real' hardware prototype is widely recognized as a way to speed up the testing and debugging phase. Trade-offs between prototype testing and simulation / emulation testing can be summarized in the table below.

	Testing / debugging on prototype	Simulation / Emulation
System observability	Low(er)	High(er)
Speed of execution	Fast	Slow

Among the respondents, we also noticed that the ones who have already used a digital pattern generator are more in favor of prototyping than the ones who have not.

You can simply be more efficient at testing and debugging embedded systems with a prototype if you use a digital pattern generator.

Click here to see all our digital pattern generator solutions.

Read more: White paper: Engineers increasingly vote for prototyping for embedded system debug (PDF).

Back to top

Actually, we have found a small bias with the above results, as a significant part of our respondents are already Byte Paradigm's customers. We think that having a preliminar experience with digital pattern generators or other of our products may explain the high number of respondents in favor of DPGs for speeding up the testing and debugging process.

This said, there is a remarkable split between the ones clearly agreeing with the above statement, and the ones 'somewhat agreeing' with it. We investigated the answers of these last ones -here is what they say:

Careful planning of the testing process is the key:

• DPG requires a connector on your board, where you can have a direct access to the signals you'll want to stimulate.
  
  
• DPG is useful for stimulating I/Os with a predefined set of pattern / stimuli that need to be sent on a cycle-to-cycle basis. When it is tolerable to have unpredictable latencies, variable timing, and slow(er) operation - a microcontroller with a GPIO may be a better option. DPG is useful when you need a cycle-accurate data vector generation - for instance, when you would like to investigate a specific sequence that causes a bug or when you would like to reuse data from a simulation.
  
  
• DPG alone will not lead to a productivity increase if its counterpart is not carefully planned too: think about how you'll observe the system's response. Will an oscilloscope be enough? Do you need a logic analyzer or a data acquisition device? Will you have to write software with your board microcontroller?
  
  
• Efficiency with a DPG highly depends on its integration in the test plan. How will you run the DPG patterns? Do you need control from your test software? Do you need synchronization with your board software? With another equipment? Respondents in our surveys stressed the fact that a programmable DPG - or a DPG that you can control from PC software (C/C++, Visual Basic, Labview, Python, ...) usually allow better testing plan since they can be synchronized with other equipment and software.
  

DPG is an essential piece of equipment for the digital embedded engineer, together with scopes, LA, data loggers/data acquisition devices, and software emulators in order to increase productivity during embedded system design.

Click here to see all our digital pattern generator solutions.

• A plain 8 MByte memory buffer, allowing long cycle-accurate runs
• 100 MHz maximum pattern frequency, a really fast operation for LVCMOS (single-ended) signaling
• 16 bit-wide connector - and multi-device support, enabling pattern width extension
• multi-voltage support (from 3.3V downto 1.5V) through its external voltage connector
• free control software that include Win 32/64 GUI and C/C++ API for test plan automation and synchronization 

Back to top