SID and eCos

SID and eCos

[Scott Dattalo]

I'm trying to use SID to simulate an ARM processor. When I build a "hello 
world" example and try to simulate it, I get this:

$ arm-elf-sid hello
loader: write to data accessor failed at address 0x2020000, status 2
loader: error loading hello

The SID code I'm using is about a 5 day old copy of a CVS download.

The gcc tool chain is: gcc 2.95.2, binutils 2.12.1. The executable was 
produced by invoking the Makefile that is included in the ecos-1.3.1 
examples. Incidently, I can simulate my executable with gdb. Oh, and one 
more thing, the tool chain targets the arm-elf.

I've serached the mailing list archives and saw this relatively recent 
message: http://sources.redhat.com/ml/sid/2002-q2/msg00003.html . Is there 
a chance that this breaks other targets?

Scott

Re: SID and eCos

[Scott Dattalo]

On Tue, 18 Jun 2002, Scott Dattalo wrote:

> 
> I'm trying to use SID to simulate an ARM processor. When I build a "hello 
> world" example and try to simulate it, I get this:
> 
> $ arm-elf-sid hello
> loader: write to data accessor failed at address 0x2020000, status 2
> loader: error loading hello

I think I answered my question.

The Makefile I used to create the executable is part of eCos. I 
specifically target Atmel's AT91EB40 evaluation board. The generic, out of 
the box, SID arm emulation knows nothing about an AT91EB40. The error 
reported above is telling me that the executable accesses RAM that doesn't 
exist (hey, I think I like that:).  So I added a few --memory-region's:

$ arm-elf-sid --cpu=arm --memory-region=0x2020000,0x20000 
--memory-region=0xfffe0000,0x1ffff --gdb=2000 -EL hello

And that worked! 

So now it looks like I have not one, but two (mostly) independent ways to 
simulate my source. I like the SID approach because of the added 
flexibility; specifically the ability to profile.

----

As an aside...

sid appears to be an extraordinarily powerful tool. Is there any reason 
why it's not more popular? Judgeing from the mailing list archives, it 
appears that not too many people are using it.

As another asided, I'm the primary author the GNUPIC Simulator, gpsim.  
This is a GPL'd simulator of Microchip PIC microcontrollers. The homepage
is: http://www.dattalo.com/gnupic/gpsim.html . The GNUPIC tool chain does
not use gcc/binutils - instead we emulate Microchip's tool chain and I'm
porting to SDCC (Small Device C Compiler). However, I'm going to
investigate to what extent it's possible to leverage our two projects.
Specifically, I'd like to incorporate the abstract hardware interface that
sid supports with gpsim.  And to reciprocate, I can add some of gpsim's
modules to sid!

Scott

Re: SID and eCos

[Ben Elliston]

Hi Scott,

>>>>> "Scott" == Scott Dattalo <scott@dattalo.com> writes:

  Scott> The Makefile I used to create the executable is part of eCos. I 
  Scott> specifically target Atmel's AT91EB40 evaluation board. The generic, out of 
  Scott> the box, SID arm emulation knows nothing about an AT91EB40. The error 
  Scott> reported above is telling me that the executable accesses RAM that doesn't 
  Scott> exist (hey, I think I like that:).  So I added a few --memory-region's:

  Scott> $ arm-elf-sid --cpu=arm --memory-region=0x2020000,0x20000 
  Scott> --memory-region=0xfffe0000,0x1ffff --gdb=2000 -EL hello

  Scott> And that worked! 

You're right.  The problem is that the default ARM configuration does
not include as expansive memory regions as the GDB simulator, so your
program was writing into unmapped regions.

  Scott> So now it looks like I have not one, but two (mostly) independent ways to 
  Scott> simulate my source. I like the SID approach because of the added 
  Scott> flexibility; specifically the ability to profile.

Great!  I'm pleased that you've seen SID for what it is.

  Scott> sid appears to be an extraordinarily powerful tool. Is there any reason 
  Scott> why it's not more popular? Judgeing from the mailing list archives, it 
  Scott> appears that not too many people are using it.

I believe there are at least a couple of factors:

  * it has only been out on the net for a year or so; and
  * I don't think it is very widely known about.

  Scott> investigate to what extent it's possible to leverage our two projects.
  Scott> Specifically, I'd like to incorporate the abstract hardware interface that
  Scott> sid supports with gpsim.  And to reciprocate, I can add some of gpsim's
  Scott> modules to sid!

That'd be terrific!  Can you summarise what gpsim modules you have?

Regards, Ben

Re: SID and eCos

[Scott Dattalo]

On Tue, 18 Jun 2002, Ben Elliston wrote:

> Hi Scott,
> 
<snip>

> 
> That'd be terrific!  Can you summarise what gpsim modules you have?

The biggest gpsim module is the LCD (HD44780 type):

http://www.dattalo.com/gnupic/lcd.html

After sending my previous message, I noticed that this is already part of 
SID. (Perhaps though, the fancy graphics are missing). I also have 7 
segment LED's http://www.dattalo.com/gnupic/7seg3.gif. 

Ralf, another gpsim developer, has recently added simple logic devices. 
Here's a screen shot with Logic gates, a PIC, and an 7 segment LED.

In addition, gpsim has several stimuli that can be attached to I/O pins.

Oh and of course, I almost forgot, gpsim simulates almost every Microchip 
PIC device; everything from the tiny 12-bit core devices, to the popular 
14-bit core devices, and the less used, but more powerful 16-bit core 
devices. These are essentially modules too.

--------

gpsim's design:

One of the goals for gpsim was speed. On my ancient 450Mhz PIII, gpsim can
simulate a PIC several times faster than real time. This was achieved by
creating an event-driven behavioral simulation model. In essence, the
simulator only simulates the things it needs to simulate. That sounds like
a tautology, but it's not how many simulators are constructed. (This is an
assumption, but most of the simulators I've studied do more than they need
to.) For example, instruction decoding is an action that does not need to
be simulated - except of course, for the first time an instruction is
decoded. gpsim creates (C++) objects for decoded instructions and places
pointers to these into a giant array that's indexed by the processor's
program counter.


gpsim interfaces to other modules through a PIN object that sounds similar 
to SID's PIN object. PIN's from different objects are connected together 
via nodes. When a PIN changes state, that information is signaled to the 
other modules. This in some cases initiate a cascade of changes (and in 
some cases cause an infinite loop - but that's a bug...). The gpsim 
modules are placed into a Dynamically Linked object and opened with 
dl_open(). Consequently, the objects must conform to gpsim's 
(undocumented) API. This is far inferior to SID's much more powerful 
high-level abstract description. In gpsim, the module creators need to be 
somewhat familiar with the inner workings of gpsim. This probably accounts 
for the fact that are so few modules. Sigh.


----

Scott

Re: SID and eCos

[Ben Elliston]

Hi Scott,

>>>>> "Scott" == Scott Dattalo <scott@dattalo.com> writes:

  Scott> After sending my previous message, I noticed that this is already part of 
  Scott> SID. (Perhaps though, the fancy graphics are missing). I also have 7 
  Scott> segment LED's http://www.dattalo.com/gnupic/7seg3.gif. 

Yep.

A seven segment display component would be a nice introduction to
using the SID API.  Please consider porting your component.  There is
plenty of programmer documentation on the web pages.

  Scott> Oh and of course, I almost forgot, gpsim simulates almost every Microchip 
  Scott> PIC device; everything from the tiny 12-bit core devices, to the popular 
  Scott> 14-bit core devices, and the less used, but more powerful 16-bit core 
  Scott> devices. These are essentially modules too.

These would be great to have in SID, if you're feeling like it!

  Scott> One of the goals for gpsim was speed. On my ancient 450Mhz PIII, gpsim can
  Scott> simulate a PIC several times faster than real time. This was achieved by
  Scott> creating an event-driven behavioral simulation model. In essence, the
  Scott> simulator only simulates the things it needs to simulate. That sounds like

In general, this is the philosophy of SID components: only simulate
sufficiently for target software to execute correctly.

Cheers, Ben

Re: SID and eCos

[Scott Dattalo]

On Wed, 19 Jun 2002, Ben Elliston wrote:

> Hi Scott,
> 
> >>>>> "Scott" == Scott Dattalo <scott@dattalo.com> writes:
> 
>   Scott> After sending my previous message, I noticed that this is already part of 
>   Scott> SID. (Perhaps though, the fancy graphics are missing). I also have 7 
>   Scott> segment LED's http://www.dattalo.com/gnupic/7seg3.gif. 
> 
> Yep.
> 
> A seven segment display component would be a nice introduction to
> using the SID API.  Please consider porting your component.  There is
> plenty of programmer documentation on the web pages.

I will look at it. (But like everyone else, I've got a lot going on - in 
particular, I'm in the middle of porting SDCC to the PIC).

> 
>   Scott> Oh and of course, I almost forgot, gpsim simulates almost every Microchip 
>   Scott> PIC device; everything from the tiny 12-bit core devices, to the popular 
>   Scott> 14-bit core devices, and the less used, but more powerful 16-bit core 
>   Scott> devices. These are essentially modules too.
> 
> These would be great to have in SID, if you're feeling like it!

This will be a little harder. :).

> 
>   Scott> One of the goals for gpsim was speed. On my ancient 450Mhz PIII, gpsim can
>   Scott> simulate a PIC several times faster than real time. This was achieved by
>   Scott> creating an event-driven behavioral simulation model. In essence, the
>   Scott> simulator only simulates the things it needs to simulate. That sounds like
> 
> In general, this is the philosophy of SID components: only simulate
> sufficiently for target software to execute correctly.

Sounds great, Ben! I'll continue to stay subscribed to this list (the 
volume certainly is low) and keep track with what's going on. When the 
SDCC port tapers off, I'll revisit more closely how gpsim could (if can) 
be merged.

BTW, my interest in SID at the moment is to simulate an ARM processor - 
so I'll definitely be a user.

Regards,
Scott