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?
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
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.
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).
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.
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:
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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!)
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.
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.
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.
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".
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)..
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.
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.
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?
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.
FPGA NOTFALLSEELSORGE schrieb im Beitrag #7175176:
> aber zur Vermeidung der allermeisten Fehler ist> die Simulation eine krasse zeitliche Abkürzung.
+1
Thread beobachten
Seitenaufteilung abschalten