XST, Virtex2-Pro, odd PAR counter timing failure

  • Thread starter John Providenza
  • Start date
J

John Providenza

Guest
I'm using XST for synthesis and I'm seeing an odd timing failure
from PAR with a 19 bit counter. The counter code is:

reg [19:1] rd_addr; // read port
wire [19:1] rd_addr_preload;

// handle ram address counter
assign rd_addr_preload = (repeat_done) ? next_wave_addr :
cur_wave_addr ;
always @(posedge clk_mem)
if (next_instr)
rd_addr <= rd_addr_preload ;
else if (rd_req_i)
rd_addr <= rd_addr + 1'b1;

The signal "next_wave_addr" comes from the output of a block ram and
is used
to broadside load the counter. Also note that "cur_wave_addr" could
load
the counter, but it's not in the critical path.

For some reason, PAR traces "next_wave_addr" though the carry chain as
a critical path. This seems wrong. I'm scheptical that bit 4 of the
broadside load data should ripple into bit 18 of the counter.

Here's the PAR timing info:


Slack: -0.008ns
Source: Mram_program_inst_ramb_21.B (RAM)
Destination: rd_addr_73 (FF)
Requirement: 5.999ns
Data Path Delay: 5.894ns (Levels of Logic = 9)
Clock Path Skew: -0.113ns
Source Clock: clk_mem rising at 1.172ns
Destination Clock: clk_mem rising at 7.171ns
Clock Uncertainty: 0.000ns

Data Path: Mram_program_inst_ramb_21.B to upatgen/rd_addr_73
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
RAMB16_X5Y6.DOB1 Tbcko 1.500
Mram_program_inst_ramb_21

Mram_program_inst_ramb_21.B
SLICE_X36Y49.F2 net (fanout=2) 1.711 seq_rd_data<77>
SLICE_X36Y49.X Tilo 0.288
rd_addr_preload<4>

Mmux_rd_addr_preload_Result<3>1
SLICE_X34Y48.F3 net (fanout=1) 0.262
rd_addr_preload<4>
SLICE_X34Y48.COUT Topcyf 0.744 rd_addr<4>

rd_addr_inst_lut3_911

rd_addr_inst_cy_125

rd_addr_inst_cy_126
SLICE_X34Y49.CIN net (fanout=1) 0.000
rd_addr_inst_cy_126
SLICE_X34Y49.COUT Tbyp 0.083 rd_addr<6>

rd_addr_inst_cy_127

rd_addr_inst_cy_128
SLICE_X34Y50.CIN net (fanout=1) 0.000
rd_addr_inst_cy_128
SLICE_X34Y50.COUT Tbyp 0.083 rd_addr<8>

rd_addr_inst_cy_129

rd_addr_inst_cy_130
SLICE_X34Y51.CIN net (fanout=1) 0.000
rd_addr_inst_cy_130
SLICE_X34Y51.COUT Tbyp 0.083 rd_addr<10>

rd_addr_inst_cy_131

rd_addr_inst_cy_132
SLICE_X34Y52.CIN net (fanout=1) 0.000
rd_addr_inst_cy_132
SLICE_X34Y52.COUT Tbyp 0.083 rd_addr<12>

rd_addr_inst_cy_133

rd_addr_inst_cy_134
SLICE_X34Y53.CIN net (fanout=1) 0.000
rd_addr_inst_cy_134
SLICE_X34Y53.COUT Tbyp 0.083 rd_addr<14>

rd_addr_inst_cy_135

rd_addr_inst_cy_136
SLICE_X34Y54.CIN net (fanout=1) 0.000
rd_addr_inst_cy_136
SLICE_X34Y54.COUT Tbyp 0.083 rd_addr<16>

rd_addr_inst_cy_137

rd_addr_inst_cy_138
SLICE_X34Y55.CIN net (fanout=1) 0.000
rd_addr_inst_cy_138
SLICE_X34Y55.Y Tciny 0.891 rd_addr<18>

rd_addr_inst_cy_139

rd_addr_inst_sum_135
SLICE_X34Y55.DY net (fanout=1) 0.000
rd_addr_inst_sum_135
SLICE_X34Y55.CLK Tdyck 0.000 rd_addr<18>
rd_addr_73
-------------------------------------------------
---------------------------
Total 5.894ns (3.921ns logic, 1.973ns
route)
(66.5% logic, 33.5% route)

Any ideas?

Thanks!

John Providenza
 
Well, with the structure the Virtex CLBs, a loadable counter implemented
in one level of logic has the carry chain after the mux. The timing
analysis does not take into account logic state, only combinatorial
paths. In the case of the loadable counter, it sees a path out of the LUT
and up the carry chain. Normally, the loadable counter uses the mult_and
to gate off the DI input of the mux_carry when the counter is being loaded
so that a carry does not propagate, but the timing analyzer has no way of
knowing this without your help. You can either do what you can to reduce
the delay on the load path so it meets timing without regard to false
paths, or you can declare this as a false path. My preference is to try
to make it pass without declaring false paths because of the danger of
inadvertently marking a valid path as false.




John Providenza wrote:

I'm using XST for synthesis and I'm seeing an odd timing failure
from PAR with a 19 bit counter. The counter code is:

reg [19:1] rd_addr; // read port
wire [19:1] rd_addr_preload;

// handle ram address counter
assign rd_addr_preload = (repeat_done) ? next_wave_addr :
cur_wave_addr ;
always @(posedge clk_mem)
if (next_instr)
rd_addr <= rd_addr_preload ;
else if (rd_req_i)
rd_addr <= rd_addr + 1'b1;

The signal "next_wave_addr" comes from the output of a block ram and
is used
to broadside load the counter. Also note that "cur_wave_addr" could
load
the counter, but it's not in the critical path.

For some reason, PAR traces "next_wave_addr" though the carry chain as
a critical path. This seems wrong. I'm scheptical that bit 4 of the
broadside load data should ripple into bit 18 of the counter.

Here's the PAR timing info:

Slack: -0.008ns
Source: Mram_program_inst_ramb_21.B (RAM)
Destination: rd_addr_73 (FF)
Requirement: 5.999ns
Data Path Delay: 5.894ns (Levels of Logic = 9)
Clock Path Skew: -0.113ns
Source Clock: clk_mem rising at 1.172ns
Destination Clock: clk_mem rising at 7.171ns
Clock Uncertainty: 0.000ns

Data Path: Mram_program_inst_ramb_21.B to upatgen/rd_addr_73
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
RAMB16_X5Y6.DOB1 Tbcko 1.500
Mram_program_inst_ramb_21

Mram_program_inst_ramb_21.B
SLICE_X36Y49.F2 net (fanout=2) 1.711 seq_rd_data<77
SLICE_X36Y49.X Tilo 0.288
rd_addr_preload<4

Mmux_rd_addr_preload_Result<3>1
SLICE_X34Y48.F3 net (fanout=1) 0.262
rd_addr_preload<4
SLICE_X34Y48.COUT Topcyf 0.744 rd_addr<4

rd_addr_inst_lut3_911

rd_addr_inst_cy_125

rd_addr_inst_cy_126
SLICE_X34Y49.CIN net (fanout=1) 0.000
rd_addr_inst_cy_126
SLICE_X34Y49.COUT Tbyp 0.083 rd_addr<6

rd_addr_inst_cy_127

rd_addr_inst_cy_128
SLICE_X34Y50.CIN net (fanout=1) 0.000
rd_addr_inst_cy_128
SLICE_X34Y50.COUT Tbyp 0.083 rd_addr<8

rd_addr_inst_cy_129

rd_addr_inst_cy_130
SLICE_X34Y51.CIN net (fanout=1) 0.000
rd_addr_inst_cy_130
SLICE_X34Y51.COUT Tbyp 0.083 rd_addr<10

rd_addr_inst_cy_131

rd_addr_inst_cy_132
SLICE_X34Y52.CIN net (fanout=1) 0.000
rd_addr_inst_cy_132
SLICE_X34Y52.COUT Tbyp 0.083 rd_addr<12

rd_addr_inst_cy_133

rd_addr_inst_cy_134
SLICE_X34Y53.CIN net (fanout=1) 0.000
rd_addr_inst_cy_134
SLICE_X34Y53.COUT Tbyp 0.083 rd_addr<14

rd_addr_inst_cy_135

rd_addr_inst_cy_136
SLICE_X34Y54.CIN net (fanout=1) 0.000
rd_addr_inst_cy_136
SLICE_X34Y54.COUT Tbyp 0.083 rd_addr<16

rd_addr_inst_cy_137

rd_addr_inst_cy_138
SLICE_X34Y55.CIN net (fanout=1) 0.000
rd_addr_inst_cy_138
SLICE_X34Y55.Y Tciny 0.891 rd_addr<18

rd_addr_inst_cy_139

rd_addr_inst_sum_135
SLICE_X34Y55.DY net (fanout=1) 0.000
rd_addr_inst_sum_135
SLICE_X34Y55.CLK Tdyck 0.000 rd_addr<18
rd_addr_73
-------------------------------------------------
---------------------------
Total 5.894ns (3.921ns logic, 1.973ns
route)
(66.5% logic, 33.5% route)

Any ideas?

Thanks!

John Providenza
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
"Ray Andraka" <ray@andraka.com> wrote in message
news:4099217F.9E954847@andraka.com...
My preference is to try
to make it pass without declaring false paths because of the danger of
inadvertently marking a valid path as false.

Indeed, be careful with declaring false paths
Click to expand...
I noticed the clock skew was quite high(!) at 113ps. Does the carry chain
straddle different bits of the clock tree? You could try locking it down to
reduce the skew. You only need 8ps! Or, you could tell the timing analyser
your worst case temperature and power supply voltage to get back the 8ps.
good luck, Syms.
 
All -

Thanks for your comments on my problem.

I'm also a bit worried about using false paths, but I
think this one *might* be safe:

NET "upatgen/*_inst_cy_*" TPTHRU = "thru_carry";
TIMESPEC "TS_seq_rd_addr" =
FROM RAMS(upatgen/seq_rd_data<*>)
THRU "thru_carry"
TO FFS (upatgen/rd_addr<*>) 10ns;

I'm a bit worried that this could be toooo agressive, is there
a way to to restrict this specifically to the COUT/CIN pins?

John P

"Symon" <symon_brewer@hotmail.com> wrote in message news:<c7bac9$21dk9$1@ID-212844.news.uni-berlin.de>...
"Ray Andraka" <ray@andraka.com> wrote in message
news:4099217F.9E954847@andraka.com...
My preference is to try
to make it pass without declaring false paths because of the danger of
inadvertently marking a valid path as false.

Indeed, be careful with declaring false paths
I noticed the clock skew was quite high(!) at 113ps. Does the carry chain
straddle different bits of the clock tree? You could try locking it down to
reduce the skew. You only need 8ps! Or, you could tell the timing analyser
your worst case temperature and power supply voltage to get back the 8ps.
good luck, Syms.
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top