Subject: re: Axis feedback / enhancement of sce-mi
From: Pryor, Duaine (duaine_pryor@mentorg.com)
Date: Fri Dec 20 2002 - 10:03:07 PST
Jason,
Thanks to you and your team for taking the time to
provide detailed feedback on the SCE-MI proposal.
I'm going to divide my response into three areas
of discussion that your comments span.
Area 1. This is where the document can be made more clear
and some of what you state may just be some misunderstanding
as to its original intent. Most probably such discussion will
belong in the tutorial section rather than the formal specification
itself. Such discussion can also include motivations.
Area 2. This is where it needs to be made more evident whether
Axis or other vendors can implement a specific feature. We can
probably just communicate these issues via e-mails rather then
updates of the specification or the tutorial.
Area 3. Areas in which you suggest improvement that we should
definitely consider for the next version of the modeling interface.
I have annotated my responses to your specific comments with
what areas above that they fall into.
Jason wrote:
> ----------------------------------------------------------------
> Section 2.1.1
>
> Multi-threading relies on SystemC or the user to implement their own
thread
> library.
This falls into area 1.
There may be a slight miscommunication between you and
the document writer here. This probably points out a couple
areas where we might want to make the document more clear.
Most probably this clarification will go into the tutorial
rather than the normative section.
It was precisely the intent of the design of this API to separate the
communication API itself from any native threading system. The advantage
of the SCE-MI API is that it can, and has been applied to a variety of
multi-threaded environments including CoWare, SystemC, TestBuilder,
POSIX pthreads, etc.
It was intentionally designed to be "thread capable but thread neutral".
Adding a threading API as you suggest may be desirable but it should
be an independent library that can be evaluated along with a
multitude of already emerging standards. I don't think it
belongs in a communication API.
Jason wrote:
> SCE-MI requires users to call the ServiceLoop() function to
> give processing time to SCEMI.
This again falls into area 1.
Yes, this is the "hook" by which you can couple to arbitrary
threading systems. Doing it this may makes it easy to place
in a "dispatcher" thread of any threading system.
Doing it as you suggest requires the SCE-MI kernel
to somehow have knowledge of the SystemC kernel
or any other.
Jason wrote:
> ----------------------------------------------------------------
> Hardware Interface
>
> The clocking is the most restrictive portion of the specification
> because it contains hardware dependent information and far too
> much detail. [...] Any discussion about the relationship between
> the testbench clock and the emulator clock should not be part of
> the spec.
> [...]
> The spec should allow for implementations that to not require the
> user to learn about the relationship between the controlled clock
> and the uncontrolled clock.
These fall into area 3.
Controlled and uncontrolled time is a "lowest common denominator"
over which any clocking scheme can be built.
It provides a way of essentially suspending emulator time
much the way a software Verilog kernel suspends sim tick time.
The scheme you propose has some merit and, in fact one can
propose a higher level interface the is predicated on controlled
time only - or perhaps we should just say "conventional time".
Some of us have been having side discussions along similar lines
and I think that people would be quite receptive to a follow-on
standard which incorporated such improvements.
In fact, one can argue that a C function call based standard such as
the one being worked in the SystemVerilog effort now is just such
a standard.
However, one can always implement a controlled time view of
the world on top of the clock suspension view that SCE-MI presents
today. What the uncontrolled time was designed to bring to
the table is a means to implement a speed gasket in environments
where otherwise free-running emulator clocks needed to be time
sync'ed to potentially slower performing execution of software
models.
One pitfall in the event based approach you're suggesting is that
you can potentially go beyond just a transaction accurate interface
between the emulator and the host simulator and end up with
much lower performing event driven co-simulation. SCE-MI we design
explicitly to avoid this pitfall and one can argue that by forcing
only transaction accuracy, it encourages higher performing
implementations.
Jason wrote:
> ----------------------------------------------------------------
> Infrastructure Linkage
>
> [whole section]
This falls into areas 1, 2.
The philosophy here was to create a complete source code based,
Verilog legal way of fully specifying the interface connecting the
C side then letting an outside compiler automatically derive
the infrastructure elements required for the interface.
This eliminates the need for complex user defined "configuration
files". It makes the HDL portion of the design fully self contained
and it fully and unambiguously specifies the interface right
from legal Verilog or VHDL code by defining simple "entrypoints"
into the HDL design in terms of the message ports contained
in transactors.
It is very similar to the approach TestBuilder took
with their $tbvConnect() tasks except that it is
structural and therefore more intuitive to users.
----------------------------------------------------------------
Parameter File
This falls into area 2.
A parameter file is not required it is only a suggestion.
It can be a config directory, a single file are or any other
mechanism. It's only purpose is to allow identification of
a named compiled configuration for the interface to a
particular HDL design. What goes into the configuration
file or directory is totally implementation dependent.
As far as the API to the parameters database, this is
convenient for gaining C access to static information
about the communication channels that were specified
on the HDL side.
John Stickley and Duaine Pryor
Mentor Graphics
This archive was generated by hypermail 2b28 : Fri Dec 20 2002 - 10:03:18 PST