This question stems from the usage of a (small) FPGA in my micro, but the issue itself is generic in nature so I'm asking it on the Hardware forum.

Previously my micro used a CPLD for glue logic, peripheral (bank switching, IDE high byte latch, tone generator), and interrupt routing. Everything worked well. The design for my new micro, which is nearly finished, uses an FPGA (EPF10K10) for these same functions, and the hope is some more: DMA controller, MMU, etc. But that isn't what this post is about.

The biggest challenge with this switch is system startup. CPLDs function like normal 74 logic in that the logic is "just there", right form power on. But FPGAs, at least the one I'm using, need to obtain the design from a memory. Here lies the problem: during this startup time (say 200mS, but likely much less), the IO pins on the FPGA are tri-stated.

This puts me in unknown territory. In every micro I've seen schematics for the signals that I'm using the FPGA to generate (including chip selects, output enables etc), are always driven. But with the FPGA generating these signals at startup there would be a time when the chip selects on the memories and peripheral ICs will be left to float. This doesn't seem to right me, since if the Chip Select (and Read) were to float low the data buses would then be driven, potentially from multiple ICs at once.

Is the solution simply to supply pull-ups for each of these pins? I'm assuming this means that when the FPGA needs to put a logic 1 on that pin it should then tristate it instead of asserting a 1? Or doesn't it matter? How bad are floating inputs anyway? I've done some reading, and it seems to vary depending on wether CMOS is used, vs TTL etc. The problem is my computer is a nice mix of modern CMOS parts and older NMOS.

It's possible I'm over complicating this and that there wouldn't be a real problem with leaving these pins to float while the system starts. But it doesn't seem right to me.

Any insight gratefully received. If anyone is interested, my blog has some more info on the current plans for my updated micro.

_________________
8 bit fun and games: https://www.aslak.net/

The answer you seek is: maybe. I am unfamiliar with the Altera 10K family; my FPGA experience is strictly limited to Xilinx parts. However, the in-system needs of these parts are similar, so I expect that the Altera parts provide many of the same capabilities that I find useful in the Xilinx parts.

First, the Xilinx parts have a dedicated output, Done, which signals that the part has loaded its configuration. I generally tie that signal, which is low while the part is loading its configuration, into the reset signal chain of my designs. Thus, any non-FPGA logic is held in reset until the FPGA is operational and can perform glue-logic type of functions in addition to its more complex functions: DMA, UARTs, timers, video generators, etc.

Second, the Xilinx parts all include programmable PUs on the I/O pins. The value of these pull ups varies greatly and is generally greater than 50k ohm. Whether this value is suitable for a particular purpose will require your analysis of the input current requirements of any circuits external to the FPGA. These PUs may or may not be enabled during the period of time that the configuration is being loaded into the FPGA. Post configuration, these PUs are completely under the control of the developer. Therefore, the Xilinx parts have either pins dedicated to the purpose of enabling these PUs during configuration, i.e. nPUDC, or they have dedicated configuration mode pins for the same purpose. The latter case is true for Xilinx parts from the same generation as the Altera 10k family of FPGAs.

_________________
Michael A.

Feels to me that the internal pullups are not going to be connected until configuration is complete. So perhaps the answer is:
- use external pullups for safety during config, on reset lines and output enables.
- don't configure the internal ones if you already have external ones
- drive to logic 0 and 1 as usual - don't use Z as a 1 condition in mission mode.

It might be that a reset controller would help here, by producing and stretching a reset condition, but I'd only have thought about reset inputs, not about output enables. It feels like it defeats the purpose a bit to have logic chips to deal with reset, when you're aiming for an FPGA design.

Sounds good. This will be an almost exclusively through hole board (the FPGAs (there are two) are PLCC84), so I guess I better get some resistor arrays. I'm not using internal pull-ups. The question logically following is what value to use, and for that I haven't much idea.



Yes. I've pondered reset generators too. My initial idea was that /RESET should be a FPGA signal (whereby the FPGA could generate resets via a watchdog-mechanism), with a pull-down to hold it low whilst the FPGA is being programmed. I suspect simply attaching it to the "Configuration done" line is a much simpler approach, with a system reset being triggered by a FPGA reprogram signal, as per MichaelM's suggestion.



In the config phase the outputs are tri-state, with no way to change that. That's the case for the Flex 10K, which is a 15 year old part. Unsure about newer Altera's.

I think I have enough info now, thanks! The only thing missing is to figure out a reasonable pull-up resistor value.

_________________
8 bit fun and games: https://www.aslak.net/

I see mention of an HSWAPEN input pin for Xilinx parts to help out - see
http://electronics.stackexchange.com/qu ... -or-output
"However, all user I/O pins have optional pull-up resistors that can be enabled during the configuration process. During configuration, a single control line determines whether the pull-up resistors are enabled or disabled. The pin name is HSWAPEN"
- http://forums.xilinx.com/t5/Spartan-Fam ... d-p/259300

If it were me and I had the board space, I would connect all the oe pins of the chips to a 74hc244 buffer with its inputs wired to Vcc and a pullup on the 74hc244's oe pin. That way all chips are tristated at startup and the FPGA can tristate the 74hc244 when its ready to drive the oe pins itself.

I think you will find this thread useful:
http://forums.xilinx.com/t5/Spartan-Fam ... d-p/259300

How is the HSWAPEN pin connected on your Xilinx?

Dave

Aslak3 asked about an Altera FPGA, and we're only feeding him additional data for Xilinx parts. My post was only intended to get him to look for capabilities like those offered by Xilinx FPGAs for controlling the PUs/PDs that his FPGA may provide.

_________________
Michael A.

Apologies for missing that crucial fact!

Maybe this is actually of some use:

Page 8-35 of:
https://www.altera.com/content/dam/alte ... f51005.pdf


Unfortunately, I suspect this might actually be a typo, and it should be referring to the 10KE devices, as I couldn't find a mention of the weak pull-ups in the 10K datasheet, but it's there in the 10KE datasheet (page 97):
https://www.altera.com/en_US/pdfs/liter ... sf10ke.pdf

Could you use a 10KE part?

Dave

I missed a detail in what you said. Do you mean that I only need pullups on output enables, and not on other inputs, like chip selects? I can see that this would stop data busses on the various ICs from driving against each other, but what about the more general problem of floating inputs causing problems with the input transistors drawing excessise current as they turn on and off?

See: http://electronicdesign.com/boards/save ... os-io-pins

Is this something to be concerned about?



I thought about something similar, but I'm confused as to how it would work. I need a truth table something like:



I'm unsure how a buffer would achieve this?



I think you are, sadly for me, correct. Unfortunately what attracted me to the 10K is 1. it is a 5V part and 2. it is available in nice and friendly PLCCC.

Thanks all for the help!

_________________
8 bit fun and games: https://www.aslak.net/

I'm only guessing, I'm afraid, but I am assuming that the short time of configuration is not an issue for the floating-input problem. I suppose it's possible that the crowbar current in the input stages would draw so much current that the chip in question fails to start up correctly... but I can't see it - all circuits see some finite ramp-up of the power rail, and we rely on reset signals to hold off critical activity until the rail is solid and the clock is running.

I think what you want is a truth table like this:


After the FPGA starts it shuts off the buffer since it doesn't need it any more. It's like having pullups that you can disable once the system has started. If it helps to conceptualize, imagine the buffer driving 8 pullups that get z-stated.

I'm still confused, I'm afraid. Would you be able to draw the schematic? How does the (say) SRAM OE line go low? I must be missing some critical, yet simple, thing!

_________________
8 bit fun and games: https://www.aslak.net/

I have been playing around with this. The Flex 10K has two outputs related to "Done". INIT_DONE is 0 when the part is configuring itself, and Z before (ie. running up to when the config process begins) and Z after the unit is in the running state. It is Z prior to receiving any bits from the flash since the bit stream contains a flag that indicates wether INIT_DONE is a user IO pin, or should signal INIT_DONE. You need this flexability on a 84 pin FPGA! There is also CONF_DONE, which is 0 prior to obtaining the config, and 1 after. But critically it raises to 1 before the device has initialised so is not directly useable for /RESET.

From what I can tell there are 4 steps to the startup on the Flex 10K (and probably many other Altera FPGAs):

1. "Warm up"
2. Configuration transfer
3. Initialising
4. Running

On my hack-around, CPLD and FPGA hybrid Frankenstein board I have obtained a nice system /RESET signal by ANDing CONF_DONE and INIT_DONE. INIT_DONE has a pullup. Further, the FPGA, and then the rest of the system, can be reset/reprogrammed by shorting nCONFIG to ground. So I will still have a nice system reset. If I wanted, I could still inject a reset from an FPGA IO pin by feeding a 0 to the /RESET n-input AND gate. I'd probably use a pull-up on that input, just for completeness, though it wouldn't be possible to hold /RESET low past the running state. It's slightly annoying to have this one piece of 74 logic on the board, but I can't see how it can be helped...

_________________
8 bit fun and games: https://www.aslak.net/