quartus io assignment warnings report

• マクニカの製品・サービス
• 半導体事業のメルマガ登録

現在 4292 件がヒットしています。

Intel：Warning (15714): Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details

カテゴリー：Tool ツール：Quartus® Prime デバイス：-

このワーニングが発生した場合は、Fitter レポートの [I/O Assignment Warnings] の Reason (要因) を確認してください。

◎ "Missing drive strength" の場合 　 Fitter レポート > Resource Section フォルダー > Output Pins または Bidir Pins において、ワーニングに該当するピンの Current Strength 欄の 　 値が 希望している電流値であれば、このワーニングは無視できます。

レポート結果が希望値であり、かつ ワーニングを解消したい場合には、Pin Planner において 各出力ピンまたは各双方向ピンの Current Strength オプションを、[〇mA(default)] ではなく、同じ値で "(default)" の表記が無い [〇mA] に変更してください。

◎ "Missing slew rate" の場合　 　 Fitter レポート > Resource Section フォルダー > Output Pins または Bidir Pins において、ワーニングに該当するピンの Slew Rate 欄の 　 値が 希望している設定値であれば、このワーニングは無視できます。

レポート結果が希望値であり、かつ ワーニングを解消したい場合には、Pin Planner において 各出力ピンまたは双方向ピンの Slew Rate オプションを、[”数字"(default)] ではなく、同じ値で "(default)" の表記が無い [”数字"] に変更してください。

◎ "Missing drive strength and slew rate" の場合 　 Fitter レポート > Resource Section フォルダー > Output Pins または Bidir Pins において、ワーニングに該当するピンの  　 Current Strength 欄、および Slew Rate 欄の値が希望している設定値であれば、このワーニングは無視できます。 　 レポート結果が希望値であり、かつ ワーニングを解消したい場合には、上記2点 (Missing drive strength の場合/Missing slew rate の場合) 　 をご覧ください。

◎ "Incomplete set of assignments" の場合 　 Fitter レポート > Resource Section フォルダー > Input Pins / Output Pins / Bidir Pins において、ワーニングに該当するピンの I/O Standard 欄 　 の値が 希望している設定値であれば、このワーニングは無視できます。 　 レポート結果が希望値であり、かつ ワーニングを解消したい場合には、プロジェクトの制約ファイル (*.qsf) に I/O 規格の制約 (全体設定) が正しく 　 記録されていない可能性がありますので、以下のフローに従い I/O 規格の情報を更新してください。

　　(1)　Quartus ® Prime 上の Assignments メニュー > Device > Device and Pin Options をクリックし 　 　　 　Category から "Voltage" を選択します。

　　(2)　画面右下付近にある [Reset] ボタンをクリックします。 　　　　 ※ 設定したい規格値が Reset ボタン押下後と異なる場合は、プルダウンから選択し直してください。

　　(3)　すべてのダイアログボックスを [OK] ボタンで閉じます。

特定製品の仕様からパーツの選定まで、当社のFAEが皆様のテクニカルなお悩みに無料で回答します。ぜひ、お気軽にご相談ください。

お客様のブラウザーの設定は、JavaScriptが無効になっています。 Javascriptを有効にして再読み込みをお願いいたします。

JavaScript is disabled in your browser settings. Please enable Javascript and reload.

Quartus: Packing registers into I/O cells

Often I prefer to handle I/O timing by ensuring that all registers are put in into the I/O cells. Where timing matters, that is.

It seems like I/O register packing isn’t the default with Quartus. Anyhow, here’s the lazy man’s recipe for this scenario.

In a previous version of this post, I suggested to disable timing checking on all I/Os. This silences the unconstrained path warning during implementation, and in particular, it prevents the "TimeQuest Timing Analyzer" section in Quartus’ reports pane from turning red:

This isn’t such a good idea, it turns out, in particular regarding input ports. This is elaborated further below.

Nevertheless, one needs to convince the fitter to put the registers in the I/O block. In the QSF, add

It’s somewhat aggressive to make these assignments on absolutely every register, but it does the job. The fitter issues warnings for the I/O elements that it fails to enforce these constraints on, which is actually a good thing.

To see how well it went, look in the "Resource Section" of the fitter report (possibly find it in Quartus’ reports pane) and look for "Input Registers" etc., whatever applies.

The difference is evident in timing reports of paths that involve I/O cells. For example, compare this path which involves an I/O register:

Note the DDIOOUTCELL element, and the zero increment in the routing between the register and the IOOBUF.

For comparison, here’s a path for which an I/O register wasn’t applied (because it was prevented by logic):

Here we see how a general-purpose flip-flop generates the signal, leading to a routing delay that amounts to 1.657 ns. The main problem is that this routing delay will be different each implementation, so if there’s a signal integrity issue with the board, the FPGA might be blamed for it, since different FPGA design versions will seem to fix the problem or make it reappear.

Timing constraints

Both the input ports and the output ports should have tight timing constraints, so they can’t be met other than taking full advantage of I/O registers. Not only will this generate a timing failure if something goes wrong with the desired register packing, but it’s also necessary to achieve the minimal input-to-register timing, as explained next.

The discussion below applies only when the clock that drives the registers is directly related to an external clock (i.e. with a PLL that multiplies the clock with e.g. an integer number). If the clock that drives the registers is practically unrelated to the external clock, things get significantly more complicated, as discussed in this post .

To demonstrate this issue, consider the following Verilog code:

Also consider the following constraint in the SDC file:

As explained on this post , set_input_delay is the maximal delay of the source of the signal, from clock to a valid logic state. Since the clock’s time period is set to 10 ns, setting the delay constraint to 8.5 ns allows for 1.5 ns until the following clock arrives (at 10 ns). In other words, the setup time on the FPGA's pin is has a constraint that forces it not to exceed 1.5 ns.

Note that set_max_delay can be used as well for this purpose (in some cases it’s the only way) as discussed in this post .

A compilation of this (along with the FAST_INPUT_REGISTER ON QSF assignment shown above) yields the following segment in the timing report:

Unlike the case with the output register, there is no flip-flop with the type "DDIOINCELL" in the list, but there's something that looks like a regular flip-flop instead. However, note that the wiring to this flip-flop has zero delay (marked in red), which is a clear indication that the flip-flop and input buffer are fused together.

The datasheet report for this input says:

As required, the setup time that is required by the FPGA is lower than the 1.5 ns limit set by the constraint.

Now let’s loosen the input setup delay by 2 ns, and leave everything else as it was, and rerun the compilation:

The segment in the timing report now says:

Huh? The interconnect suddenly rose to 1.062 ns?! Note that the placement of the register didn’t change, so there’s no doubt that in_d is an I/O register. So where did this delay come from?

To answer this, a closer look on the design is required. After a full compilation and selecting Tools > Netlist Viewers > Technology Map Viewer (Post-Fitting), the following diagram appears (partly shown below, click to enlarge):

Right-clicking in_d (the register) and selecting Locate Note > Locate in Resource Property Editor reveals the following (click to enlarge):

To the right of this drawing (not shown above), the property "Input Pin to Input Register Delay" is set to 2. This is the reason for the delay. Before the constraint was loosened up, it was set to 0. The immediate lesson is:

If the setup constraint isn’t set to the technology’s best possible value, Quartus may add a delay on its expense.

But why, Quartus, why?

So one may wonder why Quartus inserts this delay between the input pad and the register. Wasn’t the whole point to sample as soon as possible? To answer this, let’s look at the updated datasheet report:

Recall that 2 ns were reduced from the delay constraint. Hence the maximal allowed setup time went up from 1.5 ns to 3.5 ns. It’s easy to see that this requirement is met, with a slack of almost 1 ns.

So Quartus said something like "I can meet the setup requirement easily, with a surplus of 2 ns. Let’s give 1 ns extra to the setup time, and 1 ns to the hold time requirement (which is 0 ns)". And indeed, by adding 1.062 ns with this delay, the hold time improved from -0.683 ns to -1.570 ns (and please don’t pick on me on why the difference isn’t exact).

Bottom line: Quartus widened the margin for both setup and hold, making the input more robust to jitter. While this is a rather sensible thing to do, this is often not desired nor expected to happen.

Conclusion: If you want to get the absolutely minimal delay from the input to the register, run a compilation with a delay constraint that fails, and then loosen the constraint just enough to resolve this failure. This ensures that Quartus won’t try to "improve" the timing by adding this input delay for the sake of a better hold time.

Using DDR primitives

Intel’s FPGAs have logic on or near the I/O cells that is dedicated to allow for producing output as well as sample the input at a double clock rate. This topic is detailed in the relevant user guide, ug_altddio.pdf . Instantiating a DDR primitive (or using the ALTDDIO_BIDIR megafunction) is an appealing way to force the tools into putting the registers into the I/O cells. However, it’s not necessarily a good idea.

For example, an instantiation like this:

This indeed results in logic that implements a bidirectional DDR interface, but with a partial success as far as timing is concerned, at least on Cyclone IV. The clock-to-output timing is exactly the same as a plain output register that is packed into the I/O cell, but the delay on the input path is actually worse with the instantiation above. The results may be different with other Intel FPGA families.

Note that in order to mimic plain SDR registers with a DDR primitive, its datain_h port and datain_l port must be connected to the same wire, so the clock’s falling edge doesn’t change anything. Likewise, the dataout_l port’s value should be ignored, as it's sampled on the falling edge. Also note that the output enable port (oe) is an SDR input — as far as I can understand, it’s not possible to turn high-Z on and off with DDR rate with Intel FPGAs. At least not with the supplied logic primitives.

Now to why it worked nicely on the output registers, and not with the input: The hint is in the timing reports above: Even for a plain I/O cell register, a DDIOOUTCELL_Xn_Ym_Nk component is used as the register. In other words, the DDR output register is used even for single-rate outputs, but only with one clock edge. As for the input path, the timing reports above show that a logic fabric register (FF_Xn_Ym_Nk) is used. And here’s the crux: The DDR input logic is implemented in the logic fabric as well. And to make it worse, combinatorial blocks are squeezed between the I/O cell and the flip-flop in the case with DDR. Frankly, I don’t understand why, because each such combinatorial block is just a pass-through between a single input to a single output.

These observations are backed by timing reports as well as the drawings displayed by Quartus’ Post-Fit Technology Map Viewer. In particular, those useless combinatorial blocks are evident in these information sources.

This entire issue most likely varies from one FPGA family to another. As for Cyclone IV, it only makes sense to use DDR primitives for outputs.

Even more important, the fact that a DDR primitive output is used when an output register is required, allows producing an output clock that is aligned with the the other outputs. To accomplish this, feed a DDR output primitive with constant '1' and '0' on the datain_h port and datain_l port, respectively. As for the other outputs, require the use of output register packing. The toggling of the other outputs is hence aligned to the rising edge of the clock that comes from the DDR output.

Well, almost. The timing analysis of a output clock is different, because the clock toggles a mux that selects which of the two output registers feeds the output (scroll horizontally for the details):

Note that this isn’t a register-to-pin analysis, but clock-to-pin. A set_output_delay constraint will include this path nevertheless. However, a set_max_delay constraint from registers to ports, if used, won’t include this path, so it has to be handled separately. In other words, if set_max_delay is used, it has to be of the form:

Now, compare this with another pin with the same voltage standard etc., only driven by a register:

The total clock-to-output time differs by no more than 35 ps, even though the latter path is completely different on the face of it. This isn’t a coincidence. The FPGA is clearly designed to produce this similarity. Specifically, the timing analysis above is slow 1200 mV at a temperature of 100°C, but this small difference is consistent in the other analyzed conditions as well.

Allowable Quartus Warnings

→ To E15 Lab page →

As you use Quartus you will find that you get many warnings during a compilation process.  Some of these are important, some deal with minor issues.  As you work with Quartus, the following warnings are acceptable.  Other warnings should be fixed.

Allowable warnings.

Analysis and synthesis.

• Warning: Output pins are stuck at VCC or GND (Occurs because some values are constant (for example if you want to keep an LED always on or always off).)
• Warning: Output port "xxx[2..1]" at yyy.v(1) has no driver (Occurs because some pins of an output port are not used (for example you declare an register with 4 bits for LED's, but you only use two of the LED's); this can generally be avoided by using consecutive LED's.)
• Warning: Ignored assignments for entity "xxx" -- entity does not exist in design (Occurs because there is no module with the same name as the project name (project name is "xxx").)
• Warning: Classic Timing Analyzer will not be available in a future release of the Quartus II software. Use the TimeQuest Timing Analyzer to run timing analysis on your design. Convert all the project settings and the timing constraints to TimeQuest Timing Analyzer equivalents. (We'll switch to TimeQuest at a later date.)
• Warning: Ignored locations or region assignments to the following nodes (These errors occur because of all the DE2 pins that are in the "E15DE2_IO.qsf" assignments file that we don't use; i.e., switches, LED's...)
• Warning: Found (xx) output pins without output pin load capacitance assignment (To do a strict timing analysis it is necessary to know the capacitance at each pin.)
• Warning: Found invalid Fitter assignments. See the Ignored Assignments panel in the Fitter Compilation Report for more information. (These errors occur because of all the DE2 pins that are in the "E15DE2_IO.qsf" assignments file that we don't use; i.e., switches, LED's ...)
• Warning: The Reserve All Unused Pins setting has not been specified, and will default to 'As output driving ground'. (We don't specify what Quartus should do with unused pins (so it grounds them).)

Timing Analyzer:

• Warning: Found pins functioning as undefined clocks and/or memory enables (To do a strict timing analysis you should set clock properties (in "Assignments") such as rise time, fall time...)

→ To E15 Course page →

Success! Subscription added.

Success! Subscription removed.

Sorry, you must verify to complete this action. Please click the verification link in your email. You may re-send via your profile .

• Intel Community
• Product Support Forums
• Intel® Quartus® Prime Software