Prev: Quartus Web Edition on Linux - no simulation?
Next: Connecting ADC chip to sparta 3 a dsp
From: Uwe Bonnes on 4 Feb 2010 05:16
Brian Davis <brimdavis(a)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 bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
From: rickman on 5 Feb 2010 02:01
On Feb 4, 5:08 am, Uwe Bonnes <b...(a)elektron.ikp.physik.tu-
darmstadt.de> wrote:
> rickman <gnu...(a)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 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
From: Uwe Bonnes on 5 Feb 2010 18:55
rickman <gnuarm(a)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 bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
From: rickman on 6 Feb 2010 01:41
On Feb 5, 6:55 pm, Uwe Bonnes <b...(a)elektron.ikp.physik.tu-
darmstadt.de> wrote:
> rickman <gnu...(a)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

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
From: Uwe Bonnes on 6 Feb 2010 09:34
rickman <gnuarm(a)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 bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Quartus Web Edition on Linux - no simulation?
Next: Connecting ADC chip to sparta 3 a dsp