Subject: Re: [sv-ec] More on clocking domains and related stuff...
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Jan 29 2003 - 13:25:17 PST
> From: "Stefen Boyd" <stefen@boyd.com>
>
> Given some more thoughts (i.e. nightmares) about clocking
> domains all the related stuff (cruft?)...
>
> After my comments, I've got some proposals that fix
> the problems with clocking domains, remove the need for the
> separate verification phase, and remove the need for a
> program block.
>
> I see that we need to go one of two directions with
> the clocking domains:
> * Get rid of them because they aren't needed and
> they aren't necessary to access the design.
> * Fix them so they really provide an extensible way
> to access the design.
>
> 1) It's too verbose
....
>
> 2) It forces the addition of the design phase
....
>
> 3) It isn't extensible
....
>
> 4) What I'd like to see
> * Shorthand notation for interfaces
> The only value of clocking domains is to allow easy
> *non-zero* setup samples and driving holds.
....
>
> * implicit interface modport connections
> The previous unification of clocking with interfaces makes
> clocking domains extensible, but doesn't solve the verbosity
> problem. You still have to write clocking_domain.signal Although
> using really short clocking domains helps reduce the typing, the
> names become useless. What I would like to see is the ability
> to use an interface in a way that exposes the signals of
> that interface's modport so they can be accessed without the
> hierarchical reference.
>
> Proposal:
> Instances may use an interface with a modport and make
> all the signals of the modport available in the same
> scope.
> Example:
> module chip_test(simple_bus.tb(.*));
> ...
> endmodule
> Rules
> > If the modport names clash with other
> identifiers at the module scope (including
> other implicit modports), an error will be
> generated.
>
> * ##0
> The problem with the program block is that it solves
> a general problem in a very restricted and limited way.
> The biggest reason for it's existence is that it provides
> a special place to execute code in the verification phase.
> The problem of needing to wait for a "stable" point
> in the simulation is a general one. Dennis B. and Jay have
> mentioned that this is a general request they often receive.
> I submit that what we need is to simply define a new part
> of the event queue, just before rosync. In the HDL you
> could reach this by using ##0. Presumably, the PLI will
> be enhanced to support waiting until this time. Assertions
> could be defined to wait until this time to evaluate.
As I mentioned before I'd like to move the program block down into modules
and make it a special process, and maybe (similar to your modport suggestion)
bind a clock/clocking-domain to it:
module foo;
...
program @(posedge clk1) begin
...
end
...
BNF something like:
program_block ::= program [@(<clock>)] <statement>
Within the program block signals would have the value read prior to the
clock edge at the equivalent of <clock>.new (see my previous post #543),
I'm not convinced it's necessary to change the behavior of any assignments
with this approach since it doesn't look for a "stable" condition after
the clock.
Note: It isn't necessary to make <clock>.new visible to the user. If you
don't want to add "program" as a keyword just use "initial".
I think some of the problems with design/verification phase come from
having the testbench operate through PLI where it is impossible to detect
a signal is about to change, bringing the testbench functionality into the
simulator makes that possible and simplifies the problem.
Regards,
Kev.
>
> Regards,
> Stefen
>
>
> --------------------
> Stefen Boyd Boyd Technology, Inc.
> stefen@BoydTechInc.com (408)739-BOYD
> www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 13:29:08 PST