Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
I have a SigXplorer simulation showing overshoot at the die level for a mobile DDR (1.8V) device driven by a fairly new ARM11 device that violates the overshoot specification fr the memory. However, the package pin shows no specific overshoot problem. The trace length is less than 1/2 inch and the speed is 133MHz. The trace is controlled impedance. According to the memory vendor, they say their specification is for the waveform at the package pin. But according to the CPU vendor and a high speed design consultant, they say that the signal performance at the die is also important.So, who do I believe?The simulation only fails the overshoot specification when the Simulation Modes is set to FTS Mode: Fast. Typical and slow are fine. Attached is the printout from the simulation. Feel freeto email me if you have a definitive answer. Thanks in advance.
One thing to keep in mind is that the fast case is VccTypical+10%. If you take the magnitude of the overshoot and subtract from it the fast case Vcc and then add the typical case Vcc, do you still exceed the spec? What kind of package model do you have on this device?
Signal performance at the die is the important thing since that is what the silicon sees. Since we cannot use a scope probe to access the die, timing numbers are referenced to the pin except rarely when you are provided detailed package delays.
Yes, the simulation still would show violation if I subtracted off the 10% high on the VCC.
What kind of package model do you have?
137 pin FBGA, 0.8mm pitch, stacked DDR/NAND, not sharing data bus.
What kind of package model do you have?
how can I tell? All I have is the IBIS model the memory vendor sent.
Dean:You can tell by looking at the IBIS model. Is there only 1 set of package RLC with typ, min, and max at the top of the pin list or are there pin specific RLCs (unique per pin) or is there a distributed or sparse matrix package model at the end of the ibis file?
Kai,There is a [Package] at the beginning with R_pkg, L_pkg, and C_pkgfollowed by a pin list with R_pin, L_pin, and C_pin.
Hi Dean,It's true that the signal at the die is "important" and "what is actually seen by the device". However, if the memory vendor has written their overshoot spec for the "package pin" then they have accounted for what the die will actually see. It's common to spec things at points visible to the outside world. You're using the simulator to "peak" at what is actually going on inside, but most people (particularly those with oscilloscopes!) can not see the waveshape there. Consequently, IC vendors write specs for waveshapes at the pins. They know what an overshoot at the pin can cause at the die and have derated their specs accordingly. I'd say go with what/where each part vendor has spec'd. Donald