slow slew rate on CII

How slow it is?

As I remember in Cyclone 1 is about 10ns from an output pin connect back to input pin read back. As LVTTL 3.3V 24mA.

Hello,

with 3.3V (LVCMOS or LVTTL) and maximum signal strength, I would expect 500 ps or less rise time, may be up to 1 ns with higher capacitance load (Depending on your equipment, it may be difficult to measure it exactly. I use a GHz oscilloscope with active probe or 500 Ohms resistive probe for this purpose). Anything above indicates unappropriate output load or wrong pin configuration to my opinion.

Regards,

Frank

My scope is not so good, what I did is just compare rising edge between output signal and another output-input-output signal. It's about 10ns as my experiment. The loading and probe problem should be just a little because I'm doing compare (factor should be SUB to 0).

As I remember, column is little bit faster then row I/O. Not so sure which one you're working with.

Regards,

Nicholas

Hello Nicholas,

yes, signal delays can be measured with slower equipment rather exactly. Something like 10 ns for I/O delays seams reasonable. I assumed, that tns1 was talking of slew rates (which is just another way to express rise times) rather than delays, but I'm not sure about.

Regards,

Frank

Slew rate, as in rise time, as in V/us or V/ns.

My signal is ~3v/20ns and nowhere near the 1ns or so I would expect with 3.3v IO. CII parts are supposed to do 200-400Mhz+ TTL IO rates. My signal does pass thru a connector, but there is no way it has the kind of parasitics which would cause this. All I could think of is a global setting of some kind, or that when I changed my current strength setting it was ignored. The only ones I am aware of are:

IO Standard,

Current strength,

Slow slew rate,

Digital termination (OCT),

Various power settings?

The only settings files I am aware of are *defaults.qdf, *.qsf

If someone has the full picture of what the relevant settings are, please let me know.

Using different equipment I see 1.3V/us slew rate on my clock with current strength = max. This is about 2ns rise time, but with large overshoot/undershoot. With OCT set to 25ohm (the only setting allowed for 3.3LVTTL), it looked the same. With current strength = min, it was around 0.6V/us, 5ns rise time, and very clean.

You can't have both a current strength and an OCT assignment at the same time, and it seems to wait until the very end of the build before noticing you want to do something illegal.

Hello,

to my opinion, your masurements with different serial termination respectively drive strengths show that the observed effects are due to unterminated transmission line (cable, PCB trace) connected to the pin. It seems to me as a common signal quality issue.

To design an optimal signal termination, I would have to know the connected networks properties in terms of line impedance (Z0) and electrical length. A usual case is transmission line connecting output and input pin with no additional termination at either end. If the drivers output impedance is clearly below the line impedance, you get signal overshoot at the receiving end. By increasing the driver impedance to the line impedance, you can create a source-side impedance matching an hopefully get a satisfactory signal a the receiver. Please note that the "ideal" signal waveform is only achieved at the receivers side, it may look different at the driver.

I think, you effectively achieved this by setting a lower driver signal strength. If you get a sufficient signal quality by this means, you should be lucky. I can't see nothing "illegal" by using signal strength setting to adjust driver impedance. The point is, that you can't expect a specified impedance and you have no calibration as with some "OCT" variants.

When long PCB traces or cables are conected to FPGA or other fast logics output, I usually supply an external serial termination, which has lower tolerance than the internal driver impedance.

Regards,

Frank

Seems like external resister termination make sense.

Another story may not be your problem.

EP2C8 working with too many signal in one I/O bank toggle will cause PLL work not correct. See this post if you can read Chinese. This poor guy reduce output to 8mA then PLL is correct !

http://www.edacn.net/bbs/viewthread.php?tid=93473&extra=page%3d1%26amp%3bfilter%3ddigest

Good Luck!

Hello,

I can't read chinese, but I had similar issues in some Cyclone II designs. I guess, that's why Cyclone III has internal voltage regulators for PLL VCCA supply. The customer and I didn't have the time to find out yet, if the PLL loss of lock was caused mainly by ground bounce disturbing the input clock or the PLL supply, we downgraded a 32-bit data bus to 16-bit and the design was operational.

Regards,

Frank