How to synthesize without scan cell replacement 

Hi,

 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.

Maso,

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.

Brad

Hi Brad,

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?

 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.

Good luck!

Brad

Hi, Maso.

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 -both
add pin constraint 0 top/testpin/q -both

Plus there is also "add instance constraint" for flops/latches.

-Stark

Hi Brad,

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.

 Maso,

 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.

Regards,
Brad

Sorry for mixing two case.

The original case -

I set below option to do synthesis: 

set_attribute optimize_constant_0_flops false /
set_attribute optimize_constant_1_flops false /

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.

LEC fail.

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. 

Thanks for your help very much.