Hi Marco,
So, for a cap

V = Q / C.

Let's say we want 3V rise, C = 11pF, we can drive 24mA, so

3 = 24mA * t / 11pF  , where t is time.

t = 3 * 11pF / 24mA = 1.375 ns.

You can see the probe's capacitance is limiting the rise time you're 
measuring. 24mA takes 1.4 nS to charge the 'scope probe's capacitance. I 
think you need a faster scope and a FET probe, maybe 2GHz and a probe 
capacitance of 1-2pF. Or ask Xilinx for some data?

HTH, Syms.



"Marco" <marco@marylon.com> wrote in message 
news:1138366454.747563.55520@g49g2000cwa.googlegroups.com...
> They're 11.1pF and 10MOhm, also 500Mhz bandwith.
> Marco
>

Brian, thanks for the links, I also work with ISE 7.1SP4
Marco

They're 11.1pF and 10MOhm, also 500Mhz bandwith.
Marco

Marco,
What's the probe's impedance? Also, the Tektronix TDS5054 appears to be a 
500MHz bandwidth 'scope. This bandwidth limitation will be having an effect 
on your measurements.
Cheers, Syms.
"Marco" <marco@marylon.com> wrote in message 
news:1138365416.594454.310730@g14g2000cwa.googlegroups.com...
> I'm using a Tektronix TDS5054 and, after better tuning it all, I find
> rise times to be (fast-slow):
> 1.6ns and 1.9ns (drive=16, IOSTANDARD=LVCMOS33)
> 1.4ns and 1.8ns (drive=24, IOSTANDARD=LVCOMS33)
> 9ns and 6ns (drive=2, IOSTANDARD=LVCOMS33), yes 9-6, not 6-9
> Are these (mainly the first and the second) reasonable?
> Thanks, Marco
>

I'm using a Tektronix TDS5054 and, after better tuning it all, I find
rise times to be (fast-slow):
1.6ns and 1.9ns (drive=16, IOSTANDARD=LVCMOS33)
1.4ns and 1.8ns (drive=24, IOSTANDARD=LVCOMS33)
9ns and 6ns (drive=2, IOSTANDARD=LVCOMS33), yes 9-6, not 6-9
Are these (mainly the first and the second) reasonable?
Thanks, Marco

Antti wrote:
>
> the default IOBANK VCC is different in different devices so if you use 3.3V
> standard in an bank that has any IO not set to 3.3 (eg left defualt) then
> the defaults (on S3) will yield to 2.5 and causes PAR to fail.
>
> in designs for modern Xilinx FPGAs S3/V4 it is recommended (my
> recommendation) to specify IOSTANDARD for ALL USED pins (located or not)
> only then you are sure that there will be no conflicts during PAR.
>
> Antti

 Another related item worth noting: you used to be able to put HDL
pin attributes in the top level code to avoid UCF errors on unused
pins; however, version 7.1sp4 of XST/ISE coughs up an error on this
construct because the unused input defaults back to 2.5V banking,
even though you told it otherwise!

I posted some example code and notes over here:
http://groups.google.com/group/comp.arch.fpga/msg/afce49b66c1989aa
http://groups.google.com/group/comp.arch.fpga/msg/8955e7209e0c3929
>
>  There is a 7.1iSP4 bug with assigning IOSTANDARDs and LOCS
>using HDL attributes. Unused LOC'd inputs drop their IOSTANDARD
>definitions and default back to LVCMOS25, causing banking errors.
>

Brian

Hi Marco,
Maybe your 'scope and probe measurement combination is the limiting factor? 
Can you tell us what setup you have? Are you using a FET probe?
Cheers, Syms.
"Marco" <marco@marylon.com> wrote in message 
news:1138357376.575109.268200@g44g2000cwa.googlegroups.com...
> Antti, I attached an oscilloscope on the 2 pins I use to read the same
> signal. The first pin is set to FAST, the other one to SLOW, but their
> rise and fall bahaviour is identical, I can overlap the 2 traces on the
> screen, so I think I'm wrong somewhere, even if on the .pad_txt file
> they appear to be correctly set.
> Marco
>

Antti, I attached an oscilloscope on the 2 pins I use to read the same
signal. The first pin is set to FAST, the other one to SLOW, but their
rise and fall bahaviour is identical, I can overlap the 2 traces on the
screen, so I think I'm wrong somewhere, even if on the .pad_txt file
they appear to be correctly set.
Marco

"Marco" <marco@marylon.com> schrieb im Newsbeitrag 
news:1138356403.072915.211360@g44g2000cwa.googlegroups.com...
> Antti, I have to thank you very much (as always) for your suggestions.
> It now works, I specified the IOSTANDARD for all the used pins (some of
> them were LVCOMS25 as default looking inside the .pad_txt file) as an
> attribute within the declaration section of the architecture body. I've
> not been able to let it work setting those values inside the UCF as
> contraint (code 765, due to some parsing errors).
> Should I note differences in rise and fall time between fast and slow
> features?
> I found none.
> Thanks, Marco
>
I have measuered the delay difference fast<>slow on S3 its pretty 
significant.
but if you see the difference depends on your method of measuerment of 
course.

-- 
Antti Lukats
http://www.xilant.com