Forum: FPGA, VHDL & Co. Warnmeldung unter Xilinx


von Siegfried S. (dieleena)


Lesenswert?

hallo guten morgen,

arbeite mit Xilinx ISE 8.2. Nutze diese nur in meiner Freizeit, also 
Neuling.
Beim Compilieren werden " Synthesize-XST und Translate " mit einem 
gelben Ausrufezeichen versehen.
Möchte nach Möglichkeit, das diese auch in Ordnung sind.
Fehlen bei mir noch gewisse Einstellungen oder was muß ich noch machen?

gruß Siegfried

von Jan M. (mueschel)


Lesenswert?

Das heißt, das bei dem jeweiligen Vorgang Warnungen aufgetreten sind. 
Diese kannst du in den verschiedenen Reports nachlesen.

von Siegfried S. (dieleena)


Angehängte Dateien:

Lesenswert?

hallo,
Als Anhang meine *.vdh
hier die Warnmeldungen

WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_0>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_1>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_2>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_3>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_4>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_5>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_6>.
WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_7>.
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1001 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1002 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1003 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1004 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1005 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1006 =
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1007 =

Gruß Siegfried

von Siegfried S. (dieleena)


Lesenswert?

Hallo,

was bedeutet diese Meldung?

WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 =
bis
WARNING:Cpld:310 - Cannot apply TIMESPEC TS1007 =

Gruß Siegfried

von Uwe Bonnes (Gast)


Lesenswert?

Was steht in Deinem Constraints File (xxx.ucf)? Da scheint Unsinn 
drinnen zu stehen.

von Siegfried S. (dieleena)


Lesenswert?

Hallo,
Bis jetzt ist sie noch nicht bearbeitet " leer "
-->
#PACE: Start of Constraints generated by PACE

#PACE: Start of PACE I/O Pin Assignments

#PACE: Start of PACE Area Constraints

#PACE: Start of PACE Prohibit Constraints

#PACE: End of Constraints generated by PACE
<--
Gruß Siegfried

von Falk B. (falk)


Lesenswert?

@ Siegfried Saueressig (dieleena)

@Dateianhang: PIC-Fahrendstufe-Shift-Treiber.vhd (5,1 KB, 13 Downloads)

Da hast du was ziemlich Wildes zusammengestrickt.

>hier die Warnmeldungen

>WARNING:Xst:737 - Found 1-bit latch for signal <ShiftOut_0>.

Solche Warungen solle man immer ernst nehmen. Latches sind "böse" in 
CPLDs/FPGAs. Du wolltest ei Schieberegister bauen, hast aber Latches 
konsturiert. -> SCHLECHT!

Du solltest deine Prozesse sauberer trennen, dann sieht man vor allem 
schneller was los ist. Ausserdem hast du ziemlich wilde Konstruktionen 
drin. Machs mal etwas übersichtlicher.

>WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 =

Wo das herkommt weis ich auch nicht.

MfG
Falk

von Johannes T. (johnsn)


Lesenswert?

"Module Name:    PIC-Fahrendstufe-Shift-Treiber - Behavioral"

also warum Synthese, oder ist das 'Behavioral' ein Copy-Paste 
Überbleibsel?

von Siegfried S. (dieleena)


Lesenswert?

Hallo,

die "PIC-Fahrendstufe-Shift-Treiber.vhd" werde ich komplett 
überarbeiten.

Ich habe alle Dateien und Ordner in dem Projekt bis auf *.ise und *.vhd 
gelöscht und neu aufgebaut. Jetzt bekomme ich nur noch bei 
Synthesize-XST ein gelben Ausrufezeichen.
Das mit "Behavioral" gibt mir das Programm bei erstellen eines Projekts 
vor.
Muß und möchte noch viel lernen.
Anhang:
Habe soweit es geschaft, das ein anderes Projekt kein Warnmeldungen mehr 
kommen.
Gruß Siegfried

von Siegfried S. (dieleena)


Angehängte Dateien:

Lesenswert?

Hallo,
Habe das Projekt "PIC-Fahrendstufe-Shift-Treiber" überarbeitet.
Datei enthält nur eine Endstufe. Verkürzte Version.
Bis auf Synthesize-XST mit einem gelben Ausrufezeichen, bekomme ich 
werde Error noch Warnmeldungen.
Frage jetzt, ob dieses Projekt im Aufbau in Ordnung ist, oder werden 
zeilen noch besser aufgebaut.
Gruß Siegfried

von Falk B. (falk)


Lesenswert?

@ Siegfried Saueressig (dieleena)

Das ist immer noch alles andere als gut. rising_edge() muss ALLEIN in 
einer IF Abfrage stehen.
1
  ELSIF rising_edge(OutClk) then
2
    if OutStrobe = '0' then 
3
    OutSerOut   <= ShiftOutBuf(7);
4
    ShiftOutBuf <= ShiftOutBuf(6 downto 0) & OutSerIn;
5
      end if;  
6
  END IF;

MFG
Falk

von Siegfried S. (dieleena)


Angehängte Dateien:

Lesenswert?

Hallo,

Habe es geändert. Was kann ich noch besser machen?

Gruß Siegfried

von Falk B. (falk)


Lesenswert?

@ Siegfried Saueressig (dieleena)

>Habe es geändert. Was kann ich noch besser machen?

Sieht erstmal brauchbar aus und dürfte keine Warungen mehr erzeugen. 
Einzig die asynchronen Resets per ChipRst UND zusätzlicher Signale sind 
etwas unschön.

MFG
Falk

von Roger S. (edge)


Lesenswert?

> Habe es geändert. Was kann ich noch besser machen?

OutStrobe wird neben OutClk auch mit ChipClk verwendet, auch nicht sehr 
schoen.

Nach dem Source zu urteilen scheinst du ein Schriftsteller zu sein.
Mit einem Generic koenntest du bei der Instanzierung die Anzahl 
'EndShiftTeiber' auf einer Zeile festlegen.

Von z.B.
1
InSbg_0           : in     STD_LOGIC;
2
InSbg_1           : in     STD_LOGIC;
3
InSbg_2           : in     STD_LOGIC;
4
InSbg_3           : in     STD_LOGIC;
nach
1
InSbg           : in     STD_LOGIC_VECTOR(3 downto 0);
oder gar
1
InSbg           : in     STD_LOGIC_VECTOR(TREIBER_INSTANZEN-1 downto 0);
brauchts nicht viel, der Rest des codes kann dann in etwa so aussehen
1
for index in 0 to TREIBER_INSTANZEN-1 loop
2
  if ShiftInBuf(index) = '1' THEN
3
    ShiftOut(index*2+1 downto index*2) <= "00";
4
  else
5
    -- rest in aehnlicher Form
6
  end if;
7
end loop;

Cheers, Roger

von Siegfried S. (dieleena)


Lesenswert?

Hallo,
Warnungen werden nicht mehr erzeugt.
die "asynchronen Resets per ChipRst" habe ich bewust gewählt,
da -> OutEnd_0R <= '0'; und  OutEnd_0L <= '0'; <- niemals gleichzeitig 
eine 1 haben dürfen.
Hier soll wenn die Strombegrenzung aktiv werden
ELSIF InSbg_0 = '1' or SbgBuf_0 = '1' then
OutEnd_0R <= '0';
OutEnd_0L <= '0';
beide Ausgänge eine '0' haben.

Aber, ich nehme gerne Rat und Hilfe an.
Bin gespannt, wenn dieses in der Harware einsetze wird, und warte bis 
ich auf die Nase falle.

Gruß Siegfried

von Tom (Gast)


Lesenswert?

hierzu zwei Fragen an die Experten Falk und Roger:

1.Wäre es nicht besser nur eine, entsprechend höhere Clock zu verwenden 
und dann die Signale OUTCLK und CHIPCLK nur als Enable Signale zu 
verwenden?

2. Auch sehe ich keinerlei "Einsynchroniesierung" von Eignagssignalen" 
Sollte man dies2 hier nicht besser über mindestens 2FF eintakten.

Gruß

Tom

von Falk B. (falk)


Lesenswert?

@ Tom (Gast)

>1.Wäre es nicht besser nur eine, entsprechend höhere Clock zu verwenden
>und dann die Signale OUTCLK und CHIPCLK nur als Enable Signale zu
>verwenden?

Jain. Kommt darauf an, wie das Ganze angeseuert wird. Über Chipclk 
werden ja die Ausgangssignale generiert. Über Outclk werden Steuerdaten 
in ein interenes Schieberegister geladen. Prinzipiell ist es natürlich 
besser, nur einen Takt mit mehreren Clock Enables zu verwenden, 
praktisch ist aber die hier verwednete Vorgehensweise oft anzutreffen, 
un bei geeigneter Ansteuerung auch OK (kein gleichzeitiges Takten von 
Outclk und ChipCLK).

>2. Auch sehe ich keinerlei "Einsynchroniesierung" von Eignagssignalen"
>Sollte man dies2 hier nicht besser über mindestens 2FF eintakten.

Naja, die Signale OutSerIn und OutStrobe sind sicherlich synchron zu 
OutClk, da muss nix einsynchronisiert werden. InSbg_0 ist ein 
asynchrones Reset, das ist dann so schon ok.

MfG
Falk

von Tom (Gast)


Lesenswert?

@Falk

vielen Dank für die Erläuterungen.

MfG
Tom

von Roger S. (edge)


Lesenswert?

@Tom

zu 1.
braucht's nicht unbedingt in diesem Design, wenn dass Erzeugnis von 
OUTCLK sauber in die CHIPCLK domain ruebergenommen wird (siehe Punkt 2).

zu 2.
fuer die shift register Gruppe brauchts halt ensprechende constraints 
und die muss das angeschlossene Device einhalten, spricht nichts dagegen 
das so zu Realisieren.
Bloss der OutStrobe im ChipClk kann side effects haben, da ist das 
eintakten von Vorteil.

Cheers, Roger

von Siegfried S. (dieleena)


Angehängte Dateien:

Lesenswert?

Hallo,
Habe es jetzt so gemacht.
Dieses wäre mir lieber gewesen.
>Wäre es nicht besser nur eine, entsprechend höhere Clock zu verwenden
>und dann die Signale OUTCLK und CHIPCLK nur als Enable Signale zu
>verwenden?
Aber, ich habe bedenken, das der ChipClk das Shiftregister durcheinander 
bringt. OutClk ist das Taktsignal von einem PIC ( 3-Wire SPI )
Gruß Siegfried

von Roger S. (edge)


Lesenswert?

Siegfried Saueressig wrote:

> Dieses wäre mir lieber gewesen.
>>Wäre es nicht besser nur eine, entsprechend höhere Clock zu verwenden
>>und dann die Signale OUTCLK und CHIPCLK nur als Enable Signale zu
>>verwenden?
> Aber, ich habe bedenken, das der ChipClk das Shiftregister durcheinander
> bringt.

Haette funktioniert, aber dann muessten die SPI Signale 
einsynchronisiert und auf OutClk eine Flankenerkennung angewendet 
werden.
Vermutlich kein Problem aber die fMax des Schieberegisters ist dann vom 
schnellen Clock (CHIPCLK?) abhaengig.

btw, wenn das alles ist, koenntest du dir mit dem jetztigen Design den 
CHIPCLK sowieso sparen.

Cheers, Roger

von Tom (Gast)


Lesenswert?

Tom wrote
>1.Wäre es nicht besser nur eine, entsprechend höhere Clock zu verwenden
>und dann die Signale OUTCLK und CHIPCLK nur als Enable Signale zu
>verwenden?


Falk antwortete:
>Jain. Kommt darauf an, wie das Ganze angeseuert wird. Über Chipclk
>werden ja die Ausgangssignale generiert. Über Outclk werden Steuerdaten
>in ein interenes Schieberegister geladen. Prinzipiell ist es natürlich
>besser, nur einen Takt mit mehreren Clock Enables zu verwenden,
>praktisch ist aber die hier verwednete Vorgehensweise oft anzutreffen,
>un bei geeigneter Ansteuerung auch OK (kein gleichzeitiges Takten von
>Outclk und ChipCLK).

Und genau zum Thema gleichzeitiges Takten von Outclk und ChipCLK nöchte 
ich nochmals nachhaken:
So wie Siefried sagte kommt Outclk vom SPI-Port eines Pic und ChipCLK 
ist
eine, wahrscheinlich unabhängige schnelle Taktquelle für den CPLD.
Damit würden aber irgenwann auch die Taktflanken zusammenfallen, da die 
beiden Quellen nicht synchron zueinander sind und es könnten Probleme 
auftreten.
Was meinen die Profis dazu?

MfG

Tom

von Falk B. (falk)


Lesenswert?

@ Tom (Gast)

>So wie Siefried sagte kommt Outclk vom SPI-Port eines Pic und ChipCLK
>ist eine, wahrscheinlich unabhängige schnelle Taktquelle für den CPLD.
>Damit würden aber irgenwann auch die Taktflanken zusammenfallen, da die
>beiden Quellen nicht synchron zueinander sind und es könnten Probleme
>auftreten.
>Was meinen die Profis dazu?

Das ist unschön bis schlecht. Denn damit kommt es während des Nachladens 
des Schieberegisters zu undefinierten und bisweilen gefährlichen 
Zuständen (Kurzschluss des Motortreibers etc.). Wenn man es sauber lösen 
will, dann muss ein Zwischenregister her, welches auf ein Triggersignal 
von OutCLK die Daten vom Schieberegister übernimmt. Das Zwischenregister 
ist dann mit ChipCLK getaktet. Das alles kostet dan aber wieder einige 
Makrozellen (Zwischenregister + 3 FlipFlops für Triggersignal).

MFG
Falk

von Tom (Gast)


Lesenswert?

Falk wrote
>Wenn man es sauber lösen
>will, dann muss ein Zwischenregister her, welches auf ein Triggersignal
>von OutCLK die Daten vom Schieberegister übernimmt. Das Zwischenregister
>ist dann mit ChipCLK getaktet. Das alles kostet dan aber wieder einige
>Makrozellen (Zwischenregister + 3 FlipFlops für Triggersignal).

Also das mit dem "Triggersignal" hab ich noch nicht verstanden, könntest 
du das bitte noch etwas näher erläutern?

Wegen der Problematik hatte ich ja vorgeschlagen nur den schnellen Takt 
zu nehmen, und den SPI einzusynchronisieren.

Gruß

Tom

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

@ Tom (Gast)

>Also das mit dem "Triggersignal" hab ich noch nicht verstanden, könntest
>du das bitte noch etwas näher erläutern?

Nun, wenn die SPI-Übertragung beendet ist wird meist das Chip Select 
Signal wieder auf HIGH gelegt. Mit dieser steigenden Flanke kann man ein 
FlipFlop togglen. dieses togglende FlipFlop wird mittels ChipCLK 
abgetastet und verzögert. Wenn nun das FlipFlop toggelt, dann sind die 
beiden Signale für einen Takt verschieden. Mittels XOR wird das erkannt 
und dient als Steursignal für das Zwischenregister. Siehe Anhang, ein 
Bild sagt mehr als tausend Worte. Die Skizze ist nicht 100% korrekt, ich 
hab auch die Schnelle kein 8 Bit Regitser mit Clock Enable gefunden. Das 
CLR am soll ein CE sein!

>Wegen der Problematik hatte ich ja vorgeschlagen nur den schnellen Takt
>zu nehmen, und den SPI einzusynchronisieren.

Kann man machen, würde ich aber hier nicht machen. Vor allem musst dann 
ChipCLK mindestens doppelt so schnell wie OUTCLK sein, besser vielmal so 
schnell oder mehr.

MFG
Falk

von Tom (Gast)


Lesenswert?

@Falk

wow danke, aber jetzt bin ich noch mehr verwundert.

Das CS vom SPI toggelt mit der steigenden Flanke das FF IC1A, soweit 
klar.
Nun ist genau dieses neue Taktsignal (Clock von IC1A) aber auch wieder 
nicht synchron zum Chipclock.
Ich dachte immer man sollte keine "Eigangssignale" als Taktsignale im 
CPLD/FPGA verwenden, da man sonst immer Probleme mit Glitches und Spikes 
und fehlerhften State Machines bekommen kann.

Oder geht das im obigen Fall deswegen "sicher", da da der Ausgang von 
IC1A nur an genau einer Stelle mit dem Chipclock benutzt wird, es also 
nicht zu fehlerhaften Daten führen kann?
Oder angenommen, es würden statt nur ein Toggle FF zB ein 4-Bit Counter 
mit "SPI_CE" getaktet und das Ergebnis mit Chipclock benutzt könnte dies 
doch durch die fehlende Synchronität zu Fehlern führen wenn die 4Bits 
des
Counters genau in dem Moment schalten, wenn Chipclock kommt.

Gruß

Tom

von Falk B. (falk)


Lesenswert?

@ Tom (Gast)

>wow danke, aber jetzt bin ich noch mehr verwundert.

;-)

>Das CS vom SPI toggelt mit der steigenden Flanke das FF IC1A, soweit
>klar.

>Nun ist genau dieses neue Taktsignal (Clock von IC1A) aber auch wieder
>nicht synchron zum Chipclock.

Ja.

>Ich dachte immer man sollte keine "Eigangssignale" als Taktsignale im
>CPLD/FPGA verwenden, da man sonst immer Probleme mit Glitches und Spikes
>und fehlerhften State Machines bekommen kann.

Das ist eine Ausnahme, welche die Regel bestätigt. ;-) Aber du hast 
soweit Recht, dass CS glitchfrei sein muss.

>Oder geht das im obigen Fall deswegen "sicher", da da der Ausgang von
>IC1A nur an genau einer Stelle mit dem Chipclock benutzt wird, es also
>nicht zu fehlerhaften Daten führen kann?

Genau. Und es ist nur ein einziges Bit was sich ändert, damit erwischt 
man entweder den alten Zustand oder den neuen.

>Oder angenommen, es würden statt nur ein Toggle FF zB ein 4-Bit Counter
>mit "SPI_CE" getaktet und das Ergebnis mit Chipclock benutzt könnte dies
>doch durch die fehlende Synchronität zu Fehlern führen wenn die 4Bits
>des
>Counters genau in dem Moment schalten, wenn Chipclock kommt.

Genau. Wenn der Zähler von 0111 auf 1000 weiterzählt, durch minimale 
Laufzeitunterschiede aber die ersten beiden Bits noch auf dem alten 
Stand erwischt werden, dann sieht deine Schaltung auf der CHIPCLK-Seite 
0100. Und das ist vollkommen falsch! Deshalb werden für solche Sachen in 
asynchronen FIFOs Gray-Code Zähler verwendet, dort ändert sich nur ein 
einziges Bit zwischen benachbarten Codes. Damit "haut" man maximal um 
einen Zählerstand daneben.

MfG
Falk

von Tom (Gast)


Lesenswert?

@Falk

vielen Dank, genau die Antworten, die ich "hören" wollte.
Es ist ein gutes Gefühl, wenn die Ansichten von einem Profi bestätigt 
werden.
Ich denke, nun habe ich auch die "Ausnahmen" verstanden und bin ein 
ganzes Stück weiter.

MfG

Tom

von Siegfried S. (dieleena)


Angehängte Dateien:

Lesenswert?

Hallo und guten Abend,

Habe das eine Projekt ohne Fehler- Warnmeldungen beendet.

Nun, habe ich ein anderes angefangen. Langsam bin ich am verzweifeln.
Habe folgende Möglichkeiten genutzt. Aktuelles Projekt geschlossen. 
Neues Projekt angelegt. Projekt kopiert und Code geändert. Wie ich es 
anfange, bekomme ich immer Warnmeldungen. Benutze die xst.pdf zur Info.

WARNING:Cpld:997 - Error during loading TIMESPEC AUTO_TS_F2F =
WARNING:Cpld:997 - Error during loading TIMESPEC AUTO_TS_P2F =

auf der Homepage existiert dieser Fehler nicht. (Cpld:997)

Dieses sind die ersten Code für ein 1Bit-Multiplexer.
Habe auch versucht, das ganze zu takten.

Was bzw. wo mache ich die Fehler? Liegt es an der Version? (8.2)?

Gruß Siegfried

von Siegfried S. (dieleena)


Lesenswert?

Hallo,

Habe an dem Projekt weiter gearbeitet und einen 1-of-8 Decoder 
hinzugefügt.

Kaum zu glauben, es ließ sich ohne Error- und Warnmeldungen compilieren.

Ist das Programm unter- überfordert ?

Gruß Siegfried

von Falk B. (falk)


Lesenswert?

@ Siegfried Saueressig (dieleena)

>WARNING:Cpld:997 - Error during loading TIMESPEC AUTO_TS_F2F =
>WARNING:Cpld:997 - Error during loading TIMESPEC AUTO_TS_P2F =

der Name AUTO_TS_F2F lässt vermuten, dass es sich um einem AUTOmatisch 
generierte Timingspzifikation handelt. Sieht nach einem Fehler/Feature 
von ISE aus.

MFG
Falk

von Siegfried S. (dieleena)


Lesenswert?

Hallo,
soll ich einmal eine neuere Version installieren ?
Gruß Siegfried

von Falk B. (falk)


Lesenswert?

@ Siegfried Saueressig (dieleena)

>soll ich einmal eine neuere Version installieren ?

Neee, ne ÄLTERE! Kein Witz! Nimm 6.3, die läuft gut und ist für deine 
Spielerein 100mal ausreichend.
MFG
Falk

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.