State Machine mit "Unterroutinen"

Solche Synthesewerkzeuge führen eine sehr radikale Optimierung durch, 
d.h. auch auf Bitebene von Registern. Und wenn sich dabei herausstellt, 
dass sich in einem Register ungenutzte Bits befinden, werden diese 
entfernt und eine Warnung ausgegeben, denn vielfach deutet so etwas auf 
einen Fehler hin. Wenn man aber z.B. einen Peripherieblock mit einem 
externen Businterface baut, indem man einen Registerbereich mit 8/16/32 
Bit anlegt, aber nicht in jedem Register jedes Bit verwendet, bekommt 
man auch solch eine Warnung um die Ohren gehauen. Dies löse ich meist 
so, dass ich alle beschreibbaren Register miteinander "verxodere" und 
das Resultat über ein lesbares Register ausgebe.

Bei Deiner Beschreibung hast Du feste Vorgaben bezüglich der 
FSM-Zustandswerte gemacht. Dies ist eine typische Vorgehensweise in der 
Softwareentwicklung, aber bei programmierbarer Logik definiert man 
lieber einen eigenen Datentyp für jede FSM und überlässt dem Werkzeug 
die Implementierung. Dann ist es auch keine Warnung mehr wert, wenn 
intern optimiert wird. Viel wichtiger ist dabei jedoch, dass das 
Werkzeug sogar einen Fehler erzeugt, wenn man in der FSM einen Zustand 
gar nicht verwendet. Man macht also durch die Typdefinition eine 
Vorgabe, was die FSM machen soll und nicht wie sie es darstellen 
soll. Das Werkzeug hat Defaulteinstellungen für die interne Darstellung 
von FSMs (binär, Gray, one hot, usw.), die man aber durch Anweisungen 
global oder für die einzelne FSM ändern kann. Und man bietet dem 
Werkzeug die Möglichkeit, nach eigenem Gutdünken zu optimieren statt 
sinnlosen strikten Vorgaben des Entwicklers zu folgen.

Da ich bisher noch nicht in Verilog, sondern nur in VHDL entwickelt 
habe, gelten die obigen Ausführungen natürlich für VHDL. Ich gehe aber 
sehr schwer davon aus, dass es bei Verilog genauso gehandhabt wird.

egon schrieb:
> Die Defitition der FSM-Zustandswerte ist aus den Language-Templates
> der WebISE und auch im Buch "FPGA Prototyping By Verilog Examples"
> wird dies so gemacht.

Oha, ich habe mir auch gerade ein paar FSM-Beispieldefinitionen im 
Internet angeschaut und bin entsetzt darüber, dass man in Verilog 
offenbar wirklich so vorgehen muss. In VHDL würde ich schreiben:

1

TYPE t_state is (IDLE, DO_THIS, DO_THAT);

2

3

SIGNAL my_state : t_state := IDLE;

Vorteil und Nachteil gleichzeitig ist dabei, dass die dabei definierten 
Werte nur Gültigkeit für die Verwendung mit Signalen/Variable des Typs 
my_state besitzen. Würde man einen weiteren Datentyp definieren, dürfte 
man die schon zuvor definierten Werte nochmals aufführen, und sie 
besäßen dann auch nur in diesem neuen Datentyp ihre Gültigkeit.

Wenn man die Werte nach "außen" sichtbar machen möchte, benötigt man auf 
jeden Fall eine explizite Abbildung auf entsprechende Bitmuster.

1

SIGNAL my_register : STD_LOGIC_VECTOR(2 downto 0);

2

3

...

4

5

with my_state select

6

  my_register <= "001" when IDLE,

7

                 "101" when DO_THIS,

8

                 "110" when DO_THAT,

9

                 "000" when others;

> WebISE 13.1

Was soll eigentlich WebISE sein? Ich kenne nur das Xilinx ISE Webpack.

Falls es sich um letzteres handeln sollte, wundere ich mich ziemlich 
darüber, dass Du eine uralte Version statt der "aktuellen" Version 14.7 
verwendest. Im Laufe der Zeit hat Xilinx immer mehr ursprünglich 
kostenpflichtige Module (z.B. Microblaze, EDK, ILA) kostenfrei 
beigelegt.

Andreas S. schrieb:
> Dies löse ich meist so, dass ich alle beschreibbaren Register
> miteinander "verxodere" und das Resultat über ein lesbares
> Register ausgebe.

Das klingt nach ... ziemlich viel Umstand für einen Mangel im Tool (um 
es nicht "pfuschen" zu nennen). Gibt es da keine bessere Lösung?

Mich stören an VHDL in erster Linie die vielen Warnungen, die mir Dinge 
mitteilen, die (für mich) schlicht nicht relevant sind. Ist ja schön, 
dass man meinen Prozess noch optimieren kann, aber davon gehe ich aus.

Übliche C-Compiler kriegen das gefühlt besser hin, mich auf die 
wesentlichen Dinge hinzuweisen. ISE und Vivado ertränken mich lieber in 
Rauschen.

egon schrieb:
> Ja vielleicht muss ich irgendwann mal auf VHDL umsteigen. Als ich
> angefangen hab war Verilog für mich einfacher zu lesen.

Ich habe mich ganz bewusst für VHDL statt Verilog entschieden, weil 
Verilog sehr C-ähnlich aussieht. Wenn man gleichzeitig an der FPGA-Logik 
und an der Firmware entwickelt, sorgt ein größerer sprachlicher 
Unterschied dafür, dass der Wechsel zwischen den Welten besser gelingt.

> Der unterstütze Verilog Standard von der ISE ist von 2001 sprich uralt.

Xilinx bekleckert sich bezüglich der Sprachstandards nicht wirklich mit 
Ruhm. Die Unterstützung für VHDL 2008 war in ISE sogar besser als in 
Vivado, aber allmählich holt auch Vivado auf. Allerdings darf man kein 
VHDL 2008 verwenden, wenn man daraus einen IP-Block generieren will. 
Welch ein Murks... Ich weiß leider nicht, ob es bei Xilinx auch 
entsprechende Einschränkungen bezüglich der verschiedenen 
Verilog-Versionen gibt.

In dem folgenden Dokument werden ab Kapitel 5 die jeweils durch Vivado 
2019.1 unterstützten Sprachelemente aufgeführt:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug901-vivado-synthesis.pdf

> In SystemVerilog macht man die FSM-Zustandswertdefinition anscheinend
> so:
>
> enum {RED, GREEN, YELLOW} State, Next;

Aha, das ist natürlich gut.

> Sorry WebIse ist natürlich quatsch. Ich benutze Xilinx ISE WebPack.

OK.

> Ich weiss die Version ist recht alt. Ich war froh das die Version dann
> irgendwann endlich lief inkl. Impact und Modelsim.
> Unter Windows 10 ist das doch recht fummelig (Ja gibt auch eine für W10
> aber die kann kein Spartan 3 usw. usw.).

Ja, ggf. muss man die spezielle W10-Version von ISE 14.7 installieren 
und anschließend von einem anderen Rechner mit einer alten ISE 14.7 ein 
paar Bibliotheken rüberkopieren. Hierzu findet man auch ein paar 
Anleitungen im Netz.

> Bisher gabs es keinen Grund wechseln weil ich eh nur kleinere Sachen
> mache.

Naja, es geht dabei nicht um die Größe der Projekte, sondern um die 
genutzten Leistungsmerkmale.

Vancouver schrieb:
> Wobei VHDL-2018 auch schon wieder gut aufgeholt hat.

Bevor VHDL-2018 in Vivado realisiert ist, friert die Hölle zu. Irgendwie 
erinnert mich das an den C++-Compiler von Microsoft Visual Studio, der 
häufig auch um viele Jahre hinter dem ANSI/ISO-Standard zurückgeblieben 
ist; MS versucht aber offenbar, dadurch eigene, zum Standard 
imkompatible Funktionen usw. durchzudrücken, so dass der Wechsel zu 
einem anderen Compiler und womöglich Betriebssystem absichtlich 
erschwert wird. Xilinx ist natürlich auch an Marktanteilen interessiert, 
aber ich vermute, dass sie einfach mit dem dem riesigen Softwaremolloch 
namens Vivado völlig überfordert sind. Dies sieht man z.B. daran, dass 
zwar VHDL-2008 unterstützt wird, aber nicht für IP-Blöcke.

Das alte Verilog (ohne System-) ist jedenfalls ziemlich
> off.

Es gibt Unmengen an Verilog-Codebeständen, die man auch nicht so einfach 
ersetzen kann. (Zumindest ältere) ARM-Prozessoren sind z.B. in Verilog 
geschrieben. Somit wird Verilog noch ewig leben.

> Andreas S. schrieb:
>> sorgt ein größerer sprachlicher
>> Unterschied dafür, dass der Wechsel zwischen den Welten besser gelingt.
>
> So unterschiedlich sind die Geschmäcker. Ich bin immer froh, wenn ich
> nicht dauernd zwischen zwei verschiedenen "Syntaxen" umschalten muss.

Oh, ich habe mich etwas ungünstig ausgedrückt. Wesentlich passender 
wäre:
"... sorgt ein größerer sprachlicher Unterschied dafür, dass die
Unterscheidung zwischen den Welten besser gelingt."