RE: [sv-ec] Transition bins of length 1 -> disallowed. New Mantis 1787

From: Warmke, Doug <doug_warmke_at_.....>
Date: Thu Apr 26 2007 - 16:19:28 PDT
Hi Neil,

This is a matter of language in what "single value transition" means.

By our terminology, what you are describing is a transition of length 2:
it has value1 followed by value2.

What we are trying to avoid was transitions of length 1, with only
a single value -- thus the same as a state bin, not a transition bin.

I figure a little extra clarity can't hurt here.
Otherwise the user is left to infer the intention from that
solitary "value1 => value2" line in the LRM.

Thanks,
Doug

> -----Original Message-----
> From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM]
> Sent: Tuesday, April 24, 2007 3:20 PM
> To: Warmke, Doug
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Transition bins of length 1 -> disallowed. New
Mantis 1787
> 
> Hi Doug,
> 
> Isn't this already covered by the following text in the current LRM?
> From sub-clause 18.4.1
> 
> "A trans_list specifies one or more sets of ordered value transitions
of
> the coverage point. A single value transition is thus specified as
follows:"
> 
>    value1 => value2
> 
> Neil
> 
> 
> 
> 
> > Clause: 18.4.1
> >
> > At the end of Section 18.4.1, ADD the following new paragraph:
> >
> >
> > Transition bin specifications of length 1 are disallowed.  These are
> > transition bin specifications containing a trans_set production of a
> > single range_value, e.g.,  "(0)" or "([0:1])", or a single
range_value
> > with a repeat_range evaluating to 1, e.g., "(0[*1])" or
"([0:1][*1])".
> >
> >
> 
> 
> 
> Warmke, Doug wrote On 04/21/07 20:54,:
> > Hello SV-EC,
> >
> > I just entered a new Mantis with a simple proposal to disallow
> > transition bins with only one value (length 1).  That doesn't really
> > make sense, since with only one value there is no transition
possible.
> >
> > http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001787
> >
> > Regards,
> > Doug
> >
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 26 16:19:49 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 16:20:20 PDT