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.

how could I fix hold violations in my design ?&am

Status
Not open for further replies.

gauz

Junior Member level 3
Joined
Jul 18, 2005
Messages
26
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,537
There is large clock skew introduced by DCM in my design, so the .twr always report hold violations. but I think it should'nt by a big trouble for ISE, only insert some delay cell and the violations could be fixed, why ISE couldn't do it automaticly when P&Ring? does anyone know how to fix it?
 

Where exactly is the clock skew? Between which points?
Can you show some HDL code that demonstrates the problem?
 

please dun mind to show ur .twr file as well...
 

Sounds like the DCM clock output is not being routed on a global clock line. Either all your global lines are full or the PAR tool is using local clock routing due to some feature. When a locally routed clock must drive logic in physically distance parts of the chip, the clocks at these distance flops become skewed in time with each other. That is what is causing the violations.

The solutions are:
1. Force global clock routing, (low skew lines) if available.
2. Move logic closer together using LOC attributes.
3. Add pipeline registers to reduce distance that must be traveled in one clock cycle.
4. Change the effort level and PAR seed values which will affect how PAR packs in the logic.
 

Re: how could I fix hold violations in my design &#65311

here are two violations, it tells the clock skew is larger than data delay.
BTW, all effort are set highest.

================================================================================
Timing constraint: TS_fpga_clk_gen_inst_clk_hsx = PERIOD TIMEGRP
"fpga_clk_gen_inst_clk_hsx" TS_xti_pad * 2 HIGH 50%;

669893 items analyzed, 805 timing errors detected. (0 setup errors, 805 hold errors)
Minimum period is 23.817ns.
--------------------------------------------------------------------------------
Hold Violations: TS_fpga_clk_gen_inst_clk_hsx = PERIOD TIMEGRP "fpga_clk_gen_inst_clk_hsx" TS_xti_pad * 2 HIGH 50%;
--------------------------------------------------------------------------------
Hold Violation: -1.486ns (requirement - (clock path skew + uncertainty - data path))
Source: mango/corona/hsx_dxb/rch0_stage[16] (FF)
Destination: mango/corona/vd/vbrg/u_vbrg_es/u_vbrg_es_if/mst32_hrd[16] (FF)
Requirement: 0.000ns
Data Path Delay: 1.215ns (Levels of Logic = 0)
Positive Clock Path Skew: 2.701ns
Source Clock: fpga_clk_gen_inst.clk_hsx rising at 0.000ns
Destination Clock: fpga_clk_gen_inst.clk_hsx rising at 60.000ns
Clock Uncertainty: 0.000ns

Maximum Data Path: mango/corona/hsx_dxb/rch0_stage[16] to mango/corona/vd/vbrg/u_vbrg_es/u_vbrg_es_if/mst32_hrd[16]
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X189Y166.YQ Tcko 0.313 mango/rch0_stage[16]
mango/corona/hsx_dxb/rch0_stage[16]
SLICE_X191Y141.BX net (fanout=5) 0.981 mango/rch0_stage[16]
SLICE_X191Y141.CLK Tckdi (-Th) 0.079 mango/corona/vd/vbrg/u_vbrg_es/u_vbrg_es_if/mst32_hrd[16]
mango/corona/vd/vbrg/u_vbrg_es/u_vbrg_es_if/mst32_hrd[16]
------------------------------------------------- ---------------------------
Total 1.215ns (0.234ns logic, 0.981ns route)
(19.3% logic, 80.7% route)
--------------------------------------------------------------------------------
Hold Violation: -1.385ns (requirement - (clock path skew + uncertainty - data path))
Source: mango/acorn/u_pci/pci_100/pci_isa/ctl_state[0] (FF)
Destination: mango/acorn/u_pci/pci_100/pci_isa/isa_oe_ (FF)
Requirement: 0.000ns
Data Path Delay: 4.144ns (Levels of Logic = 2)
Positive Clock Path Skew: 5.529ns
Source Clock: fpga_clk_gen_inst.clk_hsx rising at 0.000ns
Destination Clock: fpga_clk_gen_inst.clk_hsx rising at 60.000ns
Clock Uncertainty: 0.000ns

Maximum Data Path: mango/acorn/u_pci/pci_100/pci_isa/ctl_state[0] to mango/acorn/u_pci/pci_100/pci_isa/isa_oe_
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X111Y281.XQ Tcko 0.313 mango/acorn/u_pci/pci_100/pci_isa/ctl_state[0]
mango/acorn/u_pci/pci_100/pci_isa/ctl_state[0]
SLICE_X120Y275.F4 net (fanout=8) 0.954 mango/acorn/u_pci/pci_100/pci_isa/ctl_state[0]
SLICE_X120Y275.X Tilo 0.179 mango/acorn/u_pci/pci_100/pci_isa/I_524_0_i
mango/acorn/u_pci/pci_100/pci_isa/I_524_0
SLICE_X89Y193.F4 net (fanout=30) 2.819 mango/acorn/u_pci/pci_100/pci_isa/I_524_0_i
SLICE_X89Y193.CLK Tckf (-Th) 0.121 mango/acorn/io_memrd_int
mango/acorn/u_pci/pci_100/pci_isa/isa_oe_s_i
mango/acorn/u_pci/pci_100/pci_isa/isa_oe_
------------------------------------------------- ---------------------------
Total 4.144ns (0.371ns logic, 3.773ns route)
(9.0% logic, 91.0% route)
--------------------------------------------------------------------------------
 

Are is the driving flop on the clock before the DCM and the receiving flop on the clock after the DCM? The reported clock skews seem extra, extra large, like the DCM delay is being included.

I would open the design in FPGA Editor and look where the clock buffers are. The global clock buffers are usually in the middle of the chip along the top and bottom edge.

Another trick is to temporarily remove your pin assignments in the UCF file and allow the tool to place pins anywhere it wants to. If that design meets timing, then it is usually a logic placement issue relative to the pin assignments.

Your reported errors could be improved with either redundant gates or pipelining. The first error has a fanout of 5. If you reduce this fanout by using redundant gates, it will make placement easier. There is a constraint about allowing redundant gates is it enabled? The second error is made worse because there are two levels of logic that must be transversed. If you could all a pipelining stage, then it would help the second error.

How much of the FPGA is full?
 

Re: how could I fix hold violations in my design &#65311

base on ur twr file, i see that source and destiation is 60ns,ad i think it should have enough time.

it seem that the constraints requirement on that path require a 0ns timing whic definately will cause hold time error.

can you post the details for UCF file and top level module so that we can have a check on it.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top