VHDL Problem

Hi!

das Problem ist, daß du mit VHDL normalerweise ein streng synchrones Design beschreibst. Das bedeutet, daß du EINE clk hast. Mit dem 'event - Konstrukt interpretiert der Compiler dein Signal als Clk, was ihn insbesondere mit dem

2ten Process und dem 2ten 'event - Konstrukt total durcheinander bringt. Wenn du auf eine Flanke triggern willst, solltest du ein Register anlegen und den Wert des Registers mit dem aktuellem vergleichen (Register werden erst am Ende eines Process zugewiesen!). Ein Prozess, der (halbwegs) sauber deklariert ist sieht dann so aus :

signal r_controllRegEnable : std_logic; -- verwende am Besten für Register immer r_ oder ne anderes Prefix. Das ist dann besser auseinanderzuhalten!

p1 : process(clk, reset,controllRegEnable) begin if reset='0' then --asynchroner Reset, aktive low signal_out1

Das ist kompletter Blödsinn. VHDL limitiert deine Clks in keinster Weise. Die Technologie ist das einzige limitierende. Da musst du natürlich schon darauf achten, das ein PLD mit nur einer Clk-Leitung mit dem Code des OP überfordert ist. Üblicherweise sollte das Layoutwerkzeug da aufschreien, wird in der Praxis aber leider nicht immer tun.

?Häh? Signale werde immer Zeitverzögert zugewiesen, dass ist komplett losgelöst vom Register. und sollte jemand noch eine Synthesewerkzeug finden, das mit Waitstatements sauber synthetisiert, kommt die Signalzuweisung evtl. _vor_ dem Ende des Prozesses.

Der VHDL-Code des OP ist zwar eigenwillig, aber wenn ich nichts übersehen habe funktionell richtig (für ein Device mit zwei Taktleitungen :). Das Problem sollte also bei Synthese/Layout vom Werkzeug erzeugt werden. Die Glaskugel kann natürlich nichts darüber sagen, wie die externen Signale WR, CS und A0 ankommen, die in die Taktgenerierung eingehen und ob Spikes/Glitches ein Problem sein können.

Bye Thomas Stanka

--
Bitte nur Viren an obige email senden. Bei Antworten per PM 
usenet_10@stanka-web.de durch thomas[at] ersetzen.

|> controllregenable process(controllregenable)

|> Counterreset process(Counterreset)

Du könntest "Ringing" auf a0 haben. Kann bei "längeren" Adressbussen schon mal passieren. Da könnte eine Terminierung mit ~220-470R gegen GND helfen.

Andererseits ist natürlich die asynchrone Erzeugung eines Taktes mit Gattern eine ziemliche Schweinerei, das ging gerade mal mit den schnarchigen TTLs gut. Bei FFs, die schon auf 2-3ns Spikes reagieren können, fängt man sich damit alles mögliche ein. Entweder nimmst du explizit den CPU-Takt und baust die Dekodierung innerhalt des if clk'event. Oder du findest das Signal, dessen Flanke tatsächlich einen Zugriff qualifiziert und nimmst das als Takt. Beim 8085/6 (und Verwandten) ist es IOR/IOW, bei Motorola eher DS.

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Hi!

bitte nicht persöhnlich werden, ich lasse mich gerne eines besseren belehren. Aber unabhängig davon ist das aber soviel ich weiß trotzdem richtig, da zumindest die großen Brüder der CPLDs, die FPGAs darauf ausgelegt sind EINE globale Clk zu verteilen. Zumindest der Leonardo Spectrum bemängelt auch bei 2 'event-Konstruktuen eben genau dieses! Im übrigen waren die Signale des OP ja auch keine Clks sondern steuersignale. Dementsprechend ist auch die Beschreibung in einem Prozess fehl am Platz. Da sollte man in der Concurrent-Umgebung designen.

werden

sauber

wait-statements und Synthese? Afaik sind wait-statements nicht synthetesierbar. Im übrigen ist das Prozess-Konstrukt soweit ich weiß eine Ablaufbeschreibung, die halt NICHT sequentiell ausgeführt wird, obwohl Sie eine Art Sequenzierung erlaubt. Signale werden auch IMMER unaghängig von der Hardware und von der Synthese am Ende eines Prozesses zugewiesen. Der Begriff Register ist vieleicht in dem Kontext nicht ganz korrekt, obwohl ich bis jetzt keine Synthese gesehen habe, die aus dem Code nicht eben genau dieses erzeugt hätte. Eben durch die Vormerkung/verzögerte Zuweisung bei geclkten Prozessen. Aus meiner (zugegebenermaßen noch nicht langen) Erfahrung, würde ich dem OP auf jeden Fall das Design mit dem geclkten Prozess empfehlen. Das hat bis jetzt immer funktioniert!

mfg Jan

Das hängt allerdings auch vom FPGA ab. Alle neueren haben mehrere Clock- leitungen/DLLs und alles was dazu gehört. Übrigens lassen sich bei den meisten FPGAs die Register auch durch "normale" interconnects takten, allerdings hat man dann mit wesentlich größerem clock-skewing zu kämpfen.

Bei CPLDs ist es ähnlich, nur das hier die Clock-Resourcen noch wesentlich eingeschränkter sind.

Trotzdem stimmt es natürlich, dass ein rein synchrones Design am wenigsten kritisch ist. Nur optimal muss es nicht immer sein :)

[..]

Fein das du dich belehren lässt :). Ich hatte nicht vor dich persönlich zu beleidigen, sollte vielleicht nochmal meine Formulierung überdenken.

Also erstmal müssen wir uns über den Begriff Takt unterhalten. Takt ist alles was an den Takteingang eines FF gehen darf. Üblicherweise hat ein FPGA einen dedizierten Takt, der mit wenig Skew an die FF geht, bei vielen FPGA dürfen daneben aber weitere Taktwelten existieren, die evtl. mit hohem Skew verteilt werden. Moderne FPGA-Famillien verfügen auch über deutlich mehr explizite Taktnetze mit unterschiedlichen Einschränkungen. (z.b. Teiltakte die nur einen bestimmten Teil des FPGA ereichen, Takte die zwar wenig Skew haben aber unsymetrisch werden, Takte die nicht "gegated" werden dürfen,...). Ein Xilinx-VirtexE hat meines Wissens 4 gleichberechtigte Taktnetze, bei Actel54SX72S hast du drei unterschiedliche Taktklassen die alle ihre Berechtigung haben.

Wie du den Takt nennst ist egal. Oftmals darf der Takt sogar über beliebige Pins ins Device, auch wenn ein normaler IO-Pad üblicherwiese unschöne effekte auf den Takt hat. Du hast Recht, dass es Devices gibt, die erlauben nur einem Takt-Netz an die FF zu gehen, das ist aber nicht die Regel. Schlimm wird es wenn du den Takt auch im Datenpfad haben willst, aber auch das ist idR möglich.

Darüber können wir streiten :). Prinzipiell lassen sich Waitstatements so einsetzen das sie _nicht_ sinnvoll synthetisierbar sind und so, das sich der Code sauber synthetisieren liesse, wenn das Werkzeug damit klar kommt. Ich kenne aber selber kein Tool von dem ich sagen könnte, das es waitstatements synthetisieren kann.

Process begin wait until Rising_Egde(Clk); OutPutgReg Im übrigen ist das Prozess-Konstrukt soweit ich weiß eine

Ein kombinatorischer Prozess mit Signal, der kein Register erzeugt:

Process (A,B) begin Summe Aus meiner (zugegebenermaßen noch nicht langen)

Es ist immer besser mit einer Taktwelt auszukommen, aber gerade bei beim Code des OP müsste dazu das Taktsignal extern erzeugt werden und würde zu weiteren Problemen führen (Taktflanke zu Steuerleitungen?).

bye Thomas

--
Bitte nur Viren an obige email senden. Bei Antworten per PM 
usenet_10@stanka-web.de durch thomas[at] ersetzen.

|> klar kommt. Ich kenne aber selber kein Tool von dem ich sagen könnte, |> das es waitstatements synthetisieren kann. |> |> Process |> begin |> wait until Rising_Egde(Clk); |> OutPutgReg end;

Hm, wenn man kein asynchrones Reset braucht, hat's bei mir (mit Synopsys) process begin wait until clk='1'; ... end;

immer getan, und das schon vor 7 Jahren...

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Hi,

die anderen Postenden haben sich ja hier schon artikuliert, wenn Du nur ein globales Clocknetz hast, wie wäre es denn hiermit?

und vielleicht auch ein bischen lesbarer

signal datalatched : std_logic_vector (7 downto 0);

-- Data wird wohl der eingang der entität sein, daher vielleicht in der Portliste ändern signal Data: std_logic_vector (7 downto 0);

clock_s begin

"Ansgar Bambynek" schrieb im Newsbeitrag news:3fcc86f8$0$280$ snipped-for-privacy@businessnews.de.uu.net...

nur ein

OK, würde ich ja gerne machen.Das Problem ist halt, dass ich zwar einen Clock habe, der aber leider unabhängig vom Bus ist. Nochmal zur näheren Erklärung, was ich eigentlich mache:

Ich baue eine MP3 ISA Karte. Dabei ist die CPLD quasi das Businterface und initialisiert(mit Hilfe der PC Software) den Player(Mas3507) und hat dann natürlich auch noch das serielle Interface zum Chip, um die Daten in den Decoder zu transportieren(wird glaub ich auch nochmal sone Sache, mit der ich euch mal konsultieren werde). Das bedeutet, dass ich zwar ein Takt habe, dieser aber nicht schnell genug ist, um Steuersignale am ISA Bus zu erkennen(vermute ich mal). Nun mache ich das auch noch so, dass ich in der Debugphase die Platine an den LPT hänge, um mich erstens beim Messen im PC nicht verrenken zu müssen und um zweitens den Bus mal anhalten kann.

Da hat Georg schon einen ganz guten Tip gegeben mit der Terminierung. Oder dass ich wenigstens mal einen Treiber zwischen LPT und CPLD verwende. Das wäre vielleicht mal was, was ich mal ausprobieren könnte. Soetwas habe ich auch schon vermutet.

Nö funktioniert leider auch nicht. So in etwa hab ich das grad mal ausprobiert. Aber wie gesagt: ich glaub ich versuch das mit den Treibern nochmal!

ciao, Arne

Die meisten koennen mehrere Clocks verarbeiten, so zwischen 3 und 8. Das ist oft auch unerlaesslich, denn gerade die groesseren Designs arbeiten in der Regel mit mehreren Clocks. Zum Beispiel beim Verbinden mehrerer Systeme die mit eigenen Clocks arbeiten (sagen wir ein PCI Bus und ein externes Geraet) muss das FPGA natuerlich beide Clocks verarbeiten.

Das wird wohl davon abhaengen, wie die Signale enstehen, die Du als Clock verwendest. Wenn es sich um einen I/O Input handelt, gibt es keine Warnung. Letztlich koenntest Du den Input hinterher einem Clock-Pin zuweisen, oder zumindestens dafuer sorgen dass es keine Raceconditions gibt. Abers aber wenn Du ein kombinatorisches Signal benutzt - dann weiss Leonardo schon sicher, dass Du die noetigen Vorkehrungen nicht getroffen hast, und macht eine Warnung. Immerhin kann schon beim AND Verknuepfen von 3 Signalen (wie der Fragesteller) eine Racecondition entstehen. Niemand garantiert dass die 3 Signale an ein 3-fach AND angeschlossen sind (statt an zB eine Kaskade von 2 2-fach ANDs), oder dass das Routing der Signale gleich lang ist. In dem Fall ist eine Warnung also aus der Sicht von Leonardo durchaus angemessen obwohl Du durch "vorsichtiges" Ansteuern der einzelnen Signale trotzdem noch eine saubere Clock erreichen kannst.

Wer sich aber auf jeden Fall beschweren muss (sofern Du mehr Clocks benutzt als die Hardware unterstuetzt), ist der Fitter. Der hat ja die Sicht auf Deine Netzliste und den Chip, und kann den Fehler bemerken.

Marc

Arne Krüger schrieb:

Hat das einen "praktischen" oder zumindest "hobbyistischen" Wert? Oder ist das ein akademisches Projekt? Ich meine, die Zeit der PC-MP3-Decoder-Hardware ist ja schon lange vorbei, noch nicht einmal Standalone-MP3-Player lohnen sich heute zu bauen. Der PUMP war ja seinerzeit recht spektakulär mit seinem Parallelportanschluß und Erik Hermann und ich haben vor zweieinhalb Jahren noch einen Parallelport-Player konstruiert, den man als "Drucker" ansprechen konnte (siehe meine Homepage), d.h. wo ein "copy /b datei.mp3 lpt1:" gereicht hat. Aber heute würde ich keine Mühe mehr darauf verschwenden. Vor allem, wenn das ganze dann später nur mit proprietärer Software funktioniert. Beim FUMP1 war die Portierung auf Linux mit "dd if=datei.mp3 of=/dev/lp0" abgeschlossen... :-)

Gruß Henning

--
henning paul home:  http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

Deine Signale NotWR, NotCS und a0 hängen direkt an den Pins? in welchem zeitlichen Bezug kommen denn die Flanken?

Mal angenommen: a0 und NotWR schalten etwa gleichzeitig um, so schaltet clock_s etwas verzögert (da ist noch ein Logic-Level und routing dazwischen!), die FF die dann die Daten registern sollen haben nun aber auch wieder ein routing-delay, so dass dein Clock (im ungünstigsten Fall) bestimmt alles mögliche registern kann ...

2 Lösungen:

- sicherstellen, dass a0 mit z.B. 10ns Abstand zu den anderen beiden umschaltet und dem Synthesetool ein entsprechendes Contraint eintragen

- oder ein synchrones Design verwenden

bye, Michael