RE: Co-simulation with SID

["Robert Cragie" <rcc@jennic.com>]

> > 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