Clock Multiplexer für PICO Design

MicroController-Ingenieur Gast #3770802 
Ich habe ein Design aufgesetzt, in das ein PICOBLAZE hinein soll (aber 
noch gar keiner drin steckt!) und stosse schon bei der 
hardware-Verdrahtung auf ein seltsames Problem:

Ich benutzte eine UART, die ein internes Register beschreibt, mit dem 
ich einen Takt umschalten möchte. Die UART läuft mit der System_Clock 
50MHz und taktet das Signal raus ins design.

Von dort geht es direkt auf einen BUFGMUX, der zwei Takteingänge von 
Außen (über IBUF, PLL und BUFG) umschalten soll.

In der Simulation geht es, d.h. die Takte werden umgeschaltet. Das 
einzige sonderbare ist, dass der eine der beiden Takte ohne BUFG auf 
einen BUFGMUX geht obwohl der auch noch Logik treibt. Das soll aber 
zunächst egal sein.

Ungewöhnlich finde ich folgende Fehlermeldung:

Xst:3218 - HDL ADVISOR - The RAM <Mram_pci_clk_sel> will be implemented 
on LUTs either because you have described an asynchronous read or 
because of currently unsupported block RAM features. If you have 
described an asynchronous read, making it synchronous would allow you to 
take advantage of available block RAM resources, for optimized device 
usage and improved timings. Please refer to your documentation for 
coding guidelines.

Was hat denn nun der Clock-MUX mit einem MRAM zu tun?

Das Signal heisst nämlich "pci_clk_sel" und dieser Takt treibt nirgendwo 
ein RAM, weder direkt noch eines seiner Derivate (also der gemuxte 
Takt).

Kann jemand was damit anfangen?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Lothar M. Moderator (Firma: Titel) Persönliche Seite #3771212 
MicroController-Ingenieur schrieb:
> In der Simulation geht es, d.h. die Takte werden umgeschaltet.
In der Simualtion geht sooooo viel mahr als in der Realität.

> taktet das Signal raus ins design.
Wo ist hier "innen" und wo "draußen"?

> Was hat denn nun der Clock-MUX mit einem MRAM zu tun?
Offenbar hat der Synthesizer deine Beschreibung als RAM 
interpretiert...

> Das Signal heisst nämlich "pci_clk_sel" und dieser Takt treibt nirgendwo
> ein RAM, weder direkt noch eines seiner Derivate (also der gemuxte Takt).
Wenn du in VHDL irgendwas hinschreibst, und der Synthesizer ist der 
Meinung, das könnte man geschickt mit einem RAM abbilden (und du glaubst 
nicht, was man alles in RAMs packen kann), dann tut er das auch.

> Das einzige sonderbare .... Das soll aber zunächst egal sein.
Sollte es wahrscheinlich nicht. Aber die Lösung liegt sehr vermutlich im 
nicht geposteten Code...
Antwort Zitieren Bearbeiten Löschen Melden Danke
MicroController-Ingenieur Gast #3771277 
Das Signal für den Takt-MUX geht wirklich nur aus dem Modul für den UART 
raus ins Restdesign, also die obere Entity und dort auf den selection 
Eingang des BUFGMUX. Der schaltet zwei externe Takte um.

Wo soll da ein RAM hingetan werden können?
Antwort Zitieren Bearbeiten Löschen Melden Danke
Daniel Gast #3780852 
MicroController-Ingenieur schrieb:
> Das Signal für den Takt-MUX geht wirklich nur aus dem Modul für den UART
> raus ins Restdesign, also die obere Entity und dort auf den selection
> Eingang des BUFGMUX. Der schaltet zwei externe Takte um.
Warum kommt das Signal aus dem UART-Modul?
Ich hätte es an ein GPIO-Modul gehangen.

Daniel
Antwort Zitieren Bearbeiten Löschen Melden Danke
MicroController-Ingenieur Gast #3781502 
Daniel schrieb:
> Warum kommt das Signal aus dem UART-Modul?

Das muss so sein, weil per UARt umgeschaltet werden können muss. Der 
Aufbau ist so:

IO-Pin RX, eingesampelt mit Systemtakt, geht auf UART-VHDL-Block, der 
mit Systemtakt läuft. Von dort kommt es als Steuersignal raus (synchron 
mit dem Systemtakt) und geht direkt auf dem MUX. Die beiden PCI-Clocks 
kommen aus unterschiedlichen PLLs.

Ich glaube, dass er intern die ganzen BUFGMUXs irgendwie umbaut und eine 
ganz andere Architektur rauskommt, als ich sie beschrieben habe. Muss 
mal das RTL file ansehen.

Ich dachte nur, dass vielleicht jemandem die Fehlermeldung geläufig sein 
könnte, weil Xilinx ja öfter mal Fehler meldet wo keine sind und der 
Hase woanders begraben liegt.
Antwort Zitieren Bearbeiten Löschen Melden Danke
Daniel Gast #3781602 
MicroController-Ingenieur schrieb:
> IO-Pin RX, eingesampelt mit Systemtakt, geht auf UART-VHDL-Block, der
> mit Systemtakt läuft. Von dort kommt es als Steuersignal raus (synchron
> mit dem Systemtakt) und geht direkt auf dem MUX. Die beiden PCI-Clocks
> kommen aus unterschiedlichen PLLs.
Also steckt in Deinem UART schon ein 'Interpreter' drin. Ich dachte Du 
verwendest schon den Picoblaze.

Zu Deinem Eingangspost: Der HDL advisor gibt keine Fehlermeldung aus, 
sondern einen Hinweis.

Das mit dem Mram ist aber wirklich komisch. Ich würde da mal genau den 
Synthesereport durchschauen, um die zweifelhafte Beschreibung zu finden.
Vielleicht kannst Du den Report hier auch anhängen.

Daniel
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 12 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.