Subject: RE: Axis feedback / enhancement of sce-mi
From: Jason Andrews (jason@axiscorp.com)
Date: Thu Jan 02 2003 - 08:00:58 PST
Duaine,
Thank you for your responses. I am only going to address the
most important issue today and leave the others for later.
The main point for Axis is the clocking macros and
the infrastructure linkage. Please remove these from
the spec as requirements. Our platform has no need for
the clock macros or an infrastructure linker. These may be
fine for a cycle-based emulation system, but are not
necessary for us.
Instead of a "lowest common denominator" why not provide
minimal detail in the spec, only making sure the C and Verilog
interfaces are specified and let each vendor do what is
necessary to implement these for a specified platform?
As it is, you are specifying too much detail and forcing
all vendors to drop to the "lowest common denominator" for
no reason. Please preserve the compatibility for
users and provide the necessary freedom for emulation vendors.
As an example, you mentioned TestBuilder, $tbvConnect().
We should have the freedom to use just such a task to to determine
the interface connections at runtime, not be restricted to use only
structural and figure it out at compile time.
Regards,
Jason
> -----Original Message-----
> From: owner-itc@server.eda.org [mailto:owner-itc@server.eda.org]On
> Behalf Of Pryor, Duaine
> Sent: Friday, December 20, 2002 12:03 PM
> To: itc@server.eda.org
> Subject: re: Axis feedback / enhancement of sce-mi
>
>
> 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 : Thu Jan 02 2003 - 08:04:43 PST