> When coming out of reset ( a likely case ), the simulation-only run of > a model may propagate Xs and U's such that the simulation will fail > whereas on an emulator, these may default to 0's and 1's and allow the > simulation to pass. That is one common scenario. Right, that was one case I was thinking of. > Do we need to address this? It could get a little complicated. Yes, it could. That's why I wanted to qualify your original statement to say that the goal should be to make it possible to write transactors that can run without change in both simulation and emulation rather than what I thought was a stronger statement. > I've always felt it's important to address the simulation-only mode > in SCEMI. The question is; how deep do we go? Big question. But when you say `simulation-only mode' you're not just talking about simulating SCE-MI transactors as they are written today. The problem is solved if you're willing to write your transactors using synthesizable RTL code and qualify your code on all the platforms you want to use. But I'm sensing you actually define `simulation-only mode' as something more than that. > No, that is not what I meant at all. What I said was, in order to be > able to run in simulation-only mode, the "whole" transactor model (sw > side and hw side) ought to consist of LRM compliant HDL (on the hw side) > and C/C++ (on the SW side). Ok, that's what I thought, but I had to make sure. It was not obvious to me. So all you're really stating is that SCE-MI shall not require language extensions on neither side, right? Or am I still missing something? > Hmm, we've always used the term "transactor" for the whole tool > -- sw side and hw side. At Zaiq we used to use `transactor' in the same sense as SCE-MI, but over the years there has been a trend to include portions of the software side, i.e., the `proxy model' in what is considered the transactor. We have been getting away with not doing this because we have standardized the interface to the transactors at a higher level and use a common library to implement this interface. Hence, the portion of the proxy model that is unique to each transactor is extremely thin, and in fact non-existent in many cases. > When someone calls me and asks "do you have a transactor for the > XYZ bus?" if I were to say, "yes, and I also have a proxy model" > that would cause a lot of unnecessary confusion. Actually, that is not so crazy as it might sound because the software side is dependent on the language environment being used. > But you're right, the spec defines it to be the hw side only. I > guess I just don't like the term "BFM", but I'll drop this point > until/unless we take up writing a new glossary for the new spec. I doubt it is worth our time to change the definitions in the glossary at least at this point. But it is a common point of confusion so we should consider it. Per -- Per Bojsen Email: <bojsen@zaiqtech.com> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com 78 Dragon Ct. Tel: 781 721 8229 Woburn, MA 01801 Fax: 781 932 7488Received on Fri Apr 1 11:13:10 2005
This archive was generated by hypermail 2.1.8 : Fri Apr 01 2005 - 11:13:13 PST