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
Reply by Vaughn Betz●August 10, 20042004-08-10
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
Reply by Pino●August 7, 20042004-08-07
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
Reply by Pino●August 1, 20042004-08-01
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
Reply by Mikeandmax●July 30, 20042004-07-30
>
> 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
Reply by rickman●July 30, 20042004-07-30
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
Reply by Pino●July 30, 20042004-07-30
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;