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                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Uwe Bonnes wrote:
> Is there a way to do so?
> Any other ideas?
use a faster clock ?

> Thanks
hope this helps ;-)
yg

-- 
http://ygdes.com / http://yasep.org

On Feb 1, 5:38=A0am, Uwe Bonnes
<b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> 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 =3D 11.42 > 11).
>
> However this eats up simultaneous switching margins, and more my test boa=
rd
> 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 de=
lay
> on the clock and a slow drive. If I could constrain half a clock period h=
old
> 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

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.

( 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. )

>
> 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

rickman <g...@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)  

Bye
-- 
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Brian Davis <b...@aol.com> wrote:
> 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.

Might be an idea. 

> ( 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. )

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.

...

>  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.

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                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Feb 4, 5:08=A0am, Uwe Bonnes
<b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> rickman <gnu...@gmail.com> wrote:
> >...
> > I'm not clear about your problem exactly. =A0It looks like your system
> > meets the setup time of the FT2232H chip. =A0The 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. =A0I am pretty sure you will not find a real way to meet a
> > half clock time hold and not blow the setup time. =A0In 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 brighte=
st,
> the question of specifying hold time requirements in general remains.
>
> > BTW, where did you get the 5.24 ns value? =A0
>
> 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. =A0Did you d=
o
> > all of that?
>
> The post layout timing uses this value too (and some adders for IO voltag=
e,
> rate and drive) =A0


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

rickman <g...@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

-- 
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Feb 5, 6:55=A0pm, Uwe Bonnes
<b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> ...
>
> > I guess I was hoping for a little more detail than just "it's from the
> > data sheet". =A0Like 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. =A0I'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. =A0This value is only
> > valid if you are using LVCMOS25 on both the clock port and the output
> > with 12 mA drive. =A0Of course, it is possible that this same value cam=
e
> > from some other combination of chip and configuration.
>
> LVCMOS25 is default, if nothing else is constrained. And the timing repor=
t
> for the LVCMOS/fast/8 mA case said something like
> =A0 COMP "adbus<0>" OFFSET =3D OUT 11 ns BEFORE | MAXDELAY =A0 =A0|
=A0 =
=A0 0.064ns|
> =A0 =A0 11.064ns| =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 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 =3D 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

rickman <g...@gmail.com> wrote:
 ...
> 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.

Often the timing in the datasheet is not as actual as the timing used in
ISE. Soslight differences may arise.

> 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!

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

> Rick

-- 
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------