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.
Does anybody know how to adjust PLE setting in RTL compiler so it will be more in line with encounter results?
I heard somebody talk about it, but he is not available now.
Any help would be appreciated.
Hi,I am not sure what you are looking for exactly but here are a few things I can think about.
Hi,In addition to the above attributes, set the scale factors to the same ones used in SOC-Encounter. Two scale factors are used to align SOC-E trial route/default extraction with final route and sign off extraction. These R and C scale factors should be set to the same value in RC. set_attr scale_of_cap_per_unit_len set_attr scale_of_res_per_unit_lenRemember that there will be differences between the PLE and FE results. The goal of PLE is to give a better starting point for place and route.Thanks,Rich
Thanks for your help. I am going to be using the scaling factors for PLE tuning.This forum is great!
I did not found any explanation about how RC computes net lenght in PLE
mode. Therefore I am not sure if it is better use PLE than wire
load models to drive synthesis, can anyone help me?
Cristiano, You will not find any explanation of how RC computes the net length as it is a proprietary algorithm. About all I can tell you is that PLE uses a combination of the information in the LEF and capTable along with the structure of the logic to model the nets more accurately than any wireload. You will find that the results after Place and Route will be better using PLE's. It is important to note that the PLE flow is meant to make the post P&R (read REAL) results better. Depending on how conservative your WLM's are, the QoR results post synthesis could be either better OR worse.Hope this helps.Regards,-Jeff-
Hi Cristiano,I tried to find out myself but, as you may have found out, R&D keeps this recipie pretty tight to their belt - understandably so. The information I was provided is pretty similar to what jflieder mentioned. The is no doubt in my mind that using some of the physical information available early on is the right approach. In addition to jflieder's comment I would like to point out the following:+ PLEs are dynamic so every time RC picks a different architecture the consequences on net topology are recomputed This is a key difference with WLM which is static in nature+ I have seen no noticeable impact on runtime or memory usage+ PLEs can be more localized since they are not bound by hierarchy and fanout only as I understand this+ In my experience it is a single iteration approach as opposed to constantly tweaking CWLMs over iterations+ On the designs I have run, PLEs have produce better or comparable resultsOne issue I have run into is that it has required a little more dilligence at reviewing all the collateral since now I do not only have to review the .libs but also the physical files. Probably not such a bad thing since we have to review them at some point and better earlier than later.good luck,GH-
Hello,1) How to correlate the timing results between RTL Compiler and pre-layout STA (using ETS or FE-CTE) since it is not possible to reproduce PLE wire prediction ?2) What is the recommended way to generate SDF file for pre-layout verification (functional simulation) if write_sdf is an unsupported command in RTL_Compiler?Thanks in advance,Cristiano.
Hi Cristiano,how are PLEs treating you these days ? I just downloaded RC71 only to be pleasantly surpsied with fully supported write_sdf. Sounds like you will be as exicted as me :)GH-
GH, it is really great!Besides that, below is what Cadence support says about correlating PLE results during STA.Cristiano.#####Cristiano.RC has the 'write_set_load' command. This command will write out a filewhich includes a set_load for every net in the design. The user can then loadthe netlist and SDCs into the timing tool, followed by this set_load file.This *should* enable the timing tool to 'see' the same timing as RC PLE. Thatis, it uses the same wire delays as RC in PLE mode. RC will not tell how PLEdoes it, but it provides the value that PLE picked.#####
Hello all,Unfortunately set_load does not work on nets in CTE (SOCE62). I found the following help messages in sourceLink but they are conflicting:http://sourcelink.cadence.com/docs/db/kdb/2007/June/11350058.htmlhttp://sourcelink.cadence.com/docs/db/kdb/2006/June/11249762.htmlSo, what is the recommended way to correlate PLE results with STA using CTE?Regards,Cristiano.
Hi Cristiano,I believe I ran into this and ETS6.2-USR1 did support set_load on nets. I have not tried it in SOC so I do not know what version of SOC would incorporate the enhancements to CTE and SOC. gh-
Hi Cristiano,write_spef is also supported in RC 7.1. write_sdf/write_spef/write_set_load are commands available in RC to help correlate PLE results with CTE. I haven't done experiments on which method works best. write_ets is also available to provide a starter script to run ETS.ETS 6.2 USR1 accepts set_load on nets. -NC
I think set_load will be supported in SOC62USR2 (planned to 08/08/2007).I tried the command spefIn using the spef file generated by RC7.1 and it seems be ok.Thanks a lot,Cristiano.