Verilog Syntax

[Sivas J. (sivas)]

Guten Tag liebes µC-Forum,

seit kurzem versuche ich mich an diesem guten Stück hier: 
https://embeddedmicro.com/mojo-v3.html
Außerdem hab ich dieses Buch an meiner Seite: 
https://www.amazon.de/Verilog-Modellbildung-Verifikation-Grundlagen-Informationstechnik/dp/3486580043/ref=sr_1_1?ie=UTF8&qid=1489068748&sr=8-1&keywords=verilog+modellbildung

Ich bin ein wenig durch die Tutorials von embeddedmicro "gerast" und geh 
diese jetzt wieder durch, Step-by-Step und Zeile für Zeile. Jedoch stell 
ich nun fest, dass mir die Modul-Beschreibung, wie sie in den Tutorials 
gemacht wird, ziemlich unverständlich ist.
Ich versuche die Module tatsächlich aufs Papier zu skizzieren um mir ein 
Bild vom Ablauf und den Bauteilen zu machen.

In diesem Tutorial hier 
(https://embeddedmicro.com/tutorials/mojo/synchronous-logic) soll nun 
ein DFF realisiert werden, ich verstehe aber nicht, woher Verilog weiß, 
was alle Ein- und Ausgänge sind.
Bei diesem Code

module blinker(
    input clk,
    input rst,
    output blink
  );
   
  reg [24:0] counter_d, counter_q;
   
  assign blink = counter_q[24];
   
  always @(counter_q) begin
    counter_d = counter_q + 1'b1;
  end
   
  always @(posedge clk) begin
    if (rst) begin
      counter_q <= 25'b0;
    end else begin
      counter_q <= counter_d;
    end
  end
   
endmodule

werden doch counter_d und counter_q nie als In- oder Output deklariert. 
Woher weiß Verilog nun, dass das eine ein Eingang und das andere ein 
Ausgang sein soll.

Für jede Hilfe bin ich dankbar (ich denke, man merkt, dass ich noch am 
Anfang stehe)

MfG, Sivas!

[Michael B. (laberkopp)]

Andi X. schrieb:
> werden doch counter_d und counter_q nie deklariert.

Doch, hier:

Andi X. schrieb:
> reg [24:0] counter_d, counter_q;

Andi X. schrieb:
> dass das eine ein Eingang und das andere ein Ausgang sein soll.

Ist es doch gar nicht. Das sind verborgene counter-Register, wobei 
counter_d eventuell wegoptimiert wird. Nur das höchstwertige Bit von 
counter_q wird als blink nach aussen gegeben.

[Sivas J. (sivas)]

Aber ein DFF hat doch tatsächlich einen D-Eingang und Q-Ausgang, wieso 
kann ich die jetzt einfach intern vor sich hinzählen lassen?

[Vancouver (Gast)]

d und q sind zunächst mal nur Signale. Erst durch die Zuweisung

counter_q <= counter_d;

bei einer steigenden Taktflanke wird das ganze zu einem Register aus 
einzelnen D-FFs. Was dabei Eingang und Ausgang sein muss, ergibt sich 
direkt aus dieser Zuweisung.

[Sivas J. (sivas)]

Also mache ich durch
counter_q <= counter_d;
mein counter_q automatisch zum Ausgang, weil es mit counter_d befütter 
(welches dann automatisch zum Eingang wird)?
Mir kommt das so furchtbar vage vor...

[Vancouver (Gast)]

Abc X. schrieb:
> Also mache ich durch
> counter_q <= counter_d;
> mein counter_q automatisch zum Ausgang, weil es mit counter_d befütter
> (welches dann automatisch zum Eingang wird)?

Genau so ist es.

> Mir kommt das so furchtbar vage vor...

Ja, ging mir anfangs auch so. Aber das ist genau die Semantik eines FFs: 
Übernehme den Wert des Eingangs an den Ausgang, sobald eine steigende 
Taktflanke kommt. Genau das beschreibt das zweite always-Statement in 
Deinem Code. Das entscheidende ist hier die Auswertung des clk-Signals. 
Ohne clk wäre es einfach eine Zuweisung von Signalen, ohne Eingang und 
Ausgang zu definieren.

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

BTW: hinter "posedge" sollte in einem einfach wartbaren synchronen 
Design (im Besonderen in jedem Anfängerdesign) immer das selbe stehen.

Wenn nicht, dann hast du mehrere Taktdomänen in deinem Design und das 
geht idR. übel aus, wenn es unbewusst gemacht wurde. Du wirst noch 
darüber stolpern, wichtig ist nur, dass dir dieser Satz dann schnell 
wieder einfällt, denn sonst suchst du tagelang an dem Fehler... ;-)

[Sivas J. (sivas)]

Uff, dann hab ich ja noch ein bisschen was vor mir ^^'
Naja, erstmal vielen Dank für die schnelle Hilfe! Habs für diesen Fall 
erstmal verstanden (verinnerlichen kommt noch...)

Nur noch eine Kleinigkeit. Da ich mit dem Board gerne weitermachen 
würde, lohnt sich dieses Buch hier? 
https://www.amazon.de/Learning-FPGAs-Digital-Design-Beginners/dp/1491965495/ref=sr_1_1?ie=UTF8&qid=1489073483&sr=8-1&keywords=fpga+mojo

[Vancouver (Gast)]

Schwer zu sagen. Ist noch nicht lieferbar und es gibt nicht mal ein 
Inhaltsverzeichnis. Ich würde erst mal mit Verilog weitermachen und die 
Sprache richtig lernen, anstatt gleich zu einer exotischen HDL-Sprache 
(Lucid) zu wechseln, die kaum jemand verwendet. Zu Verilog gibts 
Literatur wie Sand am Meer.

[Sivas J. (sivas)]

Alles klaro, danke!