Hello jothsna and Riazi, I've assembled together all of your different responses because they have relatioships to each other. To jothsna - The answer to your question depends on the chip vendor's definition! I'm accustomed to a definition which is in respect to the strobe <<output>> pin, but Mr. Riazi's definition for a source-synchronous design seems to be in respect to the strobe <<input>> pin, that's why he has both Tco_data and Tco_strobe (see his answers to me). I also understand that he refers to a design in which the strobe signal is used to capture the data on the <<opposite edge>> than the edge on which the data is transmitted. <<I>> refered to a source-synchronous bus which samples the data at the receiver on the same dege as the one used to transmit the data. Regards -------------------------- jothsna R wrote: > > > Hi Itzhak, > What does Tco physically mean. Is it the delay of data signal within the chip > with respect to the strobe signal as seen at the pin. > > thanks, > student. To Abe Riazi - My response above to jothsna is relevant also to you! Abe Riazi wrote: > Hi Itzhak: > > Please find inserted my replies to each of your comments. > I have added defintion for "Tdelay" which you asked about as part of your > comment #2. > Itzhak Hirshtal Wrote > > > > Here are some comments, which I hope will be valuable: > > > > (1) It seems to me that the source-synchronous method requires the data > bits to be > > transmitted a little AFTER the strobe signal, otherwise you'll probably > find it difficult > > to avoid setup AND hold violations. Don't you agree? > > > > No. > > Every source synchronous design I have expreienced have either > transmitted the data and strobe simulataneously or strobe being after the > data. The latter is especially desirable when the goal is to center the > edge of > strobe at middle of the data signal for optimium performance. See my response to jothsna above. > > > Additionally, in order to avoid timing degradation across variations of > temperature, voltage and process; it is essentail for PCB routing > topologies of data and strobe to be identical (and on the same board > layers). > > > > (2) Also, it seems your equations for the source-synchronous method > contain some errors and > > inappropriate parameters: > > - Tco_strobe is not a usable parameter; what is it referenced to? As I > understand it, > > only Tco_data is relevant, and it is referenced to the strobe signal > itself in the data > > sheet. > > - What is Tdelay exactly? Can you explain? It seems a non-relevant > parameter as well. > > - One must use Tco_min in the hold equations (for source-synchronous > as well as common > > clock). I shall call this parameter Toh_data. > > - In my opinion, the 2 equations should be: > > > > Tsetup_margin = Tcycle + Tflt_strobe - Tco_data - Tsetup - > Tflt_data > > > > Thold_margin = Tflt_data - Tflt_strobe + Toh_data - Thold > > > Your setup and hold equations have omitted Tco_strobe, and Tdelay > paramteres; however, several documents > (including book by Stephen H. Hall, et al.) indicate these timing paramters > need to be preserved in the source synchronous timing fromulas. > > Tco (time from clok to ouput) represents time required for a bit (data or > strobe) to appear at ouput of a latch (or buffer) after it has been clocked > in. > Tco_strobe, and Tco_data usually have different values. See my response to jothsna above. Tdelay equals delay between data and strobe clocking and, Tvb = Tco_data - (Tco_strobe + Tdelay) Where, Tvb (called valid before) is time interval that data signal is valid before strobe. > > > > > > (3) You haven't mentioned the opposite direction equations, which are > different for the > > source-synchronous case (Tflt_strobe sign is inverted). > > > True > > I referred to one direction in order to keep the discussion simple. > However, in reality the bus agents can be bi-directional and we should > remember: > > i. Tco_strobe and Tco_data are driver parameters. > ii. Tsetup and Thold belong to receivers. > > > > > (4) To be very accurate one must use the minimum and maximum parameters > and simulation > > results as appropriate. > > > Correct! > > Again, for purpose of simplicity, I had assumed a nominal corner and > constant values for Tco_strobe, Tco_data, Tflt_strobe, and Tflt_data. > However, each of these paramters can have different Minimum, Typical > and Maximum values. > > Subsequently, for worst case analyses, the (Tflt_strobe - Tflt_data ) > expression in setup equation becomes (Tflt_strobe_min - Tflt_data_max ). > Similarly, (Tflt_data - Tft_strobe) in Hold equation gets replaced by > (Tflt_data_min - Tft_strobe_max). > > The nominal Tco_strobe and Tco_data also need to be properly replaced > by their minimum or maximum values. > > > > > > (5) I would like to comment on the solution you propose for setup and hold > failures. It is > > very difficult to compensate for them by lengthening or shorting the data > traces, since > > they are generally numerous. It is much easier to do the same for one of > the clock signals, > > thus generating a deliberate skew. This, of-course, assumes the problem is > one-way, and the > > solution does not cause a new problem. > > > > > When there are a group of data signals sharing the same strobe and only one > or two of the data signals fail setup margin, then it is preferable to > shorten the data signal(s). However, when many or all of the signals fail > setup it > is desirable to lenghen the strobe signal. > > Similar reasoning can be applied to Hold margin failures to ascertain which > is simpler - lenghtening data or shortening the strobe. > > I agree with your comment that for a bi-directional bus, when fixing timing > problems of one direction we need to ensure that violations will not occur > when signalling in opposite direction. > > > > (5) The Interconnectix (ICX) simulator also provides a means for > automatically compensating > > for the load difference between the test load and the actual PCB trace > load. But this > > method depends, of course, on the manufacturer to supply the appropriate > test load > > parameters. Since the IBIS model, on which ICX simulations are based, > assumes a certain > > configuration of test capacitance and resistance, this presents a problem > where the > > manufacturer uses a different configuration. For example, I encountered a > manufacturer who > > claimed he used a current-source test load, with a different current load > for the high and > > low states of the tested outputs. I had to use approximations in order to > be able to > > simulate these outputs using an IBIS model. Has anyone encountered such a > problem and have > > a solution? > > > I had mentioned XNS becasue of familiarity with the software. It is possible > that other prgrams such as ICX can also automatically compenstate for the > buffer delays. The important point is that we need to understand our tool > and know whether this delay subtraction is to be achieved automatically or > manually. > > The test load parameters (Cref, Rref, Vref, Vmeas) have been previously > discussed in this forum, for example "Looking Inside IBIS Model", > dated May 15, 1999. > > Best Regards, > > Abe Riazi > ServerWorks -- Itzhak Hirshtal Elta Electronics POB 330 Ashdod Israel 77102 Tel : 972-8-8572841 Mobile: 972-64-238631 Fax : 972-8-8572978 email: hirshtal@xxxxxxxxxxxxx ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu