Hallo,
in dem Whitepaper "Get Smart About Reset"
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
von Ben Chapman (Xilinx WP272) wird in Figure 7 eine Art
Schieberegister als Reset Netzwerk beschrieben.
Ich habe versucht diese Schaltung in VHDL nachzubilden um sie dann für
mein Design einzusetzen. Der Code ist der folgende:
Im Anhang findet Ihr das Ergebnis der XST Synthese.(Technology
Schematic)
Wieso baut mir XST da noch ein SRL16 ein. Oder anders gefragt wie
erkläre ich XST das ich da gerne nur die Preset FFs als Schieberegister
hätte?
Viele Grüße
Sven
Denn ein Signal ohne Initialwert wird mit '0' initialisiert. Du willst
im Reset aber mit '1' loslegen, deshalb nimmt die Synthese die
zusätzliche Mimik, um die '0' in den ersten 4 Takten sicherzustellen
:-o
Fazit: "Get Smart About Reset"
> Denn ein Signal ohne Initialwert wird mit '0' initialisiert. Du willst> im Reset aber mit '1' loslegen, deshalb nimmt die Synthese die> zusätzliche Mimik, um die '0' in den ersten 4 Takten sicherzustellen> :-o
Ich bin mir nicht sicher ob das reicht um den PowerUp-Wert der FDP auf
'1' zu ziehen, da im Library Guide steht:
"For FPGA devices, upon power-up, the initial value of this component is
specified by the INIT attribute. If a
subsequent GSR (Global Set/Reset) is asserted, the flop is
asynchronously set to the INIT value."
Das verstehe ich so, das man das GSR-Netzwerk nutzen muss (STARTUP-Block
einbauen) um den Initwert der asynchr. FF zu setzen.
MfG,
Hallo Voltavi,
synthetisiere bitte den von mir oben geposteten Code. Falls wieder so
ein Konstrukt herauspurzelt, dann liegt es an deinen Synthesetool resp.
dessen Einstellungen.
Wenn nicht, dann poste bitten den vollen Code (wenns nicht zuviel ist).
Es könnte sein das das SRL von einem anderen Codeabschnitt stammt und
die Synthese hat beide beim Nutzen gemeinsamer Ressourcen
zusammengetröselt.
MfG,
Die 9.2 Synthese mit Defaulteinstellungen macht auf den ersten Blick aus
allen drei Ansätzen das selbe.
Die Verhaltenssimulation (beginnend mit einem inaktiven Reset:
not_asynch_rst='1') ist natürlich unterschiedlich. Ohne Initwert kommen
5x 'U', sonst eben '1' bzw '0'. Soweit ist das alles nachvollziehbar.
Die P&R-Simulation zeigt dagegen keine 'U' Werte mehr (logisch). Im den
ersten beiden Fällen kommt das selbe heraus. Und im dritten Fall werden
die FFs offenbar auf '0' initialisiert (das war ja so gewünscht),
deshalb kommen am Anfang nur Nullen heraus.
Zumindest die Initialisierung der FFs mit '1' ohne explizite Angabe
eines Init-Wertes ist überraschend.
@ Voltavi
Welche Version verwendest du?
Hast du Syntheseoptionen geändert?
Offenbar übernimmt die Synthese den Resetwert aus der Beschreibung. Mit
einem Code, in dem die Pegel invertiert sind, wird der Initialwert '0'
genommen (im obigen Beispiel war es ja '1'):
1
signalsig_SHIFT_REG:std_logic_vector(NUM_FFS-1downto0);-- kein Initialwert
Vielen Dank,
für Eure tatkräftige Unterstützung.
Für das gepostete Beispiel habe ich ein eigenes Projekt unter ISE 10.1
erstellt. In diesem Projekt habe ich nichts an den Synthesoptionen
verändert. Ich müßte allerdings am Montag gleich einmal prüfen ob ISE
nicht einfach die Syntheseoptionen aus meinen anderen Projekten
übernommen hat. Den FPGA für den das ganze gebaut wurde mußte ich
nämlich auch nicht mehr neu Einstellen. Ist übrigens ein Spartan 3 1200E
-FT256 Speedgrade -4
Zum Thema Initialwert für Signale. Ich verwende sie nur in Testbenches.
Habe bei der ISE bis jetzt auch die Erfahrung gemacht das es sich den
Initialwert aus der Beschreibung für den Reset holt. Wie es andere
Synthesetools halten weiß ich nicht. Habe bis jetzt nur mit XST
gearbeitet.
Darf ich Euch bitten einmal das Technology Schematic von Euren
beispielen zu posten. Mir geht es da vor allem um den Inhalt im "FDP".
Viele Grüße
Sven
Hallo Voltavi,
1) mir war nicht bekannt, das der XST neuerdings zwei verschiedene
schematics generiert. Ich habe hier das RTLschematic gepostet, das zeigt
nur die FF-Kette. Im Technology Schematic taucht dagegen zusätzlich ein
SRL16 auf. Das ist auch nach dem PlaceAndRoute per FPGA-Editor zu
finden, scheint also wirklich erzeugt zu werden.
2) Wenn man wirklich weiss, was man an FF benötigt, dann schreibt man
dies am besten nicht in RTL Beschreibung (wie von Dir), sondern
instanziert direkt. Die Beschreibung der instanzierbaren Grundelemente
findet sich bspw. im spartan3_hdl.pdf (Library Guide) im Verz.
ISE\doc\usenglish\books\docs\spartan3_hdl . Bsp. mit Technology
Schematic liegt bei.
MfG,
> Vielen Dank,>> für Eure tatkräftige Unterstützung.>> Für das gepostete Beispiel habe ich ein eigenes Projekt unter ISE 10.1> erstellt. In diesem Projekt habe ich nichts an den Synthesoptionen> verändert. Ich müßte allerdings am Montag gleich einmal prüfen ob ISE> nicht einfach die Syntheseoptionen aus meinen anderen Projekten> übernommen hat. Den FPGA für den das ganze gebaut wurde mußte ich> nämlich auch nicht mehr neu Einstellen. Ist übrigens ein Spartan 3 1200E> -FT256 Speedgrade -4>> Zum Thema Initialwert für Signale. Ich verwende sie nur in Testbenches.> Habe bei der ISE bis jetzt auch die Erfahrung gemacht das es sich den> Initialwert aus der Beschreibung für den Reset holt. Wie es andere> Synthesetools halten weiß ich nicht. Habe bis jetzt nur mit XST> gearbeitet.>> Darf ich Euch bitten einmal das Technology Schematic von Euren> beispielen zu posten. Mir geht es da vor allem um den Inhalt im "FDP".>> Viele Grüße>> Sven
INIT=>'0')-- Initial value of register ('0' or '1')
30
portmap(
31
C=>clk,-- Clock input
32
PRE=>asynch_rst,-- Asynchronous set input
33
D=>s_data(i),-- Data input
34
Q=>s_data(i+1)-- Data output
35
);
36
endgenerate;
37
38
endConnectivity;
Funktioniert bei mir einwandfrei. Es werden immer (C_shiftlength+1)
FlipFlops generiert, und C_shiftlength > 0. Auf diese Weise ist sicher,
dass es immer mindestens 2 FFs sind, damit mindestens einmal geshiftet
wird und somit der sync.Reset mind. für einen vollen Takt anliegt.
Ich habe das jetzt mit dieser Beschreibung auch mal als Technology
Schematic ausgeben lassen. Ergebnis siehe Anhang
(TechSchem_UnInitializedOne.gif).
Das Ergebnis ist das selbe wie bei der manuellen Instantiierung von
dr.schmock (TechSchem_ManuellInstantiiert.gif): es wird kein SRL16 mit
hineingezogen, nur die 5 FFs tauchen auf. Allerdings musste ich für
optisch direkt vergleichbare Ergebnisse noch einen Inverter einbauen
;-)
Ich kann die Ergebnisse von Lothar nur so zusammen fassen, das die ISE
9.2. eine saubere FF-Kette (wie gewünscht) synthesiert, die neuere
Version 10.1 dagegen parallel dazu ein SRL16 erzeugt. Dieser deutliche
Unterschied in der Synthese ist mir eine Anfrage bei Xilinx wert.Wenn
jemand einen Hinweis auf diese Änderung in der Dok etc findet, bitte
hier posten, andernfalls starte ich diese Woche eine Anfrage (WEB-CASE).
MfG,
Lothar Miller schrieb:
>
Zur Info,
ich hab den code mit einer neueren Version (11.3) synthetisiert und
erhalte das gewünschte Ergebnis (ohne SRL). Auf eine Konfrontation mit
den unterschiedlichen Syntheseergbebissen (9.*+11.3: OK; 10.*: NOK) ging
der Xilinx-FAE nicht ein. Da eine neuere Version den Fehler nicht zeigt
hat er es abgelehnt den Code selber zu kompilieren und denn Fall
nachzustellen. Professionelles Qualitätsmanagment sieht anders aus.
Zusammenfassend lässt sich hierzu sagen:
-die FF's direkt instanziieren
-keine 10.* ISE verwenden und das Syntheseergebnisse per RTL technology
view überprüfen
MfG,
Fpga Kuechle schrieb:
> Ich kann die Ergebnisse von Lothar nur so zusammen fassen, das die ISE> 9.2. eine saubere FF-Kette (wie gewünscht) synthesiert, die neuere> Version 10.1 dagegen parallel dazu ein SRL16 erzeugt. Dieser deutliche> Unterschied in der Synthese ist mir eine Anfrage bei Xilinx wert.Wenn> jemand einen Hinweis auf diese Änderung in der Dok etc findet, bitte> hier posten, andernfalls starte ich diese Woche eine Anfrage (WEB-CASE).
Ja ja die Webcase geschichte. Hab damit auch nur mehr schlechte als gute
Erfahrungen gemacht.
Gut zu wissen, nur Schade das mein Projekt komplett auf der ISE 10.1
aufbaut. Kann ich die Bausteine aus der Ise 11.3 auch unter Modelsim XE
6.3 simulieren???? Haben damals die Lizenz zusammen mit der Ise 10.1
erworben.
wenn das funzt dann steig ich sofort auf 11.3 um.
Vielen Dank für die Info Fpga Kuechle .
Dazu musst du die Libs für die CoreGenerator Bausteine neu kompilieren.
Dazu hab ich hier letztens schon mal ausführlich geschrieben, wie das
geht. Allerdings geht die nutzbare Zeilenzahl im ModelSim XE dann immer
weiter runter und er simuliert dann langsamer.
Wider Erwarten ist doch noch Post von Xilinx eingetrudelt:
-Das Verhalten wird s bestätigt, ISE 10 hat einen Bug so dass es SRL16
für FF mit asynchronen FF einzubauen versucht. Dazu gibt es einen
Eintrag in der Datenbank unter CR#479405.
-11.1 und 9.2 sind wie selbst entdeckt OK
-als Workaround kann man das automatische Einsetzen von SRL16
unterdrücken, entweder global (f. das gesamte Desing) oder lokal:
--global: SRL extract von den XST Optionen abwählen
--local: attribute SHREG_EXTRACT (S. 333 of
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/xst.pdf)
Code hängt bei.
Das mit dem lokalen Unterbinden scheint mir der passende workaround zu
sein.
MfG,
Fpga Kuechle schrieb:
> Zur Info,>> ich hab den code mit einer neueren Version (11.3) synthetisiert und> erhalte das gewünschte Ergebnis (ohne SRL). Auf eine Konfrontation mit> den unterschiedlichen Syntheseergbebissen (9.*+11.3: OK; 10.*: NOK) ging> der Xilinx-FAE nicht ein. Da eine neuere Version den Fehler nicht zeigt> hat er es abgelehnt den Code selber zu kompilieren und denn Fall> nachzustellen. Professionelles Qualitätsmanagment sieht anders aus.>> Zusammenfassend lässt sich hierzu sagen:> -die FF's direkt instanziieren> -keine 10.* ISE verwenden und das Syntheseergebnisse per RTL technology> view überprüfen>> MfG,>>> Fpga Kuechle schrieb:>> Ich kann die Ergebnisse von Lothar nur so zusammen fassen, das die ISE>> 9.2. eine saubere FF-Kette (wie gewünscht) synthesiert, die neuere>> Version 10.1 dagegen parallel dazu ein SRL16 erzeugt. Dieser deutliche>> Unterschied in der Synthese ist mir eine Anfrage bei Xilinx wert.Wenn>> jemand einen Hinweis auf diese Änderung in der Dok etc findet, bitte>> hier posten, andernfalls starte ich diese Woche eine Anfrage (WEB-CASE).
> Das mit dem lokalen Unterbinden scheint mir der passende workaround zu> sein.
Dazu müsstest du ja dein ganzes Design analysieren, ob es partiell von
diesem Bug betroffen ist. :-/
Ein Überspringen von auf ISE10 scheint mir der beste Workaround zu
sein...
BTW:
die geraden Versionen waren noch nie die Stärke von Xilinx.
Oder kennt einer noch die ISE6? ;-)