Statemachine springt in falsche "states" warum?

[statemachine (Gast)]

Ich habe eine statemachine

Irgendwie springt diese nach "debug" in "startup" dann aber wieder in 
"debug".
Kann mir jemand erklären, warum dies so ist / wo mein Fehler liegt?

Ich habe ein MachXO2 Board von lattice.

type state_t is (debugstate, startup, running);

welche so läuft:

if rising_edge(clk) then

case state is

    when debugstate =>
        debug <= NOT "10000000";
        if( delay <= CLOCK*2) then
            delay <= delay + 1;
        else
            delay <= 0;
            state <= startup;
        end if;

    when startup =>
        debug <= NOT "01100000";
        if (delay <= CLOCK) then
            delay <= delay + 1;
        else
            state <= running;
        end if;

    when running =>
        debug <= NOT "00011100";

    when others =>
        null;

    end case;
end if;

delay ist

signal delay : integer range 0 to CLOCK*5 := 0;

[Juergen P. (optronik)]

Du definierst: type state_t is ...

Du verwendest: case state is

=> state vs state_t

[statemachine (Gast)]

Sorry .. diesen Teil habe ich vergessen mit zu kopieren:

signal state: state_t := startup;

Danke für deine Antwort

[statemachine (Gast)]

Ich habe gerade mal etwas getestet und die Zeilen

type state_t is (debugstate, startup, running);
.
.
.
signal status: state_t := startup;

auskommentiert und die Zeilen

constant debugstate : integer := 0;
constant startup : integer := 1;
constant running : integer := 2;
.
.
.
signal status : integer range 0 to 4 := 0;

eingefügt.

Hiermit läuft es.

Was mache ich bei dem Aufzählungstyp falsch? Es scheint mir ein wenig, 
als wenn dieser nur mit einem Bit erstellt werden würde...
Wenn ich im Startup starte geht er in das rnning (mit Aufzählungstyp) 
aber nicht wenn ich mit debugstate starte.

[S. R. (svenska)]

Du hast keinen neuen Zustand vorgegeben, wenn die jeweiligen Bedingungen 
erfüllt sind. Schreib das mal dazu:

when debugstate =>
        debug <= NOT "10000000";
        if( delay <= CLOCK*2) then
            delay <= delay + 1;
            state <= debugstate;  <== sowas hier ueberall dazu tun
        else
            delay <= 0;
            state <= startup;
        end if;

[MaWin (Gast)]

S. R. schrieb:
> hast keinen neuen Zustand vorgegeben, wenn die jeweiligen Bedingungen
> erfüllt sind

Das ist ja auch nicht nötig weil der state sowieso schon so ist, also 
durch deine Anweisung nicht verändert wird. Und er fängt sich durch die 
fehlende Anweisung auch kein FlipFlop Register ein weil state sowieso 
ein Register sein soll.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

statemachine schrieb:
> Irgendwie springt diese nach "debug" in "startup" dann aber wieder in
> "debug".
Es gibt gar keinen Zustand "debug"...

S. R. schrieb:
> Schreib das mal dazu: when debugstate =>
Der Synthesizer meint lakonisch:

------------------------
 State      | Encoding
------------------------
 debugstate | unreached
 startup    | 0
 running    | 1
------------------------

Und auch der Simulator sieht das so. Denn mit dem Code oben passiert 
genau das, was zu erwarten ist: anfangs "startup", nach 1 Sekunde 
"running". Das Problem liegt also nicht im geposteten Code. Mach doch 
mal einen "Dreizeiler", der in 1 Datei genau das beanstandete Verhalten 
zeigt.

EDIT:
> Wenn ich im Startup starte geht er in das rnning (mit Aufzählungstyp)
> aber nicht wenn ich mit debugstate starte.
Doch, das geht auch (zweites Bild)...
Und dann macht auch der Synthesizer einen State daraus:

------------------------
 State      | Encoding
------------------------
 debugstate | 00
 startup    | 01
 running    | 11
------------------------

[statemachine (Gast)]

Bei mir ja gerade irgendwie nicht ....

Was ich soebend heraus gefunden habe: Wenn ich den Reset weg lassen, 
dann geht das alles...

Der vollständigkeit halber einfach mal das gesamte Programm.
An debug sind die LEDs des Boards, welche auf '0' Leuchten.
Am Reset ist eine Leitung direkt auf GND. Wenn ich diese auf High setze 
bleiben die LED's wie gewünscht im Zustand, welchen Sie haben.

So wie das Programm hier jetzt steht leuchten nacheinander eine LED und 
dann zwei, bevor sich das ganze wiederholt und nur eine leuchtet.

Ich nutze das Lattice Diamond (64-bit) 3.8.0.115.3
Ich werde mich heute Abend mal mit dem Simulator dieses Programms 
auseinander setzen und wie ich eine Testbench zu erstellen habe.

Warum verursacht dieses (eigentlich nicht betretene) Reset dieses 
Verhalten aus?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

library lattice;
use lattice.components.all;

entity top is
    port(

        reset: in std_logic := '0';

        debug : out std_logic_vector(7 downto 0) := (others => 'Z')
        );
end top;


architecture behavior of top is
    component osch
        generic(
            nom_freq: string
        );
        port(
            stdby: in std_logic;
            osc: out std_logic;
            sedstdby: out std_logic
        );
    end component;

    type state_t is (debugstate, startup, running);

    constant CLOCK: integer := 17730000;

    --constant debugstate : integer := 0;
    --constant startup : integer := 1;
    --constant running : integer := 2;

    signal clk: std_logic;
    signal status: state_t := debugstate;
    --signal status : integer range 0 to 4 := debugstate;

    signal delay: integer range 0 to CLOCK * 5 := 0;

begin
    osc0: osch
    generic map (nom_freq  => "17.73")
    port map (stdby => '0', osc => clk, sedstdby => open);


    process(clk, reset)
    begin

        if ( reset = '1') then                        -- Resetzustand
            --delay <= 0;
            --status <= debugstate;
        elsif rising_edge(clk) then

        case status is

                when debugstate =>
                    debug <= NOT "10000000";
                    if( delay <= CLOCK*2) then
                        delay <= delay + 1;
                        status <= debugstate;
                    else
                        delay <= 0;
                        status <= startup;
                    end if;

                when startup =>
                    debug <= NOT "01100000";
                    if (delay <= CLOCK) then
                        delay <= delay + 1;
                        status <= startup;
                    else
                        status <= running;
                    end if;

                when running =>
                    status <= running;
                    debug <= NOT "00011100";

                when others =>                      -- Im Zweifelsfall
                    null;                           -- ... nichts machen

            end case;
        end if;
    end process;

end behavior;

Wenn ich

( reset = '1' )

 durch

 rising_edge(reset)

 ersetze bringt das keine besserung.

[MaWin (Gast)]

statemachine schrieb:
> Irgendwie springt diese nach "debug" in "startup" dann aber wieder in
> "debug".

Wohl nicht.
Er SOLL zwar in debugstate starten, aber er startet in:

signal state: state_t := startup;

Also wird debugstate nie erreicht, er wechselt nur von startup in 
running, das sind die 2 Zustände, nicht debugstate und startup.

[statemachine (Gast)]

MaWin schrieb:
> Wohl nicht.
> Er SOLL zwar in debugstate starten, aber er startet in:

Du meinst wohl dieses hier:

signal state: state_t := startup;

Hier muss ich mich entschuldigen, da ich nebenbei auch weiter versuche 
war hier schon wieder etwas anderes eingetragen.

Wenn ich also

signal state: state_t := debugstate;

 schreibe geht er vom debugstate in den startup und wieder zurück.

Wenn ich

signal state: state_t := startup;

 schreibe geht er vom Startup in den running und bleibt da.

Ich habe hier: 
Beitrag "Re: Statemachine springt in falsche "states" warum?" noch 
mal mein gesamtes Programm angehängt (so wie es aktuell bei mir 
ausschaut).

Noch einmal sorry, daher dass ich nebenbei selber weiter versuche habe 
ich hier aus versehen einmal "startup" geschrieben als ich "debugstate" 
meinte und ganz am Anfang geht soll er natürlich nicht in "debug" gehen 
(gibt es ja nicht) sondern in "debugstate".

Debugstate hieß in einer älteren Version noch "debug" bis ich die Pins 
"debug" hin zu gefügt habe und es in "debugstate" umbenannt habe.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

statemachine schrieb:
> Wenn ich ( reset = '1' ) durch  rising_edge(reset) ersetze bringt das
> keine besserung.
Sowas gibts auch gar nicht:
ein Flipflop, dessen Reset-Eingang flankensensitiv wäre.

statemachine schrieb:
> noch mal mein gesamtes Programm angehängt
Sicher?
> component osch
Was ist osch?

statemachine schrieb:
> Wenn ich den Reset weg lassen, dann geht das alles...
Was tut denn der Reset?
Wie seith deine Testbench aus?

[statemachine (Gast)]

Lothar M. schrieb:
>> noch mal mein gesamtes Programm angehängt
> Sicher?

Jupp, ich habe "nur" eine einzelne VHDL Datei erstellt und das hier 
gezeigte ist alles, was darin steht. (Bild)


Lothar M. schrieb:
>> component osch
> Was ist osch?

Diesen Teil habe ich kopiert.
Diese Componente scheint von Lattice vorgegeben zu sein und den internen 
RC Oszillator zu steuern. (In diesem Fall 17.73MHz).

.pdf Seite 29 unten

COMPONENT OSCH
-- synthesis translate_off
GENERIC (NOM_FREQ: string := "2.56");
-- synthesis translate_on
PORT (STDBY:INstd_logic;
OSC:OUTstd_logic;
SEDSTDBY:OUTstd_logic);

und .pdf Seite 30 oben

OSCInst0: OSCH
-- synthesis translate_off
GENERIC MAP( NOM_FREQ => "2.56" )
-- synthesis translate_on
PORT MAP (STDBY=> stdby,
OSC => osc_int,
SEDSTDBY => stdby_sed
);

Die genaue Quelle kann ich nicht mehr nennen, ich habe mir leider 
einfach nur kopiert gehabt um erstmal irgendwas zum laufen zu bekommen.
(Vor Jahren mal kopiert, vor einer Woche wieder rausgekramt).


Lothar M. schrieb:
> Was tut denn der Reset?
Aktuell soll der Reset nichts machen. Er soll später den "Grundzustand" 
herstellen.

Lothar M. schrieb:
> Wie seith deine Testbench aus?
Aktuell schaut meine Testbench so aus (Foto).
Simulation habe ich bisher noch nicht gemacht, verspreche ich aber mich 
ein zu arbeiten. Nur nicht mehr heute da zu viel um die Ohren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

statemachine schrieb:
> Lothar M. schrieb:
>> Was tut denn der Reset?
> Aktuell soll der Reset nichts machen. Er soll später den "Grundzustand"
> herstellen.
Dann ist er unnötig, denn ein FPGA hat nach dem Einschalten und Laden 
der Konfiguration schon einen immer gleichen Grundzustand.

>> Wie seith deine Testbench aus?
> Aktuell schaut meine Testbench so aus (Foto).
Der Simulator ist der Debugger für FPGA Designs. Mal sehen, ob ich 
morgen in der Pause mal 5 Minuten finde...
Bist du sicher, dass der Oszillator sauber läuft? Wird evtl. das FPGA 
laufend neu geladen?

Noch ein Wort zum hier unnötigen "when others":
http://www.lothar-miller.de/s9y/archives/30-when-others.html

[statemachine (Gast)]

Lothar M. schrieb:
> Dann ist er unnötig, denn ein FPGA hat nach dem Einschalten und Laden
> der Konfiguration schon einen immer gleichen Grundzustand.

Ich wollte die möglichkeit haben, diesen später auch "während des 
laufens" zurück setzen zu können


Ich habe mich gerade mal mit dem Simulator auseinander gesetzt ohne 
Eingangssignale, da das Reset in diesem Fall wieso immer auf "Low" ist.

In allen Fällen zeigt die Simulation das gewünschte verhalten (Ich habe 
die Zählkonstante verringert damit die Simulation schneller geht).
Ich habe auch das Programm, welches ich Simuliert habe noch mal 1:1 auf 
den FGPA gespielt und es zeigt genau das gleiche verhalten.

Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das 
Programm normal. (Ich denke mal dann wird dieser Teil einfach 
wegoptimiert.

Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber 
unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was 
aber auch nichts besser macht.

Ist mein FPGA kaputt?

[statemachine (Gast)]

Inzwischen glaube ich, dass irgendwas mit dem "Lattice Diamond" nicht 
stimmt...

Ich habe in allen Fällen

signal status: state_t := debugstate;

Mit

type state_t is (debugstate, startup, running);

 Verhalten: debugstate -> startup -> Wiederholung

type state_t is (startup, running, debugstate);

 Verhalten: debugstate -> startup -> running -> Bleibt so

type state_t is (debugstate, startup, running, nothing);

 Verhalten: debugstate -> Bleibt so

type state_t is (nothing, startup, running, debugstate);

 Verhalten: others -> Bleibt so

Das gleiche Verhalten, wenn ich in den Varianten mit "nothing" anstelle 
einem "others" den Zustand "nothing"  habe.

[derLars (Gast)]

Gib doch mal den Takt an einem Pin aus und überprüfe, ob der stabil ist.

Wenn du nichts hast, um diesen zu messen, lass wahlweise eine LED 
blinken.

Wenn du dann sicher bist, dass das OSCH-Modul macht was es soll, geht es 
weiter :)

Gruß
derLars

[Stefan (Gast)]

Warum hat eigentlich noch keiner gefragt wo das Reset herkommt?

Für mich hört sich das so an als wenn dein Design durch Störungen am 
Resetpin dieses "merkwürdige" Verhalten zeigt.

Gruß
Stefan

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

statemachine schrieb:
> Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das
> Programm normal. (Ich denke mal dann wird dieser Teil einfach
> wegoptimiert.
So ist es.

> Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber
> unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was
> aber auch nichts besser macht.
Was tut da ein AND? Kommt der Reset aus irgendwelcher Kombinatorik (z.B. 
Vergleicher oder sonst was)? Oder ist das ein FPGA-Pin der an einen 
Taster angeschlossen ist?

statemachine schrieb:
> Ich wollte die möglichkeit haben, diesen später auch "während des
> laufens" zurück setzen zu können
Im Ernst: das deutet auf einen Designfehler hin...

[DivisionByZero (Gast)]

statemachine schrieb:
> Wenn ich die Bedingung für den "Reset" unmöglich mache läuft das
> Programm normal. (Ich denke mal dann wird dieser Teil einfach
> wegoptimiert.
>
> Zudem habe ich versucht das eintreten des Reset zu ermöglichen, aber
> unwarscheinlicher zu machen (abhängig von mehreren Pins in AND), was
> aber auch nichts besser macht.

Wenn dein Reset asynchron zum Clock zurückgenommen wird kann es Dir 
passieren das deine FF bereits den Reset hinter sich haben, das ein- 
oder andere diesen aber noch sieht...

Falls Du also tatsächlich einen externen Reset nutzen willst, solltest 
Du:

1) Sicherstellen das keine (kurzen) Störungen einen Reset (ggfs. auch 
nur auf einzelne FFs) auslösen können. In (d)einem fliegenden Aufbau 
könnte auch gffs. eine Pulsformung (Reset nur wenn er min. 2 Takte lang 
ansteht) und eine Synchronisation auf deinen Clock sinnvoll sein...

Ansonsten kannst Du Dir die Fehler einholen wie mit jedem asynchronen 
Signal in einer FSM !

Gruß

DivisionByZero

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

DivisionByZero schrieb:
> Ansonsten kannst Du Dir die Fehler einholen wie mit jedem asynchronen
> Signal in einer FSM !
Siehe 
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Dort im Besonderen die letzten paar Zeilen.

Ganz übel ist ein kombinatorischer Reset, der z.B. aus einer logischen 
Verknüpfung oder einen Vergleich zurück gesetzt wird. Stichwort dazu: 
"Glitch". Ein solcher Glitch kann dann je nach Dauer mehr oder weniger 
Flipflops in den Reset versetzen. Und so beliebiges Fehlverhalten 
hervorrufen...

[statemachine (Gast)]

derLars schrieb:
> Gib doch mal den Takt an einem Pin aus und überprüfe, ob der stabil ist.

Ich habe den Takt ausgegeben per

clkout: out std_logic;
.
.
.
clkout <= clk;

0.1us/DIV bei 1V/DIV, mehr macht mein Oszilloskop nicht mit.
Wenn ich 9Perioden über 5DIV zähle komme ich auf 18MHz, was nahe genug 
an 17.73MHz wäre und stabil ist das Bild auch.


Stefan schrieb:
> Warum hat eigentlich noch keiner gefragt wo das Reset herkommt?

Der Reset kommt von extern

reset: in std_logic := '0';

 und ist über ein kurzes Kabel fest auf Masse gelegt.

Ich habe auf diese Frage hin den Reset mal als Konstante erstellt

--reset: in std_logic := '0';
constant reset : std_logic := 0;

 und aus der Sensivitätsliste entfernt.

Wenn Reset nun diese "constant" ist .. läuft das Programm. Daher, dass 
ich den Reset auch aus der Sensivitätsliste entfernt hatte habe ich das 
gleiche noch mal mit dem input Pin versucht und hier lief es wieder 
nicht.
Ich denke aber, dass hier wieder wegoptimiert worden sein könnte.

Als nächstes habe ich den Reset so gemacht, dass hier alle Debug LEDs 
eingeschaltet werden sollten, was aber auch nicht passiert (also Reset 
wird nicht betreten)


DivisionByZero schrieb:
> Wenn dein Reset asynchron zum Clock zurückgenommen wird

Auch wenn in dem "Reset" bisher noch nichts passiert habe ich dieses mal 
in die

if rising_edge(clk) then

 reingenommen.
Um das hier alles nicht zuu lang zu machen, habe ich diesesmal das .vhd 
File angehängt.


Lothar M. schrieb:
> Ganz übel ist ein kombinatorischer Reset

Okay, ich habe den aus unwissenheit "kombinatorisch" gemacht, um zu 
verhindern, dass er auf einem Fehler auf einem der Pins (wodurch dieser 
ggf. High erkannt werden könnte) auslöst.


Ich weiß nicht wie interessant das hier gerade ist ... aber aktuell 
passiert in meinem "Reset" absolut überhauptnichts. Es testweise nichts 
auf irgendeiner Weise zurück gesetzt.
Ich habe jetzt testweise gemacht, dass im Reset "alles so bleibt" aber 
dies bringt auch keine Besserung.
Das einzige, was hier (für mich unverständlicherweise) eine Änderung 
bringt ist das Umsortieren der Zusände im type state_t.
Und: irgendwie läuft es richtig in der Simulation aber nicht auf der 
Hardware.

Ich habe falls es hilf noch mal das "Overview Datenblatt" zum Board, 
welches ich nutze hochgeladen. Meines hat den 1200ZE drauf.


Vielen Dank für die ganze Hilfe, ich hoffe ich nerve nicht zu viel. Ich 
versuche wirklich all euren Hinweisen zu folgen.

[Duke Scarring (Gast)]

derLars schrieb:
> Wenn du dann sicher bist, dass das OSCH-Modul macht was es soll, geht es
> weiter :)

Das OSC(H)-Modul ist ein "nobrainer". Per Generic die gewünschte 
Frequenz einstellen (Möglichkeiten siehe Datenblatt), STDBY auf '0' 
setzen und an OSC hat man seinen Systemtakt.

Der wird im MachXO2 intern erzeugt und ist nicht so super stabil und 
genau wie ein Quarz, aber für ein Blinky und eine langsame UART reicht 
es.

Was ich sagen will: Am OSCH liegt es sicher nicht.

Duke

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

statemachine schrieb:
> aus der Sensivitätsliste entfernt
Das juckt den Synthesizer natürlich überhaupt nichts. Die Sensitivliste 
ist nur und ausschließlich für die Simulation interessant....
Eine unvollständige Sensitivliste sorgt nur dafür, dass die Simulation 
falsch ist und nicht zur erzeugten Hardware passt.

[DivisionByZero (Gast)]

statemachine schrieb:
> Der Reset kommt von externreset: in std_logic := '0'; und ist über ein
> kurzes Kabel fest auf Masse gelegt.
>
> Ich habe auf diese Frage hin den Reset mal als Konstante
> erstellt--reset: in std_logic := '0';
> constant reset : std_logic := 0;
>  und aus der Sensivitätsliste entfernt.
>
> Wenn Reset nun diese "constant" ist .. läuft das Programm. Daher, dass
> ich den Reset auch aus der Sensivitätsliste entfernt hatte habe ich das
> gleiche noch mal mit dem input Pin versucht und hier lief es wieder
> nicht.

Wie Lothar schon schrieb, die Sensitivliste wird von der Synthese 
schlicht ignoriert.

Wenn aber das Ändern eines NICHT aktivierten Externen Resets in einen 
nicht aktiven intern Reset eine Änderung deines Designs bringt, dann 
würde ich als Fehlerquelle die Hardware/Verdrahtung in den Fokus 
setzen...

Was versteht Du unter kurzem Draht? Ich kann da Elektrotechniker bei 
denen ist alles unter 2m kurz...
Ist die Masse welche auf den Eingang setzt (im Bezug auf den FPGA) 
tatsächlich eine?
Mutmaßlich koppelst Du dir auf dem Pin eine Störung ein.

Lass dein externes Reset Signal mal durch 3 FFs (Schieberegister) laufen 
und nur wenn das Letzte und vorletzte FF (in der Kette) den von Dir 
gewünschten (Reset-) Pegel "sehen" dann lasse dies dein interner Reset 
sein...

dann solltest Du Dir erst einmal sicher sein können, dass Du Dir über 
den Pin (deines Versuchaufbaus) keine Fehler einfängst...

[statemachine (Gast)]

DivisionByZero schrieb:
> Was versteht Du unter kurzem Draht?

Ein Draht ist in diesem Falle ein 5cm langes Kabel, welches vom GND auf 
dem FPGA Board an den entsprechenden Pin geht.
Die "state" Wechsel kommen regelmäßig in den "richtigen" Zeitabständen, 
nur dass er anstelle nach "running" wieder zurück nach "debugstate" 
springt.


DivisionByZero schrieb:
> Lass dein externes Reset Signal mal durch 3 FFs (Schieberegister) laufen
> und nur wenn das Letzte und vorletzte FF (in der Kette) den von Dir
> gewünschten (Reset-) Pegel "sehen" dann lasse dies dein interner Reset
> sein...
>
> dann solltest Du Dir erst einmal sicher sein können, dass Du Dir über
> den Pin (deines Versuchaufbaus) keine Fehler einfängst...

Werde ich nach Weihnachten mal machen, da ich aktuell keinen Zugriff auf 
die Hardware habe.
Etwas ähnliches habe ich vorher ausprobieren wollen durch die 
AND-Verknüpung mehrer Eingänge.

*Eigentlich sollte doch *auch wenn ein "Reset"* kommt nichts passieren, 
da hier nichts geändert wird. Ich könnte den Namen ja noch einmal 
umändern ;).

[DivisionByZero (Gast)]

statemachine schrieb:
> *Eigentlich sollte doch *auch wenn ein "Reset"* kommt nichts passieren,
> da hier nichts geändert wird. Ich könnte den Namen ja noch einmal
> umändern ;).

Du must Dir vor Augen halten das im FPGA zwischen jedem Flipflop und 
jedem Logikelement (jede Verknüpfung wird in Lookup Tables mit maximal 
sechs Eingangssignalen heruntergebrochen) Laufzeiten durch Verbindungen 
und Switchmatrixen sind.

Das ist mit einer (idealen) Simulation nicht zu vergleichen, wenn Du nun 
also der pegel eines externen Signal kurz vor knapp (steigende Flanke 
deines Taktes) ändert dann kann es eben sein, dass ein FF dies 
mitbekommt ein weiteres in der Nähe liegendes dies nicht mehr sieht 
(korrekt - siehe auch Setup/Hold Problematiken) ...

Die Effekte welche sich daraus ergeben haben nun schon Generationen von 
Ingenieuren die Langeweile verkuerzt ...

Du kannst ja aus Spass einmal die vom Diamond synthetisierte Schaltung 
posten (ggfs. das EDIF dass das embedded Synplify generiert), dann 
können wir den heissen Pfad mal genauer untersuchen...

Gruß

DivisionByZero

[DivisionByZero (Gast)]

DivisionByZero schrieb:
> maximal sechs *(Bei Xilinx)

Bei Lattice sind es 4 Input LUTs...

[statemachine (Gast)]

DivisionByZero schrieb:
> Du kannst ja aus Spass einmal die vom Diamond synthetisierte Schaltung
> posten (ggfs. das EDIF dass das embedded Synplify generiert), dann
> können wir den heissen Pfad mal genauer untersuchen...

Ich habe im Lattice Diamond unter [Tools] den "Symplify Pro for Lattice" 
ausgeführt. Hier habe ich dann auf "Run" geklickt und unter anderen die 
Meldung erhalten, dass die impl1.edi erstellt wurde, welche ich hier 
angehängt habe.