elektroda.net NewsGroups Forum Index - FPGA - Constraining minimum hold times (Xilinx)
Uwe Bonnes
Guest
Guest
Mon Feb 01, 2010 1:38 pm
Hello,
is there a way to constrain minimum hold time requirements with ISE?
I am trying to write to an FT2232H in synchronous FIFO mode. The FT2232H
supplies a 60 MHz clock and specifies 11 ns setup and 0 ns hold. As the
FT2232H supplied clock can stop, using a DCM to retime the clock will at
least require the DCM to stabilize each time and so to wait when the
transmission is initiated.
So only with the FT2232H on a global clock, all outputs using the PAD
registers and with a XC200A and LVCMOS25/12mA/Fast slew drive TICKOF is 5.24
ns and timing can be met (16.666 -5.24 = 11.42 > 11).
However this eats up simultaneous switching margins, and more my test board
uses 3.3V and the clock is on a LHCLK, not reaching all outputs.
Another way would be to clock out data on the negative edge with input delay
on the clock and a slow drive. If I could constrain half a clock period hold
time, the 0 ns hold requirement of the FT2232h could be met.
Is there a way to do so?
Any other ideas?
Thanks
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
whygee
Guest
Guest
Mon Feb 01, 2010 1:38 pm
Uwe Bonnes wrote:
Quote:
Is there a way to do so?
Any other ideas?
use a faster clock ?
Any other ideas?
use a faster clock ?
Quote:
Thanks
hope this helps
hope this helps
yg
--
http://ygdes.com / http://yasep.org
rickman
Guest
Guest
Wed Feb 03, 2010 2:49 am
On Feb 1, 5:38 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
Quote:
Hello,
is there a way to constrain minimum hold time requirements with ISE?
I am trying to write to an FT2232H in synchronous FIFO mode. The FT2232H
supplies a 60 MHz clock and specifies 11 ns setup and 0 ns hold. As the
FT2232H supplied clock can stop, using a DCM to retime the clock will at
least require the DCM to stabilize each time and so to wait when the
transmission is initiated.
So only with the FT2232H on a global clock, all outputs using the PAD
registers and with a XC200A and LVCMOS25/12mA/Fast slew drive TICKOF is 5..24
ns and timing can be met (16.666 -5.24 = 11.42 > 11).
However this eats up simultaneous switching margins, and more my test board
uses 3.3V and the clock is on a LHCLK, not reaching all outputs.
Another way would be to clock out data on the negative edge with input delay
on the clock and a slow drive. If I could constrain half a clock period hold
time, the 0 ns hold requirement of the FT2232h could be met.
Is there a way to do so?
Any other ideas?
is there a way to constrain minimum hold time requirements with ISE?
I am trying to write to an FT2232H in synchronous FIFO mode. The FT2232H
supplies a 60 MHz clock and specifies 11 ns setup and 0 ns hold. As the
FT2232H supplied clock can stop, using a DCM to retime the clock will at
least require the DCM to stabilize each time and so to wait when the
transmission is initiated.
So only with the FT2232H on a global clock, all outputs using the PAD
registers and with a XC200A and LVCMOS25/12mA/Fast slew drive TICKOF is 5..24
ns and timing can be met (16.666 -5.24 = 11.42 > 11).
However this eats up simultaneous switching margins, and more my test board
uses 3.3V and the clock is on a LHCLK, not reaching all outputs.
Another way would be to clock out data on the negative edge with input delay
on the clock and a slow drive. If I could constrain half a clock period hold
time, the 0 ns hold requirement of the FT2232h could be met.
Is there a way to do so?
Any other ideas?
I'm not clear about your problem exactly. It looks like your system
meets the setup time of the FT2232H chip. The hold time requirement
is 0, so that is met for sure unless you have clock routing problems.
If your clock is on the wrong input, there is not much you can do
about that. I am pretty sure you will not find a real way to meet a
half clock time hold and not blow the setup time. In fact, I don't
really see where you are headed with this.
BTW, where did you get the 5.24 ns value? My concern is that the
calculation of this time is a bit messy requiring you go add more than
one offset to a base value as determined by the I/O modes. Did you do
all of that?
Rick
Brian Davis
Guest
Guest
Wed Feb 03, 2010 4:32 am
Uwe Bonnes wrote:
Quote:
Any other ideas?
If the FPGA pin driving the FT2232H WR# pin is within your LHCLK
domain,
how about making WR# the only FAST output pin, and then enable writes
on every other clock cycle.
This would cut your transfer rate to 30 Mbytes/sec max into the
fifo,
but give you two clocks of setup for the data lines.
( I've never used the FT2232H; the data sheet mentions a max transfer
rate >= 25 MB/s in synchronous mode, and it looks like you have to
monitor the TXE# line to stall writes if the FT2232H isn't ready. )
Quote:
Another way would be to clock out data on the negative edge with input delay
on the clock and a slow drive. If I could constrain half a clock period hold
time, the 0 ns hold requirement of the FT2232h could be met.
Is there a way to do so?
I would not recommend this scheme.
With a 16.67 ns clock period, starting at the falling edge you'd need
to
delay the data outputs at least 8.33 ns ( to meet the hold time ) but
no
more than 8.33 + ( 16.67 - 11 )= 14 ns to meet the next clock's setup
time.
So you'd need to hold your I/O's switching time to be within a 5.67 ns
absolute window, whilst using slow I/O's with no DLL in the clock
tree.
Brian
Uwe Bonnes
Guest
Guest
Thu Feb 04, 2010 1:08 pm
rickman <gnuarm_at_gmail.com> wrote:
Quote:
...
I'm not clear about your problem exactly. It looks like your system
meets the setup time of the FT2232H chip. The hold time requirement
is 0, so that is met for sure unless you have clock routing problems.
If your clock is on the wrong input, there is not much you can do
about that. I am pretty sure you will not find a real way to meet a
half clock time hold and not blow the setup time. In fact, I don't
really see where you are headed with this.
I'm not clear about your problem exactly. It looks like your system
meets the setup time of the FT2232H chip. The hold time requirement
is 0, so that is met for sure unless you have clock routing problems.
If your clock is on the wrong input, there is not much you can do
about that. I am pretty sure you will not find a real way to meet a
half clock time hold and not blow the setup time. In fact, I don't
really see where you are headed with this.
While the idea of half a clock hold time at the output was not my brightest,
the question of specifying hold time requirements in general remains.
Quote:
BTW, where did you get the 5.24 ns value?
It's the value form the ds529 datasheet.
Quote:
My concern is that the
calculation of this time is a bit messy requiring you go add more than
one offset to a base value as determined by the I/O modes. Did you do
all of that?
calculation of this time is a bit messy requiring you go add more than
one offset to a base value as determined by the I/O modes. Did you do
all of that?
The post layout timing uses this value too (and some adders for IO voltage,
rate and drive)
Bye
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes
Guest
Guest
Thu Feb 04, 2010 1:16 pm
Brian Davis <brimdavis_at_aol.com> wrote:
Quote:
Uwe Bonnes wrote:
Any other ideas?
If the FPGA pin driving the FT2232H WR# pin is within your LHCLK
domain,
how about making WR# the only FAST output pin, and then enable writes
on every other clock cycle.
This would cut your transfer rate to 30 Mbytes/sec max into the
fifo, but give you two clocks of setup for the data lines.
Any other ideas?
If the FPGA pin driving the FT2232H WR# pin is within your LHCLK
domain,
how about making WR# the only FAST output pin, and then enable writes
on every other clock cycle.
This would cut your transfer rate to 30 Mbytes/sec max into the
fifo, but give you two clocks of setup for the data lines.
Might be an idea.
Quote:
( I've never used the FT2232H; the data sheet mentions a max transfer
rate >= 25 MB/s in synchronous mode, and it looks like you have to
monitor the TXE# line to stall writes if the FT2232H isn't ready. )
rate >= 25 MB/s in synchronous mode, and it looks like you have to
monitor the TXE# line to stall writes if the FT2232H isn't ready. )
I now read 28 MB/sec with an adaptation of Micah Dowty fastftdi.c on the PC
side and a straight forward approach on the FT2232H side, all outputs fast
with high drive and clocked at the posedge with the USBCLK stapped to a
GCLK.
....
Quote:
With a 16.67 ns clock period, starting at the falling edge you'd need
to
delay the data outputs at least 8.33 ns ( to meet the hold time ) but
no
more than 8.33 + ( 16.67 - 11 )= 14 ns to meet the next clock's setup
time.
So you'd need to hold your I/O's switching time to be within a 5.67 ns
absolute window, whilst using slow I/O's with no DLL in the clock
tree.
to
delay the data outputs at least 8.33 ns ( to meet the hold time ) but
no
more than 8.33 + ( 16.67 - 11 )= 14 ns to meet the next clock's setup
time.
So you'd need to hold your I/O's switching time to be within a 5.67 ns
absolute window, whilst using slow I/O's with no DLL in the clock
tree.
As I wrote in the other posting, this was not the brightest idea. But the
question remains, how to specify external hold time requirements with ISE.
Bye
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
rickman
Guest
Guest
Fri Feb 05, 2010 10:01 am
On Feb 4, 5:08 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
Quote:
rickman <gnu...@gmail.com> wrote:
...
I'm not clear about your problem exactly. It looks like your system
meets the setup time of the FT2232H chip. The hold time requirement
is 0, so that is met for sure unless you have clock routing problems.
If your clock is on the wrong input, there is not much you can do
about that. I am pretty sure you will not find a real way to meet a
half clock time hold and not blow the setup time. In fact, I don't
really see where you are headed with this.
While the idea of half a clock hold time at the output was not my brightest,
the question of specifying hold time requirements in general remains.
BTW, where did you get the 5.24 ns value?
It's the value form the ds529 datasheet.
My concern is that the
calculation of this time is a bit messy requiring you go add more than
one offset to a base value as determined by the I/O modes. Did you do
all of that?
The post layout timing uses this value too (and some adders for IO voltage,
rate and drive)
...
I'm not clear about your problem exactly. It looks like your system
meets the setup time of the FT2232H chip. The hold time requirement
is 0, so that is met for sure unless you have clock routing problems.
If your clock is on the wrong input, there is not much you can do
about that. I am pretty sure you will not find a real way to meet a
half clock time hold and not blow the setup time. In fact, I don't
really see where you are headed with this.
While the idea of half a clock hold time at the output was not my brightest,
the question of specifying hold time requirements in general remains.
BTW, where did you get the 5.24 ns value?
It's the value form the ds529 datasheet.
My concern is that the
calculation of this time is a bit messy requiring you go add more than
one offset to a base value as determined by the I/O modes. Did you do
all of that?
The post layout timing uses this value too (and some adders for IO voltage,
rate and drive)
I guess I was hoping for a little more detail than just "it's from the
data sheet". Like I said, to get a clock to output timing requires
you to add several numbers depending on the IO types you are using.
Exactly what part are you using and what IO types and configuation?
The post layout timing will only be as accurate as the information it
is provided with. I'm not trying to be a pain, but I noticed that
this number exactly matches the base number for clock to output
timing, XC3S200A, DCM not in use -4 speed grade. This value is only
valid if you are using LVCMOS25 on both the clock port and the output
with 12 mA drive. Of course, it is possible that this same value came
from some other combination of chip and configuration.
As to specifying hold time, I don't recall. I know you can specify a
max clock to output delay, but a hold time would in essence be a
minimum clock to output delay. I would think they would allow for
that. On I/Os it can be important since not all devices have 0 hold
times. There is a guide for timing constraints. Have you found
that?
Rick
Uwe Bonnes
Guest
Guest
Sat Feb 06, 2010 2:55 am
rickman <gnuarm_at_gmail.com> wrote:
....
Quote:
I guess I was hoping for a little more detail than just "it's from the
data sheet". Like I said, to get a clock to output timing requires
you to add several numbers depending on the IO types you are using.
Exactly what part are you using and what IO types and configuation?
The post layout timing will only be as accurate as the information it
is provided with. I'm not trying to be a pain, but I noticed that
this number exactly matches the base number for clock to output
timing, XC3S200A, DCM not in use -4 speed grade. This value is only
valid if you are using LVCMOS25 on both the clock port and the output
with 12 mA drive. Of course, it is possible that this same value came
from some other combination of chip and configuration.
data sheet". Like I said, to get a clock to output timing requires
you to add several numbers depending on the IO types you are using.
Exactly what part are you using and what IO types and configuation?
The post layout timing will only be as accurate as the information it
is provided with. I'm not trying to be a pain, but I noticed that
this number exactly matches the base number for clock to output
timing, XC3S200A, DCM not in use -4 speed grade. This value is only
valid if you are using LVCMOS25 on both the clock port and the output
with 12 mA drive. Of course, it is possible that this same value came
from some other combination of chip and configuration.
LVCMOS25 is default, if nothing else is constrained. And the timing report
for the LVCMOS/fast/8 mA case said something like
COMP "adbus<0>" OFFSET = OUT 11 ns BEFORE | MAXDELAY | 0.064ns|
11.064ns| 0| 0
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
rickman
Guest
Guest
Sat Feb 06, 2010 9:41 am
On Feb 5, 6:55 pm, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
Quote:
rickman <gnu...@gmail.com> wrote:
...
I guess I was hoping for a little more detail than just "it's from the
data sheet". Like I said, to get a clock to output timing requires
you to add several numbers depending on the IO types you are using.
Exactly what part are you using and what IO types and configuation?
The post layout timing will only be as accurate as the information it
is provided with. I'm not trying to be a pain, but I noticed that
this number exactly matches the base number for clock to output
timing, XC3S200A, DCM not in use -4 speed grade. This value is only
valid if you are using LVCMOS25 on both the clock port and the output
with 12 mA drive. Of course, it is possible that this same value came
from some other combination of chip and configuration.
LVCMOS25 is default, if nothing else is constrained. And the timing report
for the LVCMOS/fast/8 mA case said something like
COMP "adbus<0>" OFFSET = OUT 11 ns BEFORE | MAXDELAY | 0.064ns|
11.064ns| 0| 0
...
I guess I was hoping for a little more detail than just "it's from the
data sheet". Like I said, to get a clock to output timing requires
you to add several numbers depending on the IO types you are using.
Exactly what part are you using and what IO types and configuation?
The post layout timing will only be as accurate as the information it
is provided with. I'm not trying to be a pain, but I noticed that
this number exactly matches the base number for clock to output
timing, XC3S200A, DCM not in use -4 speed grade. This value is only
valid if you are using LVCMOS25 on both the clock port and the output
with 12 mA drive. Of course, it is possible that this same value came
from some other combination of chip and configuration.
LVCMOS25 is default, if nothing else is constrained. And the timing report
for the LVCMOS/fast/8 mA case said something like
COMP "adbus<0>" OFFSET = OUT 11 ns BEFORE | MAXDELAY | 0.064ns|
11.064ns| 0| 0
Maybe I am missing something, but your original post said "XC200A and
LVCMOS25/12mA/Fast slew drive TICKOF is 5.24 ns and timing can be met
(16.666 -5.24 = 11.42 > 11)" The 5.24 ns value matches the data sheet
value for LVCMOS25 on both the clock input and the driver output with
12 mA fast slew and not using the DCM. Using the 8 mA drive you list
above adds 0.38 ns giving 5.62 ns. Subtracting from 16.666 gives
11.046 which is close to the result above, but not a perfect match. I
don't know if there is still a mismatch between your constraints and
the data I am using or maybe the timing file is more up to date than
the data sheet. Either way, I guess I am asking if the description of
your I/Os is as above, both the clock input and the driver output at
LVCMOS25 and the output at 8 mA FAST and the DCM is not being used.
If you want to get a little more margin in your timing, which is where
I think you are taking this, you can utilize the DCM and improve your
margin by almost 2 ns!
Rick
Uwe Bonnes
Guest
Guest
Sat Feb 06, 2010 5:34 pm
rickman <gnuarm_at_gmail.com> wrote:
...
Quote:
Maybe I am missing something, but your original post said "XC200A and
LVCMOS25/12mA/Fast slew drive TICKOF is 5.24 ns and timing can be met
(16.666 -5.24 = 11.42 > 11)" The 5.24 ns value matches the data sheet
value for LVCMOS25 on both the clock input and the driver output with
12 mA fast slew and not using the DCM. Using the 8 mA drive you list
above adds 0.38 ns giving 5.62 ns. Subtracting from 16.666 gives
11.046 which is close to the result above, but not a perfect match. I
don't know if there is still a mismatch between your constraints and
the data I am using or maybe the timing file is more up to date than
the data sheet. Either way, I guess I am asking if the description of
your I/Os is as above, both the clock input and the driver output at
LVCMOS25 and the output at 8 mA FAST and the DCM is not being used.
LVCMOS25/12mA/Fast slew drive TICKOF is 5.24 ns and timing can be met
(16.666 -5.24 = 11.42 > 11)" The 5.24 ns value matches the data sheet
value for LVCMOS25 on both the clock input and the driver output with
12 mA fast slew and not using the DCM. Using the 8 mA drive you list
above adds 0.38 ns giving 5.62 ns. Subtracting from 16.666 gives
11.046 which is close to the result above, but not a perfect match. I
don't know if there is still a mismatch between your constraints and
the data I am using or maybe the timing file is more up to date than
the data sheet. Either way, I guess I am asking if the description of
your I/Os is as above, both the clock input and the driver output at
LVCMOS25 and the output at 8 mA FAST and the DCM is not being used.
Often the timing in the datasheet is not as actual as the timing used in
ISE. Soslight differences may arise.
Quote:
If you want to get a little more margin in your timing, which is where
I think you are taking this, you can utilize the DCM and improve your
margin by almost 2 ns!
I think you are taking this, you can utilize the DCM and improve your
margin by almost 2 ns!
As the USB clock may stop, additional considerations need to be done when
using DCM. I will consider, but my original question was about constraining
minimum hold times. I still don't see a way to do so.
Bye
Quote:
Rick
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
rickman
Guest
Guest
Sat Feb 06, 2010 9:32 pm
On Feb 6, 9:34 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
Quote:
my original question was about constraining
minimum hold times. I still don't see a way to do so.
minimum hold times. I still don't see a way to do so.
Sorry, I thought that was explained. I can't say categorically, but I
don't think there is a way. Bsides, your approach of using a global
clock input and a register in the IOB means the delay is not
controllable by layout. It is what the data sheet says it is and they
typically don't spec minimum delays.
Inside the chip there is no reason to use minimum delays if you are
using the clock routing resources. Any other clock routing is at your
own risk and I have never seen tools to support that.
Rick
elektroda.net NewsGroups Forum Index - FPGA - Constraining minimum hold times (Xilinx)
