System Verilog Clocking

[terabits]

Hi

Is there anyone using modelsim's questa for system verilog,
im not sure if it is the problem of questa or system verilog itself
but.....below code is not supported

clocking cd2 @(posedge busb.clk);
input #2 output #4ps busb.cmd;
input busb.enable; // this one to be specific...if input enb =
busb.enable it says unsupported but fine
endclocking

any one faced similar problem ?
is it compulsory that we need to use clocking blocks along with program
block only, i am seeing strange behaviour if i use it outside i mean
part of a interface, .......
please let me know where can i find errata about such problems with
system verilog !!!!


regards.

 

[Jonathan Bromley]

On 9 Jan 2007 13:41:26 -0800, "terabits" <tera.bits@gmail.com> wrote:

im not sure if it is the problem of questa or system verilog itself
but.....below code is not supported

clocking cd2 @(posedge busb.clk);
input #2 output #4ps busb.cmd;
input busb.enable; // if input enb = busb.enable it says unsupported but fine
endclocking

any one faced similar problem ?

The names of clockvars must be simple names. If you want
to use the clockvar to talk to a signal with hierarchical name
then you must use the syntax
input[output] #2 clockvar_name = dotted.signal.name;

Whichever SystemVerilog tool you use, you will find some
unsupported constructs. The situation improves with each
new version of the tools.

is it compulsory that we need to use clocking blocks along with program
block only, i am seeing strange behaviour if i use it outside i mean
part of a interface, .......

Not compulsory, but VERY advisable... Follow these rules and you
will be safe.

* The clock event for a clocking block MUST come from a signal
that's controlled by code in a module or interface. DO NOT
use a program's variable as the clock signal for a clocking.
* The signals that are connected to a clocking block as
inputs and outputs should be signals in a module or interface.
DO NOT use a clocking block to read or write signals in
a program.
* Read and write clockvars (using the clocking_block.signal_name
syntax) ONLY from code running in a program.
* Make synchronous drives to clockvars (using the
clocking_block.signal_name <= expression;
syntax) ONLY from code running in a program, and do it ONLY
at the time of the clocking block's clock event.
* In your programs, wait for the clocking block's clock event
ONLY by using the ##N syntax or by doing @(clocking_block).
DO NOT wait for the clock signal directly.

please let me know where can i find errata about such problems with
system verilog !!!!

The rules about clocking blocks and programs are currently being
revised, because there were some problems with the original
definition. That work is taking place right now. Some of the
"rules" I describe above will no longer be necessary after that
work is standardised.

These and other LRM changes will be published in due course -
I'm not sure about the exact timetable but I think the revised
LRM will be available in late 2007/early 2008.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[JoshforRefugee]

Hi Jonathan, can you help me understand why these requirements? I
intuitively understood them, but never have enough technical details to
have a smart conversation on it. Thanks again.

* The clock event for a clocking block MUST come from a signal
that's controlled by code in a module or interface. DO NOT
use a program's variable as the clock signal for a clocking.

* The signals that are connected to a clocking block as
inputs and outputs should be signals in a module or interface.
DO NOT use a clocking block to read or write signals in
a program.

* Read and write clockvars (using the clocking_block.signal_name
syntax) ONLY from code running in a program.

* Make synchronous drives to clockvars (using the
clocking_block.signal_name <= expression;
syntax) ONLY from code running in a program, and do it ONLY
at the time of the clocking block's clock event.

* In your programs, wait for the clocking block's clock event
ONLY by using the ##N syntax or by doing @(clocking_block).
DO NOT wait for the clock signal directly.