Subject: RE: [sv-ac] comments on Surrendra's corrections
From: Bassam Tabbara (bassam@novas.com)
Date: Fri Nov 07 2003 - 14:54:37 PST
Surrendra, I don't think it is clear enough. "mclk" is shown, so it is
natural for the reader do "sample" again based on the waveform (the
waveform is similar to the earlier ones that explain the sampling.... If
mclk is taken out then yeah it is clearer...).
I still say: It does not seem that much of a change to just push the
edge a teeny bit back so everyone is happy ... Is it ?
Thx.
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of John Havlicek > Sent: Friday, November 07, 2003 1:51 PM > To: Surrendra.Dudani@synopsys.com > Cc: sv-ac@eda.org > Subject: Re: [sv-ac] comments on Surrendra's corrections > > > Surrendra: > > Maybe this is o.k. I understand the need to keep the diagram > simple, but when I looked at it I thought everything was > shifted off by a cycle. > > However, there is a practical consideration, which is, what > will people actually see in waveform viewers? I am concerned > that the convention you suggest is at odds with this. > > J.H. > > > > > X-Sender: dudani@us04.synopsys.com > > Date: Fri, 07 Nov 2003 15:44:19 -0500 > > From: Surrendra Dudani<Surrendra.Dudani@synopsys.com> > > Sender: owner-sv-ac@eda.org > > Precedence: bulk > > > > <html> > > Hi Bassam,John<br> > > Regarding Fig. 17-12, the values shown are sampled values of the > > signals. The LRM explains what sampled values are in Fig. 17-1. In > > Fig. 17-3, simulation values are explicitly shown for value change > > expressions. Once explained, the LRM doesn't show the raw > simulation > > values of signals. All values are sampled with respect to the clock > > and shown.This is also mentioned again<br><br> <font > face="Times > > New Roman, Times">Each time a data phase is true, a match for > > </font><font face="Courier, Courier" size=2>data_phase </font><font > > face="Times New Roman, Times">is recognized. The attempt at > clock tick > > 6 is illustrated<br> in Figure 17-13. The values shown for > the signals > > are the sampled values with respect to the clock. At clock<br> > > tick 6, </font><font face="Courier, Courier" size=2>data_end > > </font><font face="Times New Roman, Times">is true because > > </font><font face="Courier, Courier" size=2>stop > > </font><font face="Times New Roman, Times">gets asserted while > > </font><font face="Courier, Courier" size=2>irdy > > </font><font face="Times New Roman, Times">is asserted.<br><br> > > </font>I think when a figure appears like a waveform, > perhaps, people > > associate it with simulation values, not sampled values. <br> > > There used to be a big note about this, but somehow it > disappeared (don't > > know why).<br> > > Should we add back a note explaining that after Figure > 17-1, all values > > are sampled values?<br><br> > > Surrendra<br> > > At 12:08 PM 11/4/2003 -0800, you wrote:<br> > > <blockquote type=cite class=cite cite>Hi John,<br><br> > > Thanks for catching this! Yes you are right I think the burst_mode > > edge<br> > > *needs some pushing to the left, that would be the minimal change > > to<br> > > this figure*,(the default here is the #1step sampling so this needs > > a<br> > > push). I think we caught this in Figure 17-1 a while back > with the<br> > > "req", let's update all of 'em, we missed these.<br><br> > > ** I agree with all of John's corrections (1.17, <statements>; > > already<br> > > has a semicolon).<br><br> > > Good catch John, this would've been one huge headache!<br><br> > > -Bassam.<br><br> > > --<br> > > Dr. Bassam Tabbara<br> > > Technical Manager, R&D<br> > > Novas Software, Inc.<br><br> > > <a href="http://www.novas.com/" > eudora="autourl">http://www.novas.com><br> > > (408) 467-7893<br><br> > > > -----Original Message-----<br> > > > From: owner-sv-ac@eda.org > > [<a href="mailto:owner-sv-ac@eda.org" > eudora="autourl">mailto:owner-sv-ac@eda.org</a>] > > On <br> > > > Behalf Of John Havlicek<br> > > > Sent: Sunday, November 02, 2003 9:35 AM<br> > > > To: sv-ac@eda.org<br> > > > Subject: [sv-ac] comments on Surrendra's corrections<br> > > > <br> > > > <br> > > > All:<br> > > > <br> > > > Below are my comments on Surrendra's suggested changes in <br> > > > SV_AC_LRM_corrections_10.12.pdf.<br> > > > <br> > > > Best regards,<br> > > > <br> > > > John H.<br> > > > <br> > > > > ==============================================================<br> > > > ==========<br> > > > <br> > > > 1.1 I agree.<br> > > > <br> > > > 1.2 I agree.<br> > > > <br> > > > 1.3 I agree.<br> > > > <br> > > > 1.4 I agree.<br> > > > <br> > > > 1.5 I agree.<br> > > > <br> > > > 1.6 I agree.<br> > > > <br> > > > 1.7 I agree.<br> > > > <br> > > > 1.8 I agree.<br> > > > <br> > > > 1.9 I agree.<br> > > > <br> > > > 1.10 I agree, but I'm not happy about the way the picture <br> > > > fig 17-12 seems to confuse the > > sampling of values. <br> > > > Sampling at mclk, it > looks to me as > > though $fell burst_mode<br> > > > should be true at time > 3, not time > > 2. Etc., etc., etc.<br> > > > <br> > > > I think the same goes for fig > > 17-11. <br> > > > <br> > > > What do other people think?<br> > > > <br> > > > 1.11 I agree. With this change, the definition > of property r2 > > is<br> > > > the same as that of > property r3. > > However, I think that <br> > > > <br> > > > > property r3;<br> > > > > > > @(posedge mclk)(q != d);<br> > > > endproperty<br> > > > always > @(posedge > > mclk) begin<br> > > > > &nbs > p; if > > (a) begin<br> > > > > &nbs > p; > > q <= d1;<br> > > > > &nbs > p; > > r3_p: assert property (r2);<br> > > > > > > end<br> > > > end<br> > > > <br> > > > should be<br> > > > <br> > > > > property r3;<br> > > > > > > @(posedge mclk)(q != d);<br> > > > endproperty<br> > > > always > @(posedge > > mclk) begin<br> > > > > &nbs > p; if > > (a) begin<br> > > > > &nbs > p; > > q <= d1;<br> > > > > &nbs > p; > > r3_p: assert property (r3);<br> > > > > > > end<br> > > > end<br> > > > <br> > > > 1.12 I agree.<br> > > > <br> > > > 1.13 I agree.<br> > > > <br> > > > 1.14 I agree.<br> > > > <br> > > > 1.15 I agree, but change "atleat" to "at > > least". I have already said<br> > > > that I think these figures are > > misleading representations of the <br> > > > signal sampling.<br> > > > <br> > > > 1.16 I agree, same caveat about the sampling in the > diagrams.<br> > > > <br> > > > 1.17 I agree. Probably there should not be a > semicolon after > > <br> > > > <statements>.<br> > > > <br> > > > 1.18 I agree.<br> > > > <br> > > > 1.19 I agree.<br> > > > <br> > > > 1.20 I agree.<br> > > > </blockquote> > > <x-sigsep><p></x-sigsep> > > <br><br> > > **********************************************<br> > > Surrendra A. Dudani<br> > > Synopsys, Inc.<br> > > 377 Simarano Drive, Suite 300<br> > > Marlboro, MA 01752<br><br> > > Tel: 508-263-8072<br> > > Fax: 508-263-8123<br> > > email: Surrendra.Dudani@synopsys.com <br> > > **********************************************</html> >
This archive was generated by hypermail 2b28 : Fri Nov 07 2003 - 14:55:18 PST