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.

"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! 

"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.

"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? 

"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message 
news:esa1tc$nbt$1$8302bc10@news.demon.co.uk...
> FreeRTOS.org wrote:
>
>> "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.
>>>
>>
>> SafeRTOS (see link in sig) - ARM7 with JTAG for IEC 61508 SIL 3 no
>> problem.
>> You don't say which standard you are using though.  The *essential* 
>> thing
>> is to get agreement on your approach prior to starting the project so 
>> if
>> you can formulate an argument for JTAG and get it accepted up front 
>> then
>> you 'should' be ok.
>>
>> I have seen it stated that going above a certain SIL levels requires 
>> an
>> in-circuit emulator, but this was in documentation provided by a 
>> company
>> that sells in-circuit emulators.  You need to check the standard to 
>> which
>> you are working.  Even if its in the standard, and you are not 
>> conforming,
>> you can probably formulate a decent argument for a deviation.  For
>> example, from memory IEC 61508 'highly recommends' a strongly typed
>> language [I would
>> have to double check the actual wording] - but SafeRTOS is written in 
>> C.
>> We got this agreed up front and it was not mentioned again until the 
>> final
>> audit, at which time the appropriate box was ticked.
>
> You could use a safer subset of any language. C coding to the MISRA-C 
> rules
> would be looked upon favourably. That said, the planning out of how 
> you are
> going to prove you will meet the Essential Safety Requirements for a 
> system
> is an important first step and this is where some effort should be
> expended. This may need you to do a HAZOP study or some other form of
> Hazard Identification and Mitigation durng the devlopment phase. As 
> you are
> updating on a processor, ou should have a reasonable idea of what 
> Hazards
> your system will meet. It will, however, be worthwhile doing a full 
> review
> just to make sure that the Safety Analysis is current.
>
> Although IEC61508 recommends a strongly typed language you can argue 
> that,
> due to the attention to detail in other areas of software 
> construction, you
> may not need to be so reliant on strong typing.

My language selection is fine at the moment - the system is mature and 
the code is written and the approvals bodies are all happy with it. I 
plan to talk to them before embarking on a processor change but I just 
wanted to ask if there were an obvious gotchas before I went into the 
meeting. 

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.


Regards
  Chris



PS have you see the new Embedded Internet book? You should have had some 
on the stand at Nuremberg


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <eyd*KoOEr@news.chiark.greenend.org.uk>, Paul Gotch 
<paulg@at-cantab-dot.net> writes
>Chris Hills <chris@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?

There are quite a few ICE with exact emulation. I know of one lot that 
were used on a Satellite  if they did some independent tests to verify 
this before using the ICE.

I have seen similar things done for smart cards.

In some cases where the busses are visible the same part is used in the 
ICE as production. So the emulation is 100% accurate

In some cases the bond out part is the same as the production silicon it 
is just a different package.

However there are times when the bond out and the target are not exactly 
the same.

Of course for some single chip parts the same MCU is used in both the 
Ice and production eg for the 8051 using Hoooks (basic or enhanced)

>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.

This is true. It is not just a core license you will need to be able to 
do the peripherals as well.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

Chris Hills <chris@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
--------------------------------------------------------------------

In article <-nf*XxIEr@news.chiark.greenend.org.uk>, Paul Gotch 
<paulg@at-cantab-dot.net> writes
>Stepping through with a real ICE is nonsense from the safety citical
>validation point of view because the real processor will have different
>timing behaviour and crucially different errata from the ICE implementation.

This is incorrect. It depends on the MCU and the ICe


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/