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 tried to run the SV code on IUS583-p002. It seems a Clocking Block assignment error happens.
Please set the same seed as mine when you do simulation: ncsim -svseed 1222108611
In log file, the do_write task is called @25, and writes data non-blocking (<= NBA region is called without any time blocking). In my opinion, the simulator will schedule a non-blocking assignment @26 (I set #1 hold_time to interface clocking block). But in waveform data 3618476463 is sent out @36!
// log file
@25 wr_data is 3618476463
@25 Enter W::do_write
@25 Quit W::do_write
@25 *WRITE cmd
@25 wr_data is 3618476463
My workmates have run the same code on Synopsys VCS and find the result is different with Cadence IUS (both task call and NBA @26).
Please check if it is an IUS bug or my understanding error!
Both SystemVerilog file and waveform are attached.
I have copy the problem to a word document. It maybe easier to read.
Hello Davy.I had a look at your test case, and can confirm that I see the same behaviour. In fact it can be shown with a much simpler case.The issue here is that the LRM is not very clear about how the clocking blocks should work in the given example. Your code is waiting for the posedge CLK associated with the clocking block, then assigning signals to the clocking block outputs. Now the tricky bit - when does the clocking block apply the outputs?In IUS the implementation has been to apply them after the next clock (after all, the signals could be assigned at any point in the cycle, not just on the posedge CLK). Hence you see the effect of the assignment delayed by one cycle. Now it appears that VCS chose to apply the values after the current posedge CLK, so that the extra cycle delay isn't there.Unfortunately this is just another example of the problems in the SV LRM - it's a huge standard and has a number of gaps where interpretations can differ.For the example here, Cadence has decided that to follow the scheduling seen in VCS.I don't have details of when the change will happen though. I suggest that if you are severely impacted by this, that you file a service request such that Cadence R&D get visibility of the relative urgency.Regards.Steve H.
interface my_if; logic CLK; logic in; logic out; logic out_shadow; clocking wr_cb @(posedge CLK); default input #1 output #2; input in; output out; endclockingendinterface : my_ifmodule tb; my_if if_inst(); initial begin : clkgen if_inst.CLK = 1'b0; forever #5 if_inst.CLK = ~if_inst.CLK; end : clkgen initial begin : test $display("%m\t: starting @%0t", $time); @(if_inst.wr_cb); // wait for sampling event of interface clocking block $display("%m\t: out <= 1 @%0t", $time); if_inst.wr_cb.out <= 1'b1; // "out" will be updated after the wr_cb delay if_inst.out_shadow <= 1'b1; // "out_shadow" will be updated immediately @(if_inst.wr_cb); // wait for sampling event of interface clocking block $display("%m\t: out <= 0 @%0t", $time); if_inst.wr_cb.out <= 1'b0; // "out" will be updated after the wr_cb delay if_inst.out_shadow <= 1'b0; // "out_shadow" will be updated immediately repeat( 3) @(if_inst.wr_cb); // wait for sampling event of interface clocking block $display("%m\t: ended @%0t", $time); $stop; end : test always @(if_inst.out) begin : mon $display("%m\t: out changed to %b @%0t", if_inst.out, $time); end : mon always @(posedge if_inst.CLK) begin : clk $display("%m\t: CLK posedge @%0t", $time); end : clkendmodule : tb
tb.test : starting
@0 tb.clk : CLK posedge @5 tb.test : out <= 1 @5
tb.clk : CLK posedge @15 tb.test : out <= 0 @15 tb.mon : out
changed to 1 @17 tb.clk : CLK posedge @25 tb.mon : out changed
to 0 @27 tb.clk : CLK posedge @35 tb.clk : CLK posedge
@45 tb.test : ended @45