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 synthesize RTL with RTL Compiler.
I have setup below options.
set_attr dft_connect_scan_data_pins_during_mapping ground [find / -design *]set_attr dft_connect_shift_enable_during_mapping tie_off [find / -design *]set_attr dft_scan_map_mode preserve [find / -design *]
But when I finished synthesis, I always get my netlist with scan cells replacement.
How can I avoid the scan cells replacement ?
Thanks a lot.
I think the best way is to simply NOT run "check_dft_rules". During "check_dft_rules", RC will mark every flop as scannable, or not. All flops that are scannable will be mapped to scan. If you don't run check_dft_rules, all flops will be considered non-scan. I suggest leaving dft_scan_map_mode set to tdrc_pass.
Another option, I suppose, is to set dft_dont_scan attribute to "true" on all flops. This would also work, but simply not running check_dft_rules is probably the simplest solution.
FYI... if you want to prevent RC from using scan flops for non-DFT purposes, you will want to set this attribute: set_attr use_scan_seqs_for_non_dft false /
I am curious, why do you not want to map to scan flops? Usually this is desired to account for the extra mux delay and extra load on the flop Q pin.
In reply to bmiller:
That's the issue to pass LEC.
I use synopsys DFT Compiler to insert scan chain for synthesis netlist from RTL Compiler.
When I compare the synthesis netlist from RTL Compiler and the scan netlist from DFT Compiler.
I found some non-eq on scan flops.
Below is a scan cell RTL Compiler generated.
SDFCNQD1BWP12TNDO35CDM4NMLVT uck_reset_b_n_sync_q1_reg_0(.CDN (n_2), .CP (ck_gclkcr), .D (uck_reset_b_n_sync_q0), .SI (ck_reset_b_n), .SE (ck_reset_f_n), .Q (ck_reset_b_n));
I think scan replacement during synthesis is OK for me.
But I wnat all the scan cell pin - SE is tied to 0, and SI also is tied to 0.
I can't find correct options in RTL Compiler to do this.
Do you have any ideas for this?
In reply to Maso:
Sorry for the delayed reply.
The attributes you initially posted should tie off both the SE and SI pins: set_attr dft_connect_scan_data_pins_during_mapping ground [find / -design *] set_attr dft_connect_shift_enable_during_mapping tie_off [find / -design *]
Keep in mind that grounding the SI pin eliminates some of the benefit of inserting scan flops during mapping. Usually you want to loop back the Q pin to the SI pin so that an extra load is seen on the Q pin. This prevents timing from changing after connecting the scan chains.
I suspect RC mapped to the above flop because it is using the scan mux for "functional" purposes, not scan purposes. Using the attribute I mentioned in my last email should prevent that:
set_attr use_scan_seqs_for_non_dft false /
However, what you really need to determine is why LEC is failing. If the RC netlist matches the RTL (or post-map netlist), then you can safely assume it is correct. Be sure scan_enable is constrained in the post-DFT-Compiler netlist (revised netlist in LEC). You shouldn't see any noneqs unless something went wrong while the scan chains were built.
RC can produce a dofile for a variety of tools including LEC. The command is write_do_lec. If you are not using this command then you can try that.
If RC has the DFT signals correctly defined then the generated write_do_lec dofile will add the needed LEC DFT constraints. If the RC has some question on the constraints (maybe not safe) then the constraints will still be there but commented out. You can then review them and uncomment them.
One can also manually constrain nets and instances in LEC. To constrain a net you can do this:
add primary input top/testpin/q -bothadd pin constraint 0 top/testpin/q -both
Plus there is also "add instance constraint" for flops/latches.
You are right. It's for functional purposes that RC mapped to scan flops.
I have tried the options " set_attr use_scan_seqs_for_non_dft false / " you mentioned, and It's work to avoid scan flops replacement.
But LEC still failed. I write out the dofile by using "write_do_lec" command.
I found that when I set below options, it can pass LEC.
set_attribute optimize_constant_0_flops false /set_attribute optimize_constant_1_flops false /
But LEC will fail when I set them to true.
In synopsys design compiler can write out svf file for formality to do equivalent check.
How about RTL Compiler ?
Thanks for your help very much.
I am not sure I understand. Conformal LEC fails between what two netlists? RTL vs gates? Are you using the recommended two-step verification flow; RTL vs mapped-gates, and mapped-gates vs final-gates?
I originally understood that you had an LEC noneq between the RC synthesised gates and the DC DFT-Inserted gates.
From what you describe, it is possible that LEC is having trouble understanding an RC sequential constant optimization. Try adding "-effort high" to "set analyze option -auto" in the dofile.
If that doesn't work, file a 'service request" (SR) on support.cadence.com. The Conformal Customer Support engineers are very good.
No, RC cannot write an SVF file. It is a proprietary format.
Sorry for mixing two case.
The original case -
I set below option to do synthesis:
LEC can pass.
And then I use DC DFT to insert scan chain.
Formality fail for synthesis netlist and dft netlist.
As mentioned in last mail, it's work to avoid scan cell replacement by using "set_attr use_scan_seqs_for_non_dft false /".
I have re-run formality to check the result, and it can pass.
Another case -
I set optimize_constant to true.
In this case, I have tried -effor high but it's no use.
I will file a 'service reqest' on support.cadence.com later.
You help me a lot.