FPGA configuration time and PCIe secification

EP4CGX15 and EP4CGX22 ( which I need ) do not support FPP.

EPCS4 cost can fall below 1 USD if M25P40 is used instead. It has the same mfg ID.

The only problem is ( I overlooked it ) is that typical DCLK for AS mode is 33 MHz instead of 40 MHz as I expected.

Maybe its because internal oscillator is used to create the DCLK?

Here is a quote from Handbook:

the dclk generated by the cyclone iv device controls the entire configuration cycle

and provides timing for the serial interface. cyclone iv devices use an internal

oscillator or an external clock source to generate the dclk. for cyclone iv e devices,

you can use a 40-mhz internal oscillator to generate the dclk and for cyclone iv gx

devices you can use a slow clock (20 mhz maximum) or a fast clock

(40 mhz maximum) from the internal oscillator or an external clock from clkusr to

generate the dclk. there are some variations in the internal oscillator frequency

because of the process, voltage, and temperature (pvt) conditions in cyclone iv

devices. the internal oscillator is designed to ensure that its maximum frequency is

guaranteed to meet epcs device specifications. cyclone iv devices offer the option to

select clkusr as the external clock source for dclk. you can change the clock source

option in the quartus ii software in the configuration tab of the device and pin

options dialog box.

That apparently means , that in CLKUSR mode with the stable external clock source for DCLK, the DCLK can be exactly 40MHz.

Did You ever test CLKUSR mode?

If Yes, then what do You think about setting DCLK=40MHz in CLKUSR mode?

--- Quote Start ---

EP4CGX15 and EP4CGX22 ( which I need ) do not support FPP.

--- Quote End ---

They do however support PS mode, so you can use that mode to ensure the timing is met.

--- Quote Start ---

EPCS4 cost can fall below 1 USD if M25P40 is used instead. It has the same mfg ID.

--- Quote End ---

Yeah, the QSPI flash can also be used, it responds to the same command codes.

--- Quote Start ---

The only problem is ( I overlooked it ) is that typical DCLK for AS mode is 33 MHz instead of 40 MHz as I expected.

Maybe its because internal oscillator is used to create the DCLK?

--- Quote End ---

No idea, but of all the devices I have probed with a scope, the AS mode configuration DCLK signal is always close to 33MHz.

--- Quote Start ---

Did You ever test CLKUSR mode?

If Yes, then what do You think about setting DCLK=40MHz in CLKUSR mode?

--- Quote End ---

I have not used CLKUSR mode. I typically have a MAX II device on the board anyway, so implementing PS or FPP mode is not much effort.

p169, Table 8-2,

- EP4CGX15 => 3,805,568/40MHz = 95ms

- EP4CGX22 => 7,600,040/40MHz = 190ms X FAIL

The EP4CGX15 is close, but by the time you add in the POR delay, and any power supply delays, eg. due to hot-swap controller or power manager IC, then you might be out of time.

Compression might help you get under the limit. If your PCIe end-point logic will never change, or is completely under your control, then you could use this scheme. If however this is supposed to be a product that an end-user can configure the PCIe FPGA with arbitrary logic, then you should add a disclaimer regarding the ability of the design to meet the PCIe power-on requirement.

Cheers,

Dave

--- Quote Start ---

On the HP system I have and the Altera Stratix -V development card with SignalTrap configured for a Power-up Trigger, I don't seem to capture the slot PERST_N signal

rising edge. However the card still comes up active and is enumerated. I am able to trigger on the PERST_N signal rising edge when I perform a restart operation and the FPGA remains powered up and running.

--- Quote End ---

I'm not sure how reliable SignalTap II is when using the power-on trigger. Personally, I would probe the CONF_DONE signal and the PCIe RST# signal and look at their relative timing.

--- Quote Start ---

There is a possibility that if the power on PERST_N is long enough, say 100 ms, then if the FPGA is configuring during the 100mS , there is an additional 100 ms

from the end of the fundamental reset , PERST_N, until the FPGA needs to be ready to receive configuration requests. ( per Add-in Card System Architecture Checklist )

--- Quote End ---

Yeah, there's all sorts of ambiguous statements throughout the PCIe documentation. There's often the statement that the ability for the system to meet the power-on reset timing requirement is the responsibility of the system integrator. In my case, I define the host CPUs and the PCIe boards, so I can adjust the timing to meet my custom requirements, however, for commercial products, its important to be conservative. Since FPP can easily meet the timing requirement, that is the best way to go. In your case, you're subject to whatever the Stratix V kit implementation is.

--- Quote Start ---

Not sure how to include an image here ...

--- Quote End ---

I think the advanced viewer has a button you can use to add an image, or you can just upload a file.

--- Quote Start ---

I could compute the configuration time for the Stratix-V and figure out the endpoint card power rail stable time that will then start the configuration load via the MAX chip.

--- Quote End ---

Its a good exercise in understanding how the board was designed. Go and look at the MSEL settings, and the schematic.

Cheers,

Dave

--- Quote Start ---

Compression might help you get under the limit. If your PCIe end-point logic will never change, or is completely under your control, then you could use this scheme.

--- Quote End ---

Yes, this is my case.

--- Quote Start ---

...but by the time you add in the POR delay, and any power supply delays, eg. due to hot-swap controller or power manager IC, then you might be out of time.

--- Quote End ---

Now getting back to the very beginning to what I was asking for:

What timings ( POR-related, etc. ) I have to add to calculate that extra time?

Meanwhile, I'll try to get more info about CLKUSR mode to clarify if its possible to set DCLK=40MHz.

--- Quote Start ---

Now getting back to the very beginning to what I was asking for:

What timings ( POR-related, etc. ) I have to add to calculate that extra time?

--- Quote End ---

The timing parameters are in the response above; you have the power-on time of tRAMP < 3ms, after which point the POR time completes, the device deasserts nSTATUS and starts the configuration process. Look at the AS mode timing diagram for the "extra" delays - but they're microseconds, so can be ignored if you set your 100ms limit a little lower, eg., 95ms.

If you have an FPGA development kit, eg., a DE0-nano, then go and measure the signals on that board too. That will give you a good idea of how well the handbook numbers reflect reality.

Cheers,

Dave

--- Quote Start ---

Meanwhile, I'll try to get more info about CLKUSR mode to clarify if its possible to set DCLK=40MHz.

--- Quote End ---

I doubt there is a setting to specify the clock frequency. The handbook gives the range of valid frequencies. Its up to you to provide CLKUSR on the board.

You will have to make sure you set the design up so that it uses an external DCLK source for configuration. I've not had to do that, so cannot provide advice (though could look at the handbook if you have questions you cannot figure out yourself).

Cheers,

Dave

--- Quote Start ---

The timing parameters are in the response above; you have the power-on time of tRAMP < 3ms, after which point the POR time completes, the device deasserts nSTATUS and starts the configuration process. Look at the AS mode timing diagram for the "extra" delays - but they're microseconds, so can be ignored if you set your 100ms limit a little lower, eg., 95ms.

Cheers,

Dave

--- Quote End ---

I found Your paper ( cpci_power_on_timing.pdf ), that calculates total configuration time for EP4CGX15.

Here is a quote frome it:

the configuration time for a cyclone iv gx ep4cgx15 configured via fast passive

parallel (fpp) mode using a 66mhz clock is; 3ms power-supply ramp + 9ms power-onreset

delay + 3,805,568-bits/66mhz = 70ms.

Of course FPP is not applicable to EP4CGX15, but the calculation is also misleading...

Please explain why did You interpret Table 1–4. Recommended Operating Conditions for Cyclone IV GX Devices (Part 2 of 2) in such a way: "3ms power-supply ramp + 9ms power-onreset delay"?

https://www.alteraforum.com/forum/attachment.php?attachmentid=7868

--- Quote Start ---

I found Your paper ( cpci_power_on_timing.pdf ), that calculates total configuration time for EP4CGX15.

--- Quote End ---

Here's the more complete version of it;

http://www.ovro.caltech.edu/~dwh/wbsddc/ts4_power.pdf

--- Quote Start ---

Here is a quote from it:

the configuration time for a cyclone iv gx ep4cgx15 configured via fast passive

parallel (fpp) mode using a 66mhz clock is; 3ms power-supply ramp + 9ms power-onreset

delay + 3,805,568-bits/66mhz = 70ms.

Of course FPP is not applicable to EP4CGX15, but the calculation is also misleading...

Please explain why did You interpret Table 1–4. Recommended Operating Conditions for Cyclone IV GX Devices (Part 2 of 2) in such a way: "3ms power-supply ramp + 9ms power-onreset delay"?

--- Quote End ---

Hmm, let me try to remember ... :)

The first error I notice is that I said FPP, but the calculation is for PS mode (since there is no divide-by-8).

The 3ms power-on-ramp comes from the hardware design, eg., see p18 of the PDF I just linked to, so that is design-specific, but it is what you must implement when you select MSEL for Fast POR, i.e., tRAMP < 3ms.

The 9ms POR delay is what the "reset supervisor" delay inside the FPGA implements, and worst-case it is 9ms. Sorry, I missed including that delay in the posting earlier in the day.

So your power-on time calculation is tRAMP + tPOR + tCFG, where tCFG is the bit-stream configuration time.

In reality, if you are conservative and target tCFG < 50ms, all the other small time values do not matter. If for example you use FPP mode, then the configuration time is a small fraction of the 100ms requirement, so its no problem ... until of course you use a large Stratix V device ... but then you can use CvP.

Cheers,

Dave

--- Quote Start ---

The 9ms POR delay is what the "reset supervisor" delay inside the FPGA implements, and worst-case it is 9ms. Sorry, I missed including that delay in the posting earlier in the day.

So your power-on time calculation is tRAMP + tPOR + tCFG, where tCFG is the bit-stream configuration time.

--- Quote End ---

What is "reset supervisor" delay inside the FPGA?

I don't see any straight-forward statment in Handbook, that tells to add tRAMP + tPOR, that is 3ms + 9ms.

--- Quote Start ---

The 3ms power-on-ramp comes from the hardware design, eg., see p18 of the PDF I just linked to, so that is design-specific, but it is what you must implement when you select msel for fast por, i.e., tramp < 3ms.

--- Quote End ---

Handbook says ( p.11-4 ): "The MSEL pin settings determine the POR time (tPOR) of the device.", but not tRAMP.