Verstehe Simulationsergebnis nicht

[Steffen Hausinger (Gast)]

Hallo zusammen,

ich möchte gerne einen SJA1000 softcore auslesen. Dazu schalte ich nach 
einem "ALE" das "RD" Signal auf high, um ein automatisches Auslesen 
anzustossen. Leider funktioniert das Auslesen nicht, wenn ich "RD" nur 
für einen Takt auf high setze. Siehe Variante (A).

Variante (A) mit SJA1000_rd für 1 clk auf high gesetzt:

always @(posedge clk)
begin : SJA1000_autoread_proc
   integer rd_ctr = 0 ; // Just a sample counter for rd signal
      begin

      SJA1000_rd = 0;
      if (SJA1000_ale == 1)
         begin
         rd_ctr = 0 ;
         end
      if (rd_ctr < 1)  // SJA1000_rd high for ONE clk cycle
         begin
         SJA1000_rd = 1;
         rd_ctr = rd_ctr + 1;
         end
      end
   end

Wenn ich "RD" dagegen für zwei Takte auf high setze, klappt alles 
wunderbar. Das Kuriose ist jedoch: Es kommen bereits schon beim ersten 
Takt gültige Werte auf dem Port! Siehe Variante (B).

Variante mit SJA1000_rd für 2 clk gesetzt:

always @(posedge clk)
begin : SJA1000_autoread_proc
   integer rd_ctr = 0 ; // Just a sample counter for rd signal
      begin

      SJA1000_rd = 0;
      if (SJA1000_ale == 1)
         begin
         rd_ctr = 0 ;
         end
      if (rd_ctr < 2)  // SJA1000_rd high for TWO clk cycles
         begin
         SJA1000_rd = 1;
         rd_ctr = rd_ctr + 1;
         end
      end
   end

(Die Simulationsergebnisse findet ihr jeweils im Anhang.)

Warum ist das so? Zum Zeitpunkt des ersten Taktes mit "RD" auf high 
müssten doch beide Simulationsergebnisse gleich sein! Der Simulator kann 
doch noch gar nicht wissen, ob "RD" auch den zweiten Takt auf high 
bleibt?!

Kann mir das jemand von Euch erklären?

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

Steffen Hausinger schrieb:
> Es kommen bereits schon beim ersten Takt gültige Werte auf dem Port!
Was passiert in den 270 ns vor dem "ersten Takt"?
Wird da vorher schon mal was ausgelesen? Oder geschrieben?
Wenn ja: was?

XX deutet ja auf eine Buskollision hin (zumindest kenne ich das von VHDL 
so), da wird also evtl. durchaus auch schon was getrieben. Dann sogar 
von mehreren Sourcen...

[Steffen Hausinger (Gast)]

Ja, die Vermutung liegt nahe. Allerdings müsste das dann ja auch für den 
Fall gelten, wo "RD" zwei Takte auf high ist. Ich habe aber wirklich 
nur diese eine Zahl zwischen den beiden Varianten geändert. Sonst 
nichts!

Vor diesem Ereignis ist lediglich der Reset (siehe Anhang).

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Hallo,

welche HW Beschreibungssprache soll das sein? Ich kenne mich zwar nicht 
so gut mit Verilog aus, jedoch habe ich Verilog-Prozesse anders in 
Erinnerung, auch sieht die Zuweisung an ein Reg anders aus.

Hier mal zwei Beispiele aus dem CAN-Controller von Igor Mohor

always @ (posedge clk_i)
begin
  if (cs & (~we))
    begin
      if (data_out_fifo_selected)
        data_out <=#Tp data_out_fifo;
      else
        data_out <=#Tp data_out_regs;
    end
end

always @ (posedge clk_i or posedge rst)
begin
  if (rst)
    begin
      rx_sync_tmp <= 1'b1;
      rx_sync     <= 1'b1;
    end
  else
    begin
      rx_sync_tmp <=#Tp rx_i;
      rx_sync     <=#Tp rx_sync_tmp;
    end
end


Was für Typen hast du für SJA1000_rd und SJA1000_ale verwendet?

Tom

[Auch Hans (Gast)]

Hi,

ich sehe gerade, dass du ja Blocking Assignments (=) in nem getakteten 
always Block benutzt. Ich würde dir als erstes mal empfehlen, das alles 
auf Nonblocking Assignments (<=) umzustellen.
Da bekommt man sonst in Verilog die lustigsten Effekte und 
Verschiebungen der Signale, je nachdem in welcher Reihenfolge der 
Compiler/Simulator die Blöcke abarbeitet.

[Steffen Hausinger (Gast)]

Thomas Reinemann schrieb:
> welche HW Beschreibungssprache soll das sein? Ich kenne mich zwar nicht
> so gut mit Verilog aus, jedoch habe ich Verilog-Prozesse anders in
> Erinnerung, auch sieht die Zuweisung an ein Reg anders aus.

Ja, das ist Verilog. Allerdings ist die Simulation doch völlig 
unabhängig von der verwendeten Beschreibungssprache. In VHDL würde das 
Ergebnis genauso aussehen. Es wird die Logik simuliert und nicht die 
Beschreibungssprache. Oder liege ich da falsch?

Die Prozesse passen ganz gut zu denen von Igor Mohor. Lediglich das 
Zeitverhalten (#Tp) habe ich weggelassen. Die Basis (1'bx) habe ich mal 
hinzugefügt, ändert aber nichts am Ergebnis.



Auch Hans schrieb:
> ich sehe gerade, dass du ja Blocking Assignments (=) in nem getakteten
> always Block benutzt. Ich würde dir als erstes mal empfehlen, das alles
> auf Nonblocking Assignments (<=) umzustellen.

Stimmt, da hab ich nicht aufgepasst. Leider bleibt das Ergebnis das 
Gleiche :-(


Habt ihr noch eine andere Idee?

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

Steffen Hausinger schrieb:
> Es wird die Logik simuliert und nicht die Beschreibungssprache.
> Oder liege ich da falsch?
Nein. Es wird die Beschreibung mitsamt den Eigenarten der 
Beschreibungssprache simuliert. Ob da eine sinnvolle Logik 
dahintersteckt, das ist vorrangig komplett egal. Du kannst mit der 
Beschreibungssprache irgendwas sinnloses hinschreiben, das dann 
fehlerfrei simuliert wird, obwohl niemals eine Logik daraus generiert 
werden könnte.

> Allerdings ist die Simulation doch völlig unabhängig von der
> verwendeten Beschreibungssprache.
Nicht ganz: ein std_logic in VHDL kennt eben nicht nur 0, 1, Z und X, 
sondern da wird noch zwischen U (Uninitialisiert) und X (Kollision) 
unterschieden...

[i-Troll (Gast)]

Soweit ich's verstanden habe, benoetigt man ein steigende Clockflanke 
waehren des Read. Und das hat man im zweiten Fall