Verständnisfrage zu Timing Constrains

[mh (Gast)]

Hallo,
ich hab mal eine Frage zu Timing-Constrains.
Ich hab hierzu testweise einen 16-Bit Ripple-Carry-Adder in VHDL mit der 
Xilinx ISE 14.7 erstellt:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity adder is
  port(
      clk : in std_logic;
      a : in std_logic_vector(15 downto 0);
      b : in std_logic_vector(15 downto 0);
      c : out std_logic_vector(15 downto 0);
      erg : out std_logic_vector(15 downto 0)
  );
end adder;

architecture Behavioral of adder is

signal a_reg : signed(15 downto 0);
signal b_reg : signed(15 downto 0);
signal temp : signed(15 downto 0);

begin

process(clk)
begin
  if clk'event and clk='1' then
    a_reg <= signed(a);
    b_reg <= signed(b);
    c <= std_logic_vector(temp);
  end if;
end process;

temp <= signed(a_reg) + signed(b_reg);
erg <= std_logic_vector(temp);

end Behavioral;

Das Eingangssignal geht zuerst auf ein D-FF. Das Ausgangssignal wird 
einmal über ein D-FF rausgeführt und einmal asynchron.
Hab hierzu nun ein ucf erstellt:

NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 10 ns HIGH 50%;

Alle Prozesse (Synthese bis Place & Route) laufen durch ohne Warnung 
oder Fehler.
Wenn ich jetzt allerdings eine Timing Simulation mit dem Worst-Case 
durchführ, also

a <= "0000000000000001";
b <= "0111111111111111";

addieren lasse, so sieht man im Simulator eine Latenzzeit von ca 12 ns 
(bis der asynchrone Ausgang stabil ist).

Warum erhalte ich nun keine Warnung, da ja offensichtlich das Timing mit 
Taktperioden < 12 ns nicht eingehalten werden können??

Taucht die Zeit von 12 ns irgendwo im Design Summary auf? Hab 
dahingehend nix gefunden. Wo finde ich eine Angabe des kritischen Pfads?

Schonmal Danke für Antworten!

[endox (Gast)]

Du musst noch die Ein- und Ausgänge spezifizieren.
Also zB OFFSET_OUT.
http://www.xilinx.com/support/documentation/white_papers/wp237.pdf

Wenn Du das nicht tust, dann erhälst Du auch keinen Error, sondern 
schlichtweg keine Meldung.

[mh (Gast)]

Vielen Dank für die Antwort.
Jetzt wird ein Fehler generiert.

Wo finde ich nun genau den kritischen Pfad in der Design Summary?

[Klaus (Gast)]

Kleiner sprachlicher Hinweis:

"constrain" ist das Verb.
"constraint" das Substantiv.

[Sigi (Gast)]

mh schrieb:
> Alle Prozesse (Synthese bis Place & Route) laufen durch ohne Warnung
> oder Fehler.
Schau mal im Compilation Report, unter "Unconstraint Paths" nach,
da werden alle Signale ohne I/O-Constraints angezeigt (bzw. deren
Anzahl).

> Wenn ich jetzt allerdings eine Timing Simulation mit dem Worst-Case
> durchführ, alsoa <= "0000000000000001";
> b <= "0111111111111111";
> addieren lasse, so sieht man im Simulator eine Latenzzeit von ca 12 ns
> (bis der asynchrone Ausgang stabil ist).
12ns Latenz von Input nach unreg. Output ist kein Widerspruch zu
10ns-Clock, Du musst ja noch die Laufzeit von Input nach Register
(bei Dir a_reg,b_reg) und die Laufzeit von Adder nach Output
berücksichtigen. Da sind 2ns mehr noch sehr gut. Alleine das
Clock-Signal kann von Input-Pin hin zu den internen Register zig
ns in Anspruch nehmen.

mh schrieb:
> Wo finde ich nun genau den kritischen Pfad in der Design Summary?
Lies Dir mal "TimeQuest-Terms and Concepts" und
"TimeQuest-TimingAnalyzer" durch (entweder im QuartusII-Manual
oder einzeln runterladbar). Dort werden die Konzepte als auch
der Umgang mit TimeQuest hinreichend beschrieben.

[mh (Gast)]

Klaus schrieb:
> Kleiner sprachlicher Hinweis:
>
> "constrain" ist das Verb.
> "constraint" das Substantiv.

Alles klar, merk ich mir.
Wobei ich in Franken eher consdrainds bevorzug ;)

Sigi schrieb:
> mh schrieb:
>> Alle Prozesse (Synthese bis Place & Route) laufen durch ohne Warnung
>> oder Fehler.
> Schau mal im Compilation Report, unter "Unconstraint Paths" nach,
> da werden alle Signale ohne I/O-Constraints angezeigt (bzw. deren
> Anzahl).
>
>> Wenn ich jetzt allerdings eine Timing Simulation mit dem Worst-Case
>> durchführ, alsoa <= "0000000000000001";
>> b <= "0111111111111111";
>> addieren lasse, so sieht man im Simulator eine Latenzzeit von ca 12 ns
>> (bis der asynchrone Ausgang stabil ist).
> 12ns Latenz von Input nach unreg. Output ist kein Widerspruch zu
> 10ns-Clock, Du musst ja noch die Laufzeit von Input nach Register
> (bei Dir a_reg,b_reg) und die Laufzeit von Adder nach Output
> berücksichtigen. Da sind 2ns mehr noch sehr gut. Alleine das
> Clock-Signal kann von Input-Pin hin zu den internen Register zig
> ns in Anspruch nehmen.
>
> mh schrieb:
>> Wo finde ich nun genau den kritischen Pfad in der Design Summary?
> Lies Dir mal "TimeQuest-Terms and Concepts" und
> "TimeQuest-TimingAnalyzer" durch (entweder im QuartusII-Manual
> oder einzeln runterladbar). Dort werden die Konzepte als auch
> der Umgang mit TimeQuest hinreichend beschrieben.

Ok.
Also nochmal zum Verständnis...
Wenn ich einen PERIOD-constraint definiert hab und das Tool sagt mir, 
dass das geht, kann ich dann wirklich davon ausgehen, dass das alles mit 
der genannten min. Periodendauer läuft?
Die zusätzlichen Verzögerungen kommen also von den Ein- bzw. 
Ausgangsleitungen.

Nochmal eine andere Frage. Wie geht man nun genau bei der Verifizierung 
eines FPGA-Designs vor?
Man simuliert nur die reine Funktion mit einer Behavioral-Simulation und 
checkt nur mittels constraints, ob das mit der gewünschten Clock so 
funktioniert?

[Sigi (Gast)]

mh schrieb:
> Ok.
> Also nochmal zum Verständnis...
> Wenn ich einen PERIOD-constraint definiert hab und das Tool sagt mir,
> dass das geht, kann ich dann wirklich davon ausgehen, dass das alles mit
> der genannten min. Periodendauer läuft?
Ja, und TimeQuest gibt Dir neben der Info nocht an, welche
Pfade wie "kritisch" sind, und das auch noch in Histogramm-Form.

Habe noch eine Doku vergessen: Im "TimeQuest Cookbook" werden
nahezu alle Techniken beschrieben, mit denen man alle gängigen
Designprobleme (I/O, Multipath,Ignore etc.) bzg. Timing spezifizieren
kann. Der Clocking-Teil mag am Anfang zwar umständlich erscheinen,
hat man aber mal die Formeln verstanden, möchte man es danach nicht
mehr missen. Ihmo besser als bei Xilinx und Lattice.

> Die zusätzlichen Verzögerungen kommen also von den Ein- bzw.
> Ausgangsleitungen.
Ja, wird z.B. in den Doks und graphisch im TimeQuest beschrieben.

> Nochmal eine andere Frage. Wie geht man nun genau bei der Verifizierung
> eines FPGA-Designs vor?
> Man simuliert nur die reine Funktion mit einer Behavioral-Simulation und
> checkt nur mittels constraints, ob das mit der gewünschten Clock so
> funktioniert?
Ja, kann man, und deckt auch die grössten Probleme ab. Es kann
aber auch Fälle geben, in denen es sehr zeitkritisch wird.
Damit braucht man sich am Anfang nicht beschäftigen. Du musst
bedenken, dass die ganzen Analysetools nur statische Analysen
machen, es kann aber sein, dass ein Timing-Problem in Deinem
Model nicht auftreten. Das kann evtl. sehr schwer in Constraints
beschreibbar sein aber leichter im Simulator sichtbar gemacht
werden (z.B. mit speziellen Teststimuli etc.).

[mh (Gast)]

Danke für die ausführliche Antwort!
Ist TimeQuest nur etwas Altera-spezifisches?
Gibt es sowas auch für die Xilinx ISE?

[Sigi (Gast)]

Timing-Analyse-Tools haben alle Hersteller in ihren
Tools integriert, aber diese geben die Analyse meisst
in Textform aus. Damit wird uU das Zusammensuchen
von spezifischen Pfaden und der Vergleich mehrerer
Pfade gleichzeitig wesentlich komplizierter (siehe
Histogramm-Anzeige ganzer Pfadbündel!).

Auch die Spezifikation von Clocking-Constraints ist
teils sehr unterschiedlich (wenn man auf die Details)
schaut.

[Christian R. (supachris)]

mh schrieb:
> Also nochmal zum Verständnis...
> Wenn ich einen PERIOD-constraint definiert hab und das Tool sagt mir,
> dass das geht, kann ich dann wirklich davon ausgehen, dass das alles mit
> der genannten min. Periodendauer läuft?

Naja zumindest was intern mit diesem Takt synchron passiert. Alles 
asynchrone muss separat beschrieben werden.
Xilinx bietet natürlich auch auch statische Timing Analyse.

[Burkhard K. (buks)]

mh schrieb:

> Nochmal eine andere Frage. Wie geht man nun genau bei der Verifizierung
> eines FPGA-Designs vor?
> Man simuliert nur die reine Funktion mit einer Behavioral-Simulation und
> checkt nur mittels constraints, ob das mit der gewünschten Clock so
> funktioniert?

Wenn Du mit ISE 14.7 implemetierst, enthält der "Design Summary" auch 
einen "Timing Report", basierend auf dem tatsächlichen Placement der 
Slices, Buffer und IOBs sowie dem tatsächlichen Routing der Signale. 
Dieser Timing Report enhält eine Angabe zur max. erzielbaren Clock als 
auch zu den Setup und Hold Paths. Ich habe Deinen Adder mal auf einem 
Artix7 mit 8bit breiten Ein- und Ausgängen implementiert (mein Board hat 
4 Pmods mit jeweils 8 IO-Pins) und bekomme folgende Report-Details:

  Timing errors: 0  Score: 0  (Setup/Max: 0, Hold: 0)
   Constraints cover 100 paths, 0 nets, and 31 connections
   Design statistics:
      Minimum period:   3.229ns{1}   (Maximum frequency: 309.693MHz)

Für einen typischen "Setup Path" sehe ich folgenden Report:

  Paths for end point c_7 (SLICE_X60Y117.A2), 1 path

   Slack (setup path):     6.833ns (requirement - (data path - clock 
path skew + uncertainty))
     Source:               a_reg_4 (FF)
     Destination:          c_7 (FF)
     Requirement:          10.000ns
     Data Path Delay:      3.009ns (Levels of Logic = 1)
     Clock Path Skew:      -0.123ns (1.347 - 1.470)
     Source Clock:         clk_BUFGP rising at 0.000ns
     Destination Clock:    clk_BUFGP rising at 10.000ns
     Clock Uncertainty:    0.035ns

D.h. die Software ermittel aufgrund der tatsächlichen Platzierung (die 
während der Simulation noch nicht feststeht) Werte für die 
Gatterlaufzeit sowie weitere Angaben, aus denen zermittelt werden kann, 
ob das synthetiesierte Design den Anforderungen an das Timing genügt 
(Slack). Dabei werden allerdins nicht die tatsächlichen Laufzeiten 
gemessen, sondern Tabellenwerte für die jeweilige Komponente eingesetzt.

Den Timing-Report ist/kann/sollte also Teil der Verifizierung sein.

Gruß,
Burkkhard

[Markus F. (mfro)]

Burkhard K. schrieb:
> Den Timing-Report ist/kann/sollte also Teil der Verifizierung sein.

vernünftige Constraints sind mehr als nur ein Teil der Verifizierung.

Der Quartus-Fitter (und das wird bei Xilinx sicher nicht anders sein) 
verwendet die Constraints , um das Design für die sich daraus ergebenden 
kritischen Pfade zu optimieren.

Das kann durchaus den Unterschied zwischen "tut" und "tut nicht" 
ausmachen.