fpga4fun.com

Is there a trick to changing the IO standard? I can't get the output voltage to be anything but 3.3 volts. In QuartusII 6.1 Web Edition (with Xylo-EM) I change the IO standard in the Pin Planner from 3.3 to 1.5, compile and load, but I still get 3.3 volts out. I also tried setting drive strength to minimum, but with no apparent visual effect (although I did not measure current).
The way I'm testing this is I took the LED Blink program and widened the register to 4 bits (and assigned to match the onboard LEDs) and assigned the two new bits to external pins (routed to a solderless breadboard). I then put an LED on one pin (for visual indication) and a 1K resistor with an oscilloscope across it on the other. I can't see or measure a difference when changing IO standards. I even made sure that the new pins were from an IO bank different than the onboard LEDs. Originally I tried the testing with just measuring voltage across the onboard LEDs, but got the same result.
Any help?

Thanks,
Paul

That's because the board is hard-wired for 3.3V (the FPGA pins called VCCIO are wired to 3.3V). So you can only use an IO standard that calls for 3.3V on VCCIOs. Check the Cyclone datasheet to see what I'm speaking about.

Could that track be cut and another voltage applied? What are the options?

You cannot cut the tracks as they are below the FPGA. Your best bet is to heat up and lift the pins. But that's risky, these TQFP pins are fragile.

Why do you need 1.5V IO standard?

Ok, I thought that since it allows defining each pin separately that you could specify any IO standard that is <= the supply voltage. I'm not familiar with the input structure, but I figured that it is something like a programmable comparator and would have no problem.

What about the drive current spec - why doesn't the LED glow dimly at minimum drive?

I have an external data and a clock source that could directly trigger a 1.5 input, but not a 3.3 input. I was hoping to avoid the extra noise, jitter and construction (has to be built) issues associated with translating these signals.

Thank you,
Paul

FPGAs can't do that. There is no programmable comparators.

I think that the LED should glow dimly at minimum drive. Try both the maximum and minimum drives, to see if you can see the difference.

>>FPGAs can't do that. There is no programmable comparators.

I was just guessing as to how the IO block handled responding to the different voltage levels required by the different standards. Being new to FPGAs, I'm just surprised at their capability. My last digital project took a lot of time to design and was expensive. After I tested it, there was an abundance of cuts and jumpers to make.


I programmed the onboard LEDs - one for max and the other for min.
Side by side I see no difference in brightness.

PB

Not sure what is going on...

One idea: Create one rbf file with high drive, and another one with low drive, and check that they are different. This way, at least you know that Quartus took into account your constraint.
Another idea: check into the cyclone datasheet that the drive is configurable for the IO standard that you chose.
Third idea: measure the current using a multimeter instead of relying on your eyes for the "measurement".

See, I have lots of idea, as long as you do all the work

This issue was related to changing the IO standard, so it doesn't really matter now.

However there is one thing that doesn't make sense - How can you adjust the output voltage to push significantly more/less current when the IO standards define fixed voltages?

Doing a little research on 'drive strength', it seems to relate to peak current available to drive capacitive loads. I can see how the FPGA output structure might adjust its' resistance to allow more/less current during the rise time without violating any particular IO standard voltage. If you fanout to a bunch of CMOS gates and the drive current is set 'low', then the propagation delay (rise time until Vih is satisfied) will be long (RC time constant). Turning up the drive strength will shorten the delay, but could cause other issues if you have a lot of gates that are switching at the same time.

Unless this becomes an issue again, I think I'll leave it at that.

Thanks for all your feedback,
Paul

Where does Saxo get its VCCINT supply from?