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
Das heißt, das bei dem jeweiligen Vorgang Warnungen aufgetreten sind. Diese kannst du in den verschiedenen Reports nachlesen.
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
Hallo, was bedeutet diese Meldung? WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 = bis WARNING:Cpld:310 - Cannot apply TIMESPEC TS1007 = Gruß Siegfried
Was steht in Deinem Constraints File (xxx.ucf)? Da scheint Unsinn drinnen zu stehen.
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
@ 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
"Module Name: PIC-Fahrendstufe-Shift-Treiber - Behavioral" also warum Synthese, oder ist das 'Behavioral' ein Copy-Paste Überbleibsel?
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
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
@ 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
Hallo, Habe es geändert. Was kann ich noch besser machen? Gruß Siegfried
@ 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
> 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
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
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
@ 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
@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
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
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
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
@ 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
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
@ 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
@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
@ 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
@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
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
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
@ 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
Hallo, soll ich einmal eine neuere Version installieren ? Gruß Siegfried
@ 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.