From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14544 invoked by alias); 29 Mar 2005 07:33:29 -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 14528 invoked from network); 29 Mar 2005 07:33:23 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.8) by sourceware.org with SMTP; 29 Mar 2005 07:33:23 -0000 Received: from PCSTARVIK (dh10-84-127-186.se.axis.com [10.84.127.186]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j2T7XLDf020816; Tue, 29 Mar 2005 09:33:21 +0200 From: "Mikael Starvik" To: "'kobi maller'" , Subject: RE: Future of SID Date: Tue, 29 Mar 2005 07:33:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: X-SW-Source: 2005-q1/txt/msg00031.txt.bz2 I know nothing of the future of SID but would like to comment anyway on the possibilites. During the development of a new System-On-Chip ASIC we have developed SID components of most parts of the system including CPU, MMU, DMA, Ethernet, UART etc. We have used this to develop a working Linux port before the chips actually exist (of course we have also used gate-level simulators to verify the chip). We have also used this to test the effect of different cache-sizes and memory latencies. It would of course also be possible to do the DMA performaces meassurments you mention. Some comments about the feasability of different components: DMA: Ths core of a DMA controller is really simple. You'll need an accessor to access memory and either a bus or pins to input data from the FIFOs (or directly from the peripheral). The FIFOs are also straight-forward to implement (and could be generic). The difficult parts of the DMA is: * Different DMA controllers have different ways of configuration * The internal state-machines in the DMA may be complex The DMA model I implemented is driven by pins/function calls but I have had doubts about that later. It may be simpler to have an event-driven approach. Would make it easier to handle corner cases such as when the peripheral writes more than you expect. MMU/TLB: As commented these are tightly connected to each other. Probably not possible to write a generic MMU implementation that cover all possible usages. Ethernet/UART: Very easy to implement components that connects directly to the ethernet/serial port of your computer. Very handy as you can e.g. telnet into your simulated system. SMP: In theory it is as simple as just allocating another CPU. I have run 4-CPU systems without problems. But you have to look out for synchronization mechanism. Our CPU uses a cache-coherency protocol to discover possible breakage of an atomic operation so I had to write a simple component to emulate that. In summary: It is possible to do this by yourself but clearly some framework support could be useful (like an ethernet class you could subclass to implement the specifics). /Mikael -----Original Message----- From: sid-owner@sources.redhat.com [mailto:sid-owner@sources.redhat.com] On Behalf Of kobi maller Sent: Monday, March 28, 2005 4:18 PM To: sid@sources.redhat.com Cc: kobi_maller@hotmail.com Subject: Future of SID Friends, I was wondering what are the future plans for SID. I have tried it, for study purpose, and I was able to run an arm program. But I need to make more complex designs, an N-way SMP for example, or to=20 test DMA effects on program performance etc. There are no examples showing how to configure such boards, (except a=20 mailing thread or two talking about SMP). I looked for components such as a TLB that I could plug on the bus, or DMA controller that I can use to=20 generate IO traffic, but could not find any. Are there plans to extend the list of supported components, beyond the basic components of an embedded system board? Are you planning to add examples for setting various type of boards ? (This= =20 is very very important, especially for me, as I am no expert on board=20 design). What about the support for 'bochs' (x86). Are you going to continue work on= =20 that when new 'bochs' is released? The bottom question is what are you planning for the next couple of years=20 for SID. Is it going to develop toward a general purpose simulation tool,=20 one that can be used by the research community (need more components,=20 examples, diagrams) or remain a special purpose simulator for arm based=20 processors? Thanks a lot. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now!=20 http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/