www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Fehler Meldung


Autor: Absolut Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe folgenden Code geschrieben unter der XILINX ISE 7.1.03i:

process (CLOCK)
begin
  if rising_edge (CLOCK) then
    if RESET = '1' then
      TST_OUT <= '0';
    else
      TST_OUT <= '1';
    end if;
  else
    TST_OUT <= '0';
  end if;
end process;


Jetzt bekomme ich immer folgende Fehlermeldung:

Signal TST_OUT cannot be synthesized, bad synchronous description.

Ich habe keine Ahnung warum.

Vielen Dank für Eure Hilfe.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Überleg doch mal was dein Code macht.
Bei der steigenden Taktflanke von "clk" übergibst du dem Signal
TST_OUT eine '1' ansonsten übergibst du '0'. Das kann gar nicht
synthetisiert werden.


 if rising_edge (CLOCK) then
      TST_OUT <= '1';
 else
      TST_OUT <= '0';
  end if;
end process;

Autor: Alex H. (alex123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

es gibt verschiedene Arten, einen synthetisierbaren
synchronen Prozess zu schreiben:
- Mit und ohne Reset
- Falls mit Reset: Synchron oder Asynchron

-- Asynchroner Reset
process (Clock, Reset)
begin
  if Reset='1' then
    Ausgang <= '0'; -- Initialisierung
  elsif rising_edge(Clock) then
    -- nun kommt das was Du machen möchtest ...
    if ...
      Ausgang <= ...
      ...
    else if ...
      ...
    end if;
  end if;
end process;

Ausserhalb des "elsif - end if"-Bereiches darf nix anderes
stehen.
Das Signal Reset muss dabei auch in die Sensitivity List.

-- Synchroner Reset
process (Clock)
begin
  if rising_edge(Clock) then
    if Reset='1' then
      Ausgang <= '0'; -- Initialisierung
    else
      -- nun kommt das was Du machen möchtest ...
      if ...
        Ausgang <= ...
        ...
      elsif ...
        ...
      end if;
    end if;
  end if;
end process;

Ausserhalb des if mit dem clock darf nix anderes stehen.
Du scheinst in deinem Beispiel einen synchronen Reset zu
verwenden, hast allerdings Dein 3. TEST_OUT ausserhalb
des "if rising_edge(Clock)", daher funktioniert das ganze
nicht.
(BTW: Die Simulation würde hier folgendes tun: Mit der
steigenden Taktflanke führst Du den oberen Teil aus, also
bei Reset ist der Ausgang gleich null, ansonsten wird er
auf 1 gesetzt. Mit der Fallenden Flanke setzt Du den
Ausgang dann wieder auf 0.)

Dasselbe geht auch ohne Reset - ist wie das 2. Beispiel,
nur dass man den Resetteil weglässt.
Alternativ zu rising_edge(Clock) kannst Du auch
Clock'event and Clock='1' schreiben.

Es gäbe auch noch die Möglichkeit, mit
wait until rising_esge(Clock)
zu arbeiten, wird aber kaum verwendet.

Gruss,

Alex

Autor: Absolut Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
erstmal Danke für Eure Antworten.

@Tobias: Also Dein Codefragment funktioniert auch nicht.

Ich komme bei einer Clocksignaländerung (rising oder falling) in den
process, durch die Sensetiv-Liste. Jetzt teste ich ob eine rising-edge
vorlag
if rising_edge
   Ja, dann TST_OUT <= '1';
else (nein)
   dann TST_OUT <= '0';
end if;

Irgenwie kapiere ich das nicht. Warum das nicht gehen soll. Hab das
Gefühl das muss was mit der Hardware zu tun haben. Aber was genau???

Danke.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem Codebeispiel habe ich nur deinen Code genommen und den
überflüssigen Ballast entfernt, um dir zu verdeutlichen was du dem
Synthesewerkzeug damit antust.

Versuch mal das Verhalten dieses Codefragmentes als Blockschaltbild mit
Gattern und Flip-Flops nachzubilden.

if rising_edge (CLOCK) then
      TST_OUT <= '1';
 else
      TST_OUT <= '0';
  end if;
end process;

Auf das Ergebniss bin ich sehr gespannt.

Autor: Alex H. (alex123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Du solltest nur eine Flanke des Taktes verwenden, d,h. die
ganze Funktion sollte innerhalb des then-Zweiges Deiner
if rising_edge stehen. Alles andere macht für die Synthese
nur bedingt Sinn. Was Du beschrieben hast, ist ein Signal,
dass mit einer steigenden Taktflanke auf 1 gesetzt wird,
mit einer fallenden auf 0 - also im Prinzip den Takt selbst
(mit dem Zusatz, daß während Reset nix passiert - siehe
mein BTW von oben).

Wäre hilfreich, wenn Du schreiben würdest, was Du denn
tatsächlich machen möchtest.

Gruss,

Alex

PS: Es geht auch die fallende Flanke als Trigger. Im Prinzip
geht auch steigende und fallende und dann die Funktion im
else-Zweig, dann wird ein FF mit Set und Clear eingebaut - ich
weiss aber nicht, ob das alle Synthesetools so können.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Irgenwie kapiere ich das nicht. Warum das nicht gehen soll. Hab das
>Gefühl das muss was mit der Hardware zu tun haben. Aber was genau???


Schau Dir doch mal den Code genau an: Wenn eine steigende Flanke kommt,
soll TST_OUT den Wert 1 haben, wenn nicht, dann 0.
Das heisst in dem infinitesimal kleinen Zeitpunkt der steigenden Flanke
soll es den Wert 1 haben, ansonsten 0. Was soll denn das bitteschön für
eine digitale Hardware darstellen?

Alex H. hat übrigens nicht recht wenn er schreibt dass der else-Zweig
einer fallenden Flanke entspricht. Der else-Zweig ist jeder Zeitpunkt
der keine steigende Flanke ist. Und deshalb ist das nicht
synthetisierbar.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

process (CLOCK)
begin
  if rising_edge (CLOCK) then
     TST_OUT <= '1';
  else
     TST_OUT <= '0';
  end if;
end process;

Man muss hier klar trennen zwischen VHDL-Ursprung und Synthese.

In der VHDL Simulation funktioniert das oben beschriebene Konstrukt
wunderbar. Der Eintritt in den process wird überdie Sensitivliste
gesteuert. Bei jeder Änderung eines der Sensitivlist-Signale wird
der Prozess bearbeitet. Siehe dazu Simulationstherorie.

Wie sieht's jetzt aber beim Synthetisieren aus?
Ich bin da auch noch nicht so sattelfest, bitte korrekiert mich wenn
ich falsch liege.

Vereinfacht kann man sagen; ein process wird zu einem Baustein. Nun
besitzt dieser Baustein aber keine Sensitivliste (Nur für Simulation
nötig). Sondern nur Eingänge. Diese Eingänge werden auf eine
kombinatorische Logik geroutet. Der Ausgang des Bausteins ist im
Prinzip nichts anderes als der Ausgang der kombinatorischen Logik.

Jetzt zum obigen Konstrukt. Der Ausgang wird mit einem Taktflanken-
Gesteuerten D-Flip-Flop (mit Reset) upgdatet/gelatcht. In einem FPGA
sind diese FF in den Ausgängen der CLB. Diese CLB-FFs können einfach
nur auf eine positiv ODER negative Flanke scharf gestellt werden.

Will man jetzt wie oben auf negative und positive Flanke einen
synthetisieren dann braucht man zwei CLB's. Das fatale die zwei
CLB-Ausgänge müssten sich gegenseitig überschreiben können.
ERROR!!!!!!!!!

Also wie gesagt, ich bin noch nicht so sattelfest.
Aber ich denke das kommt der Sache sehr nahe.

Sebastian

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider stimmt Dein Verständis nicht ganz.

VHDL wurde als Sprache zur SIMULATION von digitaler Hardware entworfen.
Dabei gibt es für die Elemente der Hardware (z.B. ein Flip-Flop)
bestimmte Beschreibungsmöglichkeiten.

Bei der Synthese erkennt der Compiler diese Beschreibung an der
STRUKTUR und erzeugt dazu die beschriebene Hardware.

Lass mich das an einem Beispiel verdeutlichen.
Z.B. kann ein Flip-Flop mit Reset folgendermaßen in VHDL beschrieben
werden:

process(clock, reset) is
begin
  if (reset = '1') then
    Q <= '0';
  elsif rising_edge(clock) then
    Q <= 'D';
  end if;
end process;

Dieser Prozess steuert das Signal D, wie wenn es der Ausgang eines FF
wäre mit den Eingängen D, clock, reset.
Denk daran, hier sprechen wir von der Simulation !!

Ein VHDL-Compiler, dem Du das obige VHDL-Stück übergibst, erkennt an
der FORM (also process mit sensitivity list reset und clock, sowie "if
  (reset = '1') und dann elsif rising_edge()), daß es sich um die
Beschreibung eines FF's handelt, und erzeugt ein FF in Hardware.
Die Namen für reset und clock tun dabei nichts zur Sache.

Man sollte also nicht denken, daß ein VHDL-Programm für Simulation
einmal so, und für die Synthese einmal anders umgesetzt wird.
Der Compiler versucht nur zu erkennen, welche Hardware-Elemente man in
VHDL zu modellieren (simulieren) versucht hat, und erzeugt die
entsprechende Hardware dazu.

Das Problem für Anfänger ist oft, daß VHDL viele Freiheiten bietet.
Nicht alles, das man in VHDL gültig beschreiben kann, entspricht auch
einer Hardware. Z.B. kann man in VHDL Dateien lesen und schreiben, aber
eine Hardware-Schaltung kann das nicht.
Wenn Du dem Compiler VHDL-Code übergibts, der zwar gültig ist (so wie
Deiner), aber keine Beschreibung von Hardware ist, dann gibt's eben
eine Fehlermeldung.

Vielleicht solltest Du Dich doch noch einmal ein bischen in VHDL
einarbeiten.

Hoffentlich habe ich Dich nicht zu sehr verwirrt.
Klaus

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich dachte schon das man zwischen VHDL-Compiler und Synthesizer
klar unterscheiden kann.

Wenn ich aus Modelsim meine VHDL-Dateien compilieren lasse, werden
Tabellen erstellt in denen Ereignisse zu bestimmten Zeiten eingetragen
werden. (Mir fällt dazu gerad nicht der Fachbegriff für die genau
Bezeichnug der Tabellen ein, meine Unterlagen sind daheim.) Das
Simulationstool arbeitet doch nur nach diesen Tabellen und fügt wenn
nötig DeltaT's ein.

Warum sollte der Compiler nach Hardwarestrukturen suchen, wenn er
sowieso keine finden kann (z.B. für ReadFile etc.)

Nach bekannten Hardware-Elementen sucht das Synthese-Tool. Wenn dies
kein passendes Hardware-Element findet wird gemeckert.

Allerdings braucht anscheinend das Synthese-Tool das Ergebnis vom
Compiler. Weil der Compile-Vorgang (vielleicht nur für den Syntax
Check) immer gestartet wird bevor die HDL Synthesis angeworfen wird.
(Sieht man schön in der ISE-Shell)

Sorry, aber ich würde es gerne voll und ganz verstehen. Und es ist sehr
schwer als Autodidakt immer die richtigen Bücher bzw. pdfs zu finden.
Wenn man dazu überhaupt was finden kann.

Sebastian

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die tabelle nennt sich wohl "event list".

Das synthesetool braucht keine ergebnisse aus dem Compile für die
simulation.

Der Synthaxcheck geht i.d.R mit dem Simutool schneller als mit dem
Synthesetool.

Es gibt warnings aus dem simulatortool die die synthese nicht bringt
aber denoch zu ungewollten ergebnissen führt.

Zitat:
"Nur Genies und Idioten verzichten auf eine Simulation"

Autor: Alex H. (alex123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Xenu

> Alex H. hat übrigens nicht recht wenn er schreibt dass der
> else-Zweig einer fallenden Flanke entspricht. Der else-Zweig
> ist jeder_ Zeitpunkt der _keine steigende Flanke ist. Und
> deshalb ist das nicht synthetisierbar.

durch "process (CLOCK)" ganz oben ist der Prozess sensitiv
auf CLOCK. D.h. er wird immer genau dann durchlaufen, wenn
Clock sich ändert. Danach wird die IF-Anweisung ausgeführt.
Wird nun eine steigende Flanke erkannt, dann wird der
THEN-Teil ausgeführt. Im anderen Fall (also z.B. bei der
fallenden Flanke) wird der Else-Zweig ausgefüght. Also
folgt das Ausgangssignal dem Clock. (Falls das Signal
std_logic ist, wäre daneben z.B. auch ein Übergang von
U nach 1 oder von H nach L eine Flanke usw (steigend
oder fallend :-?), die den Prozess ausführt, aber ich gehe
mal davon aus, dass man Clock i.W. durch eine Folge von
01010101 beschreibt ... ;-)

Soviel zum Simulationsverhalten im Beispielcode.
Nach wie vor gilt aber: Man sollte so nicht beschreiben.
Oben sind Beispiele, wie man einen synchronen Prozess
richtig bescchreibt.

BTW, die Synthese "versteht" sehr wohl Clocks. Sie ignoriert
zwar sensitivity lists, kann aber getaktete Prozesse
erkennen.

> Schau Dir doch mal den Code genau an: Wenn eine
> steigende Flanke kommt, soll TST_OUT den Wert 1 haben,
> wenn nicht, dann 0.
> Das heisst in dem infinitesimal kleinen Zeitpunkt
> der steigenden Flanke soll es den Wert 1 haben, ansonsten 0.

Dies stimmt daher so nicht. Der Prozess wird mit einer
steigenden Flange angestossen und setzt TST_OUT auf 1.
Danach passiert solange NICHTS, bis wieder eine Flanke
kommt. Erst dann wird der Prozess erneut gestartet und
TST_OUT entsprechend gesetzt ...

Sorry, Xenu, aber so ist es nun mal ... ;-)

-----

Wie Klaus Falser schon schreibt ...
> Ein VHDL-Compiler, dem Du das obige VHDL-Stück übergibst,
> erkennt an der FORM (also process mit sensitivity list reset
> und clock, sowie "if (reset = '1') und dann
> elsif rising_edge()), daß es sich um die
> Beschreibung eines FF's handelt, und erzeugt ein FF in Hardware.
> Die Namen für reset und clock tun dabei nichts zur Sache.
>
> Man sollte also nicht denken, daß ein VHDL-Programm für
> Simulation einmal so, und für die Synthese einmal anders
> umgesetzt wird.

Bei der Sensitivity-Liste gibt es diese (kleinen) Unterschiede -
wenn man in einem kombinatorischen Prozess nicht alle Signale in
die Sensitivity-Liste mit aufnimmt, verhält sich die Simulation
anders als die synthesisierte Schaltung. Die Synthese geht immer
davon aus, dass alle Signale in der Sensitivity-Liste sind. Macht
man dies in Code so, dann passen Simulation und Synthese auch
wunderbar zusammen. Man sollte dies daher auch immer so tun.
BTW, man wird i.d.R. vom Compiler (bei der Synthese) darauf
hingewiesen, wenn man nicht alle Signale in einem kombinatorischen
Prozess in der Sensitivity-Liste hat.

-----

Abgesehen davon wäre es hilfreich, wenn Absolut Beginner
schreiben würde, was er genau machen möchte ...

Gruss,

Alex

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FPGAküchle: "Nur Genies und Idioten verzichten auf eine Simulation"

Naja, das hatte ja keiner vor ;-)

Sebastian

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter VHDL-Compiler versteht man ( verstehe ich ) immer das
Synthese-Tool, das andere ist der Simulator (obwohl es dort auch eine
Art Compiler gibt, der den Quelltext in die Library compiliert.

Beide sind komplett unabhängig. Bei Xilinx wird der Syntax-Check mit
dem Synthese-Tool gemacht, der ModelSim Simulator muß gar nicht
installiert sein.

Der Simulator erstellt aus dem VHDL-Quelltext eine Aufstellung von
Signalen, Prozessen und Ereignissen.
Die Prozesse ändern die Signale zu bestimmten Zeitpunkten (Ereignisse =
Event), die Ereignisse starten dann die Prozesse, welche wiederum die
Signale ändern.
Im ModelSim kann man dann graphisch verfolgen, wie sich die Signale
ändern und überprüfen ob das Design sich so verhält, wie man geplant
hat.

Der Compiler ( = die Synthese) erstellt eine Liste von
Hardware-Elementen (FF's, LUT's, Pins) aus den VHDL-Files, indem er
versucht aus den VHDL-Files zu verstehen, welche Elemente zu dem in
VHDL beschriebenem Verhalten passen.
Damit dies funktioniert, müssen die Elemente in einer bestimmten Art
(IEEE Standard) beschrieben sein.

In diesem Forum sind schon öfter Bücher und PDF's empfohlen worden, du
solltest danach googlen.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dies stimmt daher so nicht. Der Prozess wird mit einer
>steigenden Flange angestossen und setzt TST_OUT auf 1.
>Danach passiert solange NICHTS, bis wieder eine Flanke
>kommt. Erst dann wird der Prozess erneut gestartet und
>TST_OUT entsprechend gesetzt ...

Das stimmt nur für Simulations-VHDL.

Aber wenn Du Dir den Code aus der Sicht eines Synthesizers anschaust,
stimmt meine Beschreibung sehr wohl. Bei dem ist die Sensitivitätsliste
nämlich egal. Und dann steht der else-Zweig in der Tat für jeden
Zeitpunkt, der keine steigende Flanke von CLOCK ist.

Das kannst Du übrigens auch simulationstechnisch approximieren, indem
Du ein weiteres Signal in Sensitivitätsliste mit einfügst, welches mit
einer größeren Frequenz als CLOCK toggelt.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um es nochmals zu wiederholen, es gibt kein Simulations-VHDL und kein
Synthese-VHDL.

Der Simulator setzt den Standard, die Synthese ist nur das Erkennen
bestimmter VHDL-Konstrukte.

Deshalb kann man auch nicht sagen, daß die Synthese die sensitivity
list ignoriert. Die sensitivity list dient dem Compiler dazu, diese
Konstrukte zu erkennen, weil es z.B. der Unterschied zwischen Latch und
FF sein kann, ob ein Signal in der sensitivity list steht oder nicht.
Leider sind manche Compiler zu schlau, und erkennen bestimmte
Strukturen obwohl die sensitivity list nicht korrekt angeben ist. Davon
entsteht dann die Meinung, daß die sensitivity list bei der Synthese
ignoriert wird.

Deshalb hat Du, Xenu nicht recht. Der Synthesizer ist kein Simulator,
er weiss nichts über das Signal zu bestimmten Zeitpunkten. Er erkennt
die Beschreibung eines FF's oder er erkennt sie nicht, wenn sie falsch
ist.
Dein Vorschlag mit dem höherfrequentigen Signal beweist nichts. Es
stimmt zwar, daß sich die Simulation dann so verhält, wie Du schreibst,
aber du simulierst dann kein FF mehr, sondern irgend etwas sinnloses.

Autor: Alex H. (alex123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon oben gesagt:

> Zitat:
> "Nur Genies und Idioten verzichten auf eine Simulation"

Die Referenz sollte immer die Simulation sein. Die Synthese
versteht i.d.R. ohnehin nur einen Teil des VHDL-Sprachumfanges.

Wenn man die Schaltung richtig beschreibt, dann stimmen Simulation
und Synthese auch überein.

> Aber wenn Du Dir den Code aus der Sicht eines Synthesizers
> anschaust, stimmt meine Beschreibung sehr wohl.

Soweit ich bisher verstanden habe, wird die Beschreibung
ohnehin nicht synthetisiert, Absolut Beginner schreibt was
von ner Fehlermeldung "Bad description ..." oder so.
Also von welcher Synthese redest Du?

Zur Sensitivity-Liste:
Laut VHDL muss ein Signal, dass in einem (kombinatorischen)
Prozess verwendet wird, nicht notwendigerweise in der
Sensitivityliste definiert sein. Daher darf (muss!) der
Simulator hier auch einen Unterschied machen:
  process (A, B)
  begin
    C <= A and B;
  end process;
oder
  process (A)
  begin
    C <= A and B;
  end process;
Bei der Synthese wird m.E. in beiden Fällen einunddaselbe
UND-Gatter erzeugt (zumindest war das lange Zeit mit ASIC Synthesetools
so, hab schon ne Weile nicht mehr synthetisiert
- korrigiert mich, wenn sich das mittlerweile geändert hat).

Grundsätzlich stimme ich aber mit Klaus überein: Es gibt nur
EINE Bedeutung bei VHDL (die ist im Sprachstandard definiert).
Der Simulator sollte gefälligst compliant zu dieser sein.
Wenn man die Schaltung richtig beschreibt, dann sollte
nach der Synthese auch dasselbe Verhalten rauskommen wir
zuvor.

BTW, VHDL definiert mit einem Zusatz (1076.6 - Standard for RTL
Synthesis) auch einen Subset von VHDL, bzw den Weg, wie man
VHDL verwenden sollte, dass die Synthesetools damit klarkommen.
Meines Wissens nach steht dort auch was in der Art, dass in
einer Sensitivityliste eines kombinatorischen Prozesses alle
Signale enthalten sein sollen, die im Prozess ("auf der rechten
Seite des Zuweisungszeichens") verwendet werden.

Daher kann man in obigem Beispiel (mit und ohne B in der
Sensitivityliste) auch darüber streiten, ob die 2. Beschreibung
von einem Synthesetool erst gar nicht akzeptiert werden sollte
und gleich einen Fehler erzeugt (und nicht nur ne Warning),
aber das ist Auslegungssache - wie gesagt, Synthese
unterstützt ohnehin nur nen Teil des Sprachumfanges.
Ich sage nicht, dass es im Sinne von IEEE 1076 richtig ist,
wenn ein Synthesetool ein UND-Gatter aus der 2. Beschreibung
erzeugt ;-) - aber das Synthesetool nimmt i.d.R. an, dass man
den Ausgang kombinatorisch von allen Werten abhängig haben
möchte und "interpretiert" dass dann eben so.

Wie eingangs gesagt, die Simulation ist die Referenz.

Gruss,

Alex

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus Falser

>Um es nochmals zu wiederholen, es gibt kein Simulations-VHDL und kein
>Synthese-VHDL.
>Der Simulator setzt den Standard, die Synthese ist nur das Erkennen
>bestimmter VHDL-Konstrukte.

Das war es eigentlich, was ich damit meinte. Ich weiß sehr wohl, daß
VHDL ursprünglich eine Verifikations- und Simulationssprache war, und
die Synthesekonstrukte nur eine Untermenge darstellen.

Wenn ich von "Simulations-VHDL" spreche, meine ich damit den vollen
VHDL-Sprachumfang, und nicht bloß die synthesefähige Untermenge (die ja
auch noch herstellerabhängig ist).
Die meisten Leute mit denen ich rede, kommen mit dieser Bezeichnung
eigentlich gut zurecht...


>Die sensitivity list dient dem Compiler dazu, diese
>Konstrukte zu erkennen, weil es z.B. der Unterschied zwischen Latch
>und FF sein kann, ob ein Signal in der sensitivity list steht oder
>nicht.

Nein, die Sensitivitätliste ist dem Synthesizer völlig egal. Zumindest
mit allen acht Synthesizern, mit denen ich bisher gearbeitet habe.
Nenne mir doch bitte einen VHDL-Synthesizer, der sie nicht ignoriert.
Ob das gut ist, ist eine anderer Frage. Die meisten Synthesizer bringen
eine Warnung.
Selbstverständlich sollte man seinen Code so schreiben, daß Simulation
und Synthese zusammenpassen, und deswegen die Liste korrekt mit
angeben.


>Deshalb hat Du, Xenu nicht recht. Der Synthesizer ist kein Simulator,

Jetzt wird's ulkig, ausgerechnet ich soll das behauptet haben? Wo?

>er weiss nichts über das Signal zu bestimmten Zeitpunkten. Er erkennt
>die Beschreibung eines FF's oder er erkennt sie nicht, wenn sie
>falsch ist.

Habe ich jemals das Gegenteil behauptet?

>Dein Vorschlag mit dem höherfrequentigen Signal beweist nichts. Es
>stimmt zwar, daß sich die Simulation dann so verhält, wie Du
>schreibst, aber du simulierst dann kein FF mehr, sondern irgend etwas
>sinnloses.

Klar ist das sinnlos und nicht synthetisierbar und kein Flip-Flop.
Habe ich das irgendwo behauptet? Ich habe doch nur gesagt wie ein
Synthesizer das sieht, wenn er die Sensitivitätliste ignoriert (was er
tut!), und dann sieht er eben ein "Dingsbums", dessen Signal TST_OUT
für einen infinitesimal kleinen Zeitpunkt '1' ist. Klar ist das nicht
synthesefähig, das habe ich doch in meinem ersten Posting geschrieben.
Aber um dieses Konstrukt so zu simulieren, wie der Synthesizer es
sieht, muss man eben ein weiteres, möglichst hochfrequentes Signal in
Liste hängen. Es ging hierbei mir doch nur um die Veranschaulichung.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

soweit ich das sehe, ist kaum ein Unterschied zwischen kombinatorischer
Logik und flankengesteuerter Logik.

process (A,B)    -- Prozess 1
  begin
    C <= A and B;
end process;


process (CLOCK)  -- Prozess 2
  begin
    if rising_edge (CLOCK) then  -- D-FF
       C <= A and B;             -- Kombinatorische Logik
    end if;
end process;


Im ersten Prozess wird ein UND-Gatter erzeugt. Dessen Ausgang sofort
gültig ist. Man sollte natürlich noch das Einschwingen abwarten.

Im zweiten Prozess wird ebenfalls ein UND-GATTER erzeugt dessen Ausgang
aber auf ein D-FF geroutet ist. Sprich das UND-Gatter schwingt sich ein
wie im ersten process. Und mit der nächsten steigenden Taktflanke wird
der Ausgang des UND-Gatters auch am Ausgang des D-FF übernommen. Oder
anders gesagt. Das Synthesetool erzeugt ein UND-Gatter wie im ersten
Prozess und legt dessen Ausgang auf ein D-FF.

Sebastian

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist soweit richtig aber unvollständig. beim allersten Takt ist bei
der FF Variante unbestimmt. es wird vor dem ersten takt der Initwert
des FF haben, ein zweites FF das den Wert des gebufferten AND
übernimmt, kann (je nach Initwert) einen von der AND Funktion
abweichenden Wert haben.

Der grosse Unterschied zw. den beiden Beschreibungen liegt im
zeitlichen Verhalten. In der kombinatorischen Schaltung ist unbekannt
wann das Signal (spätestens) gültig(eingeschwungen) ist, bei einem FF
ist es der Einlauf des Takt + registerdurchlaufzeit (clock to output).
Man muss also bei kombinatorischer (asynchroner) beschreibung nicht nur
die Funktion sondern auch die tausenden möglichen Schaltzeitpunkte
beachten. Synchroner Entwurf macht den Entwurf einfacher, da aus den
vielen zu bechtenden möglichen Schaltzeitpunkten einer wird, der des
Eintreffen des taktes.

Aber es gibt Anwendungen wo asynchroner Entwurf möglich und gewünscht
ist.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Xenu,
ich habe geglaubt, deine Aussagen

> Aber wenn Du Dir den Code aus der Sicht eines Synthesizers
anschaust,
> stimmt meine Beschreibung sehr wohl. Bei dem ist die
> Sensitivitätsliste nämlich egal. Und dann steht der else-Zweig in
der
> Tat für jeden Zeitpunkt, der keine steigende Flanke von CLOCK ist.

beziehen sich auf das folgende Code-Stück, das zwar gültiges VHDL ist,
aber sich nicht synthetisieren läßt.

process (CLOCK)
begin
  if rising_edge (CLOCK) then
     TST_OUT <= '1';
  else
     TST_OUT <= '0';
  end if;
end process;

In diesem Fall gilt der else-Zweig (ausgenommen in der Init-Phase des
Simulators) für die abfallende Flanke, und nicht nur für alle
Zeitpunkte, die nicht die ansteigende Flanke selbst sind.
Ein Sythese-Tool, das korrekt arbeitet (und die entsprechende Hardware
zur Verfügung hat), müßte daraus ein FF erzeugen, das bei der
ansteigenden Flanke den Ausgang auf 1 und bei der abfallenden Flanke
auf 0 setzt.

Das Umsetzen von VHDL-Prozessen in Hardware heißt ja nicht, daß die
Prozesse nun dauernd laufen, weil sie jetzt ja in HW realisiert sind,
während sie bei der Simulation mangels Rechenleistung halt nur
angestoßen werden, wenn sich die sensitivity list ändert.
Das wäre ein falsches Verständnis der Synthese.
In Hardware gibt es keine Prozesse, ein Prozess ist nur ein Hilfsmittel
für die Simulation.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hallo Xenu,
>ich habe geglaubt, deine Aussagen
>beziehen sich auf das folgende Code-Stück, das zwar gültiges VHDL
>ist, aber sich nicht synthetisieren läßt.

Darauf bezog es sich auch.

>Ein Sythese-Tool, das korrekt arbeitet (und die entsprechende
>Hardware zur Verfügung hat), müßte daraus ein FF erzeugen, das bei
>der ansteigenden Flanke den Ausgang auf 1 und bei der abfallenden
>Flanke auf 0 setzt.

Da aber alle aktuellen VHDL-Synthesizer die Sensitivitätsliste
ignorieren, "sehen" sie den Code so, wie ich es beschrieben habe.
Zum dritten Mal: Ich weiß, das diese Pseudohardware Käse ist. Das habe
ich schon bei meinem ersten Posting geschrieben.

Wenn die Synthesizer alles so synthetisieren würden, wie ein
VHDL-Simulator es handhabt, dann stimmt die Aussage, daß es sich
hierbei um ein Flip-Flop mit steigender/fallender Flanke handelt (und
man davon ausgeht, daß CLOCK nur den Wert '0' und '1' annimmt).

Nur: Es gibt eben bis heute keinen Synthesizer, der das macht. Alle
ignorieren die Sensitivitätsliste.
Und alle ignorieren "wait for"- Anweisungen, obwohl es ja auch ganz
nett wäre, hätten FPGAs programmierbare Verzögerungsleitungen im
Pikosekundenbreich, mit denen diese Anweisung dann tatsächlich halbwegs
umsetzbar wäre.

Zum Thema Flip-Flop mit steigender/fallender Flanke:
Coolrunner II können das, synthesefähiger VHDL-Code schaut so aus:

process(clk)
begin

  if(clk'event) then
    if(clk = '0') then
      q <= a;
    elsif(clk = '1') then
      q <= b;
   end if;
  end if;

end process;


Wenn man das "if (clk'event)" weglässt, erkennt er keine FFs,
sondern
erzeugt Latches. Einem Simulator wäre das Wurst, da das "clk'event"
ja eigentlich implizit durch die Sensitivitätsliste vorhanden ist.
Aber VHDL-Synthesizer interessieren sich nicht für Liste, das "(clk)"
nach "process" kann man auch weglassen. Dann stimmt freilich die
Simulation nicht mehr mit der synthetisierten Hardware überein.

>Das Umsetzen von VHDL-Prozessen in Hardware heißt ja nicht, daß die
>Prozesse nun dauernd laufen, weil sie jetzt ja in HW realisiert sind,

Natürlich "laufen" keine Prozesse in der Hardware. Habe ich nie
behauptet. Das Gegenteil ist der Fall. Schau mal ältere Postings von
mir an.

>während sie bei der Simulation mangels Rechenleistung halt nur
>angestoßen werden, wenn sich die sensitivity list ändert.
>Das wäre ein falsches Verständnis der Synthese.

Freilich ist das ein falsches Verständnis.

>In Hardware gibt es keine Prozesse, ein Prozess ist nur ein
>Hilfsmittel für die Simulation.

Natürlich! Volle Zustimmung. Aber nochmals: Ich habe das doch nie
behauptet! Ich habe irgendwie das komische Gefühl Du glaubst ich kenne
den Unterschied zwischen Synthese und Simulation nicht.

Daß aber Synthesizer die Sensitivitätsliste ignorieren, ist Fakt.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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