Re: [sv-cc] Polls on extern/export and representation of SV data types


Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Mar 11 2003 - 09:12:38 PST


IMHO I would not have this problem, but I might be missing one of your important points here. I will describe this in my response to John
S.'s email, since there is some overlap. There is anyway a lot of email noise here.
-Michael

Joao Geada wrote:

> Michael,
>
> with respect to top-level externs: how would you solve this issue if you were
> not using DPI; ie if you were limited to just SystemVerilog ?
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
> -----Original Message-----
> From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> Sent: Tuesday, March 11, 2003 5:25 AM
> To: Joao.Geada@synopsys.COM
> Cc: sv-cc
> Subject: Re: [sv-cc] Polls on extern/export and representation of SV
> data types
>
> Joao,
> thanks a lot. Comments interspersed. Hope this clarifies my problems a little bit. Kevin might have some more or even better examples.
>
> -Michael
>
> Joao Geada wrote:
>
> > Michael,
> >
> > With respect to externs at top-level, the rules are no different than those
> > that apply to any other SV declaration: you cannot declare the same name
> > twice. Given that SV supports conditional compilation etc, I do not see a
> > compelling reason to violate basic SV rules just for DPI.
> > Of course, I am willing to change this if some can give a convincing reason as
> > to why DPI must have this flexibility.
>
> I agree to your point about compliance with other SV declarations, but I have to say that this is a restriction that I envision as being
> extremely reuse unfriendly. See the following example (currently from hot air, but I have seen sthg. similar already in other contexts):
>
> - Assume you have a company internal bus standard, and there are some C functions used by the related code. So you might have a
> testbench or protocol converter that uses some C code (e.g. for signature calculation, ECC calculation or similar) you have to declare
> as being external.
> - Of course your system need to include multiple instances of this bus/protocol
> - Now assume you have multiple groups providing you one or multiple blocks, all of them are using one instance of this bus
> - You are the poor integrator having to integrate all these blocks
> - Think about a system consisting of about 100 blocks from 7 groups located on 4 continents. I have seen this more than once!
>
> When for whatever reason more than one of these groups or you have decided to locate the blocks in the top-level, you might experience a
> massive amount of error messages due to multiple extern declarations, when the extern declarations are being done outside of other
> blocks. This is also the case when all these extern declarations are exactly matching.
>
> The only way to avoid this is to change the hierarchy of your system (I am sure you don't want to suggest this to a designer) or to
> introduce additional hierarchies, just to avoid those errors. On the other side this is something you very likely want to avoid.
> Everybody within your company should (re-)use the internal standard, which uses these external C functions. As such the bus/protocol
> block is very likely a standalone block that is located near to the top level. It will be only instantiated once (this can be of course
> controlled), but what about the extern declarations usually being done by the other blocks. Do you want to modify the source code 100
> blocks? Some of them you might simply not have write access to ...
>
> IMHO, the proposal is unbalanced here from a usage point of view:
> - everything is O.K. when you bury the extern definitions within lower hierarchy levels
> - as soon as you have a more flat hierachy or you want to reuse blocks containing C code on the top level or you want to define stuff
> at the top level you have to be very carefully not to collide with somebody else's code
>
> This is my problem.

--

NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.

___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \

The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )

*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***




This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 09:13:31 PST