ARM *simulators*

Hi,

[Trying not to hijack the "Best dev kits for ARM Cortex" thread]

I'd appreciate comments re: vendor offerings for ARM *simulators*
(i.e., forget the "device/vendor-specific I/O's) and their
(presumably) code generating counterparts.

I do most of my development and testing *without* target
hardware so appreciate tools that let me exercise my code
without being tethered to a physical device.

Thanks!
--don

On 20 Mar, 19:38, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi,
>
> [Trying not to hijack the "Best dev kits for ARM Cortex" thread]
>
> I'd appreciate comments re: vendor offerings for ARM *simulators*
> (i.e., forget the "device/vendor-specific I/O's) and their
> (presumably) code generating counterparts.
>
> I do most of my development and testing *without* target
> hardware so appreciate tools that let me exercise my code
> without being tethered to a physical device.
>
> Thanks!
> --don

The Rowley CrossWorks simulator is very good.

Leon

D Yuniskis wrote:
> Hi,
> 
> [Trying not to hijack the "Best dev kits for ARM Cortex" thread]
> 
> I'd appreciate comments re: vendor offerings for ARM *simulators*
> (i.e., forget the "device/vendor-specific I/O's) and their
> (presumably) code generating counterparts.
> 
> I do most of my development and testing *without* target
> hardware so appreciate tools that let me exercise my code
> without being tethered to a physical device.
> 
> Thanks!
> --don

Hi Don

Try and evaluate:

Learn Embedded Linux with ARMulator:
http://www.mcuprogramming.com/blog/2007/04/08/learn-embedded-linux-with-armulator-2/
http://en.wikipedia.org/wiki/Armulator

Glenn

D Yuniskis <not.going.to.be@seen.com> writes:

> I'd appreciate comments re: vendor offerings for ARM *simulators*
> (i.e., forget the "device/vendor-specific I/O's) and their
> (presumably) code generating counterparts.

Which devices/cores do you need to have support for? That'll limit
your options.

Many of the popular MCU toolchains come with simulators. Often you get
(restricted) free-as-in-free-beer eval versions.

If, however you are targeting higher-end cores, you might have to
consider getting ARM's RVISS (formerly Armulator), ISSM or RTSM.

The decision also depends on what kind of performance you need. ARM's
RTSM are built using their FastModels which generate JIT compiled code
on the host machine. Impressive.

-- 
Marcus Harnisch
http://www.doulos.com/arm/

In message <ho3819$krp$1@speranza.aioe.org>, D Yuniskis
<not.going.to.be@seen.com> writes
>Hi,
>
>[Trying not to hijack the "Best dev kits for ARM Cortex" thread]
>
>I'd appreciate comments re: vendor offerings for ARM *simulators*
>(i.e., forget the "device/vendor-specific I/O's) and their
>(presumably) code generating counterparts.
>
>I do most of my development and testing *without* target
>hardware so appreciate tools that let me exercise my code
>without being tethered to a physical device.

One of the best is the Keil Simulator for many reasons.

I have used Keil system for 100% unit testing on a critical project. It
works. Also it is the only system where I have seen silicon vendors say
they will guarantee that if it ran on the simulator it would run in the
silicon. This was for a system that was one time programmable and we
could not have a second byte at the cherry.

Not all systems use flash. eg ASICS, Smart cards etc.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hi Chris,

Chris H wrote:
> In message <ho3819$krp$1@speranza.aioe.org>, D Yuniskis
> <not.going.to.be@seen.com> writes
>> Hi,
>>
>> [Trying not to hijack the "Best dev kits for ARM Cortex" thread]
>>
>> I'd appreciate comments re: vendor offerings for ARM *simulators*
>> (i.e., forget the "device/vendor-specific I/O's) and their
>> (presumably) code generating counterparts.
>>
>> I do most of my development and testing *without* target
>> hardware so appreciate tools that let me exercise my code
>> without being tethered to a physical device.
> 
> One of the best is the Keil Simulator for many reasons.
> 
> I have used Keil system for 100% unit testing on a critical project. It
> works. Also it is the only system where I have seen silicon vendors say
> they will guarantee that if it ran on the simulator it would run in the
> silicon. This was for a system that was one time programmable and we
> could not have a second byte at the cherry.
> 
> Not all systems use flash. eg ASICS, Smart cards etc.

Does the simulator also give *timings* (admittedly, this requires
details of the particular device being used)?  E.g., could I use
it to fully characterize my RTOS?

(Thanks to the other respondents, as well!  My news feed is
expiring articles so I can't individually reply  :-/ )

D Yuniskis <not.going.to.be@seen.com> wrote:
> Does the simulator also give *timings* (admittedly, this requires
> details of the particular device being used)?  E.g., could I use
> it to fully characterize my RTOS?

Fully cycle accurate simulators are available but they are generally
derived from the RTL directly and are very expensive, they are also
fairly slow, generally in the KIPS or at best low MIPS range.

http://carbondesignsystems.com

Provides such models for recent ARM IP which can be built into a system
using their tools. It's probably not the kind of thing a software
developer would use to build a model but your silicon vendor may
redistribute a model built using this technology.

In the middle the technology used by the Keil uVision IDE provides
simulators which are close to being cycle accurate for cores such as
the ARM7, ARM9 and Cortex-M3. However there will be differences due to
the timing of handling of non-deterministic things such as user input
and due to assumptions about buses and peripherals. You would need to
check in the device database as to if a configuration of the model
which corresponds to your microcontroller is supported.

http://www.keil.com/dd/

The Fast Models from ARM are accurate to the level of the programmer's
model and provide higher simulations speeds. The product provides
cores and library of peripherals and example systems which correspond to
a variety of ARM development boards.

You can download a time limited evaluation version of the Fast Models
product from ARM licensed for one type of core by going to www.arm.com
and choosing "Support->Resources->Evaluation Products" from the menus,
you will need to register with ARM to do this.

Full Disclosure: I work for ARM on the Fast Models product.

-p
-- 
Paul Gotch
--------------------------------------------------------------------

In message <hoasos$29u$1@speranza.aioe.org>, D Yuniskis
<not.going.to.be@seen.com> writes
>Hi Chris,
>
>Chris H wrote:
>> In message <ho3819$krp$1@speranza.aioe.org>, D Yuniskis
>> <not.going.to.be@seen.com> writes
>>> Hi,
>>>
>>> [Trying not to hijack the "Best dev kits for ARM Cortex" thread]
>>>
>>> I'd appreciate comments re: vendor offerings for ARM *simulators*
>>> (i.e., forget the "device/vendor-specific I/O's) and their
>>> (presumably) code generating counterparts.
>>>
>>> I do most of my development and testing *without* target
>>> hardware so appreciate tools that let me exercise my code
>>> without being tethered to a physical device.
>>  One of the best is the Keil Simulator for many reasons.
>>  I have used Keil system for 100% unit testing on a critical project.
>>It
>> works. Also it is the only system where I have seen silicon vendors say
>> they will guarantee that if it ran on the simulator it would run in the
>> silicon. This was for a system that was one time programmable and we
>> could not have a second byte at the cherry.
>>  Not all systems use flash. eg ASICS, Smart cards etc.
>
>Does the simulator also give *timings* (admittedly, this requires
>details of the particular device being used)?

It should do so. You will need to set up the information on the clocks
and crystal etc  Whilst the simulator is not "real time" it is
synchronised within itself.


>  E.g., could I use
>it to fully characterize my RTOS?

Which RTOS?   You often need an RTOS awareness package for debugging and
timeings in an RTOS>

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Paul Gotch <paulg@at-cantab-dot.net> writes:
> D Yuniskis <not.going.to.be@seen.com> wrote:
>> E.g., could I use it to fully characterize my RTOS?

Not likely.

> Fully cycle accurate simulators are available but they are generally
> derived from the RTL directly and are very expensive, they are also
> fairly slow, generally in the KIPS or at best low MIPS range.
>
> http://carbondesignsystems.com
>
> Provides such models for recent ARM IP which can be built into a system
> using their tools.

While the processor models and (best case) peripheral models are
near-cycle-accurate (even the CA processor models won't reach full
100%[1]), bus transactions are not modelled precisely. Depending on the
complexity of your system this alone might skew the simulation
results.

I am afraid the only viable solution would be providing evidence, that
your RTOS behaves correctly even in uncertain environments given that
you can rely on certain parameters (clock frequency, timer accuracy,
etc.)

-- 
Marcus Harnisch
http://www.doulos.com/arm/

Footnotes: 
[1]  If my memory about SoC Designer documentation is correct.

>Paul Gotch <paulg@at-cantab-dot.net> writes:
>> D Yuniskis <not.going.to.be@seen.com> wrote:
>>> E.g., could I use it to fully characterize my RTOS?
>
>Not likely.
>
>> Fully cycle accurate simulators are available but they are generally
>> derived from the RTL directly and are very expensive, they are also
>> fairly slow, generally in the KIPS or at best low MIPS range.
>>
>> http://carbondesignsystems.com
>>
>> Provides such models for recent ARM IP which can be built into a system
>> using their tools.
>
>While the processor models and (best case) peripheral models are
>near-cycle-accurate (even the CA processor models won't reach full
>100%[1]), bus transactions are not modelled precisely. Depending on the
>complexity of your system this alone might skew the simulation
>results.
>
>I am afraid the only viable solution would be providing evidence, that
>your RTOS behaves correctly even in uncertain environments given that
>you can rely on certain parameters (clock frequency, timer accuracy,
>etc.)
>

OK, I'm coming VERY late to the party on this but just to chime in on this
topic.  Carbon's models of ARM IP are indeed actually 100% accurate since
we compile them directly from the implementation RTL.  We do this for the
fabric and peripheral models as well so the entire system can be
characterized (we also have products to compile your own RTL into a 100%
accurate virtual model in case you want to model that too)  The models are
all fully instrumented, integrated with RVDS/DS-5, etc.  You probably don't
want to boot Linux in a fully accurate system but we handle this as well
with our integration with the ARM Fast Models.  We even have a technology
which we call Swap 'n Play to enable you to start running your system with
Fast Models (running in the 10s to 100s of MIPS) and then swap over to the
100% accurate representation at any software breakpoint if you want to
characterize or debug your system after it's booted.
Sorry for the more promotional nature of the email, just wanted to clarify
the topic. Full disclosure, I'm the CTO/Founder at Carbon.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com