question regarding on output offset

cherjier · Jan 22, 2008

this is an example code:
module counter(CLOCK, ENABLE, COUNT);
input CLOCK;
input ENABLE;
output [3:0] COUNT;

reg [3:0] COUNT = 3'b000;

always @(posedge CLOCK)
if (ENABLE)
COUNT <= COUNT + 1;
else
COUNT <= 3'b000;
endmodule

the constraints :
NET "CLOCK" TNM_NET = "CLOCK";
TIMESPEC "TS_CLOCK" = PERIOD "CLOCK" 5 ns HIGH 50 %;

for behavoural simulation, the output pad COUNT and register COUNT will toggle at the same clock which is the ideal case,
after PAR and run the post PAR simulation, the register COUNT will have around 1.5ns delay with respect to current clock edge and the output pad will delay 6+ns to the same clock edge. the output pad is almost 1 clock cycle delay.

i try to experiment with the offset constraints:
OFFSET = IN 2 ns BEFORE "CLOCK" ;
OFFSET = OUT 10 ns AFTER "CLOCK" ;

but the PAR will return me an error
Slack: -1.478ns (requirement - (clock arrival + clock path + data path + uncertainty))
Source: count_int_0 (FF)
Destination: COUNT_OUT<0> (PAD)
Source Clock: CLOCK_BUFGP rising at 0.000ns
Requirement: 10.000ns
Data Path Delay: 5.282ns (Levels of Logic = 1)
Clock Path Delay: 6.196ns (Levels of Logic = 2)
Clock Uncertainty: 0.000ns

Clock Path: CLOCK to count_int_0
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
M17.I Tiopi 0.885 CLOCK
CLOCK
CLOCK_BUFGP/IBUFG
BUFGCTRL_X0Y31.I0 net (fanout=1) 0.875 CLOCK_BUFGP/IBUFG
BUFGCTRL_X0Y31.O Tbgck

0.900 CLOCK_BUFGP/BUFG
CLOCK_BUFGP/BUFG
SLICE_X174Y368.CLK net (fanout=3) 3.536 CLOCK_BUFGP
------------------------------------------------- ---------------------------
Total 6.196ns (1.785ns logic, 4.411ns route)
(28.8% logic, 71.2% route)

Data Path: count_int_0 to COUNT_OUT<0>
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X174Y368.XQ Tcko 0.360 count_int<0>
count_int_0
G10.O net (fanout=6) 1.399 count_int<0>
G10.PAD Tioop 3.523 COUNT_OUT<0>
COUNT_OUT_0_OBUF
COUNT_OUT<0>
------------------------------------------------- ---------------------------
Total 5.282ns (3.883ns logic, 1.399ns route)
(73.5% logic, 26.5% route)

the clock path delay and data path delay is large but the design is simple enough.
beside,once the offset added by increase the offset out to 12ns,the design will fail on post par simulation. if without offset constraints, the design can pass on the post par simulation but with a large delay between the FF and the pad.

lastly,how do determine the correct offset value for an input/output?
thank you..

echo47 · Jan 22, 2008

I haven't studied your timing reports, but here's a different approach to solving the problem. The best way to reduce flop-to-pad timing is to put your output flops into the IOBs, instead of into the logic fabric. Refer to the "IOB" constraint in your ISE Constraint Guide.

HOWEVER, you can't put a fast counter into the IOBs because IOBs don't provide the nice feedback and fast carry chain like in the logic fabric. Instead, you could leave the counter in the logic fabric, and add an output register to your design. That register can go into the IOBs. Now you have a fast counter and fast flop-to-pad timing, plus one cycle of latency.

cherjier · Jan 24, 2008

i had modified the code to:
output [3:0] COUNT_OUT;
reg [3:0] COUNT_OUT;

always @(posedge CLOCK)
COUNT_OUT <= COUNT;

and i add this line on UCF file:
INST "COUNT_OUT[0]" IOB= TRUE;
INST "COUNT_OUT[1]" IOB= TRUE;
INST "COUNT_OUT[2]" IOB= TRUE;
INST "COUNT_OUT[3]" IOB= TRUE;

the FF to PAD timing did improve but only from 12+ns to 10+ns, and the FF to PAD delay still look large to me.
does this normal or i did not put the register into IOB?

echo47 · Jan 24, 2008

10ns is definitely too long for an IOB flop. Your HDL looks good, but somehow the IOB constraints didn't work.
Check the mapping/routing log files for warning messages related to the IOB constraints.

When I synthesize logic like that, ISE selects IOB flops automatically, so I usually don't need to specify any IOB constraint. But sometime I need to.

Also check your "Pad Summary" report. The "IO Register" column should say "YES" if the IOB flop is used.
You can also examine the IOB configurations and general routing in FPGA Editor.

cherjier · Jan 24, 2008

i check the map report,i could not find any warning regarding IOB but i only have this warning:
WARNING:LIT:243 - Logical network N11 has no load.
which i don't know why....

i have check the PAD summary report and the IO register did show "yes".

so the output FF did located on IOB..

any idea about this?

echo47 · Jan 24, 2008

That's good news your PAD summary says IO Register is "yes".

OFFSET = OUT 10 ns AFTER "CLOCK";

Oh wait a minute! That constraint specifies the time from the CLOCK input pad to the COUNT_OUT output pad. That's all the way through the FPGA, not just from the IOB flop to the output pad. That long path could take more than 10ns on some FPGAs, especially older types.

Which type FPGA are you using?

cherjier · Jan 24, 2008

really? i thought this constraints specified the time of the IOB to the output pad after the specific clock edge.

just for information,normally did you use the offset constraints? basically,how did you figure out the offset value?

i was using virtex 4,it should be kinda fast..i think...

echo47 · Jan 24, 2008

Xilinx constraints are sometimes confusing, even after careful reading of the documentation.

The ISE 9.2i Constraints Guide's description of the OFFSET constraint begins with the following paragraph. Notice how it refers to external clock and I/O pins, and excludes internal points:

OFFSET is a basic timing constraint. It specifies the timing relationship between an external clock and its associated data-in or data-out pin. OFFSET is used only for pads-related signals, and cannot be used to extend the arrival time specification method to the internal signals in a design. A clock that comes from an internal signal is one generated from a synch element, like a FF. A clock that comes from a PAD and goes through a DLL, DCM, clock buffer, or combinatorial logic is supported.

A few pages later is "Example Three: OFFSET OUT AFTER". The comment says the constraint specifies the time from the clock input pad to the data output pad.

I've never used OFFSET constraints in my projects. Maybe I'll need it someday, but so far I've simply used IOB input/output flops, and then relied on the I/O timing switching characteristics in the data sheet.

The Virtex-4 does a lot of things really fast, but it can still have significant delay between the clock input and data output. There are quite a few internal steps between those two pads. I tried your example design in a xc4vfx12-10-ff668, and the CLOCK to COUNT_OUT delay was about 9.2ns in the Trace report and post-route simulation. That's similar to your results.

Code:

module top (CLOCK, ENABLE, COUNT_OUT);
  input             CLOCK, ENABLE;
  reg         [3:0] COUNT=0;
  output reg  [3:0] COUNT_OUT;

  always @ (posedge CLOCK) begin
    COUNT <= ENABLE ? COUNT+1 : 0;
    COUNT_OUT <= COUNT;
  end
endmodule

Code:

NET "CLOCK" TNM_NET = "CLOCK";
TIMESPEC "TS_CLOCK" = PERIOD "CLOCK" 5 ns HIGH 50 %;
OFFSET = IN 2 ns BEFORE "CLOCK" ;
OFFSET = OUT 10 ns AFTER "CLOCK" ;

cherjier · Jan 24, 2008

hum...i think perhaps i'm a bit clear for now.
the offset out is refering to the input clock to the output pad timing.

Slack: -1.478ns (requirement - (clock arrival + clock path + data path + uncertainty))
Source: count_int_0 (FF)
Destination: COUNT_OUT<0> (PAD)
Source Clock: CLOCK_BUFGP rising at 0.000ns
Requirement: 10.000ns
Data Path Delay: 5.282ns (Levels of Logic = 1)
Clock Path Delay: 6.196ns (Levels of Logic = 2)
Clock Uncertainty: 0.000ns

from here, we see that the clock arrive on the input pad time was 0ns but the clock to the FF had a large delay of 6ns and the FF to output pad had a 5ns data delay that's y it had a large output delay. i think the reason was the clock path delay.
agree?

besides,for post par simulation, after i add in the offset contraints with a large offset out constraints, the simulation will fail. but if the offset constraints was remove the simulation was pass but with a large output delay. did you face the same problem?

echo47 · Jan 25, 2008

The eight lines you listed from the timing report should be followed by additional helpful info, although it may be difficult to interpret. Here's the full section from my Trace report:

Code:

Slack:                  0.846ns (requirement - (clock arrival + clock path + data path + uncertainty))
  Source:               COUNT_OUT_0 (FF)
  Destination:          COUNT_OUT<0> (PAD)
  Source Clock:         CLOCK_BUFGP rising at 0.000ns
  Requirement:          10.000ns
  Data Path Delay:      4.146ns (Levels of Logic = 1)
  Clock Path Delay:     5.008ns (Levels of Logic = 2)
  Clock Uncertainty:    0.000ns

  Maximum Clock Path: CLOCK to COUNT_OUT_0
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    AD12.I               Tiopi                 0.944   CLOCK
                                                       CLOCK
                                                       CLOCK_BUFGP/IBUFG
    BUFGCTRL_X0Y13.I0    net (fanout=1)        0.835   CLOCK_BUFGP/IBUFG
    BUFGCTRL_X0Y13.O     Tbgcko_O              0.900   CLOCK_BUFGP/BUFG
                                                       CLOCK_BUFGP/BUFG
    OLOGIC_X1Y41.CLK     net (fanout=6)        2.329   CLOCK_BUFGP
    -------------------------------------------------  ---------------------------
    Total                                      5.008ns (1.844ns logic, 3.164ns route)
                                                       (36.8% logic, 63.2% route)

  Maximum Data Path: COUNT_OUT_0 to COUNT_OUT<0>
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    OLOGIC_X1Y41.OQ      Tockq                 0.584   COUNT_OUT_0
                                                       COUNT_OUT_0
    AB13.O               net (fanout=1)        0.002   COUNT_OUT_0
    AB13.PAD             Tioop                 3.560   COUNT_OUT<0>
                                                       COUNT_OUT_0_OBUF
                                                       COUNT_OUT<0>
    -------------------------------------------------  ---------------------------
    Total                                      4.146ns (4.144ns logic, 0.002ns route)
                                                       (100.0% logic, 0.0% route)

If I understand that correctly, it shows 0.944ns delay in the CLOCK pad input buffer, 0.835ns routing delay to the global clock buffer, 0.900ns delay in the global clock buffer, 2.329ns routing delay in the global clock net. Then, 0.584ns delay from global clock to the IOB flop output, 0.002ns routing delay to the pad output buffer, and 3.560ns delay in the COUNT_OUT<0> pad output buffer. The total time is a little over 9ns. I examined the layout in FPGA Editor, and it looks pretty tight, not much room for improvement. So if you specify a timing constraint requesting faster speed, then ISE will probably complain that it can't do it.

Your values may be somewhat different, especially if you are using a different size/speed Virtex-4 than my xc4vfx12-10-ff668.

You could specifying "FAST" output slew rate, or maybe try a faster I/O mode such as LVDS. That should decrease the 3.560ns value a little, maybe a nanosecond.

cherjier · Jan 30, 2008

hum...i can catch what u saying but somehow i dunno this large amount of delay consider acceptable since it only a simple design.

i also never used it before and just rely on the IOB switching timing only.
the offset constraints seem important but still cannot get the idea how to use it properly...

besides,i have another question and hope can get some feedback..
this is an example code:

Code:

module multi_cyc_test (
	CLK,
	RST_N,
	
	ENA,
	IN_DATA,
	OUT_DATA
	);
	
parameter	IDLE 	= 2'b00;
parameter	LOAD	= 2'b01;
parameter	COUNT	= 2'b10;
parameter	STORE	= 2'b11;	
	
input			CLK;
input 			RST_N;
input			ENA;
input	[3:0]	IN_DATA;

output	[3:0]	OUT_DATA;

reg		[1:0]	counter;
reg		[3:0]	reg_a;
reg		[3:0]	reg_b;

reg		[1:0]	current_state;
reg		[1:0]	next_state;

reg				count_start;
reg				reg_a_en;
reg				reg_b_en;

wire			count_done;

assign	count_done = &counter;
assign	OUT_DATA = reg_b;

always @(posedge CLK or negedge RST_N)
	if (!RST_N)
		counter <= 2'b00;
	else if (count_start)
		counter <= counter + 1;
		
always @(posedge CLK or negedge RST_N)
	if (!RST_N)
		reg_a <= 4'h0;
	else if (reg_a_en)
		reg_a <= IN_DATA;
		
always @(posedge CLK or negedge RST_N)
	if (!RST_N)
		reg_b <= 4'h0;
	else if (reg_b_en)
		reg_b <= ~reg_a;  //from reg_a to reg_b, intermediate might have more combinational logic
		
always @(posedge CLK or negedge RST_N)
	if (!RST_N)
		current_state <= IDLE;
	else
		current_state <= next_state;
		
always @(current_state or ENA or count_done) begin

	count_start = 1'b0;
	reg_a_en = 1'b0;
	reg_b_en = 1'b0;
	
	case (current_state) 
		IDLE : begin
			if (ENA)		next_state = LOAD;
		end
		
		LOAD : begin
			next_state = COUNT;
			reg_a_en = 1'b1;
		end
		
		COUNT: begin
							next_state = COUNT;
			if (count_done)	next_state = STORE;
			count_start = 1'b1;
		end
		
		STORE: begin
			next_state = IDLE;
			reg_b_en = 1'b1;
		end
			
		default: begin
			next_state = IDLE;
		end
	endcase
end
	
endmodule

i would like to set the multi cycle path constraints ,does from reg_a to reg_b consider a multi cycle path?

for example the CLK period is 10ns,
NET "multi_cyc_test/reg_a" TNM_NET = "group_1";
NET "multi_cyc_test/reg_b" TNM_NET = "group_2";
TIMESPEC "TS_MULTI_CYC" = FROM:"group_1"TO:"group_2":40;

any comment regarding the constraint above for multi cycle path?

Welcome to EDAboard.com

question regarding on output offset

cherjier

Member level 5

echo47

Advanced Member level 6

cherjier

Member level 5

echo47

Advanced Member level 6

cherjier

Member level 5

echo47

Advanced Member level 6

cherjier

Member level 5

echo47

Advanced Member level 6

cherjier

Member level 5

echo47

Advanced Member level 6

cherjier

Member level 5

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Connect with us

Online statistics

Forum statistics