VHDL, Xilinx ISE und Coolrunner II

Das ist kein Flip-Flop und ISE sollte dir einiges an Warnungen um die Ohren hauen. pulse wird hier auf 0 gesetzt, solange an width_in 1 anliegt. Liegt dort 0 an, dann wird es auf 1 gesetzt, solange an delay_in 1 anliegt.

Somit entspricht dieses Verhalten deiner Programmierung. Letzte Zeile: an width_in liegt 1 an, also wird pulse auf 0 gesetzt und somit auch pulse_out.

Vielleicht hilft dir die Funktion rising_edge bzw. falling_edge weiter.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss schrieb:

Wieso sollte das kein RS-Flip-Flop sein?

Genau das ist das Verhalten eines RS-FF

Letzte Zeile: an

Richtig. Das Problem ist, dass pulse_inv in dieser Zeile dann _nicht_ pulse-out ist!

Stimmt, sollte eigentlich sowas wie ein RS-Flip-Flop sein, hatte ich jetzt irgendwie mit JK-Flip-Flop verwechselt.

Es ist aber nicht jeder Zweig in dem process-Statement definiert, sodaß intern ein Latch angelegt wird, was dir wahrscheinlich als Warnung angezeigt wird. Und genau da könnte es das Problem geben, daß dann irgendwas bei der Synthese schief geht. Das Verhalten ist allerdings schon etwas merkwürdig.

Versuche es mal ohne process, in der Form

pulse

"Mathias Weierganz" schrieb im Newsbeitrag news:fdtj1e$65j$ snipped-for-privacy@rzcomm2.rz.tu-bs.de...

Hallo Mathias,

ich habe zwar wenig Ahnung von VHDL aber ich kann googeln. :-)

Kapitel 6.4-23 RS-Flipflop in VHDL

Vielleicht kann damit ja jemand erklären warum deine Lösung Probleme macht.

Gruß Helmut

In dem Beispiel dort scheinen alle Fälle von Eingangskombinationen abgedeckt zu werden, vielleicht macht das Probleme. So wie es dort steht, ist es allerdings nicht synthetisierbar, da zumindest die Programme die ich kenne, kein WAIT und AFTER unterstützen, außer für Simulationen.

Generell ist es eine gute Idee, jeden Eingang per Takt zu übernehmen, falls vorhanden, und dann im nächsten Takt diesen übernommenen Wert auszuwerten. Wenn man sich daran hält, gibt es meistens keine Probleme. Sequentielle Logik, die asynchron angesteuert wird, kann zur Metastabilität führen, was vielleicht das Verhalten erklären könnte.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Das beinhaltet eine unvollständige Signalzuweisung und ist daher _gefährlich_, speziell bei schlampig geschriebener Synthesesoftware ...

Es ist aber definitiv zulässig, in der Tat ist dann die Synthese eines Latches vorgesehen. Näheres siehe z.B. Reichardt, Schwarz, VHDL Synthese, Oldenbourg 2000, Kapitel 3.4

Da gibt es nichts zu diskutieren, das ist ein Bug im Synthesetool.

Grosse Namen schützen nicht vor grossen Fehlen ;-/

Denn:

Hallo Mathias,

Mathias Weierganz schrieb:

ich habe das mal testweise so implementiert mit Xilinx ISE 6.3i SP 3, es macht genau das, was Du sicher erwartest. Mit dieser Formulierung wird es auch gut an das CPLD angepaßt, es wird nämlich genau nur 1 D-Latch im RTL-Viewer sichtbar, also das, was in so einer Makrozelle drin sein dürfte. Im Chipviewer sind allerdings 2 D-Latches zu sehen, für beide zueinander invertierte Ausgangssignale je 1 getrennte Schaltung.

Bei mir ist 1 Inverter im Ausgang zu sehen, das Verhalten da oben tritt bei mir nicht auf, ist auch garnicht möglich. Wie sieht das denn bei Dir im RTL-Viewer aus, falls der im Webpack drin ist? Ich habe die Vollversion zur Verfügung seit Vers. 1.4.

Seltsam, hast Du von der ISE 8.2 die neuesten Service Patches samt Bibliotheken?

Der Fehler liegt hier IMHO nicht bei Dir, ich kenne mich mit VHDL allerdings auch nicht gut aus. Mir war nur mal aufgefallen, daß im process() bei einem Signalwechsel nicht gleichzeitig steigende und fallende Flanke zum Triggern benutzt werden können, was manche Probleme umständlich lösbar macht. Nach Meinung der VHDL-Puristen war es mein Fehler, sowas machen zu wollen, bis heute habe ich Zweifel an dieser Meinung.

Der Vorschlag von Michael Randelzhofer mit rein kombinatorischem Ansatz führt übrigens zu einer funktional identischen Lösung, allerdings weniger optimal für das CPLD mit einzelnen Gattern zu Fuß zusammengesetzt, dafür ließe sich das aber in einem GAL implementieren.

Fehler sehe in in beiden Fällen nicht, vielleicht solltest Du Deine Testschaltung mal isoliert von einem größeren Projekt betrachten und vor allem die aktuellen Service Patches besorgen. Die ISE 6.3i SP3 hat sich bei mir über einen längeren Zeitraum als stabil erwiesen. Ansonsten hat man bei Versionssprüngen meist mit unangenehmen Fehlern zu kämpfen und die 4.2 war die IMHO 1. ISE-Version und völlig veraltet, wir sind bei

9.2 SP2 glaube ich.

mfg. Winfried

Frank Buss schrieb:

Metatstabilität ist hier nicht das Problem. Ich kann das fehlerhafte Verhalten mit DC-Pegeln beliebig langsam reproduzieren. Dass synchrone Designs weniger Probleme machen ist mir bewusst. Der Rest des Designs ist auch synchron. Nur an dieser Stelle geht das gerade nicht, da die Signale zum Setzen und Rücksetzen des RS-FF durch digitale Delaylines verzögert werden, um den Ausgangspuls in ns-Schritten verschieben zu können.

Mathias

Mathias Weierganz schrieb:

Nach dem Download von ca. 2.4GB Daten kann ich jetzt sagen, dass der Fehler auch bei der 8.2.03i und 9.2.03i auftritt.

"Mathias Weierganz" schrieb im Newsbeitrag news:fe2hp8$alp$ snipped-for-privacy@rzcomm2.rz.tu-bs.de...

Welchen Compiler verwendest du ?

Kannst du mal die relevanten Logikgleichungen des fitter reports posten?

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310

M.Randelzhofer schrieb:

Die Frage verstehe ich jetzt nicht. Ich benutze den Compiler, der bei der jeweiligen Xilinx-ISE dabei ist.

meinst du das:

********** Mapped Logic ********** LDCP_pulse_inv: LDCP port map (pulse_inv,'0',delay_in,'0',width_in); LDCP_pulse_out: LDCP port map (pulse_out,NOT '0',delay_in,width_in,'0');

Register Legend: FDCPE (Q,D,C,CLR,PRE,CE); FDDCPE (Q,D,C,CLR,PRE,CE); FTCPE (Q,D,C,CLR,PRE,CE); FTDCPE (Q,D,C,CLR,PRE,CE); LDCP (Q,D,G,CLR,PRE);

Er benutzt offensichtlich zwei FFs. Jetzt müsste man nur noch das Verhalten eines LDCP Registers kennen...google-google

sagt mir das folgende Verhalten:

CLR PRE G D Q

1 X X X 0 0 1 X X 1 0 0 1 1 1 0 0 1 0 0 0 0 0 X No Chg 0 0 * D D

• heißt negative Flanke

für pulse_out ergibt das width 0 delay 1 pulse_out

1 X X X 0 ok 0 1 X X 1 0 0 1 1 1 ok 0 0 1 0 0 0 0 0 X No Chg 0 0 * D D

und für pulse_inv

0 width delay 0 pulse_inv

1 X X X 0

0 1 X X 1 ok 0 0 1 1 1 0 0 1 0 0 ok 0 0 0 X No Chg 0 0 * D D

D.h. hier scheint der Fehler nicht zu liegen.

Mathias

(sorry, ich habe ein posting mit verhunzter Formatierung gecancelt, bitte ignorieren, falls es noch irgendwo rumschwirrt. M.W.)

M.Randelzhofer schrieb: >

Die Frage verstehe ich jetzt nicht. Ich benutze den Compiler, der bei der jeweiligen Xilinx-ISE dabei ist.

meinst du das:

********** Mapped Logic ********** LDCP_pulse_inv: LDCP port map (pulse_inv,'0',delay_in,'0',width_in); LDCP_pulse_out: LDCP port map (pulse_out,NOT '0',delay_in,width_in,'0');

Register Legend: FDCPE (Q,D,C,CLR,PRE,CE); FDDCPE (Q,D,C,CLR,PRE,CE); FTCPE (Q,D,C,CLR,PRE,CE); FTDCPE (Q,D,C,CLR,PRE,CE); LDCP (Q,D,G,CLR,PRE);

Er benutzt offensichtlich zwei FFs. Jetzt müsste man nur noch das Verhalten eines LDCP Registers kennen...google-google

sagt mir das folgende Verhalten:

CLR PRE G D Q

1 X X X 0 0 1 X X 1 0 0 1 1 1 0 0 1 0 0 0 0 0 X No Chg 0 0 * D D

• heißt negative Flanke

für pulse_out ergibt das width 0 delay 1 pulse_out

1 X X X 0 ok 0 1 X X 1 0 0 1 1 1 ok 0 0 1 0 0 0 0 0 X No Chg 0 0 * D D

und für pulse_inv

0 width delay 0 pulse_inv

1 X X X 0

0 1 X X 1 ok 0 0 1 1 1 0 0 1 0 0 ok 0 0 0 X No Chg 0 0 * D D

D.h. hier scheint der Fehler nicht zu liegen.

Mathias

Mathias Weierganz schrieb:

... und sich mein Originaldesign unter Verzicht der nicht korrekt implementierten Inversion mit 9.2.03i _nicht_ fitten lässt. Der Fitter beendet sein Programm ohne jegliche Meldung, aber mit dem roten Kreuz. Ein erneutes Starten des Fitters führt dazu, dass auch das Kreuz nicht mehr erscheint. Ich weiß schon, warum ich ungern eine funtionierende Software ersetze.

8.2.03i übersetzt klaglos und die Funktion ist auch wie erwartet (unter Verzicht auf die Inversion)

Manche Tage können ätzend sein.

Mathias

Hallo Mathias,

Mathias Weierganz schrieb:

das läßt ja nicht Gutes ahnen. Also wenn die Postfit-Simulation stimmt, geht man ja von der Funktionsfähigkeit aus. Aber mir fällt ein, daß Du ja sicher die Hardware getestet hast, die nicht funktioniert. Bleibt also der CPLD-Fitter, mit dem ich auch schon Probleme hatte.

Jetzt habe ich Dein Beispiel im Fitter angesehen und mal willkürlich Pins 1-4 benutzt, vorher habe ich das zufällig automatisch zuweisen lassen. Jetzt sind auf einmal die 2 Input-Pins nicht mehr angeschlossen, natürlich ohne Fehlermeldung :-(.

Dann habe ich den nächsten Test gemacht, den process() weggelassen und statt dessen diese Gleichung eingesetzt:

Hier habe ich dann auch willkürlich Pins 1-4 belegt, aber alle sind angeschlossen! Die Postfit-Simulation zeigt mir in beiden Fällen das gleiche richtige Resultat. Daß der Fitter-Report Warnungen über Hazards bringt, ignoriere ich weil ich annehme, Xilinx will mir den Entwurfsstil vorschreiben, was ich nicht mag. Schließlich sind die noch nicht mal in der Lage, im process() auf steigende oder fallende Flanke zu triggern, was ich auf dem Papier ohne Probleme kann. Von Hazards ist keine Spur zu sehen.

Da ich mit dem Fitter der ISE 6.1 auch schonmal ähnliche Probleme hatte, habe ich damals einen Xilinx Case draus gemacht und als Workaround eine Einstellung der Fitter-Preferences bekommen, die den Fehler beseitigt hat. Nur hat der Coolrunner diese Option nicht und wahrscheinlich ist es ein anderes Problem.

Was mir als Test noch einfallen würde wäre, obige Gleichung anstelle des process() mal einzusetzen und nachprüfen, ob es dann geht in der Hardware. Wenn ja, macht der Fitter auch noch in der ISE 9.2 noch den Mist wie früher.

An der Stelle hätte ich jetzt 'nen Case aufgemacht und das Projekt den Leuten um die Ohren gehauen.

mfg. Winfried

Ja das kenn ich auch, normalerweise geht im Superstress auch noch der PC oder die HDD kaputt, das ist alles schon vorgekommen. Am besten erst mal ausspannen, ein Bier trinken (oder leckeren Rioja Rotwein) und am nächsten Tag wieder weitermachen (vielleicht noch Aspirin...)

Ich kann das nachvollziehen, manchmal möchte man den Rechner einfach zum Fenster rausschmeissen, gerade ISE bringt einen oft zur Weissglut. Aber - dafür ist's kostenlos. (Anfang 1990 hab ich für die Xilinx Entwicklungssoftware und ABEL je ca.

10kDM ohne Simulator bezahlt - und die Software war weitaus bescheidener...)

Und mit ein bisschen Routine macht es schon Spass mit ISE zu arbeiten, nur eben async ist meist bitter. Die ISE Entwickler gehen halt vor allem von synchronen designs aus, und damit gibt's deutlich weniger Probleme. Vor allem hält das DFF den Optimierer von allzu dreisten Vereinfachungen ab.

Also zum design: ISE 9.1 macht das was ich ursprünglich gepostet habe, also kein "infering".

Die ISE6.3 und 9.2 übersetzt bei mir wie bei dir, nämlich mit "inferten" Latches:

LDCP_pulse_inv: LDCP port map (pulse_inv,'0',delay_in,'0',width_in); LDCP_pulse_out: LDCP port map (pulse_out,NOT '0',delay_in,width_in,'0');

(Die Option "equation display style Abel" ist meist besser lesbar)

Dabei liefern beide zueinander inverse Outputs mit identischem timing, was sicher wünschenswert ist. Warum bei (width_in = '1') und (delay_in = '1') beide Ausgänge auf '0' sind ist mir nicht so ganz klar. Ist vielleicht ein globales SR netz am Werk ?

Auch instantiieren des Latches und eines Inverters produziert immer den gleichen Output. Das ist schon eine ISE Macke.

Mit einem fiesen Trick gehts, aber man braucht ein Input signal, das immer '1' oder '0' ist (hier always1):

-- rsff inference/instatiation test library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating

---- any Xilinx primitives in this code.

--library UNISIM;

--use UNISIM.VComponents.all;

entity rs_ff_test is Port ( width_in, delay_in, always1 : in std_logic; pulse_out : inout std_logic; pulse_inv : out std_logic ); end rs_ff_test;

architecture Behavioral of rs_ff_test is signal pulse : std_logic;

component ldcp port( clr : in std_logic ; d : in std_logic ; g : in std_logic ; pre : in std_logic ; q : out std_logic) ; end component ;

component inv port( i : in std_logic ; o : out std_logic) ; end component ;

component xor2 port( i0 : in std_logic ; i1 : in std_logic ; o : out std_logic) ; end component ;

begin

-- Ausgangszuweisungen: pulse_out pulse_out , i1 => always1 , o => pulse_inv );

--pulse_inv width_in , d => '1' , g => delay_in , pre => '0' , q => pulse );

end Behavioral;

das generiert dann folgende Gleichungen:

pulse_inv

Winfried Salomon schrieb:

Zumindest das erste habe ich gemacht. (Fürs zweite reichen meine Fähigkeiten im Englischen nicht).

Nach einigen emails ist jetzt auch klar, dass das LDCP-Register im Coolrunner II sich nicht so verhält, wie es ein LDCP laut Dokumentation soll. Die Preset-Leitung hat eine niedrigere Priotität als das Gate-Signal. Preset sollte aber nach der Doku eine höhere Priorität haben als Gate. Die Lösung, die Xilinx vorschlägt, ist eine kombinatorische Beschreibung.

Bisher noch nicht beantwortet wurde die Frage, ob es in absehbarer Zeit ein Update für die ISE geben wird, in der das Problem berücksichtigt wird.

Übrigens betrifft das Problem auch die Coolrunner 3 Serie (XCR3...). Ich konnte das gleiche Problem bei einem XCR3064XL sehen.

Mathias.

Hallo Mathias,

Mathias Weierganz schrieb:

die werden sich auch so wundern, hoffe ich.

Bei mir werden auch LDCP eingesetzt mit der Merkwürdigkeit, daß der ChipViewer die 2 Eingänge nicht verbunden anzeigt. In der Simulation merkt man nichts, außer daß der LDCP womöglich nur als Behavioral-Modell simuliert wird, was auch nicht sein darf.

Beim Versuch, die Eingänge "gleichzeitig" von 1 auf 0 gehen zu lassen, müßte ja die Metastabilität zuschlagen, aber nix zu sehen :-(. Das ist bei mir so ein Plausibilitätstest von Digitalsimulatoren, ob die sowas überhaupt erkennen und warnen. Bei ALDEC früher (Xilinx bis Vers. 4.2) meine ich, daß es so gewesen ist.

Das sieht auch so wie erwartet aus, nur etwas langsamer. Vor Metastabilität wird hier zwar nicht gewarnt, aber die Postfit-Simulation zeigt Dauerschwingungen an, die man auf jeden Fall sieht.

So ähnliches Verhalten hatte ich auch mal mit PSPICE gesehen mit analogen Gattermodellen (natürlich alles nicht wirklichkeitsnah), kann man also noch durchgehen lassen.

Ich kann kaum glauben, daß so 1 elementarer Bug noch nicht aufgefallen ist. Mir kam es manchmal auch schon so vor, als wäre ich der einzige, der sich mit diesen Dingen beschäftigt. Ich benutze CPLDs der 9500er Serie, Probleme gab's da auch, aber andere. Müßte eigentlich mal testen, ob das mit dem LDCP da auch so falsch läuft.

Wenn die den Bug in Dokumentation und Software nicht beseitigen, scheinen vielleicht sämtliche CPLDs betroffen zu sein. Wer weiß, wen das alles schon Nerven gekostet hat.

mfg. Winfried

Winfried Salomon schrieb:

Ich kann auch kaum glauben, dass ich der erste bin, der auf diesen Fehler gestoßen ist.

Xilinx hat mir übrigens ein Preprint eines neuen Answer-Records geschickt, in dem dieses Fehlverhalten beschrieben wird und in dem auch die Hoffnung auf ein Software-upgrade geweckt wird. (Nr 29551, ich weiß aber nicht, ob die Nummerierung schon endgültig ist; keywords: latch, CRII, HDL, VHDL, CPLD, LDP, LDCP). Dannach ist die 9500er Serie nicht betroffen.

Es ist im übrigen kein Fehlverhalten der Hardware, sondern Modell und Beschreibung sind falsch. Hat der Xilinx-Mensch extra betont...

fröhliches Debuggen

Mathias