RE: [sv-ec] More clocking block issues

I'm not a big fan of clocking blocks, and given that no users have been
heavily complaining that they aren't full supported in the tools out
there, I don't have a strong opinion on this subject, but....

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Thursday, April 12, 2007 2:35 PM
> To: sv-ec@server.eda.org
> Subject: RE: [sv-ec] More clocking block issues
> 
> [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.
[DR>] If you need to programmatically address the bits of the clock var.
Suppose you had a packed or unpacked array of request bits, each
controlled by a separate driver. You want to drive the bit with a
statement like
     cb.req[idx] <- '1;
where idx is set during the construction of the class
> 
> > 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
[DR>] That would be an error, as there are only 3 bits. Customary SV
practices would stipulate that target_slice is defined as a packed
vector [2:0], but this needs to be explicitly defined. 
> 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.
[DR>] This is no different from a port or modport expression, which has
the same issue, do ranges get normalized. 
> 
> --
> 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.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.