Emulators Philosophy

What are the collective's opinions regarding the use of in-circuit emulators for proving safety critical embedded software?

I've heard from some people that they can't imagine how it could be done without whereas others have never used an emulator and consider them entirely unnecessary. Has JTAG rendered emulators obscelete?

Reply to
Tom
Loading thread data ...

Emulators (like simulators) only serve a purpose in testing and debugging, but since actual "proving" cannot ever be done by testing, they are obviously useless for proving.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I agree that proving cannot be done by testing alone but I do think that testing is the backbone when proving that a system is safe. However, I acknowledge that emulators (and simulators) are only tools to assist in testing, but my question is whether they are essential tools.

Reply to
Tom

"Fly what you test and test what you fly".

An emulator gives you a realtime view into program state. This is very useful in debugging but not so useful in testing. Testing attempts to prove that the product works as it will be shipped to the customer.

Reply to
larwe

Emulators are not needed for testing. They are helpful for debugging. There are some types of problems that are much more easily debugged with emulators. I worked on one such problem recently: I was getting occasional incorrect handling of a complex event. I didn't have an emulator available. I put debugging outputs on test points to see the realtime sequence of operations. Sometimes a statement in a switch case was being executed when it shouldn't have been. I added realtime trace output to the switch variable just before executing the switch -- the bug went away (Heisenbug!). I removed the trace and added a debug output on a spare pin when that happened. I had another flag that was high during interrupt service. I noticed that the occasional incorrect execution was always occurring exactly 42 us after completion of an interrupt service. I checked an errata sheet and found a problem with the fast interrupt return feature. I then checked the compiler output and saw that it was using the fast return feature. After figuring out how to tell the compiler to not use this feature, the problem went away. It took me 2 days to narrow this down and solve it. With an emulator which has a trace buffer it would have been less, since I could trigger on the symptom and look at the preceding execution. The presence of an emulator would not help me detect the symptom, only fix it.

Helpful for debugging, yes. Helpful for testing, possibly. Essential, maybe for solving a few types of problems.

Thad

Reply to
Thad Smith

... ONLY if the emulator had the SAME silicon flaw that caused the errata. -jg

Reply to
Jim Granville

Emulators for difficult processor chips (those that would otherwise require massive efforts to set up monitoring and trigger points) can be useful at the pre-product-finishing stage when you need to confirm that the system can follow the whole of its programming. However, the final testing must be accomplished with the processors that will be delivered with the system, especially for safety critical systems. This is a phased testing approach and is, in my opinion, quite a valid consideration. I would not expect the testing to be carried out under the emulator alone. I would hope, however, that you would rather shy away from using such a complex and difficult processors for a safety critical system.

Where JTAG and other low-level debugging connectivity is offered it can be a great help in the early stages. When some of the software layers are in place, and proven to be working properly, these debugging ports can be left alone.

I have found that, for my Forth based systems, I do not need the services of an emulator, hardly a need for the debugging ports at all, as I can gain full control over the hardware I am using. I keep the individual system as simple as is practicable for the application at hand and will distribute over several processors in order to maintain the simplest level, commensurate with the application requirements, in each processing system.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

This is completely wrong. There are several SW tools that use full ICE for non-intrusive hard real time unit and system testing.

Besides most decent ICE had script languages that permit testing and exercising of code to prove it. More to the point as ICe can feed signals in as well as read them in some cases an ICE is the ONLY way of proving some equipment.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

This is why ICE are essential. You "put debugging outputs on test points" IE you changed the code..... A good ICE will execute the code without changing it in hard read time.

What you are doing it opening the fridge door to check the temperature. You will get a reading but by opening the door you have changed the temperature. For more things the reading is "close enough" but it is not accurate.

Changing the code can effect many things including the bug.

DO you mean you use the ICE trace? or is it an example I mentioned above of the test code changing the error?

Been there done that :-) Errata sheets are the bane of my life!

You mean would help you find it but not fix it?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Very true.... You need not only to use the same part but the same revision. It depends on the ICE as to how you do this.

In some families of MCO you use the same part in the target and the ICE. EG the HOOKS system used on some 8051's

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Depending on MCU family this is the case. In other cases the part is not always identical. However it can go a long way to help with the unit and system testing.

All processor are complex these days. Also safety critical systems are getting more complex.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

There are still, fortunately, some processors around that are reasonably simple in their architecture which would be more suitable for a High Integrity application.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

Such as?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Can they be truly non-intrusive or will Heisenberg stick his oar in?

Reply to
Tom

Interesting. First you say I'm completely wrong, then you go on throwing around arguments about something completely different.

I said: ICEs are for testing and debugging, but *not* for proving. Care telling what made that "completely wrong"?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Many of RISC chips would be simpler than the CISC processors that many here seem to use. The RISC devices that I think are worth looking at are:-

Patriot's PTSC1000 Ultra Technology's F21 Harris RTX2000 (if you are doing a space job for NASA)

There are probably more around and I think it is always worth looking at the architecture of a processor (the way ALU's and registers are used within the processor) when making an evaluation. I haven't looked at the structure of the ARM but I would expect many of the DSP processors to also be quite simple architectures also.

Sorry, by the way, for the delay getting back on this one but it has been rather hectic the past few days.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

In article , Tom writes

There are quite a few ICE that are truly non-intrusive.

It is true they have an effect on the circuit but it is so minimal that is it does have an effect on the system the circuit will not work in production (or even development) due to chip and other component tolerances.

The problem is working out which ICE are almost invisible and which are not. The problem is some of the lesser ones claim near perfection so it is sometimes difficult to tell.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Many thanks

Likewise.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.