Noise of MultiBit output pin

We recently brought to Synopsys the question of noise reports on multi-bit q pins.  Here is their response:

The conclusion is the noise reporting on the multibit flop output is expected because unbuffered output pins are also analyzed as load pins in noise analysis.

pt_shell> get_attribute [get_lib_pins -of_objects ins_pex_lpkg_top__inst_pex0__inst_phy_dll_sops_top/CDN_MBIT_inst_dist_stn_top_p0_distributor_ufifo_tlp_seq_ram_reg_19__13__MB_inst_dist_stn_top_p0_distributor_ufifo_tlp_seq_ram_reg_19__21__MB_inst_dist_stn_top_p0_distributor_ufifo_tlp_seq_ram_reg_19__8__MB_inst_dist_stn_top_p0_distributor_ufifo_tlp_seq_ram_reg_19__5_/q1] is_unbuffered

true

The attribute of the multibit flop output does have is_unbuffered attribute so noise analysis is performed.

Here’s more information in the user guide:

https://spdocs.synopsys.com/dow_retrieve/qsc-v/dg/ptolh/V-2023.12-SP3/ptolh/ptug/signal_integrity_analysis/noise/noise_modeling_with_ccs_noise_data.html#BABHIECJ

I recommend that you do what you can to improve these noise results.  The beyond rail violations (below_low and above_high) represent a potential reliability issue.  We can attempt a reliability-based waiver if we must.

  Also we are checking M5IPERLY_1_A.noise_slack_failure.gz for the noise fixes ,  do we need to fix the other endpoints mentioned in  M5IPERLY_1_A.ptsi_noise.summary.gz  ? 

Yes, that is the intent.

• The within-rail violations (above_low and below_high) should all be fixed because they represent a potential functional problem.

• The beyond-rail violations represent a potential reliability problem (discussed above)