Altera Bidi ports, Tristate Buffers & Prop. Delay?

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

Reply to
Pino
Loading thread data ...

Altera supplies timing information in their data sheets, no? Why not look up the delays there?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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

Reply to
Mikeandmax

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

Reply to
Pino

looked

registers

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

Reply to
Pino

looked

the

registers

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

formatting link

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

formatting link

Vaughn Altera

Reply to
Vaughn Betz

looked

of the

registers

formatting link

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

Reply to
Pino

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.