Ich arbeite seit Kurzem mit der 14.1 / 14.2 und habe einige seltsame Effekte. Relatv einfache und überschaubare designs / module scheinen nicht richtig zu arbeiten - je nach Syntheseeinstellung, wie mir scheint. In einem Fall geht es u.a um die Ergebnisse, die ich im ChipScope habe: 1) Eine state machine, die linear durchläuft, bedient in jedem state eine Anzahl von Signalen. In einem Fall werden z.B. 3 Signale geändert. Im Chip Scope ändern sich aber nur 2 davon und eines erst einen state später, in dem das nicht programmiert wurde. In einem anderen Fall scheint die FSM nicht korrekt erzeugt zu werden: 2) Eine ebenfalls weitgehend linear laufende FSM bedient je nach Notwendigkeit SRAM-Steuersignale WE, OE, CS sowie DAT + ADR. In einigen states, in denen die Ausgaben verarbeitet werden, wird auf den Eingang gehört. Die zuvor in einem vorheirgen state eingestellten Signale WE und OE werden nicht angetastet, sondern nur die Reaktion auf dem Bus beobachtet. Das Verhalten zeigt, dass OE nicht mehr gesetzt war (Datenbus geht weg = floatet) obwohl es noch anstehen hätte müssen. Das Problem konnte nur behoben werden, indem in jedem state alle Signale ausdrücklich gesetzt werden - auch die, die vom state vorher noch unverändert sein sollen. In einem dritten Fall geht es um RAMS: 3) Durch das Beschreiben eines Videopuffers (im FPGA rein mit BRAMs) kommt es bei manchen Synthesen zu offensichtlichen Fehlern. Die Darstellung stimmt nicht, es kommen bei manchen Zeilen Punktversatzeffekt zu Vorschein, die darauf schliessen lassen, dass Werte einen Takt zu spät eingeschrieben werden. Die Videoseite und Einschreibeseite sind getrennte Domains die laut report kein Timingproblem haben. In diesem Fall könnte es auch mit der Hardware zu tun haben: Es geht im Spartan6, die bekanntlich ein INIT-RAM Problem haben und wohl auch im 9Bit-Mode unzuverlässig arbeiten. Frage: Hat jemand ähnliche Probleme beobachtet- was ISE oder Spartan 6 angeht? Speziell bei dem Videodesign bin ich zu 100% sicher, dass es kein Designfehler ist, weil ich es in änhlicher Weise immer mal wieder in Chips einsetze und solche Fehler definitiv nicht hatte. Bei den state machine Effekten ist es so, dass diese nur in der Praxis beobachtbar sind. Die Simulationen funktioneren - sogar die post-PAR-Sim! Die state machines verlaufen sich nicht und die Signale werden zeitrichtig gesetzt. Zudem kann ich die states im realen Design ansehen und verfolgen, dass sie linear fortschreiten. Mein Erklärungsansatz: Ich benutze sowohl register retiming, als auch register duplicating. Daher sind die Signale, die ich in ChipScope sehe, bzw die, die ich in der FSM sehe, nicht zwangsläufig identisch zu ihren automatisch erzeugten Kopien, die an anderer Stelle im Design benutzt werden. Speziell beim retiming könnte es der Synthese / dem Implementierungs-Algo aufgrund von SW-Fehlern passieren, dass sie auf falsche Signale aus falschen Zeitebenen zugreift, um diese anzuzapfen oder zu vereinfachen. Kann da jemand was zu sagen? An den Constraints kann es eigentlich nicht liegen, da die Effekte duruchaus bei unveränderten Constraints auftauchen.
Hallo J.S., ich habe ähnliche Erkenntnisse mit Chipscope gemacht, dass Signale manchmal nicht gesetzt werden. Ich habe aber so um die 500 Datenpunkte (Bits), die ich in CS anzeigen will. Das was mich stutzig macht ist, dass ich ohne CS nach der Implemetierung im Report einen Max.Frequenz von ca. 118 MHz bekomme und mit CS nur 70 MHz. (Design wird abgebremmst????) In meinem Design arbeite ich mit 100MHz und 200MHz, habe einen 100 MHz Quarz, womit ich über eine DCM die 200 erzeuge. Timing-Constraints sind bei mir richtig gesetzt und werden auch eingehalten. Doch trotzdem funktioniert mein Design ab und zu sporadisch nicht richtig, habe auch mehrere FSM´s drin, beschreibe auch zyklisch einen DDR2 in meinem Design. Hat jemand dafür eine Lösung? PS: Target ist der ML507 von Xilinx mit dem Virtex 5 ISE Version ist bei mir zur Zeit die 14.1. Gruß Cihan
>Das was mich stutzig macht ist, dass ich ohne CS nach der Implemetierung >im Report einen Max.Frequenz von ca. 118 MHz bekomme und mit CS nur 70 >MHz. (Design wird abgebremmst????) Das ist durchaus üblich, da die Chipscope-Logik Teil des Logik-Pfades wird. Ich mache das immer so, dass ich Register, die ich mir anschauen möchte, nochmals registriere und mir diese ins CS reinziehe. Das entspannt in jedem Fall das Timing.
1 | signal design_register : std_logic; |
2 | signal CS_design_register : std_logic; -- das schaue ich mir in CS an |
3 | |
4 | Pipeline_fuer_Chipscope: process(clk) |
5 | begin
|
6 | if rising_edge(clk) then |
7 | CS_design_register <= design_register; |
8 | end if; |
9 | end process; |
Wenn man diese Zusatzregistrierung vornimmt, dann sollte man das für alle zu betrachtenden Register tun, sonst wird es bei der Bewertung von Abläufen schwierig ;-) Vg, SuperWilly
>An den Constraints kann es eigentlich nicht liegen, da die Effekte >duruchaus bei unveränderten Constraints auftauchen. Naja, vielleicht fehlen dir noch ein paar Constraints. Bist du dir sicher, dass du nicht asynchrone Signal-Abfragen übersiehst? Ob das dann gut geht oder nicht, hängt dann von der Platzierung ab, und somit auch von der ISE-Version...
Interessant! mir ist es passiert, dass eine Schaltung unter 14.1 gar nicht lief, daher habe ich von der Benutzung der Version abgesehen. Leider ist es aber nun so, dass ich aufgrund der mangelnden IP Unterstützung auf die neue Version werde wechseln müssen. Ich bin gerade dabei die 14.2 zu installieren.
Selbi schrieb: > Interessant! mir ist es passiert, dass eine Schaltung unter 14.1 gar > nicht lief, daher habe ich von der Benutzung der Version abgesehen. > Leider ist es aber nun so, dass ich aufgrund der mangelnden IP > Unterstützung auf die neue Version werde wechseln müssen. Ich bin gerade > dabei die 14.2 zu installieren. Und wie siehts aus mit der neuen Version, ist die besser? Ich habe zur Zeit mit der 14.1 Version unter Chipscope mächtig Probleme eine Analyse zu machen. Mal funktioniert mein Design, mal nicht, mal habe ich sporadisch Fehler drin, so kann man nicht arbeiten. Ist evtl. in der 14.2 Version Chipscope zuverlässiger oder hat sicht evtl. bei Chipscope garnichts geändert? Hat jemand einen besseren Ansatz, Lösungsweg oder Vorschlag um mit Chipscope zu arbeiten. Habe zur Zeit um die 44 Signale zur Betrachtung in Chipscope drin. Evtl. schon zu viel?!?. Cihan
Ich mach das immer so, dass ich mir vom Core-Gen den ILA und den ICON als Core erzeugen lasse und dann direkt instanziiere. Das geht bisher zuverlässig. Aber das Design wird langsamer, auch weil die im Core gated clocks und solche Schweinerein benutzen. Aber Fehler produzieren hab ich damit bisher noch nicht hinbekommen, höchstens dass ein schon so ziemlich volles Design dann nicht mehr geroutet werden kann.
Christian R. schrieb: > Ich mach das immer so, dass ich mir vom Core-Gen den ILA und den ICON > als Core erzeugen lasse und dann direkt instanziiere. Das geht bisher > zuverlässig. Aber das Design wird langsamer, auch weil die im Core gated > clocks und solche Schweinerein benutzen. Aber Fehler produzieren hab ich > damit bisher noch nicht hinbekommen, höchstens dass ein schon so > ziemlich volles Design dann nicht mehr geroutet werden kann. Wie erzeugts du die Core denn, mit dem CoreGen? Ich hatte auch schon mal sowas benutzt, so eine fertige Core dafür, hatte aber wenig Trigger und Daten Input. Deswegen hatte ich mir immer eine Chipscope File unter ISE erstellt und anschließend die Signale ausgewählt und nach der Implementierung mit Chipscope Pro betrachtet. Cihan
Ja mit dem Core Generaor. Die Anzahl der Trigger und Dateneingänge ist doch dort frei wählbar. Ich guck da öfters 2 interne 32 Bit Busse samt der Steuerleitungen an. Kein Problem. Du musst einen ICON Core erstellen, der verbindet den JTAG Anschluss mit dem ILA Core, welcher der Logic Analyzer ist.
Ich habe warscheinlich den Fehler bei mir gefunden, warum Chipscope nicht gut funktionierte. Im UG029 für Chipscope steht unter Seite 58 unter "Useful Project Navigator Settings" das man die Keep-Hierarchy auf Yes oder Soft stellen soll. Im Anschluss daran sah ich, dass ich nun ganz andere Signale im Core Inserter vom Chipscope wählen kann. Nun habe ich auch mehr Signale drin und funktioniert bis jetzt erstmal gut. Werde berichten falls es wieder zu Fehlern kommt. Cihan
J. S. schrieb: > In einem anderen Fall scheint die FSM nicht korrekt erzeugt zu werden: Die Steuersignale für die FSM hast Du aber auch alle ordentlich einsynchronisiert, oder? Duke
Ja, dass habe ich natürlich versucht immer zu berücksichtigen. Ich habe beispielsweise noch eine DDR2 Core drin, indem ich ebend einen DDR2 beschreibe. An Anfang wo ich die Signale nicht einsynchronisiert hatte, hatte ich Bitfehler zwischen meinen Daten. Nun stimmen sie, also gehe davon aus, dass ich auf dem richtigem Weg bin. Cihan
Cihan Kalayci schrieb: > Ich habe warscheinlich den Fehler bei mir gefunden, warum Chipscope > nicht gut funktionierte. > > Im UG029 für Chipscope steht unter Seite 58 unter "Useful Project > Navigator Settings" das man die Keep-Hierarchy auf Yes oder Soft stellen > soll. Das ist eher eine funktionelle Fehlbedienung, bzw ein Manko der Xilinx chain. Auch wenn ChipsCope die Signale fordert und sie dadurch ja über JTAG ausgegeben werden, kriegt das die Synthese nicht mit und optimiert es weg. Das ist also ziemlich bekannt und erklärlich. Unerklärlich dagegen ist, dass Xilinx öfters mal was an internen Strukturen ändert - währscheinlich, um einie alte Zöpfe loszuwerden. U.U. hat es auch mit Vivado zu tun, ja. Im Zuge dessen funktionieren immer mal wieder interne Dinge nicht, die eigentlich vorher schon liefen. Im Bezug auf Chipsscope gab es in den 13er Versionen dauern Problem mit dem Platz. Mehr als 2048 Zellen konnten nicht erzeugt werden, egal wie kleine sie waren und wie viel Platz noch im chip hätte sein können. J. S. schrieb: > In diesem Fall könnte es auch mit der Hardware zu tun haben: Es geht im > Spartan6, die bekanntlich ein INIT-RAM Problem haben und wohl auch im > 9Bit-Mode unzuverlässig arbeiten. Es könnte sein, dass es da Probleme mit dem Reset gibt und dem Clear. Denn diese Mechanismen sind intern dafür verantwortlich, dass Zellen vorgeladen werden (können). Soweit ich es überschaue, nutzt Xilinx keinen asynchronen Reset, sondern lädt immer synchron. Kann sein, dass dabei was nicht funktioniert. Altera braut das bekanntlich ech asynchron und es gibt zwei Möglichkeiten das RAM zu resetten und auch zwei Fehlerquellen. Gerade bei Altera gab es da öfters mal work arounds, die in fabric logic realsiert wurden, um dual port funktion möglich zu machen. Ich kann mir sehr gut vorstellen, dass Xlinx da ähnlich vorgeht, freilich ohne es zu verkünden und mit neueren ISE-Versionen da "Verbesserungen" zu erwarten sind. Benutzt Du ein asynch clear? oder ein synch clear? U.U. bringt es etwas darauf zu verzichten oder Du benutzt kein DP-Funktion.
Bei mir trifft er plötzlich keine Constraints mehr, nachdem es bereits locker ging. Beitrag "Re: XILINX ISE erzeugt plötzlich nichtfunktionierendes Bitfiles" Erreicht wurde das Phänomen mit ISE 14,2
Duke Scarring schrieb: >> In einem anderen Fall scheint die FSM nicht korrekt erzeugt zu werden: > Die Steuersignale für die FSM hast Du aber auch alle ordentlich > einsynchronisiert, oder? Schlimmer, sie kommen aus derselben state machine derselben domain. Das ist der Witz. Stachele schrieb: > Naja, vielleicht fehlen dir noch ein paar Constraints. Theoretisch ja, aber ich sehe momentan nicht, wo. > Bist du dir > sicher, dass du nicht asynchrone Signal-Abfragen übersiehst? Sehr sicher! Links und rechts vom DPRAM ist alles total synchron und zudem habe ich das Thema synchrones design und Eintakten sowas von durch, dass ich Vorträge dazu halte. Einige Probleme sind inzwischen durch work around gelöst, auch scheint die ISE 14.2 einiges zu bügeln. Ich kann es aus Zeitgründen nicht alles querchecken, aber das seltame "state machine Statusverschleppungsproblem" ist weg. Da hatte wohl das ChipsScope eine Macke. Nach wie vor habe ich die Spartan6 BRAMs in Verdacht, dass da was Seltsames passiert. Gfs hat es mit dem R/W auf gleichen Adressen zu tun, was in meinem Design unvermeidbar passiert und passieren muss. Die RAMs scheinen da - gfs infolge Synthesoptimierung oder- fehler irgendwie transparent zu sein oder aber es werden Daten nicht richtig rausgetaktet. Ich werde da aber dran bleiben.
Die BRAMs im S6 haben einige Macken, vor allem die Initialisierung im 8/9 Bit Modus. und dann musst du genau aufpassen wie du die beschreibst, wegen read/write first, das steht im XST user guide für den S6.
Ich hatte auch so ein ungeklärtes Phänomen, was in die Ecke passt. Es war eine State-Maschine die unter bestimmten Ereignissen in die entsprechenden Zustände sprang. Die Ereignisse wurden durch ein Flipflop synchron gehalten. Leider sprang die Statemachine nicht immer richtig aber eben manchmal schon. Ich hatte das Gefühl, das unter Umständen ein Signal zu spät kam, obwohl ich ein synchrones Design hatte. Die Sprungadressen kamen aus einem interen RAM. Ich habe es übern den Haufen geschnissen und noch mal neu geschrieben mit Vectoren als Sprungadressen und dann lief die Sache. Leider waren die beiden Sachen nicht mehr vergleichbar, dass ich es eindeutig herausgefunden habe.
René D. schrieb: > Ich hatte das Gefühl, das unter Umständen ein Signal zu spät kam, obwohl > ich ein synchrones Design hatte. Die Sprungadressen kamen aus einem > interen RAM. Konntest Du es an der Version der ISE festmachen? Welcher Chip war es, der betroffen war? Bei mir ist es der Spartan6, der spukt. Ein Phänomän ist, dass ich beim S6-BRAM die zusätlzichen Register am Ausgang weglassen kann oder hinzufügen, ich bekomme trotzdem irgendwie dasselbe Verzögerungsverhalten. Simulation und Realität laufen dann auseinander.
Spartanist schrieb: > Bei mir ist es der Spartan6, der spukt. Ein Phänomän ist, dass ich beim > S6-BRAM BRAM8 oder BRAM16?
1 | INFO:Bitgen:341 - This design is using one or more 9K Block RAMs (RAMB8BWER). |
2 | 9K Block RAM initialization data, both user defined and default, requires a |
3 | special bit stream format. For more information, please reference Xilinx |
4 | Answer Record 39999. |
Duke
Spartanist schrieb: > René D. schrieb: > Konntest Du es an der Version der ISE festmachen? > Welcher Chip war es, der betroffen war? Spartan6 passt auch. Es war das Entwicklungsboard SP601 und als ISE version muss es eine höhere 13.x gewesen sein. Es war vergangenes Jahr und da hatte ich keine 14 Version.
Kanst du eine Post-Place & Route-Simulation im ISE durchführen?
Ich glaube nicht, dass eine PAR Simulation hier weiter hilft, denn der Fehler muss sich nicht zwangskäufig dort abbilden. Ich hatte anderseits schon PAR-Simus, die ausfielen, während Logik-Sim und Realität funktionierten.
Leider habe ich das Thema erst jetzt gefunden. Ich hatte Anfang des Jahres auch einen solchen Effekt, dass eine state machine nicht richtig funktionierte und habe versucht, es mitchipscope zu untersuchen. Unerklärlicherweise führte die Schaltung komplett unsinnige Sprünge aus, die sich aufgrund der Signalsituation nicht hätte ergeben dürfen. Ob es am Chipscope lag, also dass die hinzutretenden Schaltungselemente dafür etwas ändern oder es nur falsch angezeigt wurde, war nicht herauszubekommen, da sich der Ablauf von Aussen nicht verfizieren liess. Es war nur zu beobachten, dass die Ausgänge, die von der FSM abhingen, nicht richtig zu funktionieren schienen - obwohl es in der Simulation gleichwohl korrekt arbeitete. Inzwischen bin ich an einem anderen Problem dran: Beitrag "ChipScope geht in 14.4 nicht"
Ich denke, dass es an ChipScope lag, bzw daran, was die Synthes diesbezüglich einbaut. Wie ich oben geschrieben habe, sind o.g. Probleme aller Wahrscheinlichkeit nach ein Phantomfehler gewesen. Der rale Ablauf im Design dürfte gestimmt haben, wenngleich ich das nicht 100% verifizieren konnte. Das Problem trat jetzt bei den neueren Version ab 14.4 nicht mehr auf - wenigstens hatte ich da in jüngster Zeit keine Probleme wahrnehmen können. Inzwischen ziehe ich mir wichtige Zustände in einen eigenen Sampler und zeige es extern an. Da weiss man, was man hat. Wegen Deiner ChipsScopefrage 14.4 antworte ich im anderen thread.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.