S-parameter model of the power delivery network in Quartus functional simulation

[Altera_Forum]

Hello everyone, 

Does anyone know if I can insert an s-parameter model of the FPGA power delivery network in Quartus or ModelSim functional/timing simulations? Has anyone done this already? Thank you, Cosmin

[Altera_Forum]

Not possible. ModelSim/Quartus are digital logic simulators only. What you require is analog circuit simulation capability; e.g. something like LinearTech LTspiceIV or Cadence PSpice.

[Altera_Forum]

--- Quote Start ---  Not possible. ModelSim/Quartus are digital logic simulators only. What you require is analog circuit simulation capability; e.g. something like LinearTech LTspiceIV or Cadence PSpice.  --- Quote End ---     Thank you ak6dn,  I don't have experience in FPGA designs but from my other design experience I know that timing margins in logic design depend on propagation delay and clock jitter, which both are very dependent on the self-generated supply noise on the FPGA power rails. Self-generated supply noise depends on the values and locations of decoupling capacitors on the PCB, which is a user dependent decision, so timing models in Quartus II cannot know this information. I assume Quartus II models estimate some (expected) supply noise but the simulator does not know if the estimation is accurate or not because ultimately this depends on the FPGA user.  So I am trying to put an s-parameter model of the FPGA PDN (that includes the decoupling capacitors on the PCB) in a circuit simulator to estimate the clock jitter and gate delay variations on FPGA. I have two follow up questions:  1. If I am able to use a Spice simulator (LT Spice for example) and find out the clock jitter on the FPGA due to the dynamic current variation of my specific design, is it a way to insert this jitter value in Quartus II timing analysis or ModelSim functional simulation to see how it affects my timing margin?  2. Does anyone know of any simulation tool, simulation method, or simulation example that uses an s-parameter model of the power delivery network to simulate the timing on an FPGA?   Best Wishes, Cosmin

[Altera_Forum]

You don't say what device family in particular you are looking at (CycloneIV, V, Max, Stratix, ...) but have you read the detailed electrical data sheets for the family/device you are looking at? They have pretty detailed specs on PLL characteristics (jitter, etc). 

 The 'set_clock_uncertainty' timequest command allows adding additional jitter/uncertainty to a clock rail if necessary. Are you aware of this? (in answer to question one). This would apply to Quartus place/route timing calculations, not modelsim simulation before place/route. How much extra jitter to add however is going to be a guess, unless you can derive the power supply noise to clock jitter transfer function (not easy without the detailed circuit level design of the FPGA).  In answer to question two, I have never seen such a tool that uses s-params for FPGA timing. Sounds like a good PhD project.  Backing up to square one, why are you so concerned about clock jitter? Is your application some how very critical in this respect?

[Altera_Forum]

Thank you ak6dn for the detailed explanation. I am using a Cyclone IV on an evaluation board, and my dynamic power consumption was so high that a few times it reset the FPGA, so I had to reprogram it. Now it does not reset the FPGA. I am now trying to quantify the clock jitter and the propagation delay variation with self-generated supply noise. I come from an IC design background so I tend to think from the circuit perspective. Thank you for the info on "set_clock_uncertainty" feature. Is it a similar feature for signal path delay? 

Thank you and Best Wishes, Cosmin

[Altera_Forum]

I don't believe that "self generated supply noise" is a suitable term to analyze signal integrity problems in FPGA interconnect. The effect is usually described as "ground bounce" generated by switching outputs. It can be modeled in a first order by ground pin inductance. 

 As already explained, FPGA timing analysis doesn't model signal integrity problems specifically, but you can account for it by an increased jitter margin. Tools like Hyperlynx are used for an in-depth analysis of PCB interconnect.  From a practician's viewpoint, instead of analyzing ground bounce details, you'll usually try to avoid its effect by using differential signaling for critical signals.

[Altera_Forum]

Thank you FvM for the helpful explanations. In troubleshooting my FPGA resetting issue I made all IOs quiet (almost all of them) and I still had the FPGA reset due to core supply voltage noise so not I/O supplies noise. I was able to eliminate the resetting issue by changing the decoupling capacitors on the core supply VCCINT. Now it does not reset but I put an oscilloscope on the VCCINT on one of the decoupling capacitors on the bottom side of the PCB under the FPGA and it shows noise as high as about 180mV_pk_pk. My concern is that this noise is seen by the core logic blocks inside the FPGA so I am not sure if the timing models used in Quartus II account for such a high noise. Does anyone know if this magnitude of noise is expected? Have anyone measured the noise on VCCINT and got similar values? 

Thank you, Cosmin

[Altera_Forum]

--- Quote Start ---  Thank you FvM for the helpful explanations. In troubleshooting my FPGA resetting issue I made all IOs quiet (almost all of them) and I still had the FPGA reset due to core supply voltage noise so not I/O supplies noise. I was able to eliminate the resetting issue by changing the decoupling capacitors on the core supply VCCINT. Now it does not reset but I put an oscilloscope on the VCCINT on one of the decoupling capacitors on the bottom side of the PCB under the FPGA and it shows noise as high as about 180mV_pk_pk. My concern is that this noise is seen by the core logic blocks inside the FPGA so I am not sure if the timing models used in Quartus II account for such a high noise. Does anyone know if this magnitude of noise is expected? Have anyone measured the noise on VCCINT and got similar values? Thank you, Cosmin  --- Quote End ---    180mV (if accurate) is on the high side for noise on the power rail. However, unless you are very careful this can easily be a false measurement ... if you use a high impedance scope probe with a flying ground lead, you will get induced noise that is not really in the circuit. I have found the only way to reliably measure the noise on a power rail is to use a length of 50ohm coax soldered directly across a decoupling cap (or remove the cap and solder the coax to the pads with no extra lead length). Then run the coax into the 50ohm input of a high performance scope, and you will see what is really happening.

[Altera_Forum]

Thank you ak6dn. I will try to measure the noise with a 50 Ohms input impedance oscilloscope.

[Altera_Forum]

An alternative is to use a differential probe directly over a decoupling cap. 

IIRC Altera uses 5% power noise for its calculations on its PDN tool so yes I'd say 180mV is quite high.

[Altera_Forum]

Thank you Daixiwen. Do you or anyone else know if 5% power noise is also used when generating the timing models for logic blocks or only as max acceptable value at the package pin on the PCB? I am thinking the logic cells may see different noise than what we measure.

[Altera_Forum]

FPGA reset is a bit more of a basic issue than increased IO jitter. Most likely the core supply falls below the POR trip point. I believe it's more likely caused by a not correctly operating voltage regulator than wrongly placed or insufficient bypass capacitors, but the difference should be obvious when looking at the "noise" waveform.

[Altera_Forum]

Thank you FvM. Yes, it seems to be related to the core supply because after choosing different capacitors the FPGA did not reset anymore. However, what I don't know is "how well" I fixed it and if it is only marginal and will reset again for a future re-compiled version of my design. This is why I am looking for a simulation tool that would take an s-parameter model and somehow provide me the information of "how well" I fixed the core supply.