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.
Hi , I am using NcVerilog 5.6 with +sv option to enable SystemVerilog.I am getting the following error during simulation.***Current stack trace: -->[Don't Know ] 0 -->[Don't Know ] 5d62b0 ncdbg_exit + 1bdc -->[Don't Know ] 3eb568 sss_tag_dbend + 520 -->[VPI Overhead ] 136a3c vpi_tag_ostart + 191b4 -->[VPI Overhead ] 136afc vpi_tag_ostart + 19274 -->[VPI Overhead ] 1385a8 vpi_tag_ostart + 1ad20 -->[VPI Overhead ] 156f68 vpi_tag_ostart + 396e0***Verilog source where error occurs: $recordfile(...) (PLI calltf) Module: TB_TST Instance: TB_TST File: ./TB_TST.v Line: 422ncverilog: *E,SIMERR: Error during Simulation (status 255), exiting. Can somebody help me.I am using $recordfile("./filename"); $recordvars();Are these PLI's not supported in SystemVerilog.
Hi ravurig,I think you may try to use latest IUS583-S003. Because Verilog and SV co-simulation is not stable in old IUS version.Regards,Davy
$recordvars(top.dut);This would make sure you dump your DUT signals without bothering about TB stuff. I've seen similar issues with other tool(s), but given the success of Specman's amazing dumping capability I thought Cadence would have done a better job here.Also check with CDN help desk on when they would support this TB dumping. I've an article in making on "Debugging Testbenches in SystemVerilog" - this will be little tool specific and will require some methodology help etc. It is not in a shape to be shared right now, but if you are based in Bangalore drop me an email ajeetha <> gmail.com and we can come and talk to you in person on this topic.RegardsAjeetha, CVCwww.noveldv.com
Hi Ravi, This is a classical problem when simulators move onto becoming fullfledged verification platforms. Honestly I'm surprised to see this with NCSIM though. As a quick fix, try:$recordvars(top.dut)This would make sure you dump your DUT signals without bothering about TB stuff. I've seen similar issues with other tool(s), but given the success of Specman's amazing dumping capability I thought Cadence would have done a better job here.Also check with CDN help desk on when they would support this TB dumping. I've an article in making on "Debugging Testbenches in SystemVerilog" - this will be little tool specific and will require some methodology help etc. It is not in a shape to be shared right now, but if you are based in Bangalore drop me an email ajeetha <> gmail.com and we can come and talk to you in person on this topic.RegardsAjeetha, CVCwww.noveldv.com <br>
I would suggest a couple of things. 1) As indicated, move to the latest Incisive (NC-Verilog) release which is currently 5.8 available on downloads.cadence.com2) File a sourcelink help request or send email to firstname.lastname@example.org - most likely support will want a test case which reproduces the error.3) try switching to shm_open() and shm_dump() 4) Contact your local Incisive AE who is always more than willing to provide some advice5) If you can identify the construct causing the problem, you can always dump "around it".I would suspect maybe the dumping of some of the SV TB constructs lagged the implementation a bit and the 5.6 release isabout 2 years old now. The latest releases have a boatload more field testing these days, are far more stable and offerway more features. Best regards,Jim McG.
Hi All, Thank you very much for your suggestions.I will try to move to newer version of IUS.For time being I have integrated Novas Debussy for waveform dumping using fsdbdumpvars() and fsdbduumpfiles.I am able to get my waveform.I have used DPI to call C-function in my SV testbench along with my Verilog module.I am comparing the simulation speed of SV testbench with Verilog'95 & DPI calling C-function and another Verilog testbench with same C-function implemented as behavioral model(Verilog-2001).I started the simulation with a view that SV testbench with DPI is going to give me better solution.But behavioral model is faster than C-model testbench.Case 1:- Testbench:- SV Verilog module:- '95 C-model :- Called by SV-DPI.Case 2:- Testbench:- Verilog'95 Verilog module:- '95 C-function as behavioral model:- Verilog 2001(to use its real and other functions).I thought Case1 is faster than Case2.But my analysis shows Case2 is faster than Case1.Can any body help me out.
Hi Rav, I'm not surprised - SV support is still new and hence may not enjoy all the performance optimizations that good old Verilog 95 has. One suggestion - try using separate ncelab commands - if possible. i.e. in your Case1:******Case 1:- Testbench:- SV Verilog module:- '95 C-model :- Called by SV-DPI.*********Compile 95 module using ncvlog -f v95.f ncelab v95_top ncvlog -sv31a -f sv.f ncelab sv_tb_top v95_topAlso, since you believe the DPI will give you the boost - do you know how much is the time spent on the C-Verilog/SV intreaction? A profile run should tell you that - unless that PLI is a significant portion you won't see any boost.More than this I believe you need to work with your AE to get it better. If you need more help on profiling and general optimization enhancements etc. (not necessariy tied to NC), contact me separately if you wish.Good LuckAjeetha, CVCwww.noveldv.com