Kette von sync. DFF => Latches?

[Queck S. (Firma: Uni) (kiigass)]

Hi Leutz,

angenommen ich habe sowas:

entity test is
    Port ( a : in  std_logic_vector(7 downto 0);
  clk : in std_logic;
           o : out  std_logic_vector(7 downto 0));
end test;

architecture Behavioral of test is
signal s0,s1,s2,s3,s4,s5,s6,s7 : std_logic_vector(7 downto 0) := (others => '0');
begin
process begin
  wait until rising_edge(clk);
  s0<=a;
  s1<=s0;
  s2<=s1;
  s3<=s2;
  s4<=s3;
  s5<=s4;
  s6<=s5;
  s7<=s6;
  o<=s7;
end process;
end Behavioral;

Das funktioniert in der Simulation super. Das Synthesetool generiert 
daraus eine Kette von synchronen D-Flipflops (siehe Anhang). Die Frage 
ist: würde das in der Realität auch funktionieren oder würde es da 
Latches geben?

Danke für eure Hilfe!
greez Kiigass

[ähmm.. (Gast)]

warum sollte das nicht gehen ?

ist nichts anders als ein Schieberegister.

[S. (Gast)]

Queck Silber schrieb:
> Das funktioniert in der Simulation super. Das Synthesetool generiert
>
> daraus eine Kette von synchronen D-Flipflops

was hattest Du erwartet?

[Sven P. (Gast)]

Ich kann mir denken, was er erwartet hat...

Als Denkanstoß: Diese Zeilen

  s0<=a;
  s1<=s0;
  s2<=s1;
  s3<=s2;
  s4<=s3;
  s5<=s4;
  s6<=s5;
  s7<=s6;
  o<=s7;

könntest du in beliebiger Reihenfolge notieren. Es würde immer zum 
selben Ergebnis führen. Das liegt am Wesen der Prozesse in VHDL, und 
dort an der Art und Weise, wann ein Signal seinen neuen Wert übernimmt.

[Falk B. (falk)]

@Queck Silber (Firma: Uni) (kiigass)

>process begin
>  wait until rising_edge(clk);

wait hat in synthetisierbarem VHDL nix zu suchen.

>Das funktioniert in der Simulation super.

SUPER!

> Das Synthesetool generiert
>daraus eine Kette von synchronen D-Flipflops (siehe Anhang).

SUPER^2!

> Die Frage ist: würde das in der Realität auch funktionieren oder würde es
> da Latches geben?

Dein Syntheseergebnis IST die Realität. Realer geht's nicht.

[Da D. (dieter)]

Falk Brunner schrieb:
> wait hat in synthetisierbarem VHDL nix zu suchen.

kann man so nicht sagen. Gerade ein wait until rising_edge am process 
Anfang kann man sehr gut benutzen, um (synthetisierbare) prozesse ohne 
sensitivity list zu schreiben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Falk Brunner schrieb:
> @Queck Silber (Firma: Uni) (kiigass)
>>process begin
>>  wait until rising_edge(clk);
> wait hat in synthetisierbarem VHDL nix zu suchen.
Uuuups...
Bei mir geht das tadellos, ich machs immer so:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

[Fritz J. (fritzjaeger)]

Queck Silber schrieb:

>

> entity test is
>     Port ( a : in  std_logic_vector(7 downto 0);
>   clk : in std_logic;
>            o : out  std_logic_vector(7 downto 0));
> end test;
> 
> architecture Behavioral of test is
> signal s0,s1,s2,s3,s4,s5,s6,s7 : std_logic_vector(7 downto 0) := (others
> => '0');
> begin
> process begin
>   wait until rising_edge(clk);
>   s0<=a;
>   s1<=s0;
>   s2<=s1;
>   s3<=s2;
>   s4<=s3;
>   s5<=s4;
>   s6<=s5;
>   s7<=s6;
>   o<=s7;
> end process;
> end Behavioral;
>

Spitzfind: da sollte nicht eine Kette sondern acht (parallele) Ketten 
synthetisiert werden.
Praxistip: In einigen FPGA shat es spezielle Schieberegister (z.B. 
Xilinx SRL16) mit der Du die Schiebeketten ressourcenfreundlicher als 
mit FF realisieren kannst.

[Falk B. (falk)]

@  Da Dieter (dieter)

>> wait hat in synthetisierbarem VHDL nix zu suchen.

>kann man so nicht sagen. Gerade ein wait until rising_edge am process
>Anfang kann man sehr gut benutzen, um (synthetisierbare) prozesse ohne
>sensitivity list zu schreiben.

Die ja gerade bei getakteten Prozessen so wahnsinnig komplex ist.

[Fritz J. (fritzjaeger)]

Lothar Miller schrieb:
> Falk Brunner schrieb:
>> @Queck Silber (Firma: Uni) (kiigass)
>>>process begin
>>>  wait until rising_edge(clk);
>> wait hat in synthetisierbarem VHDL nix zu suchen.
> Uuuups...
> Bei mir geht das tadellos, ich machs immer so:
> 
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

Vor einigen jahren hätte Falk noch uneingeschränkt Recht:
http://www.fpgarelated.com/usenet/fpga/show/606-1.php

Inzwischen habe aber die Synthesetools "wait until" gelernt,

"wait for" dagegen nicht.

http://web.ewu.edu/groups/technology/Claudio/ee360/Lectures/vhdl-for-synthesis.pdf

Einschränkungen:
Wait muss die erste Anweisung sein und es darf nur ein wait im process 
geben. Werner muss sich das wait auf eine Taktflanke beziehen.

MfG,

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fritz Jaeger schrieb:
> Vor einigen jahren hätte Falk noch uneingeschränkt Recht:
Und noch ein wenig früher hätte es VHDL gar nicht gegeben...   ;-)

Klar: die Tools entwickeln sich weiter und können immmer mehr vom 
VHDL-Sprachumfang umsetzen. Und man sollte durchaus auch Gebrauch davon 
machen, z.B. bei der Signalinitialisierung (statt eines unnötigen 
Resets):

  signal irgendeinsignal : std_logic_vector(3 downto 0) := "1001";

> Einschränkungen:
> Wait muss die erste Anweisung sein und es darf nur ein wait im process
> geben.
Weder, noch....
http://www.lothar-miller.de/s9y/archives/47-wait-im-Prozess.html

> Werner muss sich das wait auf eine Taktflanke beziehen.
Das ist richtig und hat mit den fehlen Dual-Clock-Flipflops zu tun...

[Axel R. (Gast)]

OT
"Werner" ist gut ;) Einer meiner lieben Kollegen sagt immer "Warnell" ;)
/OT

[Fritz J. (fritzjaeger)]

Axel R. schrieb:
> OT
> "Werner" ist gut ;) Einer meiner lieben Kollegen sagt immer "Warnell" ;)
> /OT

Ist  Hommage an das gestrige Fernsehprogramm (SRTL) ;-)

[Klaus (Gast)]

Falk Brunner schrieb:
> Die ja gerade bei getakteten Prozessen so wahnsinnig komplex ist.

Sorry, aber soll das ein Argument sein? Ein wait ist genau so wenig 
wahnsinnig komplex. Ich kann deinem Gedankengang in diesem Fall leider 
nicht folgen. Außer vielleicht dass die Synthesizer damals(tm) vor 
vielen Jahren das noch nicht unterstützt haben.

[T.M. (Gast)]

Lothar Miller schrieb:
> Klar: die Tools entwickeln sich weiter und können immmer mehr vom
> VHDL-Sprachumfang umsetzen. Und man sollte durchaus auch Gebrauch davon
> machen, z.B. bei der Signalinitialisierung (statt eines unnötigen
> Resets):  signal irgendeinsignal : std_logic_vector(3 downto 0) := "1001";

Und da gehts schon los: Das gilt nicht für alle FPGA Typen. Und wer sagt 
denn, dass ALLE Synthesetools mit wait in getakteten Prozessen 
klarkommen. Oder ich habe hier eine ISE6.1 installiert, weil ich nur 
alte CPLD Typen benutze.

Aus Erfahrung kann ich da nur sagen: Lieber auf einige nette Konstrukte 
verzichten, als in Probleme reinzulaufen. Zumal das wait an der Stelle 
IMHO keinen wirklichen Vorteil bringt, außer der nicht benötigten 
Sensitivitätsliste.

[Stachele (Gast)]

>Oder ich habe hier eine ISE6.1 installiert

Na dann läuft aber etwas falsch ...

[SuperWilly (Gast)]

>Werner muss sich das wait auf eine Taktflanke beziehen.

Aaaah, da ist wieder meine Lieblingsstelle:

process
begin
   wait until (clk = '1');
...
end process;

Ist auch eine Taktflanke ;-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

T.M. schrieb:
> Aus Erfahrung kann ich da nur sagen: Lieber auf einige nette Konstrukte
> verzichten, als in Probleme reinzulaufen.
Hört sich an wie: Lieber Höhlen in Berge hauen und drin hausen als ein 
undichtes Dach zu riskieren.

> als in Probleme reinzulaufen.
Wenn der Synthesizer das nicht kann, dann sagt er es dir schon. 
Ausserdem kann VHDL noch viel mehr, und es wird langsam Zeit, dass die 
Tools es lernen, z.B. auch Dateizugriffe zu synthetisieren. Oder 
wenigstens Zeiten...

SuperWilly schrieb:
> Ist auch eine Taktflanke ;-)
Wenn man mal den (real möglichen) Übergang von 'H' nach '1' ausser 
Betracht lässt...  ;-)

[T.M. (Gast)]

Stachele schrieb:
>>Oder ich habe hier eine ISE6.1 installiert
>
> Na dann läuft aber etwas falsch ...

?

Es gibt zB. Projekte, die vor Jahren begonnen wurden. Da wird am Anfang 
eine Buildumgebung erstellt und festgelegt, die dann bis zum Ende des 
Projektes auch so bleibt. Da wird nicht jeder neuen (verbuggten) ISE 
Version von Xilinx nachgesprungen.

Lothar Miller schrieb:
> T.M. schrieb:
>> Aus Erfahrung kann ich da nur sagen: Lieber auf einige nette Konstrukte
>> verzichten, als in Probleme reinzulaufen.
>Hört sich an wie: Lieber Höhlen in Berge hauen und drin hausen als ein
>undichtes Dach zu riskieren.

Genau das heißt es, überspitzt gesagt. Zum Beispiel im 
sicherheitsrelevanten Umfeld. Da geht man lieber auf Nummer sicher.

[Andreas H. (ahz)]

Queck Silber schrieb:
> Die Frage
> ist: würde das in der Realität auch funktionieren oder würde es da
> Latches geben?

Nein, eigentlich nicht.

Ein Latch ist levelsensitiv, d.h. es "transportiert" D->Q, solange das 
Enable aktiv (z.B. High) ist und hält den Q Wert, wenn Enable inaktiv 
(z.B. Low) ist.

Da Dein Prozess aber nur auf rising_edge ( EDGE = Flanke !!!) reagiert, 
setzt die Synthese dann auch Flipflops ein, die Du in Deinem Bild ja 
auch siehst. (Ich nehme hier an, dass in Deiner Technologie FD ein 
D-Flipflop).

Dadurch werden die Änderungen nur mit der (steigenden) Flanke 
propagiert.

[Andreas H. (ahz)]

Lothar Miller schrieb:
> Klar: die Tools entwickeln sich weiter und können immmer mehr vom
> VHDL-Sprachumfang umsetzen. Und man sollte durchaus auch Gebrauch davon
> machen, z.B. bei der Signalinitialisierung (statt eines unnötigen
> Resets):  signal irgendeinsignal : std_logic_vector(3 downto 0) := "1001";

Ehm, nur für die Akten: Dein "unnötiger" Reset ist nicht immer unnötig.

Bei FPGAs werden die LUTs (meist) beim POR initialisiert, da kann man 
den Reset oft weglassen, falls keine externe Resetsteuerung benötigt 
wird.

Bei ASICs kommen die FFs beim POR aber (mehr oder weniger) zufällig 
hoch. Ohne Reset wirds dann Chaos. Z.B. läuft eine CPU irgendwo los (PC 
= rand()), aber selten da, wo Du es erwartet hättest.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas H. schrieb:
> Bei ASICs kommen die FFs beim POR aber (mehr oder weniger) zufällig
> hoch. Ohne Reset wirds dann Chaos. Z.B. läuft eine CPU irgendwo los (PC
> = rand()), aber selten da, wo Du es erwartet hättest.
Korrekt. Bei ASICS musst du dich auch um den Clock-Tree und das 
Clock-Balancing und evtl. entstehende Race-Conditions (fast) selber 
kümmern...

[Josef G. (bome)]

Ein Reset-Signal ermöglicht es, eine Schaltung oder Teile davon
nicht nur bei der Konfiguration, sondern auch später, zurückzusetzen.

Auch wenn man im FPGA eine Schaltung verifizieren will, die später
auf andere Weise (zB. Antifuse-FPGA) realisiert werden soll, kann
ein Reset-Signal sinnvoll sein.

(Meine Rechtfertigung dafür, mich hier einzumischen: Auch ich
verwende für ein im Forum beworbenes Projekt Reset-Signale.)

[Klaus (Gast)]

Ja, man kann immer bei dieser (jede Woche einmal auftauchenden) 
Diskussion Fälle angeben, in denen ein Reset auch gebraucht wird. Und 
das ist ja auch richtig, diese Fälle gibt es und da braucht man einen 
Reset. Das ändert aber nichts daran, dass in (geschätzten) 95% aller 
FPGA Designs (ich schreibe extra FPGA Designs, nicht VHDL Designs) ein 
expliziter Reset nicht nötig wäre.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus schrieb:
> Das ändert aber nichts daran, dass in (geschätzten) 95% aller
> FPGA Designs ein expliziter Reset nicht nötig wäre.
Richtig. Eher mehr. Denn ein "normaler" User wird bei einem "hängenden" 
System nicht nach einen Reset-Knopf suchen, sondern einfach Aus- und 
wieder Einschalten.

[Andreas H. (ahz)]

Klaus schrieb:
> Das ändert aber nichts daran, dass in (geschätzten) 95% aller
> FPGA Designs (ich schreibe extra FPGA Designs, nicht VHDL Designs) ein
> expliziter Reset nicht nötig wäre.

Lothar Miller schrieb:
> Richtig. Eher mehr. Denn ein "normaler" User wird bei einem "hängenden"
> System nicht nach einen Reset-Knopf suchen, sondern einfach Aus- und
> wieder Einschalten.

Das wiederum kann ich mir kaum vorstellen.
Viele FPGAs sind so verbaut, dass man das Gesamtsystem nicht einfach 
an-/ausschalten kann, z.B. in industriellen Anlagen.

Wo seht ihr die 95% ?

Und nein, ich will nicht Rumtrollen. Ich hab halt immer nur Anwendungen 
vor Augen, wo es eben nicht geht.

[Klaus (Gast)]

Selbst da wo das nicht geht, sitzt bei den Designs, die ich bisher 
gebaut habe, der externe Reset einfach an der Config-Leitung. So dass 
das FPGA einfach neu geladen wird.

[Andreas H. (ahz)]

Klaus schrieb:
> Selbst da wo das nicht geht, sitzt bei den Designs, die ich bisher
> gebaut habe, der externe Reset einfach an der Config-Leitung. So dass
> das FPGA einfach neu geladen wird.

Oh, stimmt. Hat sogar den Vorteil, das Bitkipper in den LUTs gleich 
mitkorrigiert werden wenn der heartbeat mal ausfällt :-)

Ich denk zu sehr in ASIC :-/

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas H. schrieb:
> Viele FPGAs sind so verbaut, dass man das Gesamtsystem nicht einfach
> an-/ausschalten kann, z.B. in industriellen Anlagen.
>
> Wo seht ihr die 95% ?
Wohin verkaufen die Hersteller ihre FPGAs? Das bisschen Industrie macht 
den Kohl da nicht arg fett. Und ein z.B. Umrichter, in dem ein FPGA sein 
könnte hat seinen Reset-Anschluss auch nicht nach aussen geführt...

> Ich hab halt immer nur Anwendungen vor Augen, wo es eben nicht geht.
Oder solche, wo es durchaus ginge, man sich aber nicht getraut hat, den 
Reset einfach weg zu lassen. Ein 74245 hat auch keinen Reset...  ;-)

Andreas H. schrieb:
>> Selbst da wo das nicht geht, sitzt bei den Designs, die ich bisher
>> gebaut habe, der externe Reset einfach an der Config-Leitung. So dass
>> das FPGA einfach neu geladen wird.
> Oh, stimmt. Hat sogar den Vorteil, das Bitkipper in den LUTs gleich
> mitkorrigiert werden wenn der heartbeat mal ausfällt :-)
So oft und leicht kippt so ein Konfigbit auch nicht um...  ;-)

[Josef G. (bome)]

Andreas H. schrieb:
> z.B. in industriellen Anlagen.

Lothar Miller schrieb:
> Und ein z.B. Umrichter,

Sehr interessant sind in diesem Zusammenhang die
Sicherheitshinweise von Xilinx ("Limited Warranty"),
wo darauf hingewiesen wird, wo überall man FPGAs
nicht einsetzen darf.

[Andreas H. (ahz)]

Lothar Miller schrieb:
> Wohin verkaufen die Hersteller ihre FPGAs? Das bisschen Industrie macht
> den Kohl da nicht arg fett. Und ein z.B. Umrichter, in dem ein FPGA sein
> könnte hat seinen Reset-Anschluss auch nicht nach aussen geführt...
>
Oh, ich meinte mit industriellem Markt nicht nur den Markt für 
Werkzeugmaschinen. Denk z.B. an Windräder, Rolltreppen, elektrische 
Drehtüren, <endless list truncated>
Also alles was nicht Consumer/Medical/Automotive ist.

100K Stück/p.a. sind im industriellen Umfeld nicht ungewöhnlich.
Pro Geräteserie, pro Hersteller.

Es gibt ja viele "Mittelständler", die weltweit Marktführer auf ihrem 
Gebiet sind und auch weltweit liefern. Und deren Konkurenz gibts ja auch 
...

Für Die rechnen sich ASICs aus verschiedenen Gründen nicht 
(time-to-market, NRE-cost, no field-update ... ). Also weicht man im 
digitalen Bereich ggf. auf FPGAs aus.

Angeblich benutzten auch größere Router FPGAs weil sie besser im Feld 
upgradbar sind (hörensagen über einen Ex-Nokia Entwickler aus diesem 
Bereich).

Da kommen durchaus Stückzahlen zusammen.


> Oder solche, wo es durchaus ginge, man sich aber nicht getraut hat, den
> Reset einfach weg zu lassen. Ein 74245 hat auch keinen Reset...  ;-)
Der '245 hat auch keine States, die man setzen könnte ;-)

> So oft und leicht kippt so ein Konfigbit auch nicht um...  ;-)
Wenn es umfallen kann muss man aber in einer FMEA das Risk bewerten.
Da ist es Vorteilhaft, ggf. einen einfachen Mechanismus angeben zu 
können, der diesen Faultcase recovert ;-)

[Andreas H. (ahz)]

Josef G. schrieb:
> Sehr interessant sind in diesem Zusammenhang die
> Sicherheitshinweise von Xilinx ("Limited Warranty"),
> wo darauf hingewiesen wird, wo überall man FPGAs
> nicht einsetzen darf.

Ich dachte, das machen die wegen Regressvermeidung.
Das US-Recht hat ja da echt "seltsame" Auswüchse :/

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Josef G. schrieb:
> ("Limited Warranty"),
> wo darauf hingewiesen wird, wo überall man FPGAs nicht einsetzen darf.
http://www.xilinx.com/warranty.htm
Ich finde nichts...

> wo darauf hingewiesen wird, wo überall man FPGAs nicht einsetzen darf.
Ja, und wenn man es trotzdem tut, ist man selber schuld. DARUM geht es 
Xilinx. Solche Floskeln haben alle Hersteller im Angebot....

[Josef G. (bome)]

Lothar Miller schrieb:
> Ich finde nichts...

Abschnitt: Critical Applications Disclaimer

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ja, das was dort steht, das steht aber bei jedem Halbleiterhersteller, 
der nicht speziell für lebenserhaltende oder sichere Systeme entwickelt.
Und deshalb werden z.B. in der Sicherheitstechnik zweikanalige Systeme 
verwendet, sobald es über Kategorie 1 rausgeht...

Andreas H. schrieb:
>> So oft und leicht kippt so ein Konfigbit auch nicht um...  ;-)
> Wenn es umfallen kann muss man aber in einer FMEA das Risk bewerten.
> Da ist es Vorteilhaft, ggf. einen einfachen Mechanismus angeben zu
> können, der diesen Faultcase recovert ;-)
Ja, nur geht dieses Recovery eben nicht über einen Resetzustand im 
FPGA, sondern nur und ausschliesslich über eine Neukonfiguration des 
FPGAs. Und dass sowas sinnvoll sein kann, das sehe ich sofort ein.