Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21584 Discussions

Asserting DEV_CLRn during configuration

Altera_Forum
Honored Contributor II
1,434 Views

Hi, 

 

I would like to know if on Cyclone IV devices DEV_CLRn is held asserted during configuration and beyond the initialization phase if that will cause the registers to remain reset right out of configuration. I want to do this so some pins are tri-stated initially until DEV_CLRn is released to avoid bus contention. I can't use DEV_OE because it tri-states all pins and I don't want that. Thanks.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
455 Views

DEV_CLRn is not going to help you avoid bus contention. DEV_OE could - although you suggest that's no good. 

 

However, use of these, optional, functions is determined by the configuration bitstream. So, DEV_CLRn & DEV_OE will not function so until the FPGA is configuring. They may take effect early in the configuration bitstream (although I do not believe that's the case). However, until they take effect the FPGA will simply tri-state and pull-up all it's pins. So, you always have to manage the period between power up and the point at which the FPGA is configured as part of the board design. 

 

The weak pull-ups present on the FPGA's I/O pins prior to configuration shouldn't cause any problems with bus contention. They have been known to cause problems with latch-up of other devices, easily overcome with the use of a pull-down resistor. 

 

Once you're FPGA is configured you should be able to avoid any bus contention by design. If you only require some pins to tri-state you can code for that. 

 

Regards, 

Alex
0 Kudos
Altera_Forum
Honored Contributor II
455 Views

Thanks for the info. The idea is to have some pins forced to hi-Z while reset is asserted; this would be coded into the design file. The problem I have with DEV_OE is that it removes the weak pull-ups when it's asserted and that would let other output pins float.

0 Kudos
Reply