VHDL Problem

[Arne Krüger]

Hallo,
ersteinmal nachträglich vielen Dank für alle, die mir im thread "JTAG
Downloader für XC9536" geholfen haben. Es funktioniert soweit. Was ein
Krurzschluss auf dem CPLD Board so alles bewirken kann..

Naja, jedefalls versuche ich gerade eine Busschnitstelle zu
programmieren:

controllregenable <= (not NotWR and not NotCS and not a0);
process(controllregenable)
begin
if (controllregenable'event) and (controllregenable='1') then
notresetfomdata <= data0;
SDA <= Data1;
SCL <= Data2;
end if;
end process;

Counterreset <= (not NotWR and not NotCS and a0);
process(Counterreset)
begin
if (Counterreset'event) and (Counterreset = '1') then
datalatched0 <= Data0;
datalatched1 <= Data1;
datalatched2 <= Data2;
datalatched3 <= Data3;
datalatched4 <= Data4;
datalatched5 <= Data5;
datalatched6 <= Data6;
datalatched7 <= Data7;
end if;
end process;

Aus irgenwelchen Gründen ist es dem Chip egal, ob A0 high oder low
ist. Es werden immer beide Register angesprochen.

Habt ihr eine blassen schimmer, warum er nicht zwischen daten und
steuerregister unterscheidet?

Nun ist dies mein erstes Projekt, bei dem ich ein CPLD verwende und in
VHDL programmiere. Habe dementsprechend wenig Erfahrung. Was solls,
learing by doing!

ciao, Arne

 

[Jan Stumpf]

Hi!

controllregenable <= (not NotWR and not NotCS and not a0);
process(controllregenable)
begin
if (controllregenable'event) and (controllregenable='1') then
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<='0'; --Beispiel für nen Resetvalue
...
elsif clk='1' and clk'event then --getakteter Process (high-Flanke)
-- Default Values z.B. r_signal_out<='0'; bedeutet, das am ENDE der
Prozesses r_signal_out=0 gesetzt wird, falls nicht bis zum end process eine
anderweitige Zuweisung stattfindet. Default Values sind praktisch für
1-Takt-Impulse. Da wird das Signal nach einem Takt automatisch wieder auf
null gesetzt.

-- Anweisungen, in deinem Fall z.B.
r_ControllRegEnable<=controllRegEnable; -- Vormerkung innerhalb
des Prozesses. Die Zuweisung erfolgt erst beim end process!
if (r_controllRegEnable='0' and controllRegEnable = '1') then --
hier können r_controllRegEnable und controllRegEnable unterschiedliches
enthalten!
--Anweisungen...
end if;
end if;
end process p1;

Nun ist dies mein erstes Projekt, bei dem ich ein CPLD verwende und in
VHDL programmiere. Habe dementsprechend wenig Erfahrung. Was solls,
learing by doing!
gute Einstellung ;-) Am besten wäre noch ein gutes Buch

mfg
Jan

 

[Thomas Stanka]

"Jan Stumpf" <jast@netcologne.de> wrote:

controllregenable <= (not NotWR and not NotCS and not a0);
process(controllregenable)
begin
if (controllregenable'event) and (controllregenable='1') then
das Problem ist, daß du mit VHDL normalerweise ein streng synchrones Design
beschreibst. Das bedeutet, daß du EINE clk hast.

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.

und den Wert des Registers mit dem aktuellem vergleichen (Register werden
erst am Ende eines Process zugewiesen!). Ein Prozess, der (halbwegs) sauber

?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]<vorherige Domain> ersetzen.

 

[Georg Acher]

In article <bqdrcj$29u$07$1@news.t-online.com>,
"Arne Krüger" <news.KruegerArne@web.de> writes:

|> controllregenable <= (not NotWR and not NotCS and not a0);
|> process(controllregenable)
<...>
|> Counterreset <= (not NotWR and not NotCS and a0);
|> 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

 

[Jan Stumpf]

Hi!

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.
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.

und den Wert des Registers mit dem aktuellem vergleichen (Register
werden
erst am Ende eines Process zugewiesen!). Ein Prozess, der (halbwegs)
sauber

?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.
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

 

[Tim Boescke]

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.
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

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

 

[Thomas Stanka]

Hallo,

"Jan Stumpf" <jast@netcologne.de> wrote:

Das ist kompletter Blödsinn. VHDL limitiert deine Clks in keinster
[..]
bitte nicht persöhnlich werden, ich lasse mich gerne eines besseren
belehren.

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

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.

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.

und den Wert des Registers mit dem aktuellem vergleichen (Register
werden
erst am Ende eines Process zugewiesen!). Ein Prozess, der (halbwegs)
sauber

?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.
wait-statements und Synthese? Afaik sind wait-statements nicht
synthetesierbar.

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<=Input;
end;

Wäre aber ohne Einschränkung zu einem Register synthesierbar.

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.

Ein kombinatorischer Prozess mit Signal, der kein Register erzeugt:

Process (A,B)
begin
Summe<=A+B;
end;

Gut, in dem Fall würde ich dafür keinen Prozess verwenden sondern ein
concurrent Statement, aber wenn die Manipulationen aufweniger werden,
sind kombinatorische Prozesse sinnvoll.

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!

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]<vorherige Domain> ersetzen.

 

[Georg Acher]

In article <ef424d2c.0312020202.747dd1b8@posting.google.com>,
usenet_10@stanka-web.de (Thomas Stanka) writes:

|> 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<=Input;
|> 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

 

[Ansgar Bambynek]

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 <= NotWR or NotCS;

process(clock_s)
begin
if (rising_edge(clock_s)) then
if (a0 = '0') then
notresetfomdata <= Data(0);
SDA <= Data(1);
SCL <= Data(2);
else
datalatched <= Data;
end if;
end if;
end process;


oder das ganze mit reset

process(clock_s, reset)
begin
if (reset = '1') then
notresetfomdata <= '0';
SDA <= '0';
SCL <= '0';
datalatched <= (others => '0');
elsif (rising_edge(clock_s)) then
if (a0 = '0') then
notresetfomdata <= Data(0);
SDA <= Data(1);
SCL <= Data(2);
else
datalatched <= Data;
end if;
end if;
end process;


HTH

Ansgar
--
Attention please, reply address is invalid, please remove "_xxx_" ro reply


"Arne Krüger" <news.KruegerArne@web.de> schrieb im Newsbeitrag
news:bqdrcj$29u$07$1@news.t-online.com...

Hallo,
ersteinmal nachträglich vielen Dank für alle, die mir im thread "JTAG
Downloader für XC9536" geholfen haben. Es funktioniert soweit. Was ein
Krurzschluss auf dem CPLD Board so alles bewirken kann..

Naja, jedefalls versuche ich gerade eine Busschnitstelle zu
programmieren:

controllregenable <= (not NotWR and not NotCS and not a0);
process(controllregenable)
begin
if (controllregenable'event) and (controllregenable='1') then
notresetfomdata <= data0;
SDA <= Data1;
SCL <= Data2;
end if;
end process;

Counterreset <= (not NotWR and not NotCS and a0);
process(Counterreset)
begin
if (Counterreset'event) and (Counterreset = '1') then
datalatched0 <= Data0;
datalatched1 <= Data1;
datalatched2 <= Data2;
datalatched3 <= Data3;
datalatched4 <= Data4;
datalatched5 <= Data5;
datalatched6 <= Data6;
datalatched7 <= Data7;
end if;
end process;

Aus irgenwelchen Gründen ist es dem Chip egal, ob A0 high oder low
ist. Es werden immer beide Register angesprochen.

Habt ihr eine blassen schimmer, warum er nicht zwischen daten und
steuerregister unterscheidet?

Nun ist dies mein erstes Projekt, bei dem ich ein CPLD verwende und in
VHDL programmiere. Habe dementsprechend wenig Erfahrung. Was solls,
learing by doing!

ciao, Arne

 

[Arne Krüger]

"Ansgar Bambynek" <a.bambynek_xxx_@avm.de> schrieb im Newsbeitrag
news:3fcc86f8$0$280$4d4ebb8e@businessnews.de.uu.net...

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

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.

signal Data: std_logic_vector (7 downto 0);

clock_s <= NotWR or NotCS;

process(clock_s)
begin
if (rising_edge(clock_s)) then
if (a0 = '0') then
notresetfomdata <= Data(0);
SDA <= Data(1);
SCL <= Data(2);
else
datalatched <= Data;
end if;
end if;
end process;

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

 

[jetmarc]

da zumindest die großen Brüder der CPLDs, die FPGAs darauf
ausgelegt sind EINE globale Clk zu verteilen.

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.

Zumindest der Leonardo Spectrum bemängelt auch bei 2 'event-Konstruktuen
eben genau dieses!

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

 

[Henning Paul]

Arne Krüger schrieb:

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).

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

 

[Michael Schöberl]

signal Data: std_logic_vector (7 downto 0);

clock_s <= NotWR or NotCS;

process(clock_s)
begin
if (rising_edge(clock_s)) then
if (a0 = '0') then
notresetfomdata <= Data(0);
SDA <= Data(1);
SCL <= Data(2);
else
datalatched <= Data;
end if;
end if;
end process;

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!

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