FPGA überprüfen?

[Norbert (Gast)]

Hallo,

ich hatte in einem anderen Posting ein Problem beschrieben, dass 
gentrennte Prozesse, die mit unterschiedlichen Clock-Frequenzen getaktet 
werden, Probleme machten bzw. das Ganze hat nicht funktioniert. Ich habe 
nun auch mal anstelle des DCM alternativ den Systemtakt vom Board und 
einen zweiten Takt, den ich mit einem digitalen Ringoszillator 
generiere, für diesen Code verwende.

Hier habe ich das selbe seltsame Resultat. Sobald mehrere Taktfrequenzen 
in irgendeiner beliebigen Form im Spiel sind, funktioniert nichts mehr. 
Das geht sogar soweit, dass ein VHDL Code, der einfach den Systemtakt 
herunterteilt und eine LED blinken läßt, plötzlich nicht mehr 
funktioniert wenn eine weitere Architektur ins Spiel kommt, auf der ein 
weiterer Takt generiert wird (z.B. mit dem Ringoszillator). Selbst dann, 
wenn diese zusätzliche Architektur logisch völlig getrennt und in sich 
gekapselt ist, d.h. keinerlei Verbindungen zur "Außenwelt" bestehen!!! 
Selbst das einfache Auskommentieren einer Zuweisung eines Signals zu 
einem Port mit einer LED verursacht seltsame Effekte, obwohl das Signal 
von allem Anderen getrennt ist.

Mittlerweile habe ich starke Bedenken, dass der FPGA auf meinem Board 
irgendwelche internen Defekte hat und nicht korrekt funktioniert. Das 
wäre die einzige logische Erklärung für die Probleme, die ich schon bei 
relativ einfachen Teststellungen erlebe. Es gibt zwar von Digilent 
Testroutinen für mein Board (Digilent Nexys3), aber diese überprüfen nur 
die Peripherie. Also ob z.B. alle LEDS und Schalter richtig 
funktionieren und ob Ein- und Ausgänge des FPGA keine Kurzschlüsse 
untereinander oder zur Masse hin haben. Desweiteren kann man die 
Speicherbausteine auf dem Board prüfen. Aber das alles sagt ja nichts 
über die 100%ige Funktionsfähigkeit des FPGA aus.

Gibt es eigentlich irgendwelche Testmöglichkeiten, um so einen FPGA 
(Spartan 6) komplett durchchecken zu können? Oder zumindest 
irgendwelche Teststellungen als VHDL Code, die eine relativ hohe 
Auslastung bzw. Ausnutzung der vorhandenen LUTS und der weiteren 
Logikblöcke erreichen um so eine Aussage über deren Zustand bzw. 
Funktionsfähigkeit zu erhalten?

Wenn der FPGA wirklich eine Macke haben sollte, würde ich das Board 
gerne beim Händler reklamieren. Dazu muß ich solch einen Defekt 
allerdings nachweisen können.

Vielen Dank für Eure Hilfe!

Beste Grüße,

Norbert

[Marius W. (mw1987)]

Teste doch einfach mal ein Beispiel-Design, das für dein Board gemacht 
worden ist. Sollte es beim Hersteller des Boards geben.

Gruß
Marius

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

Norbert schrieb:
> ich hatte in einem anderen Posting ein Problem beschrieben
Siehe den Beitrag "Anfänger hat Probleme mit parallelen Prozessen"

> Selbst dann, wenn diese zusätzliche Architektur logisch völlig getrennt
> und in sich gekapselt ist, d.h. keinerlei Verbindungen zur "Außenwelt"
> bestehen!!!
Dann sollte das ganze Zeug eigentlich einfach rausoptimiert werden...

Probiers doch einfach mal so: nimm Taster als Taktquelle und lass damit 
eine LED toggeln. Klar prellen die Taster, aber man erkennt wenigstens, 
ob sich überhaupt was tut...

signal led0 := '0';
signal led1 := '0';
:
:

   led0 <= not led0 when rising_edge(taster0);
   led1 <= not led1 when rising_edge(taster1);
   :

[Arthur Artig (Gast)]

Schau doch mal in den Place&route resp Map report für ein 
funkrtionierendes und für  ein nichtfunktionierendes design. Gut 
möglich, das durch einen schaltfehler (reset permanent Aktiv) alles 
wegoptimiert wird und  daher der FPGA nix tut.




Zitat:
Hier habe ich das selbe seltsame Resultat. Sobald mehrere Taktfrequenzen
in irgendeiner beliebigen Form im Spiel sind, funktioniert nichts mehr.
Das geht sogar soweit, dass ein VHDL Code, der einfach den Systemtakt
herunterteilt und eine LED blinken läßt, plötzlich nicht mehr
funktioniert wenn eine weitere Architektur ins Spiel kommt, auf der ein
weiterer Takt generiert wird (z.B. mit dem Ringoszillator). Selbst dann,
wenn diese zusätzliche Architektur logisch völlig getrennt und in sich
gekapselt ist, d.h. keinerlei Verbindungen zur "Außenwelt" bestehen!!!
Selbst das einfache Auskommentieren einer Zuweisung eines Signals zu
einem Port mit einer LED verursacht seltsame Effekte, obwohl das Signal
von allem Anderen getrennt ist.

[Norbert (Gast)]

Hallo Lothar,

ehrlich gesagt, ich glaube, ich habe heute einen schlechten Tag.

Ich verwende folgende Source

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity test is
  port(
    Btn1:in std_logic;
    Led1:out std_logic
      );
end test;

architecture Behavioral of test is

signal sig1 : std_logic := '0';

begin
  process begin
     wait until(Btn1'event and Btn1='1');
        if(Btn1 = '1') then
           sig1 <= not sig1;
        end if;
  end process;
  Led1 <= sig1;
  
end Behavioral;

und folgende UCF Definition

NET "Btn1"         LOC = "B8"  | IOSTANDARD = "LVCMOS33";
NET "Led1"         LOC = "U16" | IOSTANDARD = "LVCMOS33";

Der Synthesizer läuft ohne Warnungen und Fehler durch und bei Place & 
Route kommt dann folgende Fehlermeldung:

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been 
found that are not placed at an optimal clock IOB / BUFGMUX site pair. 
The clock IOB component <Btn1> is placed at site <B8>. The corresponding 
BUFG component
<Btn1_IBUF_BUFG> is placed at site <BUFGMUX_X2Y3>. There is only a 
select set of IOBs that can use the fast path to the Clocker buffer, and 
they are not being used. You may want to analyze why this problem exists 
and correct it.
If this sub optimal condition is acceptable for this design, you may use 
the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this 
message to a WARNING and allow your design to continue. However, the use 
of this override is highly discouraged as it may lead to very poor 
timing results. It is recommended that this error condition be corrected 
in the design. A list of all the COMP.PINs used in this clock placement 
rule is listed below. These ERROR:Pack:1654 - The timing-driven 
placement phase encountered an error.


Sicherlich mag ISE es nicht, wenn man ihm einen Taster als Systemtakt 
verkaufen möchte. Ich würde ja noch weitere Prozesse mit Buttons und 
LEDs einbauen aber zunächst muß das hier mal gelöst werden.

Habe ich irgendwo ein Komma oder einen Punkt vergessen? Durch sowas 
sollen ja schon Weltraumraketen abgestürzt sein ;-)

Beste Grüße,

Norbert

[Norbert (Gast)]

Lothar Miller schrieb:
> led0 <= not led0 when rising_edge(taster0);

Das konnte ich übrigens so nicht übernehmen weil es nicht dem VHDL93 
Standard entspricht.

[Schlumpf (Gast)]

> Sicherlich mag ISE es nicht, wenn man ihm einen Taster als Systemtakt
> verkaufen möchte. Ich würde ja noch weitere Prozesse mit Buttons und
> LEDs einbauen aber zunächst muß das hier mal gelöst werden.

Woher soll denn die ISE wissen, was da außen am FPGA angeklemmt ist?


> Habe ich irgendwo ein Komma oder einen Punkt vergessen? Durch sowas
> sollen ja schon Weltraumraketen abgestürzt sein ;-)

Nein, was du falsch gemacht hast, steht in dem sehr ausführlichen 
Report, den du selbst gepostet hast.
Du hast den Takt auf einen Eingang gemapped, der nicht als Takteingang 
geeignet ist. Es geht zwar trotzdem, aber, mal laienhaft ausgedrückt, 
nicht so gut. Was dagegen zu unternehmen ist, steht auch gleich noch 
dabei.

Vielleicht überlegst du dir ja nochmal, ob es doch zielführend sein 
kann, Reports zu lesen, auch wenn du in deinem anderen Thread da anderer 
Meinung warst.

[Norbert (Gast)]

>Woher soll denn die ISE wissen, was da außen am FPGA angeklemmt ist?

Du hast selbst weiter unten die Antwort auf diese Frage gegeben. 
Irgendwie hats schon bemerkt, dass es kein Takteingang ist.


>> Habe ich irgendwo ein Komma oder einen Punkt vergessen? Durch sowas
>> sollen ja schon Weltraumraketen abgestürzt sein ;-)

>Nein, was du falsch gemacht hast, steht in dem sehr ausführlichen
>Report, den du selbst gepostet hast.

Ok, das war jetzt eine ironische Bemerkung. Leider gibts keinen 
entsprechenden Tag um sowas entsprechend zu kennzeichnen.


>Du hast den Takt auf einen Eingang gemapped, der nicht als Takteingang
>geeignet ist. Es geht zwar trotzdem, aber, mal laienhaft ausgedrückt,
>nicht so gut. Was dagegen zu unternehmen ist, steht auch gleich noch
>dabei.

Ja, indem man einen CLOCK_DEDICATED_ROUTE Constraint in die UCF-Datei 
einfügt. Ich hab das schon gelesen. Aber da ich nicht genau weiß, was 
das ist und was es bewirkt, habe ich es nicht getan. Wie bereits 
erwähnt, ich beschäftige mich gerade mal einen Monat mit dem Thema. Da 
kann man noch nicht alles wissen.


>Vielleicht überlegst du dir ja nochmal, ob es doch zielführend sein
>kann, Reports zu lesen, auch wenn du in deinem anderen Thread da anderer
>Meinung warst.

Jawohl Chef ;-)
Mach ich!

[berndl (Gast)]

Norbert schrieb:
> Ja, indem man einen CLOCK_DEDICATED_ROUTE Constraint in die UCF-Datei
> einfügt. Ich hab das schon gelesen. Aber da ich nicht genau weiß, was
> das ist und was es bewirkt, habe ich es nicht getan.

Naja, das solltest du aber mal machen... Ein CLOCK Tree ist etwas 
fundamental anderes als Logikverdrahtung. Guck mal in die Datenblaetter 
deines FPGA und staune, wenn das so eine 'H-Struktur' ueber das ganze 
Chip gelegt wird. Das musst du halt entweder wissen oder auch 
(schmerzhaft) lernen...

[Schlumpf (Gast)]

Norbert schrieb:
>>Woher soll denn die ISE wissen, was da außen am FPGA angeklemmt ist?
>
> Du hast selbst weiter unten die Antwort auf diese Frage gegeben.
> Irgendwie hats schon bemerkt, dass es kein Takteingang ist.

Leider falsch. "Takt" meint nicht, dass es ein intermettierendes, 
wiederkehrendes Signal sein muss, sondern Takt meint, dass dieser Pin 
auf einen dedizierten Clock-Tree geroutet werden kann, der dann wiederum 
auf den CLK-Eingang der Register führt.
Daher habe ich die Frage nicht, wie du sagst, weiter unten selbst 
beantwortet, sondern du hast nicht verstanden, was damit gemeint ist.

TAKT bedeutet lediglich, dass das an diesem Port anstehende Signal zum 
Takten der internen Register genutzt wird. Und das hat sie Synthese auch 
richtig erkannt und dich darauf hingewiesen, dass der Port, den du dafür 
verwendest eher ungeeeignet ist und du deswegen damit rechnen musst, 
dass es eventuell zu Problemen führen kann.
Was die Synthese aber nicht weiss und was ihr auch vollkommen egal ist, 
ist die Tatsache, ob du den Takt mit einem Oszillator oder einem ollen 
Lichtschalter machst..

Norbert schrieb:
> Ja, indem man einen CLOCK_DEDICATED_ROUTE Constraint in die UCF-Datei
> einfügt.

Auch falsch. Damit beseitigst du nicht das Problem, sondern sagst des 
Synthese lediglich, dass du weisst, dass es zu einem Problem führen 
kann, es dir aber vollkommen hupe ist und sie dich nicht weiter damit 
nerven soll.. Lese doch einfach den Report zuende.
Was hilft ist, den Eingang auf einen Port zu routen, der mit dem 
Clocktree verbunden werden kann. Welche das sind, das verrät dir das 
Datenblatt

Norbert schrieb:
> Jawohl Chef ;-)
> Mach ich!

Ne, nicht Chef, aber ich begreife ganz ehrlich nicht, warum du hier um 
Hilfe schreist, aber dann denjenigen, die dich um weiterführende 
Inforamtioen bitten, diese vorenthältst. Stattdessen machst du wilde 
weitere Exprimente und veruchst, das Problem empirisch irgendwie 
einzukreisen. Ich bin da eher der Fan von einer strukturierten 
Vorgehensweise. Aber gut, jeder hat da einen anderen Stil.

[Norbert (Gast)]

berndl schrieb:
> Naja, das solltest du aber mal machen... Ein CLOCK Tree ist etwas
> fundamental anderes als Logikverdrahtung. Guck mal in die Datenblaetter
> deines FPGA und staune, wenn das so eine 'H-Struktur' ueber das ganze
> Chip gelegt wird. Das musst du halt entweder wissen oder auch
> (schmerzhaft) lernen...

Da gibts so ein schönes Trainigsvideo auf der Xilinx Website, wo ein 
netter Herr eine geschlagene dreiviertel Stunde über dieses Thema 
(Spartan6 Clocking Ressources) referiert. Da geht es ziemlich ins 
Eingemachte und ich kann mir ungefähr vorstellen, was Du mir damit sagen 
willst. Ist wohl eine Wissenschaft für sich.

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

@Norbert: setz einfach den Constraint und sei dir bewusst, dass die 
Taktverteilung dann ungünstig ist, für einen Test aber trotzdem reicht.

Und sieh dir mal deinen Code an und beantworte dir die Frage, warum und 
ob da zweimal auf btn='1' abgefragt werden muss...

[Sanfredo (Gast)]

Man kann im Allgemeinen von einem Pin über einen BUFG gehen und von dort 
in das Taktnetz. Das ist auch das, was Xilinx baut, wenn man das 
dedicate route constraint von oben verwendet. Man hat dann nur ein 
skew-Problem und weniger Taktreserve für high speed Anwendungen sowie 
leider etwas mehr Jitter.

Zur Prüfung eines FPGA einfach alle Ausgänge an eine lange Registerkette 
legen und per Timer durchzählen. Dann hat man wenigstens mal die 
Ausgänge und die Ladefunktion gecheckt.

[Norbert (Gast)]

Lothar Miller schrieb:
> @Norbert: setz einfach den Constraint und sei dir bewusst, dass die
> Taktverteilung dann ungünstig ist, für einen Test aber trotzdem reicht.
>
> Und sieh dir mal deinen Code an und beantworte dir die Frage, warum und
> ob da zweimal auf btn='1' abgefragt werden muss...

Hallo Lothar,

das mit der zweiten Abfrage ist natürlich Unsinn. Ich habs mal so 
gemacht.

Leider funktioniert es nicht. Bestimmt wieder ein Fehler.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Blinkled is
  port(
      Btn1:in std_logic;
      Led1:out std_logic
      );
end Blinkled;

architecture Behavioral of Blinkled is
signal sig1 : std_logic := '0';

begin
   process begin
    wait until(Btn1'event and Btn1='1');
    sig1 <= not sig1;
  end process;
  Led1 <= sig1;
end Behavioral;

UCF-Datei:

NET "btn1"         LOC = "B8"  | IOSTANDARD = "LVCMOS33";
NET "btn1"         CLOCK_DEDICATED_ROUTE = TRUE;
NET "Led1"         LOC = "U16" | IOSTANDARD = "LVCMOS33";

[Tschaebe (Gast)]

Da wäre jetzt ein FALSE besser ;=)
Aus meinem .ucf zum Nexys*2*

# Digilent says: "Xilinx WebPACK version 10+ needs this."
# I'd say: Use clock pins for clocks and you would not get this message 
NET "U_IFCLK"      CLOCK_DEDICATED_ROUTE = FALSE;

Grüße,
Tschaebe

[Omega (Gast)]

1) mich würde mal noch interessieren, was du mit "Ringoszillator" 
gemeint, bzw. realisiert hast?

2) Hast du Timing Constraints angegeben? Gerade bei "blos" eine Led 
Blinken lassen steckt dahinter ein Zähler, dass eine etwas längere carry 
chain nach sich ziehen kann. Timing kann hier kritisch sein. Ohne Timing 
Constrains zwingst du die Synthese nicht in seine Schranken!

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

Norbert schrieb:
> Leider funktioniert es nicht.
Was ist "es"?
Simulation?
Synthese?
Hardware?

[Norbert (Gast)]

Lothar Miller schrieb:
> Was ist "es"?

Naja, in der PAD-Datei steht bei den constraints überall unlocated. Ich 
weiß auch nicht genau, wie dieser CLOCK_DEDICATED_ROUTE Eintrag in der 
UCF-Datei aussehen muß. Ist das evtl so richtig?

NET "<Pin-Name>"      CLOCK_DEDICATED_ROUTE = FALSE;

Wo kann ich nachschauen um die Ursachen dieser unlocated Fehler zu 
finden?

Danke für die Hinweise.

Gruß, Norbert

[Christian R. (supachris)]

Poste doch mal bitte endlich mal die Report Dateien.

Synthesis Report *.syr
Mapping Report *.mrp
Place and Route Report *.par

Und die pad.txt Datei zum Vergleich. Dann muss man nicht so rätseln.

[Norbert (Gast)]

Christian R. schrieb:
> Poste doch mal bitte endlich mal die Report Dateien.

Sorry, ich wußte nicht welche von den vielen Dateien relevant sind.

Hier sind sie.

[berndl (Gast)]

Norbert schrieb:
>> Naja, das solltest du aber mal machen... Ein CLOCK Tree ist etwas
>> fundamental anderes als Logikverdrahtung. Guck mal in die Datenblaetter
>> deines FPGA und staune, wenn das so eine 'H-Struktur' ueber das ganze
>> Chip gelegt wird. Das musst du halt entweder wissen oder auch
>> (schmerzhaft) lernen...
>
> Da gibts so ein schönes Trainigsvideo auf der Xilinx Website, wo ein
> netter Herr eine geschlagene dreiviertel Stunde über dieses Thema
> (Spartan6 Clocking Ressources) referiert. Da geht es ziemlich ins
> Eingemachte und ich kann mir ungefähr vorstellen, was Du mir damit sagen
> willst. Ist wohl eine Wissenschaft für sich.

also ueberleg mal: Idealerweise bekommen alle FFs in deinem FPGA den 
gleichen Takt, z.B. 10ns. Gefuettert wird der D-Eingang des FFs mit 
irgendwelcher Logik, die halt 'Laufzeit' braucht. Was willst du also 
haben: Alle FFs sehen den Takt zur gleichen Zeit. Dafuer ist der 
sogenannte Clock-Tree da. Und nur damit kann die Toolchain auch 
berechnen, ob deine fliegende Logik, die in den D-Eingang will, das 
Timing schafft.

Wenn du jetzt ueber 'normale' Logikverdrahtung den Takt an ein oder 
(noch schlimmer) mehrere FFs bringst, dann kannst du dieses 
Zeitverhalten nicht mehr oder nur noch schwer vorhersagen, du hast also 
einfach am FF mehr Jitter.

Einfach im Datenblatt mal die Anordnung des Clock-Tree und auch die 
Anordnung der sog. 'routing resources' anschauen.

[Christian R. (supachris)]

Hm, entweder ist die UCF Datei falsch, oder nicht korrekt ins Design 
eingebunden. Bis auf die Pin-Zuweisung sieht alles soweit korrekt aus. 
Poste mal bitte noch die bld Datei und die UCF Datei. Da scheint was 
nicht zusammen zu passen. Wird die UCF Datei im Projekt Navigator ganz 
unten angezeigt?

[Norbert (Gast)]

Christian R. schrieb:
> Hm, entweder ist die UCF Datei falsch, oder nicht korrekt ins Design
> eingebunden. Bis auf die Pin-Zuweisung sieht alles soweit korrekt aus.
> Poste mal bitte noch die bld Datei und die UCF Datei. Da scheint was
> nicht zusammen zu passen. Wird die UCF Datei im Projekt Navigator ganz
> unten angezeigt?

Hallo Christian,

vielen Dank für den Hinweis. Die UCF-Datei war nicht richtig 
eingebunden. Da hatte ich irgendwie was falsch gemacht. Ich habe die 
UCF-Datei rausgeworfen und nochmal eine neue erstellt. Sie lag im 
Projekt Navigator nicht unterhalb des Top Level Objekts, sondern auf der 
selben Ebene. Jetzt sind alle Pins in der PAD-Datei als LOCATED markiert 
und das Ganze läuft wie erwartet. Wegen der CLOCK_DEDICATED_ROUTE 
Direktive bekomme ich Warnungen aber ich denke mal, dass die so ok sind.

Dass die Buttons so ab und zu prellen weil hier keine Entprellung 
vorliegt ist auch klar, das wurde ja schon erwähnt. Aber es 
funktioniert.

Vielen Dank für die Unterstützung! Erst muß man mal mit den kleinen 
Sachen zurecht kommen um überhaupt ein Gefühl für die ganze Sache zu 
erhalten.

Alleine hier habe ich schon viel gelernt. Z.B. welche Dateien es gibt, 
die wichtige Diagnoseinformationen über den Vorgang enthalten und wo man 
mal hineinschauen sollte, wenn etwas nicht wie erwartet funktioniert.

Beste Grüße,

Norbert

[Christian R. (supachris)]

Na prima, wenn es jetzt klappt. Das mit der ucf Datei ist manchmal 
seltsam, ich hatte auch schon oft, dass die nicht als zum Projekt 
gehörend drin war. Weiß der (Xilinx-)Geier wieso. Du wirst noch auf sehr 
viele Merkwürdigkeiten bei ISE und Co stoßen. Die kriegen das bis heute 
z.B. nicht auf die Reihe, Packages in der Projektübersicht anzuzeigen. 
Aber damit lernt man leben ;)