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.
We are starting to experiment with a technique to simulate multicycle paths on the Palladium. Our definition of a multicycle path is a path from flip-flop A to flip-flopB where the timing in the path exceeds one clock cycle as shown by the timing analysis tool. These paths must either be re-designed to meet the one clock cycle criteria, or be assured that the data from flop-flopA will change at most every other clock cycle.There are 3 steps to this process:1. We have defined our system clock to be made-up of 4 qtfclks. One qtfclk is the basic Palladium clock, and is used to defined your clock signals.2. The Palladium has a flip-flop that is clocked the qtfclk. We made up a verilog module that uses six of these flip-flops to produce a 6 qtfclk delay. This delay corresponds to a 1-1/2 clock cycle delay.3 We then instantiate our verilog module in the path from flip-flopA to flip-flopB and run tests on the Palladium.The early result show that we are achieiving the expected delays, and so far the test are running.
Hi Tom,your description is correct and Palladium can handle multicycle paths in the way you described it.However, your step 1) is NOT a prerequisite for enabling multicycle paths. Your design or environment may require a 4 to 1 ratio between fclk and fastest design clock but this would be a very rare case and it is absolutely NOT a requirement to enable multicycle paths. Multicycle paths are also possible with a 2/1 or even 1/1 ratio between fclk and fastest design clock, giving a speedup of up to 4x over your current environment.Also I would suggest to use the qel command breakNet rather than inserting delay-flops. This would allow keeping the RTL as is, rather than modifying it.Off course, when modeling multicycle paths within a 2x or 1x environment, the number of fclk-delays outlined in step 2) need to be reduced accordingly. In 2x mode you would need 2 or 3 fclks delays while in 1x mode you would need 1fclk delay.I write this to make sure nobody misreads the original post.Best regards, Volker