Xilinx OBUF attributes on Spartan3

Hi, I'm trying to learn the way to work with output buffers and other features of the XC3S1000FG456 installed on my Analog Devices FPGA extender board. This board has 3 connectors placed in such a way to be able to connect it to a Blackfin DSP evaluation board, but it can work stand-alone as a normal Spartan3 evaluation board and that's the way I'm using it now. I wanted to push out a signal and see how it behaves changing slew, drive current and IO standard (the 3 attributes of the OBUF template). I made a couple of examples in VHDL and I'd like you to tell me what you think about the 2 different approaches.

First one:

OBUF_inst_slow : OBUF generic map ( DRIVE => 16, IOSTANDARD => "LVCMOS33", SLEW => "SLOW") port map ( O => slow_out, -- slow_out is the out port of my entity (same for fast) I => slow_sig_out -- slow_sig_out is the signal I want to send out (same for fast) );

OBUF_inst_fast : OBUF generic map ( DRIVE => 16, IOSTANDARD => "LVCMOS33", SLEW => "FAST") port map ( O => fast_out, -- Buffer output (connect directly to top-level port) I => fast_sig_out -- Buffer input );

I places this snippet inside the architecture of my code and "check syntax" tells me there are no errors in the VHDL.

Second one, I commented the previous code and inserted the following lines in the declaration part of the architecture section:

attribute slew : string; attribute SLEW of fast_out : signal is "FAST"; attribute SLEW of slow_out : signal is "SLOW";

then I put these assignments just before the end of the behavioural section:

fast_out

Reply to
Marco
Loading thread data ...

"Marco" schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

Hi Marco,

Xilinx tools dont know and dont care about your jumper, only what you have specified in your design files. The FPGA doesnt care much either so you can select 2.5 or 3.3 in desgin and set jumper to 2.5 or 3.3 and in most cases everything still works. For maximum performance and standard compliance and voltage tolerance the bank io and standard setting must be correct.

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

Reply to
Antti Lukats

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

Reply to
Marco

"Marco" schrieb im Newsbeitrag news: snipped-for-privacy@g44g2000cwa.googlegroups.com...

I have measuered the delay difference fastslow 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
Reply to
Antti Lukats

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

Reply to
Marco

Reply to
Symon

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:

formatting link
formatting link

Brian

Reply to
Brian Davis

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
Reply to
Marco

Marco, What's the probe's impedance? Also, the Tektronix TDS5054 appears to be a

Reply to
Symon

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

Reply to
Marco

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

Reply to
Marco

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.

Reply to
Symon

Symon, thanks, do agree with what you wrote, it's straight and simple. Thanks

Reply to
Marco

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.