If-Bedingung nach dem Einschalten, falsch initialisiert?

Steven (. schrieb:
> Warum durchläuft das "Programm" den "then"-teil des ifs obwohl der
> Counter noch 0 ist?
Die Formulierung wird wieder einige anziehen, die dir sagen werden, dass 
es in der Hardwarebeschreibung kein Programm gibt und nichts durchläuft. 
;-)

Erste, triviale Idee: Wie schnell ist dein Takt? Ich weiß nicht, wie 
8'hFF zu lesen ist, aber wenn das für 0xFF steht, dürfte der Zähler in 
Sekundenbruchteilen überlaufen.
Zweitens: Ich kenne mich mit Verilog nicht aus, aber warum weist du 
einmal mit '=' zu und einmal mit '<=', (led = 1 und counter <= counter + 
1) wo doch beides Register sind? Hat das damit zu tun, dass counter 
mehrere Bit hat oder ist das ein Fehler?

da ich die Schaltung nicht kenne, vielleicht ist das Signal invertiert? 
Ist die LED über VCC-zu-PIN, PIN-zu-GND oder über einen Transistor (und 
wie) angeschlossen?

ein paar Fragen:

1.also du willst das, bei/ab einem bestimmten Zählerwert, eine Led für 
einen Takt leuchten lassen?
2.der Ausgang zur Led ist das led-Register?

Also nach deinem zweiten Code-schnipsel zu urteilen... der Zähler zählt 
einmal hoch, dann wird das Register led auf 1 "gestellt", tja und danach 
kann der Zähler fröhlich weiterzählen und es passiert nichts mehr. Weil 
du stellst das led-Register ja nirgendwo mehr zurück...
ich denke daher ist es auch die ganze zeit an.
wahrscheilich registrierst du das erste hochlaufen zeitlich gar nicht 
oder hälst es für das normale "hochfahren/programmieren" des Fpgas

1

module fillRam (clk, wclk, counter, led);

2

  input clk;

3

  output wclk;

4

  output reg [24:0] counter = 0;

5

  output reg led = 0;

6

7

  always @(posedge clk)

8

  begin

9

    counter <= counter + 1;

10

11

    if(counter == 24'hFFF)

12

      led = 1;

13

    else if(counter != 24'hFFF)

14

      led = 0;

15

16

17

  end

18

19

endmodule

das wäre mein erster Verbesserungsvorschlag, aber dann leuchtet deine 
Led für nur einen Takt... das wird man kaum wahrnehmen, daher eher 
sowas:

1

 if(counter >= 24'h0FF)

2

      led = 1;

3

    else if(counter < 24'h0FF)

4

      led = 0;

würde ich als Bedingung für das Led-Register eher sowas vorschlagen.
Kostet ein bissel mehr Hardware, aber ich denke die Led sollte jetzt 
sichtbar an und ausgehen. Ohne das jetzt zeitlich berechnet zu haben.

Steven (. schrieb:

1

> output reg [24:0] counter = 0;

also 25 bit (alte Informatiker-Weisheit: Es ist immer eines mehr oder 
weniger, als man so denkt...)

1

>     if(counter == 24'hFFF)

* Falscher Zaehlwert (wie Du schon geschrieben hast) +
* falsche Bitbreite

1

> led = 1;

um Probleme zu vermeiden, im getakteten Prozess non-blocking, also

1

led <= 1'b1;

verwenden

eine Sache die ich überlesen habe aber schon von anderen erwähnt wurde:
defintiv würde ich das "led =" durch ein "led <=" auswechslen, damit das 
Synthesetool ein sauberes getaktetes Register aus led macht und nicht 
irgendein mischmasch.

ob die Led ein low oder ein high braucht um zu leuchten, müsstest du in 
den Layoutdaten deines Boards nachsehen.

>     case (mux)
>     3'b110: LEDs = fifodin[7:4];
>     3'b101: LEDs = fifodin[3:0];
>     3'b011: LEDs = debug;
[/code]

da fehlt noch einiges in der sensitivity list:

1

  always @(mux, fifodin, debug)

2

    case (mux)

3

    3'b110:  LEDs = fifodin[7:4];

4

    3'b101:  LEDs = fifodin[3:0];

5

    default: LEDs = debug; // 3'b011

6

    endcase

Mit der Aenderung macht die Simulation, was du spezifiziert hast (siehe 
Anhang, der Counter hoert auf zu zaehlen, wie im Code angegeben. Ob das 
das ist, was du willst, sein mal dahingestellt.

Wenn Du das nicht in der Hardware siehst, koennte das an location 
constraints liegen, oder aber dass Deine Hardware keine Initialisierung 
kann. Das sollte aber in den Synthesedoks beschrieben sein.
Dass die Initialisierung nicht unterstuetzt wird kenne ich nur von 
ASICs, FPGAs koennen das ueblicherweise und dein counter scheint Deiner 
Beschreibung nach auch zu funktionieren.
Ich tippe mal auf location constraints - vertausch doch mal debug[0] und 
debug[1]...

Tschaebe

Steven (. schrieb:
> Der Mux geht auch so. Habs aber auch mit deiner Lösung getestet.

Hm, das wundert mich jetzt ein bisschen - die Simulation sollte im 
ursprünglich geposteten Design eigentlich nicht zur Synthese passen. 
Außerdem dachte ich, dass da ev. Latches generiert würden, da du ja 
nicht alle zustände des Mux ausdekodiert hast (deshalb habe ich das 
"default" Statement verwendet), aber wenn es im Synthesereport keine 
Warnungen gibt...

Steven (. schrieb:
> Ich habe eine .pcf-File:

Das sieht plausibel aus

Irgendwie denke ich, dass das Problem nicht im geposteten Code steckt. 
Was sagen den die Synthese/P&R reports und logs?

Tschaebe

Hast du auch Lattices LSE Synthese probiert, statt Synplify Pro?
Läuft viel schneller durch und das rgebnis benötigt meist auch weniger 
LUTs.
Umschalten kannst du einfach mit Rechtsklick auf Synthesis Tool.

Synplify benutze ich nur noch um Fehler im Verilog zu finden, da ist es 
etwas besser.

Dieses Modul funktioniert auf meinem IceBlink (HX, nicht LP) tadellos, 
die LEDs zählen hoch und das ganze stoppt wenn die 4.LED leuchtet:

1

module Test (CLK_3P3_MHZ, LEDs);

2

  input        CLK_3P3_MHZ;

3

  output [3:0] LEDs;

4

  reg   [23:0] counter;

5

6

always @(posedge CLK_3P3_MHZ)

7

  if(!counter[23]) counter <= counter+1;

8

9

assign LEDs = counter[23:20];

10

11

endmodule

Andi

Lothar M. schrieb:
> Steven (. schrieb:
>> immernoch das gleiche Problem...
> Evtl. hatten Andere schon das selbe Problem...
> Siehe den Beitrag "Lattice Diamond: A user-defined clock should be defined"

Dort geht es um Diamond, Diamond unterstützt den ICE40 nicht.

>
> Da fällt mir gerade ein: WER aus WELCHER Toolchain bringt diese Meldung?

@W: MT420 |Found inferred clock
ist eine SynplifyPro Message, d.h. er eine etwas gefunden was als Clock 
verwendet wird, und schätzt auf Grunde der Beschreibung und dem 
konfiguriertem FPGA, dass die maximal Clock 140 MHz haben sollte. Das 
hat aber eine KEINE Auswirkung auf das entscheidende P&R im Rest der 
Toolchain.
Wie man bei IceCube2 ein Timingconstraint für P&R definert weiss ich 
nicht, aber hier ist der Unterschied zwichen 3 MHz und 140 MHz wohl 
gross genug.

Ich habe mir Mal die Hilfe bei SynplifyPro vond Diamond angeschaut (da 
sind auch die Guidlines für ICE4 enthalten). Wenn ich nicht irre, 
unterstützt SynplfyPro keine Initialwerte für Register beim ICE40.

Lattice User schrieb:
>
> Ich habe mir Mal die Hilfe bei SynplifyPro vond Diamond angeschaut (da
> sind auch die Guidlines für ICE4 enthalten). Wenn ich nicht irre,
> unterstützt SynplfyPro keine Initialwerte für Register beim ICE40.

Nachtrag: Und ohne Initialwerte wird das Register eventuell als Konstant 
erkannt und wegoptimiert.
Sollte man im HDL-Analyst von SynplifyPro (Technology View) sehen 
können.

Steven (. schrieb:
> Lattice User schrieb:
>> Sollte man im HDL-Analyst von SynplifyPro (Technology View) sehen
>> können.
>
> Meinst du einfach den Output?
> Habe mal den Output der Synthese angehägt

Nein, das meine ich nicht.
Sondern eine graphische Darstellung des Synthesergebnis als Schaltplan.

HDL-Analyst ist eine Funktion von Synplify Pro.

Bei Diamond kann man das Userinterface von Synplify Pro aufrufen. Es 
würde mich wundern wenn das nicht auch bei IceCube2 der Fall wäre.

Steven (. schrieb:
> Dann wunder dich schon mal, ich seh da nix...

Habe mir mal auf die Schnelle den IceCube2 Userguide angeschaut. Da sehe 
ich Screenshots mit der Synplify Pro GUI. Es muss also irgendwo sein.

Aus dem Synthesereport:

1

@W: CS263 :"C:\Users\wagnersn\Desktop\VerilogRamTest\RamTest\main - Kopie.v":47:11:47:17|Port-width mismatch for port counter. Formal has width 25, Actual 8

2

@W: CG360 :"C:\Users\wagnersn\Desktop\VerilogRamTest\RamTest\main - Kopie.v":14:6:14:13|No assignment to wire newclock

3

@W: CG360 :"C:\Users\wagnersn\Desktop\VerilogRamTest\RamTest\main - Kopie.v":17:6:17:13|No assignment to wire fiforclk

4

@W: CG360 :"C:\Users\wagnersn\Desktop\VerilogRamTest\RamTest\main - Kopie.v":18:12:18:19|No assignment to wire fifodout

5

@W: CG360 :"C:\Users\wagnersn\Desktop\VerilogRamTest\RamTest\main - Kopie.v":20:6:20:13|No assignment to wire fifowclk

Ah, abesehen von nicht werwendeten Signalen ist der counter  25 bit 
breit, aber fifodin nur 8 bit - muss noch kein Problem sein...

aber dann

1

@N: BN362 :"c:\users\wagnersn\desktop\verilogramtest\ramtest\main - kopie.v":90:1:90:6|Removing sequential instance led in hierarchy view:work.fillRam(verilog) because there are no references to its outputs 

2

@A: BN291 :"c:\users\wagnersn\desktop\verilogramtest\ramtest\main - kopie.v":90:1:90:6|Boundary register led packed into a complex cell. To disable register packing, set syn_keep=1 on net between register and complex cell. 

3

@N: BN362 :"c:\users\wagnersn\desktop\verilogramtest\ramtest\main - kopie.v":90:1:90:6|Removing sequential instance counter[24] in hierarchy view:work.fillRam(verilog) because there are no references to its outputs 

4

@A: BN291 :"c:\users\wagnersn\desktop\verilogramtest\ramtest\main - kopie.v":90:1:90:6|Boundary register counter[24] packed into a complex cell. To disable register packing, set syn_keep=1 on net between register and complex cell.

das sieht so aus, als ob die Synthese led und counter[24] wegopimiert. 
Counter[24] ist klar, das verwendest du nie, aber led? Sollte eigentlich 
nicht, ist aber der Grund, warum deine LED nicht das tut, was du 
erwartest...

Da ich Deine toolchain nicht kenne, ein paar Vorschlaege zum Test 
(Syntheselauf und Blick aufs log reicht, verschwindet sie Message?):

1. Kannst Du mal testweise in fillRam

1

    if(counter[22])

2

      led <= 1'b1;

mit

1

    led <= counter[22];

ersetzen? (Vielleicht kommt der Syntesizer mit er Initialisierung und 
konstanten Zuweisung durcheinander (bei Xilinx gibt es da eine Warnung, 
dass man viel einsparen koennte, wennn man der Init-Wert anedern wuerde, 
sie Synthese laeuft allerdings korrekt)

2. Mal den counter nicht als output port definieren (brauchst du ja 
aktuell nicht), sodass die erste Warnung mal verschwindet.

Ein bischen wundert mich noch, dass der Synthesereport nicht weegen den 
unbenutzten ports SCK, MISI und MISO meckert, dass die oben gepostete 
Datei main - kope.v noch zum geposteten Synthesereport?

3. Entferne mal den mux und lege den Ausgang direkt auf eine LED 
(simplest system...) und definiere dabei auch LEDs[2] und LEDs[3]...

Tschaebe