LEC : Unmapped Points issue 

Hi ,

We are using conformal software Version 7.1 to perform LEC check.
we used netlists ( VQM )  to compare the Logic equivalences. Both the netlists are generated using synplify tool. When compared between these two netlists we could see warnings Unmapped points due to DLAT's ( D LATCHES ).

Few among the warning messages are extracted and shown below.

unmapped point (unreachable: all paths to outputs are blocked):
(G) 9404 DLAT /sclrsclrb2_ebus_top_ebus_slave_to_gms_top_v2_ebus_controller_TIMEOUT_ERR_1_sqmuxa_0_a3_0_a2_i_o2_4_a_s_cZ/lc_ff

Unmapped point (unreachable: all paths to outputs are blocked):
(R) 9408 DLAT /G_4029_cZ/lc_ff.

Unmapped point (unreachable: all paths to outputs are blocked):
(G) 9409 DLAT /sclrsclrb2_ebus_top_ebus_slave_to_gms_top_v2_ebus_controller_TIMEOUT_ERR_1_sqmuxa_0_a3_0_a2_i_o2_a_cZ/lc_ff

Unmapped point (unreachable: all paths to outputs are blocked):
(R) 9409 DLAT /G_4029_a_cZ/lc_ff

In the warning messages mentioned above,
1, G refers to golden & R refers to Revised netlists.
2, Lc_ff refers to technology specific DFF intance name.

We observed that, DLAT's are araised due to CLK pins of the instanced DFF  are grounded. lc_ff is an instance name of the DFF ( Technology Specific )

Based on this we have following queries:-

1, Are this messages are valid warnings?
2, Is there any approach to reduce or eliminate these warning messages?

Kindly help us about this issue.

Thanks,
Dinakaran.R

Hi Dinakaran

Unreachable means there's no path from that keypoint to a primary output through any sort of logic.

Hence they can't have an effect on the behaviour of the design. Conformal by default won't map them nor compare them. The typical causes:

1) unused code in RTL
2) spare gates
3) disabled logic (e.g. pre to post test)

We still like to show you have them though because they could be a problem if they are unexpected.

There's a way to make some of the warnings go away (set mapping method -unreach). I do ***not*** recommend using it however. It makes the tool more strict than is necessary for most EC runs. Yes, warnings about unreachables will be reduced but you may wind up with non-equivalences you won't care about.

Also, since you're trying to run gate-gate on 2 different synthesis netlists you would want to have look at our 'tip of the month' posted on June 13 to see the potential pitfalls associated with that.

Chrystian

Thanks Chrystian

As per your suggestion i will have a look into the "Tip of the month" , i will get back to you if i have any queries

Best Regards,
Dinakaran.

Hi ,

I had gone through "Tip of the month" on june 13 as per your suggestion.
With respect to that, i would like to provide the details on set of experiments which were executed.

Ist case:-

Synthesis netlist ( VQM's ) were generated using same tool with same version ( Synplify 8.2.0, Build 119R ). Upon LEC comparison, unreachable points come up which was mentioned in my previous query.

2nd case:- 

One VQM was generated using Synplify 8.2.0, Build 119R and the other one was generated using Synplify pro 8.2.0, Build 119R. Please note that ***software version is same*** in both the VQM. Upon LEC comparison, unreachable points were same as to the first case.

Kindly let me know if this would result variance in synthesis strategy .

Thanks,
Dinakaran.

Hi Dinakaran

I don't think I understand your question. Are you concerned about the presence of those unreachables?

I forgot one more cause of unreachables:

4) clock-gating latches (with set flatten model -gated_clock turned on)

The algorithm will undo the clock-gating, modeling the circuit as mux-feedback, but it leaves the latch there, dangling, hence unreachable.

'report message -model -verbose > model.rpt' should give you a better idea about what's going on with those keypoints.

Chrystian