Altera Bidi ports, Tristate Buffers & Prop. Delay?

P

Pino

Guest
To all,

I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus
both within a BDF graph and also made my own configuration developed
using VHDL. They all work similarily but the concern is the
propagation delay which seems to be large (~ 7-10 ns). This limits
the total operation of the chip that I have to 100 MHz, which is a bit
strange? The chipset to which I synthesized too in Quartus is
EP1S10F780C6ES.

Can anyone tell me if this propagation delay is EXPECTED??? If so,
what is causing this FPGA speed limit? Can I reduce this somehow? I
anticipate to use this with my memory controller for PC100 SDRAM.

The configuration coded is as follows:
(not)OE
|
|
|\
| \
IN -------| /-------
|/ |
|----------Bidi-pin
/| |
OUT -------/ |-------
\ |
\|
|
|
OE

The functional VHDL code that I have implemented and simulated is as
follows:

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY Tristate_Buffer IS

PORT
(
OE : IN STD_LOGIC;
DATA_IN : IN STD_LOGIC;
DATA_OUT : OUT STD_LOGIC;
BUS_INOUT : INOUT STD_LOGIC
);

END Tristate_Buffer;

ARCHITECTURE mainRTL OF Tristate_Buffer IS
signal bus_wire1, bus_wire2 :STD_LOGIC;

BEGIN


op_assign_process: PROCESS (OE, DATA_IN, BUS_INOUT)
BEGIN

IF OE = '1' THEN
bus_wire1 <= DATA_IN;
bus_wire2 <= 'Z';
ELSE
bus_wire1 <= 'Z';
bus_wire2 <= BUS_INOUT;
END IF;

DATA_OUT <= bus_wire2;

END PROCESS op_assign_process;

bus_assign_process: PROCESS (bus_wire1)
BEGIN

BUS_INOUT <= bus_wire1;

END PROCESS bus_assign_process;

END mainRTL;
 
Pino wrote:
To all,

I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus
both within a BDF graph and also made my own configuration developed
using VHDL. They all work similarily but the concern is the
propagation delay which seems to be large (~ 7-10 ns). This limits
the total operation of the chip that I have to 100 MHz, which is a bit
strange? The chipset to which I synthesized too in Quartus is
EP1S10F780C6ES.

Can anyone tell me if this propagation delay is EXPECTED??? If so,
what is causing this FPGA speed limit? Can I reduce this somehow? I
anticipate to use this with my memory controller for PC100 SDRAM.

The configuration coded is as follows:
(not)OE
|
|
|\
| \
IN -------| /-------
|/ |
|----------Bidi-pin
/| |
OUT -------/ |-------
\ |
\|
|
|
OE
Altera supplies timing information in their data sheets, no? Why not
look up the delays there?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus
often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer. Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae
 
mikeandmax@aol.com (Mikeandmax) wrote in message news:<20040730131548.23098.00002650@mb-m07.aol.com>...
I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus

often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer. Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae
Thanks for the update on where to start looking. After reading
further the specificatios in the delays within the Stratix IOE
structure, I've managed to compute the internal timing and external
timing for a given drive strength at the output for a bidirectional
pin:

Internal Timing:
=================
total prop. delay = ip/op register clock-to-output delay + IOE data
input to combinatorial output + setup time + hold time + routing delay

In equation form I have this as:

tpd1 = tco_c + tpcombin2pin_c + tsu + th + tlocal
tpd1 = 0.171 + 3.357 + 0.080 + 0.068 + 0.345
tpd1 = 4.021 ns

External Timing (4mA drive strength LVTTL) :
==========================================

total prop. delay = Setup time for bidi pin using column IOE registers
+ Hold Time for bidi pin using column IOE registers + Clock-to-Output
Delay Bidi pin using column IOE registers

In equation form I have this as:

tpd2 = tinsu + tinh + toutco
tpd2 = 2.33 + 0 + 4.922
tpd2 = 7.252 ns

** Hopefully I interpreted the specifications correctly?

If my interpretation is correct, the issue I have now is that I'm not
sure if I should take total prop. delay = tpd1 + tpd2 = 11.273 ns?
Does anyone know if this is the correct thing to do?

My reasoning for combining both is that the internal one relates to
the IOE internal timing & the external timing is associated directly
to the output bidirectional pin.

Regards,
Pino
 
pinod01@sympatico.ca (Pino) wrote in message news:<b7ed9648.0407312040.783610f9@posting.google.com>...
mikeandmax@aol.com (Mikeandmax) wrote in message news:<20040730131548.23098.00002650@mb-m07.aol.com>...

I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus

often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer. Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae

Thanks for the update on where to start looking. After reading
further the specificatios in the delays within the Stratix IOE
structure, I've managed to compute the internal timing and external
timing for a given drive strength at the output for a bidirectional
pin:

Internal Timing:
=================
total prop. delay = ip/op register clock-to-output delay + IOE data
input to combinatorial output + setup time + hold time + routing delay

In equation form I have this as:

tpd1 = tco_c + tpcombin2pin_c + tsu + th + tlocal
tpd1 = 0.171 + 3.357 + 0.080 + 0.068 + 0.345
tpd1 = 4.021 ns

External Timing (4mA drive strength LVTTL) :
==========================================

total prop. delay = Setup time for bidi pin using column IOE registers
+ Hold Time for bidi pin using column IOE registers + Clock-to-Output
Delay Bidi pin using column IOE registers

In equation form I have this as:

tpd2 = tinsu + tinh + toutco
tpd2 = 2.33 + 0 + 4.922
tpd2 = 7.252 ns

** Hopefully I interpreted the specifications correctly?

If my interpretation is correct, the issue I have now is that I'm not
sure if I should take total prop. delay = tpd1 + tpd2 = 11.273 ns?
Does anyone know if this is the correct thing to do?

My reasoning for combining both is that the internal one relates to
the IOE internal timing & the external timing is associated directly
to the output bidirectional pin.

Regards,
Pino
Sorry to ask another question, but I wasn't too clear on whether if I
am using a bidi pin I only have to take the above bidi pin prop. delay
parameters or if I have to use the internal IOE prop. delay as well?
Anyone know the answer to this?

Cheers,
Pino
 
pinod01@sympatico.ca (Pino) wrote in message news:<b7ed9648.0408061906.79dd84ab@posting.google.com>...
pinod01@sympatico.ca (Pino) wrote in message news:<b7ed9648.0407312040.783610f9@posting.google.com>...
mikeandmax@aol.com (Mikeandmax) wrote in message news:<20040730131548.23098.00002650@mb-m07.aol.com>...

I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus

often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer. Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae

Thanks for the update on where to start looking. After reading
further the specificatios in the delays within the Stratix IOE
structure, I've managed to compute the internal timing and external
timing for a given drive strength at the output for a bidirectional
pin:

Internal Timing:
=================
total prop. delay = ip/op register clock-to-output delay + IOE data
input to combinatorial output + setup time + hold time + routing delay

In equation form I have this as:

tpd1 = tco_c + tpcombin2pin_c + tsu + th + tlocal
tpd1 = 0.171 + 3.357 + 0.080 + 0.068 + 0.345
tpd1 = 4.021 ns

External Timing (4mA drive strength LVTTL) :
==========================================

total prop. delay = Setup time for bidi pin using column IOE registers
+ Hold Time for bidi pin using column IOE registers + Clock-to-Output
Delay Bidi pin using column IOE registers

In equation form I have this as:

tpd2 = tinsu + tinh + toutco
tpd2 = 2.33 + 0 + 4.922
tpd2 = 7.252 ns

** Hopefully I interpreted the specifications correctly?

If my interpretation is correct, the issue I have now is that I'm not
sure if I should take total prop. delay = tpd1 + tpd2 = 11.273 ns?
Does anyone know if this is the correct thing to do?

My reasoning for combining both is that the internal one relates to
the IOE internal timing & the external timing is associated directly
to the output bidirectional pin.

Regards,
Pino
Hi Pino,

The equations above look wrong to me.

It looks like what you're most worried about is the Tco of the output.
That is given in the Stratix datasheet at
http://www.altera.com/literature/hb/stx/ch_4_vol_1.pdf

The parameter you want is Toutco. Its precise value depends on:

1. The device you are using (e.g. 1S10 vs. 1S80)
2. The speed grade
3. Whether you are using a PLL or not.
4. What kind of global network you are using (if you're not using a
PLL).
5. The capacitive load on the IO (this is only an approximation of the
true board delay; better accuracy requires that you actually simulate
your board).
6. The IO standard, drive strength and slew rate you use.

Assuming you want an LVTTL IO, driving a 10 pF load, using fast slew
rate, and a 24 mA drive strength (this is the default IO setup), and
are using a global clock with no PLL:

Toutco = 4.71 ns in a 1S10 -5
Toutco = 5.777 ns in a 1S80 -5

If you use a 4 mA drive strength add 570 ps to the numbers above.

If you use a PLL, things speed up by approximately 3 ns.

While you can use the datasheet to answer these questions, I think
you'll find it easier to just do simple sample designs in Quartus and
look at the timing you achieve rather than doing manual timing
analysis of various timing paths. The calculation I did above was
just the Tco of the output (generally the most challenging timing
parameter for this kind of design). To see the delays of paths into
the IO input register and within the FPGA, it is easiest to just use
Quartus rather than trying to add all the right numbers from the
datasheet.

You can grab a free version from
https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp

Vaughn
Altera
 
vbetz@altera.com (Vaughn Betz) wrote in message news:<48761f7f.0408092009.27cbc9eb@posting.google.com>...
pinod01@sympatico.ca (Pino) wrote in message news:<b7ed9648.0408061906.79dd84ab@posting.google.com>...
pinod01@sympatico.ca (Pino) wrote in message news:<b7ed9648.0407312040.783610f9@posting.google.com>...
mikeandmax@aol.com (Mikeandmax) wrote in message news:<20040730131548.23098.00002650@mb-m07.aol.com>...

I've discovered that there is some significant propagation delay
between the input and bidirectional pin & bidirectional pin to output
pin in my simulation. I've compared the function LPM_BUSTRI within
Quartus, a construction made up from Tri-state buffers within Quartus

often prop delays in a tristate pin are due to OE performance - have you looked
at the OE timinng numbers, or are you indeed looking at the prop delay of the
in or out buffer. Most modern FPGAs now have syncronous OE and data registers
at the pin, which can give you much better timing through the I/O.

Mike Thomas
Lattice fae

Thanks for the update on where to start looking. After reading
further the specificatios in the delays within the Stratix IOE
structure, I've managed to compute the internal timing and external
timing for a given drive strength at the output for a bidirectional
pin:

Internal Timing:
=================
total prop. delay = ip/op register clock-to-output delay + IOE data
input to combinatorial output + setup time + hold time + routing delay

In equation form I have this as:

tpd1 = tco_c + tpcombin2pin_c + tsu + th + tlocal
tpd1 = 0.171 + 3.357 + 0.080 + 0.068 + 0.345
tpd1 = 4.021 ns

External Timing (4mA drive strength LVTTL) :
==========================================

total prop. delay = Setup time for bidi pin using column IOE registers
+ Hold Time for bidi pin using column IOE registers + Clock-to-Output
Delay Bidi pin using column IOE registers

In equation form I have this as:

tpd2 = tinsu + tinh + toutco
tpd2 = 2.33 + 0 + 4.922
tpd2 = 7.252 ns

** Hopefully I interpreted the specifications correctly?

If my interpretation is correct, the issue I have now is that I'm not
sure if I should take total prop. delay = tpd1 + tpd2 = 11.273 ns?
Does anyone know if this is the correct thing to do?

My reasoning for combining both is that the internal one relates to
the IOE internal timing & the external timing is associated directly
to the output bidirectional pin.

Regards,
Pino

Hi Pino,

The equations above look wrong to me.

It looks like what you're most worried about is the Tco of the output.
That is given in the Stratix datasheet at
http://www.altera.com/literature/hb/stx/ch_4_vol_1.pdf

The parameter you want is Toutco. Its precise value depends on:

1. The device you are using (e.g. 1S10 vs. 1S80)
2. The speed grade
3. Whether you are using a PLL or not.
4. What kind of global network you are using (if you're not using a
PLL).
5. The capacitive load on the IO (this is only an approximation of the
true board delay; better accuracy requires that you actually simulate
your board).
6. The IO standard, drive strength and slew rate you use.

Assuming you want an LVTTL IO, driving a 10 pF load, using fast slew
rate, and a 24 mA drive strength (this is the default IO setup), and
are using a global clock with no PLL:

Toutco = 4.71 ns in a 1S10 -5
Toutco = 5.777 ns in a 1S80 -5

If you use a 4 mA drive strength add 570 ps to the numbers above.

If you use a PLL, things speed up by approximately 3 ns.

While you can use the datasheet to answer these questions, I think
you'll find it easier to just do simple sample designs in Quartus and
look at the timing you achieve rather than doing manual timing
analysis of various timing paths. The calculation I did above was
just the Tco of the output (generally the most challenging timing
parameter for this kind of design). To see the delays of paths into
the IO input register and within the FPGA, it is easiest to just use
Quartus rather than trying to add all the right numbers from the
datasheet.

You can grab a free version from
https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp

Vaughn
Altera
Vaughn,

Thanks for the reply to this and I appreciate your advice in
using the timing analysis tool to extract a more appreciable number
than manual calculations. I still think the manual calculations also
give a good feel for how things are calculated internal to the
software. Quartus calculates ~ 8.4 ns, and my calculation above shows
close to that if I only use the External Timing. It seems from what
you mentioned, you only have to worry about Tco for the External
timing part within the documentation and not the Internal part.

I appreciate the clarification on the specific section.

Cheers,
Pino
 

Welcome to EDABoard.com

Sponsor

Back
Top