Configuration time of Cyclone 3

[Altera_Forum]

Hi- 

 I have a design that utilizes a Cyclone 3 (configured in active serial mode using fast POR). My design is a daughter card that connects to an existing 5V system. In debugging I realized that the power on reset of the existing system is something on the order of a few (5ish) mS. Almost immediately the system attempts to drive transactions towards my design. The existing system supplies my design with 5VDC which is fed into LDOs that supply 3.3, 2.5, and 1.2 for the Cyclone 3. I noticed that on power-up my design appears to jam the existing system, but when power has already been applied transactions are properly handled. I then observed with a logic analyzer triggered on the rising edge of +5V (eg power on) that the conf done pin of my Cyclone goes high about 45 mS after power is supplied to my card. The delay between 5V and a stable 3.3/2.5/1.2 is about 1 mS. This seems to mean that the existing system resets MUCH faster than the cyclone and tries to communicate with the cyclone while it's still in configuration mode (eg I/O pins are weakly pulled up). Does it make sense that the configuration takes so long?? Anyone have ideas for a faster configuration time option? Thanks,  D

[Altera_Forum]

I should state that I'm configuring using an EPCS4 device...

[Altera_Forum]

Take care that the power ramps on all 3.3/2.5/1.2 voltage supplies must meet the "Fast POR" power ramp specifications. 

Basicaly use a 4 channel scope (not an LSA) to see if all three supplies appear almost at the same time (I think the max interval between them must be smaller that 6 ms but I'm not sure) See the chapter about power ramps on the configuration manual.

[Altera_Forum]

Thanks for the reply. I'll check that out come monday. That said, the POR time for fast POR is max 9 mS. There is still configuration and initialization time which seem to be far more significant (at least when using fast POR). Is ~45mS logical for 9 mS POR + configuration + initialization?

[Altera_Forum]

I just had a problem - with Config_done.....my system 

reset i/o pin was de-asserted prior to Config_done being released which caused all i/o pins (including inputs) go high (for around 200ms) I needed a signal to be low during that time (an i/o) pin..... Make sure that config_done goes high before system reset signal is goes inactive. .....