Forum: FPGA, VHDL & Co. Bug in Quartus 21.1?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max F. (fpgaaa)


Angehängte Dateien:

Lesenswert?

folgender einfacher MUX:
1
 
2
entity OUTSEL2 is
3
4
  port(
5
    Signal1_i        : in  std_logic; 
6
    Signal2_i        : in std_logic;
7
    Error_i      : in std_logic;
8
    Ready_i      :in std_logic;
9
    Out_o       : out std_logic 
10
  );
11
end entity OUTSEL2;
12
architecture rtl of OUTSEL2 is
13
begin
14
Out_o <= '0' when (Ready_i = '0' and Error_i = '0') else
15
  Signal2_i when (Ready_i = '0' and Error_i = '1') else
16
  Signal1_i when (Ready_i = '1' and Error_i = '0') else
17
  Signal2_i when (Ready_i = '1' and Error_i = '1');
18
end architecture rtl;
liefert im Signaltap den angehängten Signaltap Plot (Signal1_i wird 
durchgeschaltet obwohl Error_i = '1' und Ready_i = '0' !). Im Modelsim 
ist dieser Fehler nicht.
Ich benutze Quartus 21.1. Hat dies irgendwie mit der VHDL Version zu tun 
oder sonnst irgend eine Erklärung?

: Bearbeitet durch Moderator
von Max F. (fpgaaa)


Lesenswert?

So funktionierts korrekt im Quartus:
1
 
2
  p_mux : process(Signal1_i,Signal2_i,Error_i,Ready_i)
3
  begin
4
    if(Error_i='0') then
5
    if(Ready_i='0') then
6
      Out_o <= '0';
7
    else
8
      Out_o <= Signal1_i;
9
    end if;
10
    else
11
    Out_o <= Signal2_i;
12
    end if;
13
  end process p_mux;

: Bearbeitet durch Moderator
von externer Projektleiter im home office (Gast)


Lesenswert?

Max F. schrieb:
> Out_o <= '0' when (Ready_i = '0' and Error_i = '0') else
>   Signal2_i when (Ready_i = '0' and Error_i = '1') else
>   Signal1_i when (Ready_i = '1' and Error_i = '0') else
>   Signal2_i when (Ready_i = '1' and Error_i = '1');
> end architecture rtl;

dann definiere bitte eindach mal beide Signale getrennt voneinander.

dann siehst du, dass du die Pfade nicht vollständig beschrieben hast.

die Simulation ist deshalb anders, weil dort ein Zeitablauf mit 
integriert ist

von Dussel (Gast)


Lesenswert?

Vielleicht stehe ich total auf dem Schlauch, aber:
externer Projektleiter im home office schrieb:
> dann definiere bitte eindach mal beide Signale getrennt voneinander.
Welche beiden Signale? Welche sind nicht getrennt voneinander definiert?
externer Projektleiter im home office schrieb:
> dann siehst du, dass du die Pfade nicht vollständig beschrieben hast.
Was fehlt denn noch? (Ready_i & Error_i) = {"00", "01", "10" und "11"} 
sind berücksichtigt. Welche(n) Pfad(e) gibt es noch in Hardware? (In der 
Simulation gibt es natürlich noch "1X", "UH", "WZ", "X-" usw.)

Allgemein kann man sich bei dem kleinen Beispiel mal den 'Schaltplan' im 
RTL Viewer ansehen und nachsehen, was compiliert/elaboriert oder 
synthetisiert wurde und nachvollziehen, ob es das ist, was man wollte.

von Max F. (fpgaaa)


Lesenswert?

Dussel schrieb:
> Allgemein kann man sich bei dem kleinen Beispiel mal den 'Schaltplan' im
> RTL Viewer ansehen und nachsehen, was compiliert/elaboriert oder
> synthetisiert wurde und nachvollziehen, ob es das ist, was man wollte.

Habe ich per Signaltap gemacht, nun gem. OP Post Photo ist es 
offensichtlich nicht so wies sein soll. (Das kleine) Problem habe ich 
nun gelöst mit dem process.
Shockierend finde ich dass sich Modelsim und Quartus unterscheiden. Da 
ich rein zufällig daruaf gestossen bin, und ich mich normalerweise auf 
Modelsim verlasse. (Zum Glück hat etwas nicht funktioniert, debuging hat 
dann über 2h gedauert da an allen anderen Stellen gesucht).

von Dussel (Gast)


Lesenswert?

Max F. schrieb:
> Habe ich per Signaltap gemacht, nun gem. OP Post Photo ist es
> offensichtlich nicht so wies sein soll.
Das Bild am Anfang und Signal Tap zeigen nicht den Schaltplan 
("Schematic", Tools->Netlist Viewers->RTL Viewer, zumindest in 20.1).

Max F. schrieb:
> Shockierend finde ich dass sich Modelsim und Quartus unterscheiden.
Ich würde vom Gefühl her sagen, das geht auch weiterhin. Ich gehe eher 
davon aus, dass es an was anderem liegt.
Leider habe ich keine Ahnung, woran.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Ich würde fast darauf tippen, dass die erste Beschreibung wegen des 
Latches auf die Nase fällt. Im Besonderen, weil das Durchschalten von 
Signal2_i ja gar nicht von Ready_i abhängt.

Probiers mal so:
1
Out_o <= '0' when (Ready_i = '0' and Error_i = '0') else
2
   Signal1_i when (Ready_i = '1' and Error_i = '0') else
3
   Signal2_i;

von Max F. (fpgaaa)


Lesenswert?

Lothar M. schrieb:
> Ich würde fast darauf tippen, dass die erste Beschreibung wegen des
> Latches auf die Nase fällt.

Dem scheint so zu sein, da im Signaltap ebenfalls der Latch aufgeführt 
ist.
Nur verstehe ich nicht woher die Idee dieses Latches kommen soll. Es ist 
ja ausschliesslich kombinatorische Logik - wieso kommt Quartus (und auch 
du) auf die Idee hier ein Latch zu platzieren?

Lothar M. schrieb:
> Im Besonderen, weil das Durchschalten von
> Signal2_i ja gar nicht von Ready_i abhängt.

Nun im VHDL ist die das Durchschalten eigentlich vollständig 
beschrieben. Wie eine LUT mit 2 bits und wass in allen möglichen 
Zuständen gemacht werden soll.
Das "Problem" ist mit Post2 gelöst, ich bin einfach noch schockiert wie 
so etwas passieren konnte. Insbesondere das sich Quartus und Modelsim 
unterscheiden bei identischem HDL.

: Bearbeitet durch User
von Sigi (Gast)


Lesenswert?

Der Fehler tritt auch in sehr alten Quartus-Versionen auf (bei mir: 
11.1).

Wenn du im ersten Beitrag die Concurrent-Anweisung um

  else '0';

erweiterst, dann funktionierts. Du kannst auch die Input-MUX-Signale
in Bits casten und dann per deiner Concurrent-Anweisung verwenden,
dann funktionierts ebenso.

(allerdings wird im Process mit einer CASE-Anweisung ein "schöneres"
RTL-Viewer-Ergebnis erzeugt. Im finalen Tech-Map-Viewer siehts dann
idR wieder ganz anders aus, und das ist ja als finales Ergebnis das,
was zählen sollte => deshalb verwende ich, wenns geht, immer die
PROCESS-Schreibweise)

Das der Code aus deinem ersten Beitrag nicht so funktioniert wie
erwartet und sogar ein Latch impliziert, sollte mit etwas Überlegung
keine überrachung sein.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Max F. schrieb:
> Nun im VHDL ist die das Durchschalten eigentlich vollständig
> beschrieben. Wie eine LUT mit 2 bits und wass in allen möglichen
> Zuständen gemacht werden soll.
std_logic ist eine 9-wertige Logik. 2 Bits davon können 81 Zustände
einnehmen. Bei deiner Beschreibung sind also 77 Zustände nicht 
berücksichtigt.

Max F. schrieb:
> Modelsim unterscheiden bei identischem HDL.
Na ja, Synthesizer können bestenfalls 5% vom VHDL Sprachumfang in 
Hardware umsetzen. Und das auch nur, wenn man sich an die Coding-Styles 
aus dem Handbuch des Synthesizers hält.
Was gibt er denn da als Warnung oder Info aus? Wenn ein Latch auftaucht, 
obwohl keines geplant ist, dann hat sich was quer gestellt.

von Max F. (fpgaaa)


Lesenswert?

Lothar M. schrieb:
> std_logic ist eine 9-wertige Logik

Dank diesem groben Unfug ist std_logic auch nicht mit bool konbinierbar. 
Und wir haben bei jeder if Abfrage das Vergnügen " = '1'" hinzuzufügen.

Lothar M. schrieb:
> Bei deiner Beschreibung sind also 77 Zustände nicht
> berücksichtigt.

Nun wenn ich definiere was bei Ready_i = 'W' und Error_i = 'X' passieren 
soll, hätte die Synthese/Fitter wenig freude. Also es sind alle 
sinnvollen Zustände abgedeckt.

Lothar M. schrieb:
> Na ja, Synthesizer können bestenfalls 5% vom VHDL Sprachumfang in
> Hardware umsetzen.

Das ruft in Erinnerung, dass wir uns mit ner Sprache aus den 80ern 
rumschlagen, vieles obsolete/discouraged oder sogar discouraged by 
design.

Lothar M. schrieb:
> Wenn ein Latch auftaucht,
> obwohl keines geplant ist, dann hat sich was quer gestellt.

Ja bei Logikbeschreibung ein Latch einfügen: ist schon ne 
Selbstübertreffung von Intel.

Sigi schrieb:
> (allerdings wird im Process mit einer CASE-Anweisung ein "schöneres"
> RTL-Viewer-Ergebnis erzeugt

Sollte eignetlich zu 100% identisch sein, da die Beschreibung auch 
gelichwertig. Habs nun im process (problem damit umgangen) anyway finde 
die when else schreibweise übersichtlicher da ich process normalerweise 
nur im zusammenhang mit posedge clk nutze und daher eher verwirrend.

Sigi schrieb:
> Das der Code aus deinem ersten Beitrag nicht so funktioniert wie
> erwartet und sogar ein Latch impliziert, sollte mit etwas Überlegung
> keine überrachung sein.

Kannst du das bitte genauer erläuern, kann beim besten willen nicht 
erkennen wie dies zu nem Latch füren soll?

Sigi schrieb:
> Der Fehler tritt auch in sehr alten Quartus-Versionen auf (bei mir:
> 11.1).

Danke für den Test.

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Max F. schrieb:
> Dank diesem groben Unfug ist std_logic auch nicht mit bool konbinierbar.
Doch, natürlich kann man völlig unterschiedliche Typen im Code 
kombinieren . Man muss nur den Typ entsprechend konvertieren. Aber das 
Hantieren mit false und true ist meist weniger intuitiv als mit 0 und 1. 
Und ausserdem kann bool kein Z.

> Also es sind alle sinnvollen Zustände abgedeckt.
Mag sein, dass du das so denkst, aber der Synthesizer liest eben keine 
Gedanken. Und natürlich ist es klar, dass eine Abfrage in der realen 
Hardware nur 0 oder 1 ergeben kann. Nicht mal Z ist für einen Eingang 
ein auswertbarer Zustand.

> Das ruft in Erinnerung, dass wir uns mit ner Sprache aus den 80ern
> rumschlagen
Der Hieb geht in die falsche Richtung: es ist nicht die Sprache, die 
hier das Problem hat.

Es ist schlicht der Programmierer, der einfach nur die Sprachsyntax 
umgesetzt, aber eben das Ziel "aufs FPGA" nicht verstanden und so einen 
Fehler in den Parser eingebaut hat, der an dieser Stelle zu einem Match 
führt, das sich zudem noch nicht mal wie die Beschreibung verhält.

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

So, hier mal etwas Einblick was woraus gemacht wird.

von Sigi (Gast)


Lesenswert?

Max F. schrieb:
> Sigi schrieb:
>> Das der Code aus deinem ersten Beitrag nicht so funktioniert wie
>> erwartet und sogar ein Latch impliziert, sollte mit etwas Überlegung
>> keine überrachung sein.
>
> Kannst du das bitte genauer erläuern, kann beim besten willen nicht
> erkennen wie dies zu nem Latch füren soll?

Wie Oben schon geschrieben, handelt es sich bei deinen
Input-Signalen ja nicht um Bits, sondern um std_logic-Signale.
Für die Synthese sind dabei nicht alle 9, sondern nur 3 Werte
wichtig: '0', '1', 'Z'. In deinem Fall also 9 statt 81 Fälle.
Bei deinem Code (Concurrent-Anweisung) fehlen also Fälle, was
dann durch implizite Ergänzungen zu einem Latch führt. Bei
meinem Process/Case sollte es also genauso sein, vermute mal,
hier liegt ein Fehler vor. Ich habe das ganze auch mal unter
Xilinx-ISE getestet, und hier klagt (wie von mir erwartet)
ISE über die fehlenden Fälle (ISE meldet sogar ein erkanntes
MUX, perfekt!). Mit der Erweiterung "when others" läufts dann,
was aber der Erweiterung von "else <= '0'" oÄ bei deinem Code
entspricht.

Bleibt also nur die Frage, warum Quartus mit einer CASE-Anweisung
ohne Defaults klarkommt, mit deiner aber nicht. Hier muss man
aber betonen, dass Synthesetools ja nicht die Semantik erkennen,
sondern nur den Syntax schrittweise abarbeiten. Da hier
unterschiedliche Anweisungen vorliegen, gibt's auch verschiedene
Skripte zum Übersetzen. Aber wie die aussehen, wird man wohl
nicht erfahren.

Max F. schrieb:
> Dank diesem groben Unfug
Sei dankbar für diese Erfindung, und sei's nur wegen der Behandlung
von 'Z'. Bei komplexeren Simus lernt man sowas zu schätzen, schon
alleine wegen der nichterforderlichen manuellen Codierung solcher
Fälle.

Max F. schrieb:
> Ja bei Logikbeschreibung ein Latch einfügen: ist schon ne
> Selbstübertreffung von Intel.
Passiert auch bei Xilinx-ISE und Lattice-Diamond, liegt aber,
wie schon gesagt, an der Semantik von std_logic.

Max F. schrieb:
> Danke für den Test.
Nein, ich danke. Ich versuche meinen Code immer so zu schreiben,
dass er in möglichtst vielen Umgebungen (Dev+Sim) läuft. Das
Ignorieren/NichtWarnen von fehlenden Default-Anweisungen innerhalb
von CASE-Anweisungen in Quartus ist mir glaube ich noch nie
aufgefallen.

von Max F. (fpgaaa)


Lesenswert?

Gustl B. schrieb:
> So, hier mal etwas Einblick was woraus gemacht wird.

Danke. Das erste BSP ist eine Zwecksentfremdung des Latches, in dem es 
als Logikgate genutzt wird mit dem aclr.

Aber: alle 3 BSP liefern ein korrektes Ergebnis. Beim OP BSP ist das 
Ergebnis inkorrekt (bei den in HDL klar definierten fällen).

Sigi schrieb:
> In deinem Fall also 9 statt 81 Fälle.
> Bei deinem Code (Concurrent-Anweisung) fehlen also Fälle, was
> dann durch implizite Ergänzungen zu einem Latch führt.

Wenn das Latch so Verwendung findet wie im BSP von Gustl B., dann ist 
mit Input 'Z' von error_i und ready_i der output zwangsläufig ebenfalls 
undefiniert. Aber gesehen über alle Input Signale reduziert sich die 
Anzahl 'Z' im Ausgang.

Auch habe ich gegen die Latch implementation von Gustl B. eigentlich 
nichts einzuwenden: ist zwar auch gröberer Unfug; aber funktioniert 
korrekt.

Dies erklärt nicht weshalb im Quartus ein in HDL klar definierter Fall 
ein falsches Ergebnis liefert (selbst wenn die Beschreibung 
unvollständig, ein Latch eingebaut wird etc.)

von Gustl B. (-gb-)


Lesenswert?

Max F. schrieb:
> Danke. Das erste BSP ist eine Zwecksentfremdung des Latches, in dem es
> als Logikgate genutzt wird mit dem aclr.

Bitte.

Nun die ersten beiden Beschreibungen stammen hier aus dem Thread und 
nicht von mir. Ich habe mux_2 gemacht. Denn das VHDL Konstrukt with ... 
select ... ist genau dazu da um einen kombinatorischen MUX zu 
beschreiben.
Wegen der Mehrwertigkeit von std_logic muss/sollte aber auch ein others 
vorkommen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Max F. schrieb:
> erklärt nicht weshalb im Quartus ein in HDL klar definierter Fall
> ein falsches Ergebnis liefert
Nein, das Problem liegt wie gesagt nicht in der Sprache, sondern in der 
fehlerhaften Umsetzung einer offensichtlich einwandfreien Beschreibung 
in Hardware.

Der Programmierer hat halt einfach nicht mitgemacht, sondern die laufend 
eingebläute Regel umgesetzt: "Wenn bei Logik nicht alle Kombinationen 
auscodiert und zudem kein Defaultpfad angegeben ist, dann muss das ein 
Latch geben!"

Es mag also 1000 Gründe geben, warum dieser Fehler da im Synthesizer 
ist, aber es ist halt trotzdem ein Fehler.

Gustl B. schrieb:
> Wegen der Mehrwertigkeit von std_logic muss/sollte aber auch ein others
> vorkommen.
Das gilt wieder nur für die Simulation. Der Synthesizer kann technisch 
auf seiner Zielhardware ausschließlich 1 oder 0 abfragen. Er kann 
technisch kein Z erkennen. Wenn ein Treiber im FPGA ein Z ausgeben 
würde, dann erkennt ein Logikeingang je nach Leckstrom und EMV trotzdem 
entweder eine 0 oder eine 1.

von Sigi (Gast)


Lesenswert?

Max F. schrieb:
> Dies erklärt nicht weshalb im Quartus ein in HDL klar definierter Fall
> ein falsches Ergebnis liefert (selbst wenn die Beschreibung
> unvollständig, ein Latch eingebaut wird etc.)

Ich muss noch zu meinen Beispielen von Oben schreiben,
dass ich gewohnheitsgemäss seit 1-2 Jahrzehnten in den
ungetakteten Prozessen immer eine Default-Aneisung am
Anfang mache. Das hatte ich leider bei der Synthese
vergessen. Lasse ich die Default-Anweisung weg, dann
ist das Ergebnis wie von mir Anfangs erwartet: es wird
in allen 3 Fällen (Concurrent,Process-Case,Process-If)
ein Latch erzeugt. Sorry für das Misverständnis, aber
über diese Default-Zuweisungen denke ich eiglich nicht
mehr nach.

Bleibt nur die Frage, warum Xilinx-ISE bei fehlender
CASE-"When others"-Anweisung mekert (korrekt!), Quartus
aber nicht (Fehler!).

Der Rest, d.h. das erzeugte Latch, ist aber bei allen
3 mir gerade zur Verfügung stehenden Umgebungen identisch.
(Xilinx-ISE erzeugt sogar ein kleines schnuckeliges LUT4
für den MUX, schönes Ergebnis!)

von Sigi (Gast)


Lesenswert?

Lothar M. schrieb:
> Der Programmierer hat halt einfach nicht mitgemacht, sondern die laufend
> eingebläute Regel umgesetzt: "Wenn bei Logik nicht alle Kombinationen
> auscodiert und zudem kein Defaultpfad angegeben ist, dann muss das ein
> Latch geben!"

Bei dir liest sich das ein wenig negativ betont, ist
aber doch die Std.Regel für das Inferieren von FFs/Latches.
Concurrent-Anweisungen sind dabei wie Processe zu sehen,
können aber nicht getaktet werden, deshalb ein Latch. Ist
vollkommen korrekt.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Sigi schrieb:
> deshalb ein Latch.
> Ist vollkommen korrekt.
Wenn der Synthesizer dann schon ein Latch draus macht, dann sollte er 
wenigstens eines machen, das sich wie die Beschreibung verhält und eben 
nur bei Zuständen wie X, Z, H, L, U usw. speichert.

Mir will aber nicht in den Kopf gehen, wie er das machen könnte. Und 
deshalb wäre da dann eine entsprechende Warnung angebracht.

: Bearbeitet durch Moderator
von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Max F. schrieb:
> liefert im Signaltap den angehängten Signaltap Plot (Signal1_i wird
> durchgeschaltet obwohl Error_i = '1' und Ready_i = '0' !). Im Modelsim
> ist dieser Fehler nicht.

Das könnte ein Phantomfehler sein. Du darfst nicht vergessen, dass der 
Signaltap nichtkoheränt sampelt, weil der selber aus LUTs ausgebaut ist 
und eine Zeitverzögerung an seinen Eingängen hat. Diese ist auf bis zu 
einen Takt ausgedehnt. Wenn man dann Kombinatorik erfasst, dann sieht 
man u.U. schon mal einen Signalwechsel im Folgetakt. Das liegt mithin 
auch daran, dass der Signal-TAP per constraint entspannt ist. Man kann 
probieren, den asynchron zu fahren oder man sampelt die Signale in ihrer 
domain nochmal extra ab und schaltet ein Constraint.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Jürgen S. schrieb:
> Wenn man dann Kombinatorik erfasst, dann sieht man u.U. schon mal einen
> Signalwechsel im Folgetakt.
Guter Verdacht. Im Screenshot oben toggelt alles sehr regelmäßig...

Man sollte natürlich generell irgendein Signal mindestens doppelt so 
schnell abtasten als es selber getaktet ist. Oder eben das Signal für 
mehrere Takte lang stabil halten.

Aber das lernt man ja schon bei "Grundlagen der Signalverarbeitung".

von Rezy (Gast)


Lesenswert?

Lothar M. schrieb:
> Sigi schrieb:
>> deshalb ein Latch.
>> Ist vollkommen korrekt.
> Wenn der Synthesizer dann schon ein Latch draus macht, dann sollte er
> wenigstens eines machen, das sich wie die Beschreibung verhält und eben
> nur bei Zuständen wie X, Z, H, L, U usw. speichert.
>
> Mir will aber nicht in den Kopf gehen, wie er das machen könnte. Und
> deshalb wäre da dann eine entsprechende Warnung angebracht.

Die Logikextraktion aus der Beschreibung baut das Latch hier ein. Das 
kann man mit dem RTL Viewer (wie oben schon gezeigt) auch schön sehen. 
Nach Synthese bzw. dem Mapping auf die Zielhardware ist das Latch nicht 
mehr vorhanden (Technology Map Viewer). Es entsteht ein einfaches 4-LUT. 
Deshalb meckert Quartus wohl auch nicht und gibt keine Warnung aus.

Nimmt man bspw. das letzte else weg (else Signal2_i when (Ready_i = '1' 
and Error_i = '1');), wird auch nach Mapping korrekterweise ein Latch 
erzeugt und Quartus schmeißt eine Warnung.

Weshalb der output wie oben gezeigt aber nun falsch ist - das erschließt 
sich mir gerade nicht. Das 4-LUT, was erzeugt wird, hat auch die 
korrekte Wahrheitstabelle und es entsteht wie gesagt kein Latch nach 
Technologiemapping (getestet mit dem target: Cyclone V)..

von Sigi (Gast)


Lesenswert?

Lothar M. schrieb:
> Sigi schrieb:
>> deshalb ein Latch.
>> Ist vollkommen korrekt.
> Wenn der Synthesizer dann schon ein Latch draus macht, dann sollte er
> wenigstens eines machen, das sich wie die Beschreibung verhält und eben
> nur bei Zuständen wie X, Z, H, L, U usw. speichert.
>
> Mir will aber nicht in den Kopf gehen, wie er das machen könnte. Und
> deshalb wäre da dann eine entsprechende Warnung angebracht.

Oh, das wär aber schon ein ausgefallener Wunsch.
Implementieren liese sich das schon:
- Ein 2:1-MUX für das eigentliche Ziel
- ein Latch L1, um die zusätzlichen Geschichten zu speichern
- ein weiteres Latch L2 (man muss ja schliesslich wissen,
  dass eine Nicht-Std.-Zuweisung erfolgt ist)
- ein weiteres MUX, dass zwischen eig.lichen MUX und L1
  mittels Ausgang von L2 entscheidet
Puh, wär schon kompliziert, von Glitches gar nicht erst
zu sprechen!

Aber das passiert nicht, es wird in der Synthesephase ein
Latch generiert, für mich aus gutem Grund. (meine Meinung
dazu: es handelt sich ja um abstrakte Signale, nicht um
Leitungen oder Ähnliches. Die Semantik dieser Signale inkl.
deren Zuweisungen, bedingt oder unbedingt, wird in VHDL-Specs
festgelegt, siehe std_logic-Specs. Also ich mag diese
Definitionen, steckt ein haufen guter Arbeit drin)

Jetzt kommt aber noch ein Hammer (für mich eigentlich nicht,
da ich das eh schon so erwartet habe), der Fitter (PostSynth.)
schmeisst dieses Latch wieder raus. Und zwar aus dem ganz
einfachen Grund: Der Fitter erkennt anhand der vollständigen
Netzliste, dass ja die zusätzlichen Zustande (hier nur 'Z')
nicht vorkommen. Also fliegt das Latch wieder raus.

Für mich ist aber nicht klar, warum das der Synthesizer nicht
schon gemacht hat. Hat hier vlt. jemand eine Idee????

Jürgen S. schrieb:
> Das könnte ein Phantomfehler sein.

Das lässt sich ja sehr schnell durch Zusatzinfos ausschliesen.
Schaut man sich den Verlauf an, so erkennt man, dass nach einem
Signalwechsel viele Takte bis zum nächsten vergehen. Wenn also
die Eingangssignale (error, ready, etc.) in diesen Zeitabschnitten
unverändert sind, dann ist die Anzeige schon "koherent genug".
Max: kannst du dazu mal bitte eine Aussage machen.

@Max: hatte gerade ein Projekt aufgesetzt und für ein Board
laufen lassen. Da erscheint wohl der selbe Fehler. Ich habe
aber Heute Abend nicht mehr die Zeit, mir die Gleichungen
aus dem RTL-Viewer-Diagramm bzw. aus dem Chip-Viewer anzuschauen.
Vlt. erkennt man ja dann, was schiefläuft.

P.S. Max, du vergleicht im ersten Post Modelsim mit SignalTap.
Das erste ist ein Simulator, das zweite ein LogicAnalyzer.
Beides arbeitet grundverschieden und kann auch sehr unterschiedliche
Ergebnisse ausspucken.

von Fitzebutze (Gast)


Lesenswert?

Vorweg, ich habe Quartus selten genutzt, generell schenkt sich da aber 
zu anderen Tools nicht viel: Hier manifestiert sich mal wieder ein 
klassisches Coverage-Problem, was die Synthese eigentlich anmahnen 
sollte, wenn's nicht schon der Coding-Style-Polizist vorher tut (ob's 
GHDL von Haus aus tut, muesstest du ev. mal probieren). Ich bin 
eigentlich ziemlich sicher, dass GHDL in der Simulation bei allen zu 
erwartenden Zustaenden fuer diesen Code Warnungen wirft.
Das Thema mit dem echten Booleans (nur 0 oder 1) in VHDL ist leider ein 
aergerlicher Dauerbrenner, sobald es in die Synthese geht, VHDL-2008 
bringt durch seine implizite Konversion zwar Abdeckung, aber nicht alle 
Tools setzen das 100% korrekt um. Deswegen muss man sich leider schon 
vorab seinen Code scharf anschauen, durch den Coverage-Test jagen oder 
ganz auf verbesserte HDL-Konzepte setzen.

von Max F. (fpgaaa)


Lesenswert?

Jürgen S. schrieb:
> Das könnte ein Phantomfehler sein. Du darfst nicht vergessen, dass der
> Signaltap nichtkoheränt sampelt,

Signaltap habe ich erst begonnen einzusetzen nachdem ich festgestellt 
habe, dass der output am pin falsch ist.

Rezy schrieb:
> entsteht wie gesagt kein Latch nach
> Technologiemapping (getestet mit dem target: Cyclone V)..

Bei mir giebts ein latch bis ins FPGA runter. Anyway gem. hier bereits 
aufgeführtem bsp. existiert die (exotische) Möglichkeit das Latch 
mittels aclr als Logikgate zweckszuentfremden und dennoch ein korrektes 
Ergebnis zu erzielen.

Sigi schrieb:
> Jetzt kommt aber noch ein Hammer (für mich eigentlich nicht,
> da ich das eh schon so erwartet habe), der Fitter (PostSynth.)
> schmeisst dieses Latch wieder raus. Und zwar aus dem ganz
> einfachen Grund: Der Fitter erkennt anhand der vollständigen
> Netzliste, dass ja die zusätzlichen Zustande (hier nur 'Z')
> nicht vorkommen. Also fliegt das Latch wieder raus.

Wäre ja super. Dann liegts einfach am Fitter diesen Unfug wieder 
wegzuoptimieren. Die Programierer des Fitters werden sich über die 
Definiton von std_logic freuen :P.

Sigi schrieb:
> @Max: hatte gerade ein Projekt aufgesetzt und für ein Board
> laufen lassen. Da erscheint wohl der selbe Fehler. Ich habe
> aber Heute Abend nicht mehr die Zeit, mir die Gleichungen
> aus dem RTL-Viewer-Diagramm bzw. aus dem Chip-Viewer anzuschauen.
> Vlt. erkennt man ja dann, was schiefläuft.

Super danke

Sigi schrieb:
> Simulator, das zweite ein LogicAnalyzer.
> Beides arbeitet grundverschieden und kann auch sehr unterschiedliche
> Ergebnisse ausspucken.

Sollte/darf nicht passieren. Insbesondere nicht wenn mittels HDL das 
Verhalten klar und eindeutig beschrieben ist(für die relevanten fälle 
ist es eindeutig beschrieben).
Also von Modelsim - HW - Logikanalyzer intern - Logikanalyzer am Pin. 
Ist ein abweichendes verhalten fatal. Insbesondere wenn sich viele auf 
Modelsim verlassen.

Evtl. zukünftig besser: Weniger Modelsim und mehr Endverifikation mit 
Signaltap?

von FPGA NOTFALLSEELSORGE (Gast)


Lesenswert?

Max F. schrieb:
> Evtl. zukünftig besser: Weniger Modelsim und mehr Endverifikation mit
> Signaltap?

Nein.

Lieber in Zukunft die Simulation so beschreiben, dass sie zur Hardware 
passt.
Klar kann man am der echten Hardware viel debuggen, aber das kostet 
Zeit. Das kann man sich sparen wenn man ordentlich simuliert. Ja, 
vielleicht bleiben ein paar wenige Fehler übrig die man dann an der 
Hardware finden muss, aber zur Vermeidung der allermeisten Fehler ist 
die Simulation eine krasse zeitliche Abkürzung.

von Duke Scarring (Gast)


Lesenswert?

FPGA NOTFALLSEELSORGE schrieb im Beitrag #7175176:
> aber zur Vermeidung der allermeisten Fehler ist
> die Simulation eine krasse zeitliche Abkürzung.

+1

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.