This is the mail archive of the sid@sources.redhat.com mailing list for the SID project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SID and eCos


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]