Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Synchronizers @Synthesis and @STA

Status
Not open for further replies.

ivlsi

Advanced Member level 3
Joined
Feb 17, 2012
Messages
883
Helped
17
Reputation
32
Reaction score
16
Trophy points
1,298
Activity points
6,868
Hello All,

How to define constrains on the synchronizers during the synthesis and STA?

Besides the set_false_path, should be set_multicycle_path be defined as well? Why?

Thank you!
 

first method: set_false_path -from [get_clocks CLK1] -to [get_clocks CLK2]
second method: set_clock_groups -asynchronous -group {CLK1} -group {CLK2}
 
So, setting multi-cycle paths on the synchronizers is not necessary?
 

not necessary
 
  • Like
Reactions: ivlsi

    ivlsi

    Points: 2
    Helpful Answer Positive Rating
I have even seen designs that work without setting false path as well.

You have to see this

https://opencores.org/websvn,filedetails?repname=ac97&path=/ac97/trunk/syn/bin/comp.dc

I am also pasting the script that does the real synthesis. "Note there is no false path or multicycle path command."

###############################################################################
#
# Actual Synthesis Script
#
# This script does the actual synthesis
#
# Author: Rudolf Usselmann
# rudi@asics.ws
#
# Revision:
# 3/7/01 RU Initial Sript
#
#
###############################################################################

# ==============================================
# Setup Design Parameters
source ../bin/design_spec.dc

# ==============================================
# Setup Libraries
source ../bin/lib_spec.dc

# ==============================================
# Setup File IO

set junk_file /dev/null
append log_file ../log/$active_design "_cmp.log"
append pre_comp_db_file ../out/$design_name "_pre.db"
append post_comp_db_file ../out/$design_name ".db"
append post_syn_verilog_file ../out/$design_name "_ps.v"

sh rm -f $log_file
# ==============================================
# Setup Misc Variables

set hdlin_enable_vpp true ;# Important - this enables 'ifdefs

# ==============================================
# Read Design

echo "+++++++++ Reading Design ..." >> $log_file
read_file $pre_comp_db_file >> $log_file

# ==============================================
# Operating conditions

echo "+++++++++ Setting up Operation Conditions ..." >> $log_file
current_design $design_name
set_operating_conditions WORST >> $log_file

# ==============================================
# Setup Clocks and Resets

echo "+++++++++ Setting up Clocks ..." >> $log_file

set_drive 0 [find port {*clk}]

# !!! WISHBONE Clock !!!
set clock_period 5
create_clock -period $clock_period clk
set_clock_skew -uncertainty 0.1 clk
set_clock_transition 0.5 clk
set_dont_touch_network clk

# !!! BIT Clock !!!
set clock_period 500
create_clock -period $clock_period bit_clk
set_clock_skew -uncertainty 0.1 bit_clk
set_clock_transition 0.5 bit_clk
set_dont_touch_network bit_clk

# !!! Reset !!!
set_drive 0 [find port {rst*}]
set_dont_touch_network [find port {rst*}]

# ==============================================
# Setup IOs

echo "+++++++++ Setting up IOs ..." >> $log_file

# Need to spell out external IOs

set_driving_cell -cell NAND2D2 -pin Z [all_inputs] >> $junk_file
set_load 0.2 [all_outputs]

set_input_delay -max 1 -clock clk [all_inputs]
set_output_delay -max 1 -clock clk [all_outputs]

set_input_delay -max 1 -clock bit_clk sdata_in
set_output_delay -max 1 -clock bit_clk sdata_out

# ==============================================
# Setup Area Constrains
set_max_area 0.0

# ==============================================
# Force Ultra
set_ultra_optimization -f

# ==============================================
# Compile Design

echo "+++++++++ Starting Compile ..." >> $log_file
#compile -map_effort medium -area_effort medium -ungroup_all >> $log_file
compile -map_effort low -area_effort low >> $log_file
#compile -map_effort high -area_effort high -ungroup_all >> $log_file
#compile -map_effort high -area_effort high -auto_ungroup >> $log_file

# ==============================================
# Write Out the optimized design

echo "+++++++++ Saving Optimized Design ..." >> $log_file
write_file -format verilog -output $post_syn_verilog_file
write_file -hierarchy -format db -output $post_comp_db_file

# ==============================================
# Create Some Basic Reports

echo "+++++++++ Reporting Final Results ..." >> $log_file
report_timing -nworst 10 >> $log_file
report_area >> $log_file



#########################################################################

I have run the design myself. The synthesis script works and the design is correctly synthesized.
 
Last edited:
  • Like
Reactions: ivlsi

    ivlsi

    Points: 2
    Helpful Answer Positive Rating
# !!! WISHBONE Clock !!!
set clock_period 5

# !!! BIT Clock !!!
set clock_period 500

If the 2 clocks are synchronous (generated from same source) and edge-aligned:
1. There will no metastability possibilities due to unaligned edges that is the case with asynchronous clocks. So false paths need not be set.
2. Since false path is not set, timing analysis will proceed as it normally does for single-clock designs. There is the possibility of metastability due to setup-hold violations arising out of heavy delays from combinational paths, clock skew etc. Setting multi-cycle constraint may help solve this by letting the tool know that the capture clock edge (either of 5ns or 500ns clock) need not be the immediate next edge after the launch clock edge (which is the default).

If the 2 clocks are synchronous but out of phase (not edge-aligned), I think the phase relationship is probably known not to cause metastability ever and hence no false path has been set in the script. I'm not absolutely sure of this though.

If the 2 clocks are asynchronous, false paths have to be necessarily set.

Am not a synthesis guy hence cannot tell what is the clock relationship from the script.
 
The false paths for the synthesis are NICE TO HAVE, not a MUST. If you don't set false paths for the synthesis, the synthesis tool will just spend more time for the synthesis - that's all! If that is not a matter for you then of course you HAVE NOT set false paths at all.
Hope this help
 
The false paths for the synthesis are NICE TO HAVE, not a MUST.
If they are not set, not only more time will be spent by the tool, irrelevant violations will be reported in the asynchronous cross-clock paths, debugging which will add more time to reach a clean netlist.
 

more time to reach a clean netlist
Agree with you. I actually meant a possibility not to define the false paths, but also define aligned clock edges.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top