Forum: FPGA, VHDL & Co. Statemachine springt in falsche "states" warum?


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 statemachine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
1
type state_t is (debugstate, startup, running);

welche so läuft:
1
if rising_edge(clk) then
2
3
case state is
4
5
    when debugstate =>
6
        debug <= NOT "10000000";
7
        if( delay <= CLOCK*2) then
8
            delay <= delay + 1;
9
        else
10
            delay <= 0;
11
            state <= startup;
12
        end if;
13
14
    when startup =>
15
        debug <= NOT "01100000";
16
        if (delay <= CLOCK) then
17
            delay <= delay + 1;
18
        else
19
            state <= running;
20
        end if;
21
22
    when running =>
23
        debug <= NOT "00011100";
24
25
    when others =>
26
        null;
27
28
    end case;
29
end if;

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

von Juergen P. (optronik)


Bewertung
-1 lesenswert
nicht lesenswert
Du definierst: type state_t is ...

Du verwendest: case state is

=> state vs state_t

von statemachine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sorry .. diesen Teil habe ich vergessen mit zu kopieren:
1
signal state: state_t := startup;

Danke für deine Antwort

von statemachine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade mal etwas getestet und die Zeilen
1
type state_t is (debugstate, startup, running);
2
.
3
.
4
.
5
signal status: state_t := startup;
auskommentiert und die Zeilen
1
constant debugstate : integer := 0;
2
constant startup : integer := 1;
3
constant running : integer := 2;
4
.
5
.
6
.
7
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.

von S. R. (svenska)


Bewertung
-3 lesenswert
nicht lesenswert
Du hast keinen neuen Zustand vorgegeben, wenn die jeweiligen Bedingungen 
erfüllt sind. Schreib das mal dazu:
1
when debugstate =>
2
        debug <= NOT "10000000";
3
        if( delay <= CLOCK*2) then
4
            delay <= delay + 1;
5
            state <= debugstate;  <== sowas hier ueberall dazu tun
6
        else
7
            delay <= 0;
8
            state <= startup;
9
        end if;

: Bearbeitet durch User
von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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:
1
------------------------
2
 State      | Encoding
3
------------------------
4
 debugstate | unreached
5
 startup    | 0
6
 running    | 1
7
------------------------
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:
1
------------------------
2
 State      | Encoding
3
------------------------
4
 debugstate | 00
5
 startup    | 01
6
 running    | 11
7
------------------------

: Bearbeitet durch Moderator
von statemachine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.numeric_std.all;
4
5
library lattice;
6
use lattice.components.all;
7
8
entity top is
9
    port(
10
11
        reset: in std_logic := '0';
12
13
        debug : out std_logic_vector(7 downto 0) := (others => 'Z')
14
        );
15
end top;
16
17
18
architecture behavior of top is
19
    component osch
20
        generic(
21
            nom_freq: string
22
        );
23
        port(
24
            stdby: in std_logic;
25
            osc: out std_logic;
26
            sedstdby: out std_logic
27
        );
28
    end component;
29
30
    type state_t is (debugstate, startup, running);
31
32
    constant CLOCK: integer := 17730000;
33
34
    --constant debugstate : integer := 0;
35
    --constant startup : integer := 1;
36
    --constant running : integer := 2;
37
38
    signal clk: std_logic;
39
    signal status: state_t := debugstate;
40
    --signal status : integer range 0 to 4 := debugstate;
41
42
    signal delay: integer range 0 to CLOCK * 5 := 0;
43
44
begin
45
    osc0: osch
46
    generic map (nom_freq  => "17.73")
47
    port map (stdby => '0', osc => clk, sedstdby => open);
48
49
50
    process(clk, reset)
51
    begin
52
53
        if ( reset = '1') then                        -- Resetzustand
54
            --delay <= 0;
55
            --status <= debugstate;
56
        elsif rising_edge(clk) then
57
58
        case status is
59
60
                when debugstate =>
61
                    debug <= NOT "10000000";
62
                    if( delay <= CLOCK*2) then
63
                        delay <= delay + 1;
64
                        status <= debugstate;
65
                    else
66
                        delay <= 0;
67
                        status <= startup;
68
                    end if;
69
70
                when startup =>
71
                    debug <= NOT "01100000";
72
                    if (delay <= CLOCK) then
73
                        delay <= delay + 1;
74
                        status <= startup;
75
                    else
76
                        status <= running;
77
                    end if;
78
79
                when running =>
80
                    status <= running;
81
                    debug <= NOT "00011100";
82
83
                when others =>                      -- Im Zweifelsfall
84
                    null;                           -- ... nichts machen
85
86
            end case;
87
        end if;
88
    end process;
89
90
end behavior;

Wenn ich
1
( reset = '1' )
 durch
1
 rising_edge(reset)
 ersetze bringt das keine besserung.

von MaWin (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von statemachine (Gast)


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

Du meinst wohl dieses hier:
1
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
1
signal state: state_t := debugstate;
 schreibe geht er vom debugstate in den startup und wieder zurück.

Wenn ich
1
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch Moderator
von statemachine (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
1
COMPONENT OSCH
2
-- synthesis translate_off
3
GENERIC (NOM_FREQ: string := "2.56");
4
-- synthesis translate_on
5
PORT (STDBY:INstd_logic;
6
OSC:OUTstd_logic;
7
SEDSTDBY:OUTstd_logic);
und .pdf Seite 30 oben
1
OSCInst0: OSCH
2
-- synthesis translate_off
3
GENERIC MAP( NOM_FREQ => "2.56" )
4
-- synthesis translate_on
5
PORT MAP (STDBY=> stdby,
6
OSC => osc_int,
7
SEDSTDBY => stdby_sed
8
);

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch Moderator
von statemachine (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von statemachine (Gast)


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

Ich habe in allen Fällen
1
signal status: state_t := debugstate;


Mit
1
type state_t is (debugstate, startup, running);
 Verhalten: debugstate -> startup -> Wiederholung

1
type state_t is (startup, running, debugstate);
 Verhalten: debugstate -> startup -> running -> Bleibt so

1
type state_t is (debugstate, startup, running, nothing);
 Verhalten: debugstate -> Bleibt so

1
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.

von derLars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von DivisionByZero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von statemachine (Gast)


Angehängte Dateien:

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

Ich habe den Takt ausgegeben per
1
clkout: out std_logic;
2
.
3
.
4
.
5
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
1
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
1
--reset: in std_logic := '0';
2
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
1
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.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von DivisionByZero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von statemachine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;).

von DivisionByZero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von DivisionByZero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DivisionByZero schrieb:
> maximal sechs *(Bei Xilinx)

Bei Lattice sind es 4 Input LUTs...

von statemachine (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.
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.