X hits on this document

PDF document

The Designer’s Guide Community - page 28 / 31





28 / 31

Principles of Top-Down Mixed-Signal Design

Design Example

ulation covered on the order of 2000 cycles of the high frequency clock. These mixed- level simulations were used to identify the worst corners, over which full transistor level simulations were the performed that included the entire clock recovery circuit.

The verification plan also specified a series of tests to confirm performance in demand- ing situations. For example, the reaction of the circuit was observed while being sub- jected to noise or jitter from various sources, such as at the input, through the bias and supply lines, and from the reference oscillator. In addition, it specified a series of chal- lenging situations for which operation had to be verified, such as when the input con- tained long streams of zeros or ones that are allowed under SONET standards, which with a NRZ code results in long intervals during which no input transitions are received, making lock difficult to maintain. With the phase interpolator at the transistor level (about 1000 transistors) simulations took 3-6 hours, and with the entire clock recovery circuit at transistor level, the simulations required 3-4 days. Thus, a full transistor level simulation required the same compute resources of roughly 30 mixed-level simulations.

As a reusable block, an important part of the output of the design process is a model that can be used both to evaluate the block to determine its suitability for use in a larger sys- tem, and as part of the system integration and verification process. The Verilog model that was developed and refined during the block design phase is a natural choice, as it has been extensively tested and refined. However, as it is a Verilog model, it cannot model the degradation in the performance of the system as a result of the parasitics from the package, the board, or the connectors (the Verilog model allows timing-related impairments to be easily modeled, but not impairments due to effects such as dispersion, variations in the input signal amplitude, small couplings, etc.). For this reason, another model is provided that describes the front-end of the serdes (the input amplifier and equalizer) in a SPICE format. The system integrators are expected to use this model to assure that the input signal reaches the deserializer with enough fidelity (has a suffi- ciently open eye) to assure proper operation.

While in this case it was possible to follow a top-down design methodology using an older mixed-signal simulator that provides a relatively distant coupling of SPICE and Verilog, the design process could be substantially improved by using Verilog-AMS. Vir- tually all of the behavioral modeling for the cell was done using Verilog, which means that no analog effects could be included. This was problematic in several situations. The first of which is that two models needed to be developed and delivered to the customer. A single Verilog-AMS model would have been sufficient to include both the complex event-driven behavior of the deserializer, as well as the analog behavior at the input, including the degradation that occurs as a result of parasitics from the package, the board, and the connectors. In addition, both the equalization in the input amplifier and amplitude and pre-emphasis levels in the driver are programmable, a fact that had to be ignored when the model was delivered in two distinct non-interoperable pieces, but could have been easily included in a single Verilog-AMS model. Finally, use of Verilog- AMS would have allowed more analog effects to be modeled during the mixed-level simulation process. For example, in a multi-lane serdes macro there can be up to 200 bias current lines distributed to the many lanes. These bias lines were not included in the top-level model because of limitations in Verilog. They could have been included if Ver- ilog-AMS were used. Mis-connection of any of the bias lines would have caused the associated lane to fail.

28 of 31

The Designer’s Guide Community


Document info
Document views56
Page views56
Page last viewedMon Oct 24 22:58:19 UTC 2016