From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2315 invoked by alias); 19 Jun 2002 05:06:39 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 2308 invoked from network); 19 Jun 2002 05:06:37 -0000 Received: from unknown (HELO brouhaha.com) (209.66.107.17) by sources.redhat.com with SMTP; 19 Jun 2002 05:06:37 -0000 Received: (qmail 20946 invoked by uid 1032); 19 Jun 2002 05:06:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2002 05:06:39 -0000 Date: Tue, 18 Jun 2002 22:06:00 -0000 From: Scott Dattalo X-X-Sender: sdattalo@ruckus.brouhaha.com cc: sid@sources.redhat.com Subject: Re: SID and eCos In-Reply-To: <15631.57966.122255.2563@tooth.toronto.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-q2/txt/msg00032.txt.bz2 On Tue, 18 Jun 2002, Ben Elliston wrote: > Hi Scott, > > > 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