Todd, You are correct that you should calculate the timing based on flight time compensated numbers, or in other words, use the time-to-vmeas. This is the only way that you can correlate your simulation result times with the timing numbers supplied by the IC vendors. I wrote a short application note about this some years ago. You can access it at http://supportnet.mentor.com/reference/appnotes/library/3906.pdf The application note talks about doing these calculations in ICX, but the principle is the same for any simulator. If you have further questions after reading the note referenced, feel free to contact me directly. Regards, Weston -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Todd DeRego Sent: Monday, December 22, 2008 8:14 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Time_to_VM on a clock forwarded interface? I'm trying to figure out the correct way to simulate the flight time of a clock on a clock forwarded interface (SDRAM memory, in this case). We have used XTK previously to extract flight times and are using HyperLynx now but my question is really about the concept and not the specific tool. The data flight time out of the tool makes sense: Tco (related to clock) --> <-- Time_to_VM (based on datasheet AC test load) Simulation Flight Time to SDRAM (based on etch & receiver capacitance) --> But doing the clock the same way doesn't seem right to me since there isn't really isn't a Tco for the clock since the clock represents "time zero" for the rest of the timing. If I just use the simulated flight time out of the tool with no Time_to_VM adjustment, the flight time ends up much longer than the data flight times and breaks the interface. I was thinking the simulated flight time isn't really based on the same "time zero" that I'm applying the Data Tco from. I really want to apply the Data Tco to the time the clock passes through Vmeas (1.25V in this case) not when the tool starts it simulation. Because of this I redid the Time_to_VM simulation for the clock output using 0pF load (versus 15pF load in the IBIS model). The resulting 0pF Time_to_VM is less than the 15pF Time_to_VM (which was making the final result flight time for the clock negative, which would make sense with a positive value Tco but there isn't a Tco for the clock) and makes the clock flight time make more sense compared to the data flight times. In past simulations, we have applied the test load Time_to_VM to clocks in clock forwarded interfaces. But when we couldn't make timing work on this interface and started to look deeper, we are wondering if we should have been doing that for any clock forwarded interface. Anybody have any thoughts on this? Thanks! Todd Todd DeRego Principal Hardware Engineer - Signal Integrity Cedar Point Communications Derry, NH tderego@xxxxxxxxxxxxxxxxx ------------------------------------------------------------------ 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 technical documents are available at: http://www.si-list.net 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 ------------------------------------------------------------------ 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 technical documents are available at: http://www.si-list.net 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