Verständnisproblem Xilinx XC9572 CPLD

[C. L. (calle)]

Hallo Kollegen,

Ich benötige mal Hilfe zum Thema I/O - Pins vom XC9572.
Momentan werde ich aus dem Ganzen noch nicht richtig schlau!
Das Datenblatt zeigt 4 Funktionsblöcke mit á 18 Macrozellen.
Die Pin´s sind mit I/O beschriftet. Soll ja 36V18 sein -??????

Was sind denn nun Eingänge und was sind Ausgänge oder was für Pins 
eignen sich besonders für welchen Anwendungsfall?
Zusätzlich stolpere ich im WEB noch über Eagle-layouts,
wo FB1 als IN und FB2 als OUT definiert sind.
Weiterhin rausgefunden, das man am besten vor einer Layoutentwicklung 
darüber im klaren sein muss, wie der Baustein I/O mäßig angeschlossen 
wird.
Das kann aber das Layout unnötig verkomplizieren m.M. nach.
Ist das nicht egal, kann man doch mit Software richtigstellen, oder?

Auch gelesen: "immer einen I/O Pin frei lassen pro FB".   ???

Wenn ich als Test z.B. 3 Eingänge verunde auf 1 Ausgang, compiliere, 
dann erhalte ich in ISE Webpack 7.1 alles grüne Haken und das ganze 
läuft ohne Fehler auf dem Baustein.
Nehme ich einen dieser Eingänge und definiere ihn als Ausgang
(schliesse ich natürlich auch so an ;-)) erhalte ich ein gelbes 
Rufzeichen, mit dem Hinweis "check syntax", auf dem Baustein läuft es 
aber trotzdem.

Kann mir da mal jemand etwas helfen? - Blick da nicht durch.

Gruß Carsten.

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

C. L. schrieb:
> Weiterhin rausgefunden, das man am besten vor einer Layoutentwicklung
> darüber im klaren sein muss, wie der Baustein I/O mäßig angeschlossen
> wird.
Macht Sinn, denn nicht jeder Pin hat jede Funktion.

> Das kann aber das Layout unnötig verkomplizieren m.M. nach.
> Ist das nicht egal, kann man doch mit Software richtigstellen, oder?
Sieh dir den Plan vom IC an: nicht jeder Pin ist gleichwertig.

> Auch gelesen: "immer einen I/O Pin frei lassen pro FB".   ???
Quellenangabe?

> Wenn ich als Test z.B. 3 Eingänge verunde auf 1 Ausgang, compiliere,
> dann erhalte ich in ISE Webpack 7.1 alles grüne Haken und das ganze
> läuft ohne Fehler auf dem Baustein.
Gut.
> Nehme ich einen dieser Eingänge und definiere ihn als Ausgang
> (schliesse ich natürlich auch so an ;-)) erhalte ich ein gelbes
> Rufzeichen, mit dem Hinweis "check syntax", auf dem Baustein läuft es
> aber trotzdem.
Bei unverändertem Code? Wie sieht der denn überhaupt aus? Wer macht das 
Fragezeichen? Der Synthesizer oder der Fitter?

> Zusätzlich stolpere ich im WEB noch über Eagle-layouts,
> wo FB1 als IN und FB2 als OUT definiert sind.
Ich finde im Datenblatt keinen FB1 und FB2...
http://www.xilinx.com/support/documentation/data_sheets/ds065.pdf

[Duke Scarring (Gast)]

C. L. schrieb:
> Die Pin´s sind mit I/O beschriftet.
>
> Was sind denn nun Eingänge und was sind Ausgänge
Du kannst die Pins entweder als Eingang oder als Ausgang verwenden. 
Deswegen I/O.
Außerdem kannst Du mit einem dritten Signal (OE) die Datenrichtung 
umschalten (für z.B. I2C).

C. L. schrieb:
> Weiterhin rausgefunden, das man am besten vor einer Layoutentwicklung
> darüber im klaren sein muss, wie der Baustein I/O mäßig angeschlossen
> wird.
Ja.

> Das kann aber das Layout unnötig verkomplizieren m.M. nach.
Ja.

> Ist das nicht egal, kann man doch mit Software richtigstellen, oder?
Jein. Solange wie Dein Design den Chip nicht übermäßig füllt, kann der 
Synthesizer Deine Pinwünsche berücksichtigen. Aber ein CPLD hat (im 
Vergleich zum FPGA) relativ unflexible Routingressourcen. Wenn Dein 
Design größer wird, kann es sein, das noch Funktionsblöcke oder 
Produktterme frei sind, aber durch das beschränkte interne Routing nicht 
genutzt werden können.

C. L. schrieb:
> Nehme ich einen dieser Eingänge und definiere ihn als Ausgang
> (schliesse ich natürlich auch so an ;-)) erhalte ich ein gelbes
> Rufzeichen, mit dem Hinweis "check syntax", auf dem Baustein läuft es
> aber trotzdem.
Dann wird wohl was an der Syntax sein. Um das genauer zu beurteilen 
müßtest Du etwas mehr von Deinem Testprojekt zeigen (Quelltext, 
Screenshots).

Duke

P.S.: Schau Dir mal lieber die XL-Variante an (XC9572XL). Die ist vom 
Stromverbrauch erträglicher.

[C. L. (calle)]

Hey Ihr!

ok.

Danke erstmal für die Antworten!

@Lothar

> Nehme ich einen dieser Eingänge und definiere ihn als Ausgang
> (schliesse ich natürlich auch so an ;-)) erhalte ich ein gelbes
> Rufzeichen, mit dem Hinweis "check syntax", auf dem Baustein läuft es
> aber trotzdem.
Bei unverändertem Code? Wie sieht der denn überhaupt aus? Wer macht das
Fragezeichen? Der Synthesizer oder der Fitter?

==>> Der Code/Declaration ist natürlich entsprechend der Funktion 
verändert!
Im Datenblatt auf Seite 6 stehen doch die Pinouts.
Da sind 4 Funktionsblöcke beschrieben.
Ich poste nachher mal die Schaltung mit den entsprechenden Pins und dem 
Code.
Dann sehen wir, welches Modul da nochmal meckert.


@Duke

OE Signal ist ja interessant. Könnte auch nochmal ein Thema werden.
Einsatzort ist später ein Adressdecoder und zum anderen kleine Steuerung 
für u.ä. Schrittkettenablauf/Bitmusteranwendung. Momentan ist das eher 
eine Lernphase.
XL Variante habe ich nicht genommen, da Leistungkein Problem darstellt.

Ich sitze nachher wieder davor, dann kann ich alles weitere posten wie 
Code Screenshots usw.

Danke

Carsten

[C. L. (calle)]

Hallo!

Leider Leider!  Ich kann das von gestern nicht mehr reproduzieren. Das 
gelbe Rufzeichen kommt nicht mehr. Die Screenshots sind alle "grün 
abgehakt" und es läuft auch auf dem Zielsystem.

Der Baustein verhält sich so wie erwartet. Die verwendeten Pins sind als 
IN oder OUT zu nutzen.

Trozdem habe ich bei näherem hinsehen ein gelbes Fragezeichen entdeckt!
Wenn ich dann doppelklicke auf Check Syntax, dann ist alles wieder grün.

Ist das so richtig?

Kann ich jetzt doch alle IOs beliebig nutzen?

Gruß CL

[Falk B. (falk)]

@  C. L. (calle)

>Kann ich jetzt doch alle IOs beliebig nutzen?

Fast. Jede Marozelle kann Ein- oder Ausgang sein, oder beides 
gleichzeitig (Bustranceiver). Es gibt ein paar Spezialeingänge, die man 
für Takte und Resets nutzen sollte, weil hier die globalen Takt- und 
Resetnetze angeschlossen sind.

MFG
Falk

[C. L. (calle)]

Ja!

Takt und Reset usw. sind dann die Pinne GCK2,3,4 und GSR.
JTAG und Spannungsversorgung ist auch klar.

Dann haben wir es doch schon fast!

Heisst das dann, alle Pins, die keine Sonderfunktion besitzen, sind 
konfigurierbar als IN oder OUT?

mfG

CL

[Falk B. (falk)]

@  C. L. (calle)

>Heisst das dann, alle Pins, die keine Sonderfunktion besitzen, sind
>konfigurierbar als IN oder OUT?

Ja.

[C. L. (calle)]

Hey Falk!

Du hast in einem anderen Beitrag gesagt, das die ISE Engine das Pinning 
selbst vornehmen kann. Und von "Pins gelockt" war da auch was.

Kannst Du da nochmal was zu sagen? Ich nutze ISE V7.1
Würde gerne das ein bischen besser kennenlernen!

CL

[Falk B. (falk)]

@  C. L. (calle)

>Du hast in einem anderen Beitrag gesagt, das die ISE Engine das Pinning
>selbst vornehmen kann.

Sicher, einfach keinerlei Vorgaben machen.

> Und von "Pins gelockt" war da auch was.

Man kann das Pinning festlegen, meistens im UCF (User Constrainst File). 
Gibt irgendwo auch einen Befehl, die automatisch verteilten Pins nund 
festzulegen, weiß ich aber jetzt nicht wo der zu finden ist. Irgendwas 
mit Lock Pinning oder so.

MfG
Falk

[C. L. (calle)]

Supi

Habe das gerade mal ausprobiert mit der Pinvergabe!
Im Report steht dann alles genau drin.

Wird langsam klarer das Teil. Als nächstes werde ich mich mit CLK 
beschäftigen und eine Ampel oder Schrittkette oder so machen.
Just for fun ....

CL

[Duke Scarring (Gast)]

C. L. schrieb:
> Der Baustein verhält sich so wie erwartet. Die verwendeten Pins sind als
> IN oder OUT zu nutzen.
Schön :-)

Ich würde Dir noch empfehlen was Moderneres (VHDL oder Verilog) als Abel 
zu verwenden.

Duke

[C. L. (calle)]

Hallo!

Die ISE bietet doch auch VHDL oder Verilog an. Ich glaube bei der 
Projekteröffnung da was gelesen zu haben. Muss ich mich nochmal schlau 
machen!
Habe zum Test mal mit der Planlogik (Gattertechnik) programmiert.
Ist für mich neu das Thema VHDL oder Verilog.

C + Assembler + SCL usw. kein Problem.

Hast Du das was schnelles verfügbar zum einsteigen?
(dann muß ich das Rad nicht neu erfinden)

Sonst google ich mal.

Gruß

CL

[Duke Scarring (Gast)]

C. L. schrieb:
> Hast Du das was schnelles verfügbar zum einsteigen?
> (dann muß ich das Rad nicht neu erfinden)
Nicht direkt.

Es gibt ein paar Bücher, siehe hier:
Beitrag "Suche VHDL Buch"

Wobei ich bei Reichardt & Schwarz: "VHDL-Synthese" viele Dinge im 
Kapitel 10.1 (VHDL-Codierungsempfehlungen) sehr anders sehe.

Es kann auch nicht schaden, sich ein paar (praxisbezogene) Tutorials 
anzuschauen. Den prinzipiellen Workflow kannst Du ja schon.

Duke

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

Duke Scarring schrieb:
> Wobei ich bei Reichardt & Schwarz: "VHDL-Synthese" viele Dinge im
> Kapitel 10.1 (VHDL-Codierungsempfehlungen) sehr anders sehe.
Welche Ausgabe hast du denn da? Brauche ich mal ein Upgrade?
Bei mir ist mit Kapitel 9 Ende...   :-o

Mal bei Amazon nachgeschaut, und richtig:
die Regeln 2, 3, 8, 12, 14 sehe ich auch ganz anders.

Zu 2: Nimm std_logic, unsigned, signed und integer.
Die ganzen Geschwindigkeitsargumente bei der Simulation zählen bei 
heutigen Rechnern nicht nennenswert.

Zu 3 (und zu 4 Reset): Lies das WP272 und den XST-Users-Guide von 
Xilinx. Ähnliche Dokumente gibt es auch von den anderen Herstellen.

Zu 5: verwende rising_edge() und falling_edge() statt 'event

Zu 8: nimm die Ein-Prozess-Schreibweise. Und auf gar keinen Fall 
symbolische Verzögerungszeiten in synthesefähigem Code!

Bei 14 müsste es heißen: Vergiss die alten Synopsys-Libs und nimm 
numeric_std für Berechnungen.

Bei 12 ist es noch schlimmer:  da hilft das Nichtplatzieren eines 
Signals in der Sensitivliste (also das Ignorieren von Regel 9) nur zum 
Verhindern einer kombinatorischen Schleife im Simulator, in der 
Hardware wird sie trotzdem eingebaut!

[Duke Scarring (Gast)]

Lothar Miller schrieb:
> die Regeln 2, 3, 8, 12, 14 sehe ich auch ganz anders.
Das sollte man mal versuchen, mit den Autoren zu diskutieren.
So lernen die Studenten nur schlechtes Deuts...^W VHDL.

Duke