Subject: Re: [sv-ec] C Implementation for random number generator
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Fri Mar 14 2003 - 10:19:25 PST
Is this something else that can be re-written in SV and put in a
standard include file?
Kev.
Jayant Nagda wrote:
> Hello David and Fellow SV-EC members,
>
> We understand and respect your request for a donation of our
> implementation of $srandom
> and $urandom. Our implementation is based on the paper "Maximally
> Equidistributed
> Combined Tausworthe Generators" by Peierre L'Ecuyer Mathematics
> of Computation, 65, 213
> (1996), 203--213. A copy of this paper (from
> citeseer.nj.nec/com/cs) has been included
> with this response. While we are happy to provide this reference
> to the implementation
> there are some additional thoughts from the Synopsys point of
> view on this subject.
>
> 1) We cannot officially donate what is already in public domain
>
> Accellera is free to recommend the reference algorithm.
> The following reasons will describe why we think
> donating an specififying an algorithm as part of SystemVerilog is
> undesirable.
>
> 2) Importance of implementation freedom
>
> We like Accellera's approach where EDA vendors are given freedom
> to implement algorithms in the best
> possible way. This provides us freedom to continue to improve
> performance and quality
> of results. In this case, distribution of generated random
> numbers is similar to
> performance of a simulator. We also believe that Accellera has
> been able to deliver
> standards rapidly with this strategy.
>
> It is our belief that by including the implementation of a
> specific algorithm as part of
> standard will be a more limiting factor than any use.
>
> 3) Use of repeatability in random stimulus
>
> Based on our experience with test bench users, users do want
> random numbers to be
> "random". We have found that different distribution of random
> numbers help users even
> uncover bugs. Most test benches are written which are self
> checking. Thus even if
> different versions of testbench tools or simulators will not
> impact the test output.
> Writing test benches which depend on the same random number to be
> generated by all tools
> may limit users ability to find the same bugs all the time. One
> should note that users
> do want different invocations of a given tool or multiple runs
> to be repeatable to be able
> to debug. This is different and supportable without requiring
> specific algorithm
> implementation across multiple vendors. However forcing that the
> same algorithm to be used is
> not needed.
>
> Let me emphasize why what happened with $random is not likely to
> be a problem again.
> I believe $random was used in a very linear fashion so having the
> same code was enough
> for the very simple tests people were using back then. With
> random constraints, the situation
> is very different and the expectation of a simulation matching is
> not even there.
>
> 4) Can user still do that?
>
> The language provides mechanism to bind any system call to C/C++
> implementation. Thus
> $urandom and $srandom can be linked by user to a specific
> algorithm if desired. If a user
> still wants to use a specific algorithm for random generation,
> the user will be able to
> link the same binary library with multiple tools or different
> versions of tools.
>
> Please note that $srandom and $urandom are different thatn
> constraint random generation.
>
> In summary, we decline the request of a reference implementation
> of $srandom and
> $urandom. As participants, we urge you to examine the usefulness
> and need of such
> implementation.
>
> Jayant Nagda
>
>
> -------------------------------------------------------------------------------
>
> Jayant Nagda
> Group Director, R&D
> Verification Technology Group
> Synopsys, Inc.
>
> Tel: 650-584-1502
> Email: jayantn@synopsys.com
> Address: 310 N. Mary Ave, Sunnyvale, CA 94086
>
> -------------------------------------------------------------------------------
>
>
>
> "David W. Smith" wrote:
>
>> Hello Jayant,As the chair for the SV-EC I request that Synopsys make
>> a donation of the C implementation of $srandom and $urandom. This was
>> voted on in today's meeting and the committee voted to request this
>> implementation.There were a number of comments made that the
>> implementation that exists is intimately tied to the constraint
>> solver and an agreement by the committee that donation of the
>> constraint solver would not be appropriate. The primary requirement
>> stated for having a single implementation is to provide repeatability
>> in generating random numbers when not used with a constraint
>> solver.If you could please consider this request and either provide
>> the implementation or, if Synopsys does not wish to make the
>> donation, a statement as to why it is not
>> appropriate.RegardsDavid David W. Smith
>> Chair, SV-EC
>
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 10:19:34 PST