Co-simulation with SID

Co-simulation with SID

[Robert Cragie]

I read in the SID Faq-O-Matic that SID has been used with an HDL Simulator.
Can anyone give me more details on what work was done here and if it is
likely to be included in the open source project? Or give me some pointers
as to how I might go about developing 'proxy' components which would
interact with an HDL simulator?

TIA

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655

Re: Co-simulation with SID

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hi -


On Mon, Sep 02, 2002 at 03:05:59PM +0100, Robert Cragie wrote:
> I read in the SID Faq-O-Matic that SID has been used with an HDL Simulator.
> Can anyone give me more details on what work was done here 

There was a prototype sid component that, in conjunction with a special
startup shell, interfaced a Synopsis HDL model of some peripheral to a
running SID model of an encompassing computer.  It was a little prototype
of a specialized protocol bridge.  It worked okay, from what I recall.


> and if it is likely to be included in the open source project? 

This is unlikely.  A baby prototype dealing with a third-party 
proprietary tool would not help an open-source project. :-(


> Or give me some pointers as to how I might go about developing 'proxy'
> components which would interact with an HDL simulator?

The size of such bridging code may not be too large, provided that
one designs a decent mapping between the SID and HDL abstractions.
Issues to consider involve whether a slave/master or peer-to-peer
relationship is more appropriate; embedding one sim within another
vs. running separately; how/whether to synchronize simulated time;
configuration & startup.

What do you have in mind?


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Co-simulation with SID

[Robert Cragie]

> > and if it is likely to be included in the open source project?=20
>
> This is unlikely.  A baby prototype dealing with a third-party=20
> proprietary tool would not help an open-source project. :-(

OK, I understand.

> The size of such bridging code may not be too large, provided that
> one designs a decent mapping between the SID and HDL abstractions.
> Issues to consider involve whether a slave/master or peer-to-peer
> relationship is more appropriate; embedding one sim within another
> vs. running separately; how/whether to synchronize simulated time;
> configuration & startup.
>
> What do you have in mind?

I've only given it a fairly cursory consideration up to now but have also
come up with the same sort of issues about how to run the two sims together.

My idea is to have some sort of proxy component in SID which connects into a
SID target system as usual using pins, accessors etc., but when accessed by
an application running on SID, it will bridge to an HDL model running in a
commercial HDL simulator like Synopsys or whatever.

I imagined running the two simultaneously essentially in a peer-peer
configuration. SID can initiate transactions on the HDL simulated device and
the HDL simulated device can initiate transactions to SID. This level of
abstraction could support a wide range of peripheral types. A derivation
from the abstract would be a slave peripheral type where SID would initiate
register access transactions and the HDL simulator would initiate interrupt
transactions. I envisaged using sockets for this.

However, there is obviously an issue here of synchronising them in a time
sense, plus I'm not even sure if you could do this using commercial HDL
simulators; we tend to use Verilog, which has the PLI; it may be possible to
use this somehow, but I haven't worked out how yet.

An alternative idea would be to somehow slave SID off the HDL simulator,
i.e. get the main loop clock from the HDL simulator somehow, and slave all
operations off that. This sounds good in theory, but it could be horribly
slow in executing the software.

I'll investigate the sockets approach a bit further and consider if it might
be possible.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655