We have seen this occur at other silicon vendors as well. We are continuously working with different silicon vendors to educate them and urge them to provide the information that their customers need in order to properly analyze their designs. For vendors that do want to push routing guidelines above all else, we work with them to create DRC sets in HyperLynx DRC to provide comprehensive verification of routing including time-based (electrical length) routing checks. If you are uncomfortable with the "follow our routing guidelines and everything will be fine" approach, I would urge you to push your silicon vendor to provide you with the information you need to implement your designs reliably. Ultimately the leverage to get that kind of information needs to come from you guys, our mutual customers.
I would also agree that there is a tight relationship between timing and signal integrity. The HyperLynx DDRx Wizard is probably one of our more popular features - you all realize the need for comprehensive analysis when it comes to interfaces like DDR3 and DDR4, which is why so many people use it. For example, including the on-chip timing is essential for accurately predicting crosstalk on a DDRx interface, since you need to know how the edges are lining up on the board. And, of course, the crosstalk will ultimately affect the overall system timing. Not to mention other effects, like reflections, loading, and via effects, that all impact the overall system timing as well. Since DDRx is a source-synchronous interface, it is certainly tempting to say that timing can be ensured by minimizing skew, but of course "skew" is more than just routed lengths - it includes propagation delays, reflections, loading, via effects, and crosstalk, all of which are difficult to keep uniform across all signals on any design...
thank you for your answer.
Could you please help me to understand better hyperlynx weak points below (from TI's BLOG):
Unfortunately the DDR wizard makes many assumptions and is incompatible with many different IBIS model formats.
For example the wizard requires that the data and other IO models are modeled as IO and cannot handle discrete selectors with separate input and output models. This is a major issue since TI generally includes separate input and output models rather than IO models.
It also assumes the model to model relative timing is accurate, but this is not a general requirement for IBIS since IBIS is only designed really for signal integrity and not pin to pin timing checks.
Is this really the case?
To address TI's statements:
>>the DDR wizard makes many assumptions
Yes, the DDR Wizard does make assumptions, but all of them are extremely reasonable. For instance, we assume that I/O buffers get modeled as I/O models...
>>is incompatible with many different IBIS model formats
This sounds to me like they made an unusual choice with how they modeled their I/Os and don't feel like changing their models. The DQS and DQ pins on a DDR controller are I/Os - they drive in both directions. So, I'm not sure why anyone would model them using separate buffers, especially if they expected their customers to do system-level simulations with the models.
>>It also assumes the model to model relative timing is accurate, but this is not a general requirement for IBIS
It is true that IBIS does not require different models to have time-correlated V-t curves (only the V-t curves within a single model need to be time-correlated). However, the signals with the tightest timing margins are the DQ and DQS signals, which always use the same buffers and therefore the same models (I have yet to see a part where this was not the case). But even for signals that do use different models, we have a V-t stripping algorithm that will align edges as they start transitioning (default threshold is 1% - and can be changed under Setup -> Options -> General -> Advanced).