CPLD in-Clock Problem

[phanaton (Gast)]

Hallo,

Ich bin derzeit an meinen ersten Gehversuchen mit VHDL und CPLDs.

Ich versuche derzeit einen Led-Counter zu implementieren(in einen Xilinx 
XC9572XL).
Nur leider scheint hier etwas nicht ganz so zu funktionieren wie es 
sollte...

Derzeit generiere ich einen Takt über einen Hardware-entprellten 
Taster(http://www.mikrocontroller.net/articles/Entprellung)

Die Leds, welche durch den Takt langsam hochzählen sollten, schalten 
lediglich hin und her bei jedem Takt, was am Anfang in etwa so aussieht:

0000
Takt
0110
Takt
0000
Takt
0110
...

Ich habe testweise mal den Takt komplett entfernt, so, dass der 
Takteingang  hochohnmig ist, und, dann ändert sich tatsächlich etwas(was 
ich mir beim allerbestem Willen nicht erklären kann...), nämlich 
leuchten die Leds erstmal willkürlich in irgendeiner Reihenfolge 
auf(aber konstant, also kein blinken...), sei es 1100.
Wenn ich dann den Takt wieder hinzufüge, dann invertieren sich die Leds 
wie folgend z.B.:
1100
Takt
0011
Takt
1100
...

Folgend kommt der VHDL-Code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE . STD_LOGIC_ARITH .ALL;
use IEEE . STD_LOGIC_UNSIGNED . ALL;

entity Test is
    Port ( LED : out  STD_LOGIC_VECTOR (3 downto 0);
           GCLK : in  STD_LOGIC;
           SWITCH : in  STD_LOGIC);
end Test;

architecture Behavioral of Test is

signal counter : STD_LOGIC_VECTOR (3 downto 0)
:= ( others => '0');

begin

process ( GCLK )
  begin
    if rising_edge ( GCLK ) then
      counter <= counter + 1;
    end if;
  end process ;

LED <= counter;

end Behavioral;

Simuliert funktioniert alles wie es soll(über ISIM...)

Übrigens habe ich schon die Leds einfach mal konstant als Ausgang 
definiert(Beispiel 0101) und das gibt auch keine Probleme bzw tut genau 
das was es soll...

Das ganze läuft übrigens über ein selbst gebasteltes(geätztes) Board, 
welches aber  an den wichtegen Stellen keine Fehler aufweist(alles nach 
nachgemessen etc...)

[Freddy (Gast)]

Und dein Taster ist auch wirklich entprellt? Hast dir das mal aufm Scope 
angeschaut?

Ansonsten sieht dein Code ziemlich richtig aus. Wobei du mal versuchen 
solltest, einen Reset in deinen Prozess einzubauen, sodass du für den 
counter einen definierten Anfangswert hast.

[Simon K. (simon)]

Tja, das geht so nicht. Du musst zwischen dem entprellten Taster und dem 
CPLD einen Schmitt-Trigger bauen.
Da der XC9572XL keine Schmitt-Trigger Eingänge hat, benötigt er 
Rise/Fall Times an seinen Eingängen von weniger als 100ns (? Den genauen 
Wert weiß ich nicht). Das schaffst du mit deinem künstlich langsam 
gemachten Taster niemals.

[Freddy (Gast)]

Simon K. schrieb:
> Tja, das geht so nicht. Du musst zwischen dem entprellten Taster und dem
> CPLD einen Schmitt-Trigger bauen.
> Da der XC9572XL keine Schmitt-Trigger Eingänge hat, benötigt er
> Rise/Fall Times an seinen Eingängen von weniger als 100ns (? Den genauen
> Wert weiß ich nicht). Das schaffst du mit deinem künstlich langsam
> gemachten Taster niemals.

Also der der 74HC14d aus dem Entprellungs-Tutorial hat maximal 75ns 
output transition time.

[Simon K. (simon)]

Ja, ein solcher CMOS-kompatibler Logikchip ist dafür gut geeignet. Hast 
du so einen verbaut? Du hast leider keinen Schaltplan angehangen.

[Freddy (Gast)]

Ich hab gar nichts verbaut :)

[Simon K. (simon)]

EDIT: Oh, habe ich dich mit dem TO verwechselt :-)

[phanaton (Gast)]

Ich glaub ich war gemeint ;).

Ja ich hab den genau so aufgebaut,
Das Teil(Taster) ist aus einer Schaltung für einen AVR gewesen, dort hat 
es auch keine Probleme gegeben.

Ich hatte vergessen noch zu erwähnen, dass ich auch einen Quarzosilator 
mit 16 MHz angeschlossen hatte - das gleiche  Problem(nur nicht mehr 
sichtbar). Ich hab das mal mit dem einzigen Messgerät, dass ich besitze 
durchgemessen(Multimeter mit Frequenzzähler) an allen Outputs eine 
Frequenz von 16/2 = 8 Mhz, was auch ziemlich genau mit dem 
Tasterübereinstimmt.

Mittlerweile bin ich am überlegen, ob der Programmer irgendeinen Mist 
baut(was aber nicht unbedingt mit dem ersten Test mit der Konstante am 
Output übereinstimmt).

Hättet ihr noch eine Idee/Ideen wie ich testen könnte, ob irgendwas in 
der Kette nicht stimmt?

Gruß Philipp

[phanaton (Gast)]

Edit:

Der Programmer ist ein USBProg mit xsvf-Player.

[phanaton (Gast)]

Hier noch mal das Schaltbild, was ich aber extra nicht angehangen habe, 
weil noch ein paar Komponenten fehlen(was aber nicht die Funktion 
beeinträchtigen sollte).
Aufgebaut vom Schaltplan ist die Energie-Versorgung(LP2985, mit 
Hühnerfutter),
sämtliche Entkopplungskondensatoren, und natürlich Program-Port und 
CPLD(es wurde der xc9536 im Schaltbild genommen weil ich zu faul war 
extra noch ein Bauteil für den XC9572 zu erstellen der, ja mehr oder 
weniger Pin-kompatibel ist...).
Die Taktgeneratoren(NE555 und Quarzosillator mit dem entsprechendem 
Hühnerfutter) muss ich noch bestellen.
Derzeit nehme ich halt noch die manuelle Variante mit dem Taster und 
einem anderem Quarzosillatoren...

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

In diesem Schaltplan ist kein entprellter Raster, wie ein 300MHz CPLD 
ihn brauchen würde...

[phanaton (Gast)]

Wie ich schon schrieb, benutze ich derzeit einen Taster der von einem 
anderem Projekt stammt, welcher (hier sieht man auch warum ich den 
Schaltplan eigentlich nicht veröffentlichen wollte, da er für mehr 
Verwirrung sorgt als für Klarheit)
Jedenfalls, liegt es glaub ich auch nicht an der Taktquelle, da ich ja 
auch schon das Ganze mit dem Quarzoszillator getestet habe(siehe weiter 
oben), und dort(vermute ich jedenfalls, mangels weiterer Messgeräte) das 
Gleiche rauskam.
Ist der Schaltplan denn(wenn man vom Taster absieht) sonst in Ordnung?

Gruß Philipp

[Sebastian Hepp (Gast)]

Es fehlen die ganzen Stützkondensatoren

[phanaton (Gast)]

Wenn du 100nf parallel zu VCC und GND meinst, und das möglichst nahe am 
IC dann habe ich die eingebaut, sind aber doch im Schaltplan vorhanden, 
oder meinst du noch andere Kondensatoren - Werte?

[phanaton (Gast)]

Ich hab jetzt noch mal ein komplett neues Projekt in ISE erstellt, die 
Leds an andere Pins geschlossen und die Polung umgedreht(low-active), 
auch den Taster, bzw. den Clock hab ich an verschiedenen Pins getestet.
Leider hat alles nichts geholfen, es ist jetzt sogar so, dass die 
Eingänge gar nicht mehr funktionieren.
Ich bin mir lediglich soweit relativ sicher, dass in der Programmierung 
des CPLDs nichts schiefläuft, da der Output der Leds immer genau dem 
entspricht, was passieren würde wenn der Takt nicht stattfindet(also das 
initialisierte)

Kann es sein das die Eingangstreiber(falls solche bei dem CPLD 
existieren) kaputt sind, oder irgendwas mit den Eingängen nicht stimmt?
Ausgänge gehen ja alle soweit ich das getestet habe...
Oder hab ich vielleicht etwas übersehen, dass zwingend notwendig ist, 
damit die Eingänge funktionieren?

Gruß Philipp

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

Ich würde einfach mal vorschlagen, dass du systematisch vorgehst:
mach es mal so, dass du einfach einen Tastereingang auf ein paar LEDs 
ausgibst:

 led <= "0101" when taster = '1' else "1010";

Dann siehst du schon mal, ob ein Eingang überhaupt das tut was du 
willst.

Und dann nimm einen vernünfitgen und stabilen Takt und probier das 
nochmal mit dem Zähler. Das ist ja schließlich keine Raketentechnik, was 
du da gerade machst...

Und: man rechnet nicht mit std_logic_vector, sondern nimmt 
eingeschränkte Vektoren vom Typ signed, unsigned oder gleich einen 
integer. Und das alles zusammen mit dem Komplettpaket in der 
numeric_std. Siehe dazu auch den 
Beitrag "Re: IEEE.STD_LOGIC_ARITH.ALL obsolete"

Und dann wirst du bald sehen: CPLDs sind KLEIN. Mit den 36 oder 72 
Flipflops machst du keine großen Sprünge. Steig dann besser bald mal auf 
ein FPGA um. So ein EVAL-Board mit Programmer gibts für um die 80 
Euronen...

[phanaton (Gast)]

Hallo,

Danke schon mal für den Tipp.
Leider hat es nicht geholfen, bzw. das Ganze wird immer komischer oder 
vielleicht auch klarer(Eingänge sind kaputt...).
Mit deinem Codeschnipsel leuchtet komischerweise gar nichts mehr auf. 
daraufhin hab ich noch mal einfach eine Konstante( LED <= "0101"; ) 
probiert, und das klappt nach wie vor...
Kann ich davon ausgehen, dass das CPLD kaputt ist, und ich es 
gegebenenfalls austauschen muss?

Ein FPGA-Board werde ich mir demnächst zulegen(habe ich schon länger im 
Sinn), jedoch hatte ich irgendwann mal CPLDs mitbestellt, die ich jetzt 
endlich mal verbauen wollte, um mich an VHDL zu versuchen.
Eigentlich wollte ich in naher Zukunft, daraus einen Adress-decoder, und 
andere "glue-logic" bauen, um dieses dann über einen Mikroprozessor, 
bzw. dessen Bus anzusteuern.

[Ralf R. (rrascher)]

phanaton schrieb:
> Mit deinem Codeschnipsel leuchtet komischerweise gar nichts mehr auf.
> daraufhin hab ich noch mal einfach eine Konstante( LED <= "0101"; )
> probiert, und das klappt nach wie vor...
> Kann ich davon ausgehen, dass das CPLD kaputt ist, und ich es
> gegebenenfalls austauschen muss?

Wenn du den Codeschnipsel richtig gemacht hast, muss etwas leuchten.

  led <= "0101" when taster = '1' else "1010";

Hier steht ja dort, das entweder die zweite und vierte LED,
oder bei gedruecktem Taster die erste und dritte LED
leuchten soll.

Zeig doch mal deinen vollstaendigen Code von Lothars
Beispiel. Ich glaube nicht das der Eingang kaputt ist.

Ralf

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

Ralf R. schrieb:
> Zeig doch mal deinen vollstaendigen Code von Lothars Beispiel.
Und die UCF-Datei dazu...

[phanaton (Gast)]

Hallo,

Ich hänge jetzt einfach mal das komplette ISE Project an.
Für die die noch einen schnellen Überblick haben wollen:

Inhalt von Test.vhd(Kommentierungen aus Platzgründen entfernt):

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE . STD_LOGIC_ARITH .ALL;
use IEEE . STD_LOGIC_UNSIGNED . ALL;

entity Test is
    Port ( LED : out  STD_LOGIC_VECTOR (3 downto 0);
           GCLK : in  STD_LOGIC;
           SWITCH : in  STD_LOGIC);
end Test;

architecture Behavioral of Test is

signal counter : STD_LOGIC_VECTOR (3 downto 0) := "0010";

begin

LED <= "0101" when SWITCH = '1' else "1010";

end Behavioral;

Inhalt von Test.ucf:

#PACE: Start of Constraints generated by PACE

#PACE: Start of PACE I/O Pin Assignments
NET "GCLK"  LOC = "P30"  ;
NET "LED<0>"  LOC = "P33"  ; 
NET "LED<1>"  LOC = "P32"  ; 
NET "LED<2>"  LOC = "P31"  ; 
NET "LED<3>"  LOC = "P29"  ;
NET "SWITCH"  LOC = "P28"  ;

#PACE: Start of PACE Area Constraints

#PACE: Start of PACE Prohibit Constraints

#PACE: End of Constraints generated by PACE

Übrigens vielen Dank, dass wenigstens ihr noch Hoffnung im CPLD habt :).

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

Und wie sieht denn jetzt die Beschaltung vom P28 aus?
Kommen da sicher richtige High- und Low-Pegel an?

[Duke Scarring (Gast)]

phanaton schrieb:
> use IEEE . STD_LOGIC_ARITH .ALL;
> use IEEE . STD_LOGIC_UNSIGNED . ALL;

Diese Bibliotheken sind: Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

Außerdem wird bei Dir momentan gar nix gerechnet. Ich empfehle Dir 
dringend die Dinger rauszunehmen. Wenn Du wirklich rechnen musst, dann 
mit der

use ieee.numeric_std.all;

und dort mit den richtigen Datentypen (unsigned, signed).

Duke

[phanaton (Gast)]

Ich hab's endlich geschafft!!

Also es war doch die Programmierung vom Device.

Ich hab den usbprog xsvf-Player unter Windows kompiliert, hab allerdings 
dort statt "arpa/inet.h", "Winsock2.h" eingebunden(weil manche 
Funktionen fehlten, und gesagt wurde, das Winsock2.h gleichwertig ist)
Stutzig machte mich die ganze Zeit schon die Ausgabe von dem Programm, 
welches nach 26% aufhörte und "Done" ausgab.
Ich hab mir dabei allerdings erstmal nichts weiter gedacht(was für ein 
Fehler...).
Jetzt hab ich das Ganze noch mal unter meiner Ubuntu-Installation 
kompiliert, so wie es auch in der Anleitung steht(ich frage mich 
allerdings warum dort eine Linux-Distri vorausgesetzt wird...)
Dann funktionierte die Programmierung perfekt, lief durch bis 100% und 
das Beispielprogramm macht jetzt auch endlich das, was es machen soll...

@Duke Scarring
Danke für den Tipp.
Die ganzen Sachen sind noch von den alten Beispielen(counter...) 
eingebunden gewesen. Aber das sollte auch nicht weiter schlimm sein, da 
ich denke das der ganze Kram ohne weiteres wegoptimiert wird oder?

Gruß und Dank

Philipp

[Simon K. (simon)]

Regel Nummer 1: Benutze immer Entwicklungstools des Herstellers oder 
Tools, die von den Herstellern zertifiziert sind. Besonders, wenn du neu 
an der Sache bist.

Das hab ich nach vielen AVR Bastelprogrammern gemerkt und mir beim CPLD 
Einstieg direkt einen digilent USB-Cable geholt.

[phanaton (Gast)]

Ja, dem geb ich dir mehr oder weniger (vor allem nach dieser Sache) 
Recht.
Aber als armer(mittlerweile mehr oder weniger ehemaliger) Schüler kann 
man sich nicht immer alles so schnell leisten, auch wenn es vernünftig 
wäre in die Sache zu investieren, und da ich eben gerade den usbProg 
übrig hatte von meinen ganzen Avr-Projekten, und es sogar extra ein 
Xilinx-spezifisches Aufspielprogramm gibt, liegt es doch Nahe erst mal 
dieses auszuprobieren.

Naja man lernt draus...
Demnächst kommt sowieso ein vernünftiges FPGA-Evalboard ins Haus, mit 
Programmer integriert etc. dann habe ich hoffentlich andere Probleme wo 
man die Lösung eben durch vernünftige Denkarbeit(VHDL etc.) finden 
kann...

Gruß
Philipp

[Simon K. (simon)]

Ich kenne die Problematik. Bin auch von zuhause ausgezogener Student ;-) 
Oft gibt es aber für Studenten Sonderkonditionen. z.B. für die Digilent 
Hardware bei Trenz-Elektronik. Und ein AVR ISP mkII gibt es bei eproo 
für die Hälfte.