Safety Critical ARM

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:l7WjCQGoR96FFA5E@phaedsys.demon.co.uk...
> In article <1173037058.700819.31000@8g2000cwh.googlegroups.com>, 
> Robert.NXP@gmail.com writes
>>On Mar 3, 4:10 pm, Paul Gotch <p...@at-cantab-dot.net> wrote:
>>> Chris Hills <c...@phaedsys.org> wrote:
>>> > This is incorrect. It depends on the MCU and the ICe
>>>
>>> So you are saying that in most cases it is correct then? Which MCUs 
>>> are you
>>> claiming that an ICE version can be proved to be exactly equivalent 
>>> to the
>>> real processor and how is this proof done?
>>>
>>> In this case it's academic since I know of no traditional ICEs that 
>>> emulate
>>> a ARMs they'd need an architecture license in order to do so.
>>>
>>> -p
>>> --
>>> "Unix is user friendly, it's just picky about who its friends are."
>>>  - Anonymous
>>> --------------------------------------------------------------------
>>
>>
>>The bondout chip was usually identical in timing and Erratas at the
>>time it hit the market but it was not feasible to update the bondout
>>chip every time the production chip was fixed. So, over time they
>>drifted apart until a bondout redesign was done.
>>The good news is that with an ARM that includes ETM, the above
>>mentioned obsticles are not present any more. The production chip has
>>the emulation build in. Advantage, real-time execution trace is
>>possible, disadvantage, you will loose some pins.
>>The ETM got different priorities from different manufacturers of ARM
>>devices. Most ARM7 devices do not include ETM, many ARM9 devices do.
>>Exception on ARM7 is NXP which delivers most devices with ETM.
>>
>>Robert
>>
>
> Hi Robert. (Robert T I assume)
>
> Not only were many of the bond out parts identical (bar the different 
> package with more pins) some did not need a bond out as the busses 
> were visible externally anyway.
>
> Also there was, for the 8051 the hooks system, which meant the same 
> part was used in the ICE as the target.
>
> I am still not convinced the  that JTAG/ETM is as good as a full ICE 
> but in time I think there will be a one or two wire debug system that 
> will be used generally on most parts that will be as good as the old 
> full ICE.

What advantages would the full ICE bring over the JTAG/ETM method? 

"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in 
message news:1172855473.15269.0@proxy02.news.clara.net...
> I'm currently looking at replacing the processor in a safety critical 
> system from an 80188 to likely some form of ARM.
>
> I'd been told that this might be tricky because approvals houses (mainly 
> TUV and GasTec) like to step through the code on an in-circuit emulator 
> rather than stepping through code on a JTAG emulator. This seems unlikely 
> to me but could it be true? Surely the JTAG method is used a lot these 
> days.
>

We produce Validation Suites for safety-critical software and I have not run 
into situation you describe with any of our projects.  Their are 3 TUVs 
though and I have only worked with one of them, but I find it highly 
unlikely that there would be this level of difference between them.  In none 
of the cases has TUV stepped through code with anything.  I have had them 
supply someone to witness tests, but they have not done any direct testing. 
I think there is no merit whatsoever to the idea that they would require an 
ICE over JTAG.

The primary concern with IEC-61508 is safety.  Stepping through code by 
itself can not assure any degree of safety.  If your existing product has 
already undergone certification then you must have previously supplied 
requirements, designs, documentation, code, tests, etc. to prove the safety 
of your system to the applicable safety integrity level (SIL).

If your product is older and has not been through full examination then you 
may have a lot of work in front of you.

Converting a product from 80188 to ARM should not present a problem for 
certification other than the normal amount of work that any certification 
requires.  In fact it should be easier and may be able to be done as a 
modification of the original certification.  Section 7.8 of both IEC-61508-2 
and-3 deals with modifications to the system and software respectively.

-- 
Scott
Validated Software Corp.

"Not Really Me" <scott@validatedQWERTYsoftware...XYZZYcom> wrote in 
message news:552rhgF239t4bU1@mid.individual.net...
>
> "Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote 
> in message news:1172855473.15269.0@proxy02.news.clara.net...
>> I'm currently looking at replacing the processor in a safety critical 
>> system from an 80188 to likely some form of ARM.
>>
>> I'd been told that this might be tricky because approvals houses 
>> (mainly TUV and GasTec) like to step through the code on an 
>> in-circuit emulator rather than stepping through code on a JTAG 
>> emulator. This seems unlikely to me but could it be true? Surely the 
>> JTAG method is used a lot these days.
>>
>
> We produce Validation Suites for safety-critical software and I have 
> not run into situation you describe with any of our projects.  Their 
> are 3 TUVs though and I have only worked with one of them, but I find 
> it highly unlikely that there would be this level of difference 
> between them.  In none of the cases has TUV stepped through code with 
> anything.  I have had them supply someone to witness tests, but they 
> have not done any direct testing. I think there is no merit whatsoever 
> to the idea that they would require an ICE over JTAG.
>
> The primary concern with IEC-61508 is safety.  Stepping through code 
> by itself can not assure any degree of safety.  If your existing 
> product has already undergone certification then you must have 
> previously supplied requirements, designs, documentation, code, tests, 
> etc. to prove the safety of your system to the applicable safety 
> integrity level (SIL).
>
> If your product is older and has not been through full examination 
> then you may have a lot of work in front of you.
>
> Converting a product from 80188 to ARM should not present a problem 
> for certification other than the normal amount of work that any 
> certification requires.  In fact it should be easier and may be able 
> to be done as a modification of the original certification.  Section 
> 7.8 of both IEC-61508-2 and-3 deals with modifications to the system 
> and software respectively.

Thanks for that. The system is already certificated with everyone that 
it needs to be so it is really just a processor change - the 
functionality will remain the same except for very low-level code 
required for hardware interfacing.

There is also the temptation to use the new on-chip peripherals that a 
new processor might bring so we can get rid of the cost of the discretes 
but that then makes you more dependent on one device. I'm sure that 
devices based around the ARM core will be available for a long time but, 
knowing my luck, if I commit to a device with just the peripherals I 
need then it will be obsolete by the weekend! 

On Mar 5, 4:23 am, "Tom Lucas"
<news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote:
> "Chris Hills" <c...@phaedsys.org> wrote in message
>
> news:l7WjCQGoR96FFA5E@phaedsys.demon.co.uk...
>
>
>
> > In article <1173037058.700819.31...@8g2000cwh.googlegroups.com>,
> > Robert....@gmail.com writes
> >>On Mar 3, 4:10 pm, Paul Gotch <p...@at-cantab-dot.net> wrote:
> >>> Chris Hills <c...@phaedsys.org> wrote:
> >>> > This is incorrect. It depends on the MCU and the ICe
>
> >>> So you are saying that in most cases it is correct then? Which MCUs
> >>> are you
> >>> claiming that an ICE version can be proved to be exactly equivalent
> >>> to the
> >>> real processor and how is this proof done?
>
> >>> In this case it's academic since I know of no traditional ICEs that
> >>> emulate
> >>> a ARMs they'd need an architecture license in order to do so.
>
> >>> -p
> >>> --
> >>> "Unix is user friendly, it's just picky about who its friends are."
> >>>  - Anonymous
> >>> --------------------------------------------------------------------
>
> >>The bondout chip was usually identical in timing and Erratas at the
> >>time it hit the market but it was not feasible to update the bondout
> >>chip every time the production chip was fixed. So, over time they
> >>drifted apart until a bondout redesign was done.
> >>The good news is that with an ARM that includes ETM, the above
> >>mentioned obsticles are not present any more. The production chip has
> >>the emulation build in. Advantage, real-time execution trace is
> >>possible, disadvantage, you will loose some pins.
> >>The ETM got different priorities from different manufacturers of ARM
> >>devices. Most ARM7 devices do not include ETM, many ARM9 devices do.
> >>Exception on ARM7 is NXP which delivers most devices with ETM.
>
> >>Robert
>
> > Hi Robert. (Robert T I assume)
>
> > Not only were many of the bond out parts identical (bar the different
> > package with more pins) some did not need a bond out as the busses
> > were visible externally anyway.
>
> > Also there was, for the 8051 the hooks system, which meant the same
> > part was used in the ICE as the target.
>
> > I am still not convinced the  that JTAG/ETM is as good as a full ICE
> > but in time I think there will be a one or two wire debug system that
> > will be used generally on most parts that will be as good as the old
> > full ICE.
>
> What advantages would the full ICE bring over the JTAG/ETM method?

Timings.  Stepping via Jtag is slow.  Jtag is flexible but slow.