why io buf delay is so long

[Altera_Forum]

file:///C:/DOCUME%7E1/dsun/LOCALS%7E1/Temp/moz-screenshot.jpg I am compiling a cyclone 3. I found some io buf delay is almost 4ns. how could this happen? if this is not true. how to make this number smaller?

[Altera_Forum]

Hi, can you post the screenshot again? Btw, which I/O std was used?

[Altera_Forum]

IOBUF is slow in Cyclone3. If you look at the Cyclone III Handbook Vol.2 Ch.1, you'll see all timing parameters. For example, I'm using EP3C16C7 3.3V LVCMOS, and Table 1-60 (column IO) shows tco from GCLK PLL is 6.143ns and Table 1-61 (row IO) shows 3.493ns. 

 Regarding the output delay, I have two related questions:  1. Why do the tco numbers NOT match "report_timing" in timequest? In my case, the numbers are completely off (more than an order of magnitude). What am I missing?  2. In the same Cyclone III Handbook, Table 1-42 on pp. 1-33 shows max output toggle rate for 3.3V LVCMOS at C7 speed grade is 74MHz, but timequest reported that my design could run at 200MHz. Again why is this discrepancy between timequest and handbook?

[Altera_Forum]

You can improve output-enable delay by driving it from a register and assign that register to be placed in a "Fast Output Enable Register" in the IOE.

[Altera_Forum]

I don't have output enable -- it's always on. Also I'm using the fastest driver mode, and PLL to drive clock tree. 

 Can someone from Altera please explain the discrepancy between handbook and timequest?