Subject: Re: [sv-ec] More on clocking domains and related stuff...
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Wed Jan 29 2003 - 14:22:20 PST
Kevin,
You are mixing two separate concepts. The clocking abstraction introduces
the notion of a synchronous interface, which has nothing to do with the
program block, predictive edge detection, or PLI limitations. The synchronous
interface allows users to explicitly declare the clocking discipline used by a
particular interface. By moving this description to its declaration, users do not
need to replicate statements like "data <= @(posdege clock);". They simply
write it once and then use the clockvar (note new terminology) to denote the
sampled input. Likewise, there is no need to replicate drive statements
that will move the driven values away from the clock edge (using another clock,
#delay statements, or some other artificial mechanism).
The program block is an abstraction that allows users to denote what pieces
of code are strictly verification code and therefore should not execute intermingled
with the design. There are perfectly good reasons to use a program construct
that does not even require a clock. For example, when verifying or modeling an
asynchronous piece of hardware, such as a memory. On the other hand, there
are many good places where a clocking abstraction can be used as part of the
design to model synchronous interface behavior.
Finally, the current proposal allows you to do almost exactly what you wrote.
programs can be declared and instantiated within a module, so you can certainly
do something like:
module foo;
...
program bar;
clocking xyz @(posedge clk1) ...
endclocking;
...
endprogram
bar b1;
...
Or the much shorter version:
program foo;
...
clocking xyz @(posedge clk1) ...
endclocking;
...
endprogram
...
Arturo
----- Original Message -----
From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
To: <sv-ec@eda.org>; <stefen@boyd.com>
Sent: Wednesday, January 29, 2003 1:25 PM
Subject: Re: [sv-ec] More on clocking domains and related stuff...
> 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 - 14:22:03 PST