VERILOG in VHDL Code

[Bastian Cpunkt (Gast)]

Hallo liebe FPGA-VHDL-Microcontroller-Gemeinde,
aktuell beschäftige ich mich mit meinem FPGA und dem damit gelieferten 
,,First Project"-Tutorial

Ich arbeite mit dem DE0-Nano Board.

Nach dem ich das Tutorial abgearbeitet habe und alles funktioniert hat, 
wollte ich es anpassen, erweitern und den entsprechenden Aufwärtszähler 
in VHDL selbst schreiben und implementieren. Um mehr Übung zu bekommen.

Der mitgelieferte Code (leider in Verilog, habe ich Null-erfahrung mit):

module simple_counter 
(
  CLOCK_5,
  counter_out
);
input CLOCK_5 ;
output [31:0] counter_out;
reg [31:0] counter_out;

always @ (posedge CLOCK_5)
begin
  counter_out <= counter_out + 1;
end
endmodule

Mein eigens geschriebener Code in VHDL sieht wie folgt aus:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity simplecount is
PORT    (
                clk:  in   std_logic;
    res:   in   std_logic;
    y:    out   std_logic_vector(31 downto 0)
        );
end simplecount;

architecture verhalten of simplecount is
SIGNAL ctr_s: unsigned(31 downto 0);
CONSTANT zero: unsigned(31 downto 0) :=(others => '0');

BEGIN

  ctr: PROCESS(clk, res)
  BEGIN  
    IF res ='1' then
      ctr_s <= zero;
    ELSIF clk'event and clk ='1' then
        ctr_s <= ctr_s+1;
    end if;
  end PROCESS ctr;

  y<=std_logic_vector(ctr_s);
  
END verhalten;

Wie ihr euch denken könnt funktioniert es nicht, daher auch die Bitte 
nach Unterstützung.

Ist der Code von mir korrekt?


Vorab, schonmal vielen Dank.
Beste Grüße,
Bastian.

[peter (Gast)]

Hallo,schau mal mit Google "vdhl ...."
Dann bekommst du sehr viel in VHDL, auch dein Wunschprogramm.

Das umschreiben von Verilog bringt nur etwas wenn man Verilog kennt.

Ich Spiele auch mit Verilog, ist nicht so schwer, weil es "C"-lastig 
ist.
Eigentlich ist Verilog leichter zu erlernen. Habe mal einiges erstellt 
damit.

Mit VHDL tue ich mich auch schwer.

Gruss

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

peter schrieb:
> Ich Spiele auch mit Verilog, ist nicht so schwer, weil es "C"-lastig
> ist.
Zum Thema "Verwandtschaft von Verilog und C" (seit wann hat C eigentlich 
begin und end und := Zuweisungen wie Pascal?) das hier:
Beitrag "Re: SPLD (GAL) - welche Software"
Und das:
Beitrag "Frage zur Lernkurve VHDL vs. Verilog"

Bastian Cpunkt schrieb:
> Mein eigens geschriebener Code in VHDL sieht wie folgt aus:
> ....
> Wie ihr euch denken könnt funktioniert es nicht
Wie hast du das festgestellt? Gab es eine Fehlermeldung? Welche?

> daher auch die Bitte nach Unterstützung.
Bitte mach die vhdl-Tokens um den VHDL-Code:

[vhdl]VHDL-Code[/vhdl]

> Ist der Code von mir korrekt?
Er entspricht wegen des zusätzlichen asynchronen Resets nicht der 
Verilog-Beschreibung.

Warum schreibst du den Reset nicht so:

ctr_s <= (others=>'0');

Dann brauchst du die Konstante nicht...

[Bastian M. (bastiancmitpunkt)]

Guten Tag,
es war von mir beabsichtig ein asynchronen Reset zu integrieren.

Festgestellt das es nicht funktioniert, habe ich: Die angesteuerten LED 
zeigten keine Reaktion.

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

Bastian Cmitpunkt schrieb:
> es war von mir beabsichtig ein asynchronen Reset zu integrieren.
Das hast du gemacht.

> Festgestellt das es nicht funktioniert, habe ich:
> Die angesteuerten LED zeigten keine Reaktion.
Welche Reaktion hätten Sie denn zeigen sollen?
Wo sind die LEDs angeschlossen? Warum simulierst du deine Beschreibung 
nicht einfach? Der Simulator ist für VHDL das, was in C der Debugger 
ist!

[59154 (Gast)]

Lothar Miller schrieb:
> Der Simulator ist für VHDL das, was in C der Debugger
> ist!

Nicht so richtig.
Dem Debuggen in C kommt eher so etwas wie Chipscope am nächsten.

[Schlumpf (Gast)]

59154 schrieb:
> Dem Debuggen in C kommt eher so etwas wie Chipscope am nächsten.

Schonmal im Chipscope nen Breakpoint gesetzt?

[abc123 (Gast)]

Schlumpf schrieb:
> Schonmal im Chipscope nen Breakpoint gesetzt?

naja, wenn man lustig wäre könnte man ja mit dem TrigOut von Chipscope 
alle ClockEnables jedes FlipFlops auf low setzen und somit alles lahm 
legen ;-) Dann könnte man auch mit einem VIO SingleClock Pulses (für 
einen Takt das Clock Enable Signal auf high setzen) machen und so durch 
die Logik steppen.

Nicht gleich in der Luft zerfetzen, es war nur ein Gedankenexperiment, 
was aber gehen könnte und auch funktionieren würde. Man muss nur jedem 
FlipFlop ein ClockEnable spendieren. Aber auch in C muss ja extra Code 
zum Debuggen reingepackt werden, um einen Breakpoint setzen zu können. 
So weit ist das also nicht weg ;-)

Schönen Abend noch!

[Schlumpf (Gast)]

abc123 schrieb:
> naja, wenn man lustig wäre könnte man ja mit dem TrigOut von Chipscope
> alle ClockEnables jedes FlipFlops auf low setzen

Stimmt, könnte man. Aber dazu muss man schon sehr, sehr lustig sein :-)

> Man muss nur jedem FlipFlop ein ClockEnable spendieren.

In deinem Quellcode, den du prüfen willst.. sehr unschön, oder?

> Aber auch in C muss ja extra Code zum Debuggen reingepackt werden, um einen 
Breakpoint setzen zu können.

Also ich musste in C bisher noch nie meinen QUELL-Code umbauen, dass ich 
durchsteppen konnte.

Ganz abgesehen von dieser eher philosophischen Frage halte ich von 
Chip-Scope nicht viel.

Ob der Code das macht, was er machen soll, wird in der Simulation 
geklärt.
Kommt es dann auf dem Target zu Problemen, liegt das entweder daran, 
dass der Code an einer Stelle "unsauber" ist (z.B. nicht synchron) oder 
die Constraints nicht korrekt gesetzt sind.
Packt man dann diesen "Schnüffler" mit in das Design, so ist das Layout 
des Designs ziemlich sicher ein anderes, als wenn Chipscope nicht mit 
auf dem Chip wäre. Daraus ergeben sich dann andere Laufzeiten und somit 
tritt unter Umständen das Problem, nach welchem man sucht, gar nicht 
mehr auf.

[59154 (Gast)]

Was ich meinte ist, dass eine Programm in C Debugger auf der realen 
Hardware läuft, während das bei einem HDL Simulator nicht der Fall ist. 
Es gibt durchaus Fälle, bei denen sich ein Design auf echter Hardware 
anders verhält als in einem Simulator, auch wenn die Tools meinen, dass 
das Timing stimmt. Bei so einfachen Designs wie diesem ist das 
vermutlich eher nicht der Fall, bei großen komplexen Designs kann das 
aber passieren. Und abgesehen davon kann man in einem Simulator vieles 
nicht simulieren, zum Beispiel Hardware IP Blöcke.

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

59154 schrieb:
> Es gibt durchaus Fälle, bei denen sich ein Design auf echter Hardware
> anders verhält als in einem Simulator, auch wenn die Tools meinen, dass
> das Timing stimmt. Bei so einfachen Designs wie diesem ist das
> vermutlich eher nicht der Fall
Das hat mit der Größe und Vermutungen nichts zu tun: ich kann dir ein 
ganz simples und einfaches Design zeigen, das tadellos simuliert, aber 
in der Hardware laufend Probleme macht und irgendwie seltsames Verhalten 
aufweist. Du musst nur ein asynchrones Signal nicht einsynchronisieren.

Es reicht schon aus, einen asynchronen Reset zu verwenden. Dann läuft 
evtl. ein Teil des Designs jetzt los, und der Rest erst einen Takt 
später. Das sind dann die Designs, die "manchmal nicht richtig 
anlaufen", aber wenn sie mal laufen, dann tagelang ohne Probleme...

59154 schrieb:
> Was ich meinte ist, dass eine Programm in C Debugger auf der realen
> Hardware läuft, während das bei einem HDL Simulator nicht der Fall ist.
Was ich meinte, ist, dass der ERSTE Schritt für eine (Teil-)Komponente 
in VHDL der Simulator ist. Klar kann man jetzt Pfennigfuchsen, ob der 
Simulator jetzt genau dem Debugger entspricht oder nicht.
Es ist nur so, dass ohne lauffähigen Debugger auch Softwareentwicklung 
unglaublich zäh und kompliziert ist. Und das selbe gilt für VHDL und den 
Simulator.

[Christian R. (supachris)]

Lothar Miller schrieb:
> Es ist nur so, dass ohne lauffähigen Debugger auch Softwareentwicklung
> unglaublich zäh und kompliziert ist. Und das selbe gilt für VHDL und den
> Simulator.

Da kommts auch drauf an, wen du fragst. Wir haben hier auch so einen 
"Wissenschaftler" am Institut, knapp über 60, promoviert. Der "braucht" 
auch keinen Debugger, weil er ja alles im Kopf viel besser kann. Und 
sowieso hat er ja schon jede Prozessor in ASM und C programmiert, da 
reicht es, wenn man mal das Summary Sheet überfliegt. FPGA macht er 
auch, aber alles in Schematic und Blindflug ohne Simulator. Er hat ja 
einen LA und 5 Testpunkte.

Im Forum hier gibts ja auch jede Menge AVR Freaks, denen eine LED als 
Debugger als völlig ausreichend erscheint.

Naja, was der Bauer nicht kennt, das isst er nicht.

[MaWin (Gast)]

> Zum Thema "Verwandtschaft von Verilog und C"

Es gibt keine.
Vermutlich verwechselt mit System-C.

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

Christian R. schrieb:
> Er hat ja einen LA und 5 Testpunkte.
Man muss sich dazu zwingen, dann geht das schon...

> Im Forum hier gibts ja auch jede Menge AVR Freaks, denen eine LED als
> Debugger als völlig ausreichend erscheint.
Habe ich jetzt gerade: ein ATtiny im 8 Pin Gehäuse, davon 6 IO. Ein 
Tastereingang wird als Debugausgang verwendet. Das ist wirklich 
beschwerlich... ;-)

> Da kommts auch drauf an, wen du fragst. Wir haben hier auch so einen
> "Wissenschaftler" am Institut, knapp über 60, promoviert. Der "braucht"
> auch keinen Debugger
Ich kenne auch das Gegenteil, da wurden von Praktikanten simpelste 
Subkomponenten (Zähler) zu Tode simuliert, weil sie sich nicht an die 
Hardware wagten, vor lauter Angst, etwas kaputt zu machen.

[Christian R. (supachris)]

Lothar Miller schrieb:
> Ich kenne auch das Gegenteil, da wurden von Praktikanten simpelste
> Subkomponenten (Zähler) zu Tode simuliert, weil sie sich nicht an die
> Hardware wagten, vor lauter Angst, etwas kaputt zu machen.

Die kenne ich auch. Das sind dann die, für die es immer die akademische 
"Lösung" sein muss, als nächstes erzeugen die dann VHDL Code aus Matlab 
Simulink Modellen. Solche gibts hier auch.

Lothar Miller schrieb:
>> Er hat ja einen LA und 5 Testpunkte.
> Man muss sich dazu zwingen, dann geht das schon...

Klar, für den allergrößten Notfall schon. Aber der simuliert ja auch 
nix. Der sucht dann einfachste logische Fehler mit den Pins.

Sein schönster Spruch ist ja sowieso: "Ich hab nix geändert, daran 
kann´s nicht liegen". Denn Versionskontrolle usw. ist ja auch 
Teufelszeug.

Achja einen hab ich noch von dem Experten: "Bei mir gibts nur eine 
Version und das ist die aktuelle".

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

Christian R. schrieb:
> Sein schönster Spruch ist ja sowieso:
> "Ich hab nix geändert, daran kann´s nicht liegen".
> Achja einen hab ich noch von dem Experten:
> "Bei mir gibts nur eine Version und das ist die aktuelle".
:-D

[59154 (Gast)]

Lothar Miller schrieb:
> Das hat mit der Größe und Vermutungen nichts zu tun: ich kann dir ein
> ganz simples und einfaches Design zeigen, das tadellos simuliert, aber
> in der Hardware laufend Probleme macht und irgendwie seltsames Verhalten
> aufweist. Du musst nur ein asynchrones Signal nicht einsynchronisieren.

Das stimmt natürlich. Meiner Erfahrung nach häufen sich solche Probleme 
bei größeren Designs aber eher. ^^

Lothar Miller schrieb:
> Was ich meinte, ist, dass der ERSTE Schritt für eine (Teil-)Komponente
> in VHDL der Simulator ist. Klar kann man jetzt Pfennigfuchsen, ob der
> Simulator jetzt genau dem Debugger entspricht oder nicht.
> Es ist nur so, dass ohne lauffähigen Debugger auch Softwareentwicklung
> unglaublich zäh und kompliziert ist. Und das selbe gilt für VHDL und den
> Simulator.

Da hast du natürlich recht, ein Simulator ist ein nützlicher erster 
Schritt bei der Entwicklung eines HDL Designs, genau so wie ein Debugger 
beim der Soiftware Entwicklung sehr nützlich ist. Dann habe ich dein...

> Der Simulator ist für VHDL das, was in C der Debugger
> ist!

... wohl falsch verstanden. ;)