* SID and eCos @ 2002-06-18 13:51 Scott Dattalo 2002-06-18 15:59 ` Scott Dattalo 0 siblings, 1 reply; 6+ messages in thread From: Scott Dattalo @ 2002-06-18 13:51 UTC (permalink / raw) To: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SID and eCos 2002-06-18 13:51 SID and eCos Scott Dattalo @ 2002-06-18 15:59 ` Scott Dattalo 2002-06-18 18:46 ` Ben Elliston 0 siblings, 1 reply; 6+ messages in thread From: Scott Dattalo @ 2002-06-18 15:59 UTC (permalink / raw) Cc: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SID and eCos 2002-06-18 15:59 ` Scott Dattalo @ 2002-06-18 18:46 ` Ben Elliston 2002-06-18 22:06 ` Scott Dattalo 0 siblings, 1 reply; 6+ messages in thread From: Ben Elliston @ 2002-06-18 18:46 UTC (permalink / raw) To: Scott Dattalo; +Cc: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SID and eCos 2002-06-18 18:46 ` Ben Elliston @ 2002-06-18 22:06 ` Scott Dattalo 2002-06-19 14:19 ` Ben Elliston 0 siblings, 1 reply; 6+ messages in thread From: Scott Dattalo @ 2002-06-18 22:06 UTC (permalink / raw) Cc: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SID and eCos 2002-06-18 22:06 ` Scott Dattalo @ 2002-06-19 14:19 ` Ben Elliston 2002-06-19 20:42 ` Scott Dattalo 0 siblings, 1 reply; 6+ messages in thread From: Ben Elliston @ 2002-06-19 14:19 UTC (permalink / raw) To: Scott Dattalo; +Cc: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SID and eCos 2002-06-19 14:19 ` Ben Elliston @ 2002-06-19 20:42 ` Scott Dattalo 0 siblings, 0 replies; 6+ messages in thread From: Scott Dattalo @ 2002-06-19 20:42 UTC (permalink / raw) Cc: sid 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-06-20 3:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-18 13:51 SID and eCos Scott Dattalo 2002-06-18 15:59 ` Scott Dattalo 2002-06-18 18:46 ` Ben Elliston 2002-06-18 22:06 ` Scott Dattalo 2002-06-19 14:19 ` Ben Elliston 2002-06-19 20:42 ` Scott Dattalo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).