RE: [sv-ec] More clocking block issues

Jonathan,

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. 

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!

Dave


> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com]
> Sent: Wednesday, April 11, 2007 3:13 AM
> To: Rich, Dave; sv-ec@server.eda.org
> Subject: RE: [sv-ec] More clocking block issues
> 
> Dave,
> 
> I agree that this isn't covered, and should be.
> 
> > If I have a clockvar output whose target is a variable
> > bit vector, and within a given clock cycle I only drive
> > a part or bit select of that clockvar, do the undriven
> > bits use their previous value?
> 
> Similarly for any packed thing.
> 
> My personal opinion is that it should be illegal to drive
> such selects.  I imagine the clockvar to be "hiding" the
> specific structure of the target variable, and I'm entirely
> OK with that; clocking blocks already hide many aspects
> of the target - its timing, the specific clock expression
> with which it's synchronized, whether it's a net or a
> variable - from the testbench.
> 
> Suppose, for example, we had a target that was a
> concatenation:
> 
>   clocking cb...
>     output #1 controls = {Rd, Wr, Mode[4:2]};
>   endclocking
> 
> What does it mean to do
>   cb.controls[2] <= 1'b1;  ??
> 
> I'd be much happier not to get enmired in that discussion;
> it's already caused much headache on sv-ac where they're
> trying to come up with a way of bit/part-selecting arbitrary
> expressions.
> 
> For most users, my preferred restriction that a clockvar
> cannot be part-selected or otherwise decomposed is at
> worst a minor inconvenience.  It encourages the idea that
> you should prepare your desired clocking drive value in
> an auxiliary variable and then drive it out to the
> clockvar all of a piece, which I suspect is pretty good
> guidance anyway.  If you want to control things
> independently, put 'em on distinct clockvars.
> 
> > A similar question for unpacked structs and arrays:
> > If a member of an unpacked type is selected in a clockvar
> > drive, then should the entire target variable be assigned
> > with previous values of all the other clockvar members?
> 
> Again, I'd prefer it if this were forbidden.  If people
> want individual access to elements of an unpacked thing,
> they can create a distinct clockvar for each element.
> --
> 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.