RE: [sv-ec] More clocking block issues

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Thu Apr 12 2007 - 14:34:58 PDT
[Dave Rich]
> If I have to create a separate variable that maintains what's being
> driven by my clockvar output, then I'll have to keep track of when I
> write to its value so it can be assigned to the clockvar in the
> appropriate cycle. I might as well then not even use a clockvar output
> in the first place since that's essentially what it supposed to do for
> me. 

Yes, but I'm questioning why you want to be able to mess with 
individual elements of a packed thing through a clocking drive.
Seems like you're breaking the encapsulation that clockings
provide, to an extent that I find undesirable.

> Now about unpacked types, I don't really see people trying to use a
> clocking block to drive a large memory; it would be a shame if I had a
> small array of ports and was required to flatten them out for 
> a clocking block. That's like so 1995!

Agreed.  But doesn't this potentially cause some problems when 
there is an expression alias (or whatever it's called) for the 
clocking target signal?  Given
  
  bit target[0:9];  // 10-element unpacked array
  clocking c @...;
    output target_slice = target[4:6];
  endclocking

what does it mean to drive c.target_slice[5] ??  I don't 
think we have solidly defined the notion of the data type
of the clockvar in this case.  However, if you're happy 
that this can be resolved robustly, then I have no 
problem with the idea of clocking drives to components of
an unpacked object.

-- 
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 12 14:35:27 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 12 2007 - 14:35:46 PDT