Hi Leute! Folgendes Problem: Ich habe ein Design in ISE14.1 (Spartan-6) und habe eine Design-Version welche komplett durchsimuliert bis post-route und mir dabei als Eingangsbuffer für einen gewissen Pin welcher A:FFs clockt und B:in ein OR gatter reinläuft. Er meckert garnicht wenn ich ihn alles machen lasse und realisiert mir dann als Eingangsbuffer für diesen Pin ein BUFGP, welches ich im Libraries Guide noch nicht mal finden kann (Hilfe!). Dann wenn ich etwas am Code ändere (was eigentlich nichts damit zu tun haben sollte... andere Story), meckert er rum und ich würde ihn nun einfach gerne zwingen, nicht ein BUFGP zu synthetisieren sondern ein anderes Buffer was ich möchte. Kann man das automatische Buffern für einen einzlenen Pin per Attribut oder so deaktivieren? Ich würde lieber ein IBUF oder IBUFG nehmen... Bitte melden! Ist recht zeitkritisch... Danke !! Gilles
*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.
Gilles schrieb: > 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 Darf man fragen, wozu das (intern) gut ist?
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)... ;)
Hat der keinen synchronen Modus für den EBI? Solche asynchronen Sachen sind meistens ziemlich blöd im FPGA zu realisieren. Am besten arbeitet man intern mit einem höheren Takt und tastet dann die Signale entsprechend ab. Muss aber dann mindestens díe doppelte Freqenz sein, damit das was wird. So kann man intern alles schön synhron machen.
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
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.