EDA: Design data is geometry-based, and modeling options and issues are much the same as those for package design. However, S-parameter data is usually much simpler—for example, representing three line pairs (12 ports). Various design approaches help with this tricky problem, such as using experience-based design rules, partial modeling of critical paths using closed-form and cross-sectional models, and adopting automatic parasitic calculation tools that are part of trace-routing utilities.
Challenge: These techniques can work well from the hundreds-of-megabits-per-second region through a few gigabits per second. At higher speeds, geometry-related problems like surface-and space-wave propagation become significant. So-called phase velocity dispersion, where higher-frequency components of a signal travel more slowly on nonsymmetric transmission structures like the microstrip, can become problematic. These issues point to the use of EMbased analytic tools, though until recently, such tools were constrained by memory limitations to solving for only small parts of key signal paths.3
Connectors And Sockets: Connector design is almost always left to specialist houses. Ensuring good electrical characteristics (isolation, characteristic impedance, and skew performance) while meeting mechanical needs and keeping within cost constraints is extremely challenging.
EDA: Design often is carried out with 3D drafting tools in association with 3D EM analysis. Here again, S-parameters and equivalent-circuit models can represent the electrical data. This is usually made available to customers.
Challenge: Designers must generate accurate broadband models for customer use.
Link-Level Simulation: These various discrete-link design tasks generally occur in the context of the same overall system specification. Yet in most ways, they're isolated from one another by design, the (necessarily) different design methods, and the available tools.
For example, a Spice user can't directly-use a Matlab module, or vice versa. This isolation leaves little room for verifying a link design until the first evaluation or test boards are produced—when correcting errors becomes time-consuming and expensive.
It would be a major advance if each of the above design disciplines, with their differing models and IP, could connect through a common design tool to check and verify the link during the design phase without waiting for hardware. So, how might this be done, and what would a "link-level" simulator look like?
Such a tool, which would be called an integrating link simulator (ILS), would have to deal with the data in all forms and facilitate all of the necessary link tests (e.g., eye measurements and bit error ratio, or BER). In the meantime, it must be able to use the native models and measurement data produced at each design stage. There are three possibilities to consider when working with link models and intellectual property (IP):
- creating a single simulator that can work natively with all link functions
- directly using the original design information to create a native model for the ILS
- allowing the ILS to invoke other simulation tools when needed
The first approach appears to be the most desirable. But such a product doesn't exist yet, and no one seems to be attempting to develop such a simulator. The challenges of combining all possible current model types into one simulator are substantial. Trying to unify all design methods under a new design format would likely be highly disruptive.
The second approach could be effective when link design information comes in a form similar to the ILS's own model language. If ILS models were written in C++ and link functions also were represented in C++, then it should be possible to incorporate this link function code directly by building a new ILS model. As long as this process was reasonably simple and well documented, it would supply the necessary functionality without raising a usability barrier.
The third approach, allowing the ILS to invoke another simulation tool, is termed co-simulation. Co-simulation has the benefit of using the "right simulator for the job." For example, HDL code would run in a HDL simulator. Cosimulation requires a bridge between the host ILS and the client engine, which means developing some kind of dedicated interface on the ILS for each client simulator.
Reprints
