Xilinx Spartan 6 BUFGP Buffer

*mir einen BUFGP synthetisiert fehlt da oben im Satz... wie auch 
immer...

Gilles schrieb:
> Kann man das automatische Buffern für
> einen einzlenen Pin per Attribut oder so deaktivieren? Ich würde lieber
> ein IBUF oder IBUFG nehmen...

Laut XST User Guide, kannst Du Dir so helfen:

1

Declare as follows:

2

attribute buffer_type: string;

3

Specify as follows:

4

attribute buffer_type of signal_name: signal is "

5

{bufgdll|ibufg|bufgp|ibuf|bufr|none}";

Im UG616 auf Seite 72 findest Du übrigens Deinen BUFGP.

Duke

hey danke duke!
wo füge ich das ein das attribut?
direkt in der entity unter dem pin um den es geht?
danke dir!
Gilles

dieses verkackte xilinx ise!!! er synthetisiert einfach trotzdem 
immernoch en bufgp obwohl ich per attribut ibuf einstellt habe... 
wahnsinn!

Gilles schrieb:
> er synthetisiert einfach trotzdem
> immernoch en bufgp obwohl ich per attribut ibuf einstellt habe
Vermutlich liegt Dein Problem an einer anderen Stelle.
Läuft denn Dein Design im Simulator richtig?

Duke

jaja im simulator läuft es post-route schon länger, es gibt nur eine 
kleine sache die im code eignetlich so nicht emhr nötig wäre udn es 
eventuell noch performanter machen würde... muss halt nicht sein aber 
wäre cool... und wenn ich das dann also vereinfache, dann kommt auf 
einmal eine lawine aus so unerklärlichen fehlern... mal allgemein 
gefragt.. bin ich der einzige, der bei der xilinx ise öfter mal auf 
probleme stößt, bzw. sachen die man sich erstmal nicht erklären kann...?

Gilles schrieb:
> eignetlich so nicht emhr nötig wäre udn es
> eventuell noch performanter machen würde... muss halt nicht sein aber
> wäre cool... und wenn ich das dann also vereinfache, dann kommt auf
> einmal eine lawine aus so unerklärlichen fehlern... mal allgemein
> gefragt.. bin ic...

Man sieht dem Beitrag an, wie sehr dich die Sache nervt. Aber um bei dem 
Problem weiter zu kommen, solltest du wieder etwas ruhiger werden.

Laut meiner Version des Libraries Guide 
(http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/spartan6_hdl.pdf) 
ist ein BUFGP einfach eine Kurzbezeichnung: "It is equivalent to an 
IBUFG driving a BUFG". Die ISE nutzt also einen "Dedicated Input Clock 
Buffer" IBUFG und treibt damit über BUFG ein Taktnetz. Genau das sollte 
man mit einem Taktsignal tun. Das ist schon die optimale Kombination, 
"noch performanter" wird es mit den von dir gewünschten Alternativen 
sicher nicht.

Die von dir gewünschten Alternativen sind nicht sehr günstig ausgewählt, 
weil:
IBUFG selbst das Taktnetz wohl nicht direkt treiben kann sondern nur 
über BUFG (und genau das macht BUFGP)
IBUF der Buffer für ein "normales" Logiksignal ist, aber sich nicht für 
Takte eignet.

Die "lawine aus so unerklärlichen fehlern" kommt wohl daher, dass du die 
ISE zwingen willst, einen ungeeigneten Buffer für das Taktnetz zu 
verwenden.

schöne Grüße

Achim

danke für die antwort!

Mittlerweile bin ich mit Mr Xilinx wieder in Frieden...
Aber trotzdem heute schon wieder en Fehler in nem Datenblatt gefunden... 
Irgendwo echt nicht in Ordnung für so nen prestigeträchtigen und teils 
a****h teuren Hersteller...

Naja habe nun mich mal hingesetzt und ne Lösung gefunden, wie man ein 
taktsignal nutzen kann, um ein Signal zu erzeugen, welches genau dann 
auf 1 ist, wenn das taktsignal auf 1 ist:

rising edge in Flipflop1 --> variable1 ändert wert von 0 auf 1 oder 1 
auf 0
falling edge in Flipflop2 --> variable1 ändert wert von 0 auf 1 oder 1 
auf 0

variable1 xor variable2 = dann 1 wenn clk auf 1 ist...

so kann mans dann doch lösen, außer dass dann einiges an gerade bei mir 
tötlichem delay hinzukommt...

Danke.

Es geht darum im FPGA nen Speicher mit mehreren Adressräumen zu 
simulieren.
Das ganze teil sit über 32 bit(pins) an nen EBI (external bus interface) 
von nem 32-bit-MPC von freescale angeschlossen. Auf diesem Bus sind 1. 
Adresse dann 2. Daten zeitlich gemultiplext.

Das ganze läuft mit 66 MHz. Also hab ich genau 15,15 ns Zeit um zwischen 
den beiden Takten zu erkennen welche Adresse er anspricht udn dann zum 
nächsten Takt die Daten am gleichen bidirektionalen Pin wieder 
auszugeben.

Der Takt um den es geht ist ein Hilfssignal (Adress Latch Enable) von 
Freescale, welches ich nutzen muss um einerseits für nen burst-Read nen 
counter zu reseten (das wäre die NICHT-flanken-nutzung) und um zweitens 
mit der flanke des ALE signals die nur kurz anliegende Adresse zu 
speichern um sie dann an einen externen MRAM-baustein länger anlegen zu 
können (das wäre dann die flanken-nutzung)... ;)

Gilles schrieb:
> Der Takt um den es geht ist ein Hilfssignal (Adress Latch Enable)
Für mich sind Takt und Latch Enable zwei verschiedene Sachen.

Ich würde auch -- wie schon vorgeschalgen -- das Latch Enable mit einem 
hohen internen Takt abtasten und damit die Flanke zu erkennen.

Duke