SPI-Master in Verilog mit TLC5970

[Michael (Gast)]

Hallo,
ich bin neuling auf dem Gebiet der FPGAs, jedoch sehr begeistert von den 
Möglichkeiten die sie einem bieten. Ich versuche nun schon seit wochen 
eine RGB-LED die an den TLC5970 angeschlossen ist per SPI anzusteuern 
jedoch schaffe ich es ums verrecken nicht.
Laut Datenblatt schreibt man per SPI 40-Bit hintereinander in ein Latch. 
Nach der letzten steigenden Flanke des SPI-Clocks wartet der TLC5970 
eine Latch-Time ab bis er die Daten in sein internes Latch 
weiterschiebt. Mein Problem ist jetzt, dass ich mir nicht sicher bin ob 
ich überhaupt die ganzen 40-Bit hintereinander an das TLc senden muss 
und wie lange ich warten muss nach der letzten steigende Flanke .Ich 
arbeite mit dem Digilent Spartan-3A Bord mit einem Spartan-3 XC3S200. 
Mein Code ist sehr gewöhnungsbdürftig, ich hoffe ihr versteht dennoch 
was ich vorhabe.

SPI-Master-Top

`timescale 10ps/10ps

module spi_master_top(
  input wire clk_50m,
  output wire sclk,
  output wire mosi,
  output wire cs,
  output wire test_sclk,
  output reg clk_2m
  );

wire clk_108m;
reg [9:0] clkcount = 0;


spi_master spi_m (
  .clk_2m(clk_2m),
  .mosi(mosi),
  .sclk(sclk),
  .cs(cs),
  .test_sclk(test_sclk)
  );
  
pll_108m pll (
    .CLKIN_IN(clk_50m),
    .RST_IN(1'b0), 
    .CLKFX_OUT(clk_108m), 
    .CLKIN_IBUFG_OUT(), 
    .CLK0_OUT(), 
    .LOCKED_OUT()
    );

always@(posedge clk_108m)
begin
  if(clkcount == 26)
  begin
    //test_sclk = ~test_sclk;
    //test_mosi = ~test_mosi;
    clkcount = 0;
    clk_2m = ~clk_2m;
  end
  clkcount = clkcount + 1;
end

endmodule

SPI-Master

`timescale 10ps/10ps

module spi_master(
  input wire clk_2m,
  output wire mosi,
  output wire sclk,
  output wire cs,
  output wire test_sclk
  );

reg [199:0] out_data [2:0];
reg sclk_buffer = 0;
reg mosi_buffer = 0;
reg cs_buffer  = 1;

reg [199:0] out_buffer = 199'd0;
integer clk_count = 0;
integer pos = 0;

       
initial
begin
  out_data[0] = 200'b11110000000000000000000000000001011111111111000000000000000000000000000101111111111100000000000000000000000000010111111111110000000000000000000000000001011111111111000000000000000000000000000101111111;
  out_data[1] = 200'b11100000000000000001111111111111111111111110000000000000000111111111111111111111111000000000000000011111111111111111111111100000000000000001111111111111111111111110000000000000000111111111111111111111;
  out_data[2] = 200'b00000000000000000000000000001111111111110000000000000000000000000000111111111111000000000000000000000000000011111111111100000000000000000000000000001111111111110000000000000000000000000000111111111111;
  //out_data[0] = 200'b11111110100000000000000000000000000011111111111010000000000000000000000000001111111111101000000000000000000000000000111111111110100000000000000000000000000011111111111010000000000000000000000000001111;
  //out_data[1] = 200'b11111111111111111111100000000000000001111111111111111111111110000000000000000111111111111111111111111000000000000000011111111111111111111111100000000000000001111111111111111111111110000000000000000111;
  //out_data[2] = 200'b00000000000000000000000011111111111100000000000000000000000000001111111111110000000000000000000000000000111111111111000000000000000000000000000011111111111100000000000000000000000000001111111111110000;
end

always@(negedge clk_2m)
begin
  if(clk_count == 26000)
  //if(clk_count == 10)
  begin
    cs_buffer = 0;
    out_buffer = out_data[pos];
    mosi_buffer = out_data[pos][199];
    out_buffer = out_buffer << 1;
  end
  if(clk_count >= 26001)
  //if(clk_count >= 12)
  begin
    sclk_buffer = ~sclk_buffer;
    if(!sclk_buffer)
    begin
      mosi_buffer = out_buffer[199];
      out_buffer = out_buffer << 1;
    end
    if(clk_count == 26400)
    //if(clk_count == 91)
    begin
      mosi_buffer = 0;
      sclk_buffer = 0;
      cs_buffer = 1;
      clk_count = 0;
      pos = pos + 1;
    end
  end
  if(pos == 3)
  begin
    pos = 0;
    clk_count = 0;
  end
  clk_count = clk_count + 1;
end

assign sclk = sclk_buffer;
assign mosi = mosi_buffer;
assign cs = cs_buffer;
assign test_sclk = clk_2m;

endmodule

Danke für eure Hilfe...

MfG
Michael

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

Michael schrieb:
> Mein Problem ist jetzt, dass ich mir nicht sicher bin ob
> ich überhaupt die ganzen 40-Bit hintereinander an das TLc senden muss
Ja klar, denn da sind immer 4 Adressbits und 36 Datenbits dabei. Sieh 
dir einfach mal die Seite 32 an...
> und wie lange ich warten muss nach der letzten steigende Flanke
Seite 41 "Internal Latch Pulse Delay Time"

Sihe dir einfach mal das Datenblatt des Bausteins noch ein wenig genauer 
an. Als Tipp: PDFs lassen sich super toll durchsuchen...

[Michael (Gast)]

Danke für sie schnelle Antwort !
Ich muss zugeben, ich hab die Frage gestellt weil ich das schon die 
ganze zeit mache, es aber trotzdem nicht funktioniert.
Ich habe das so verstanden, dass ich die FC/BC sende (Adresse 1111) und 
dann die LATTIM abwarte damit der TLC die Daten in das FC/BC Register 
schiebt. Daraufhin sende ich wieder 40-Bit, diemal jedoch für das 
DC-Register (Adresse 1110). Dann warte ich wieder und sende nochmal die 
40-Bit für das GC-Register. Wenn DSPRPT nun aktiviert ist, sollte die 
erste LED nun leuchten oder?
Der TLC den ich verwende, sitzt auf einer LED-Leiste. Der Hersteller von 
dem ich die habe, hat die LATTIM auf 1111 gesetzt. Also muss ich 10-16 
ms warten.

MfG
Michael

[Lattice User (Gast)]

Etwas schwer zu lesen, aber es sieht so aus als ob du pos bei jeder SPI 
Clockflanke erhöhst, sozusagen DDR.

Was sagt die Simulation? Was sagt das Osci?

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

Lattice User schrieb:
> Etwas schwer zu lesen
Richtig, weil der Takt-Vorteiler in den Code mit reingemantscht ist...

> Was sagt die Simulation?
Das wäre allerdings interessant.

[Michael (Gast)]

Wie gesagt, ich programmiere erst seit ca. 2 Monaten in Verilog, daher 
entschuldigt meinen sehr unprofessionellen Code. DIe Simulation habe ich 
mal angehängt. Das Oszi sagt dasselbe, wenn die LATTIM am Ende der 
Übertragung ganz kurz ist (10 Takte). Ist Sie jedoch so lang wie im 
Datenblatt gefordert (10-16 ms), sieht man auf dem Oszi nichts 
erkennbares mehr.

MfG
Michael

[Michael W. (michael_w85)]

Den Taktteiler habe ich übrigens mit reingemischt, weil ich es leider 
nicht hinbekommen habe die MOSI Leitung einen Takt bevor SCLK anfängt 
mit dem ersten Bit zu setzen. Nur zur Erklärung...

[Lattice User (Gast)]

Ich habe mir das Datenblatt des TLC5970 jetzt mal angeschaut. SPI würde 
ich das Interface nicht nennen. Wenn du später mal einen richtigen SPI 
Master daraus ableiten möchtest bekommst du graue Haare.

Wenn ich es richtig verstanden habe braucht der TLC5970 alle 40 bit eine 
Pause in der Clock um den internal Latch zu erzeugen. Und diese Pause 
fehlt bei dir.

[Michael W. (michael_w85)]

Das ist mir auch bewusst... Der TLC benötigt ja auch keinen CS, demnach 
ist das eine sehr schlechte SPI-Umsetzung. Zu der Pause: Richtig, so 
habe ich das auch verstanden. Und die Pause ist auch vorhanden, jedoch 
nicht nach 40 Bit sondern nach 200 Bit. Das liegt daran das auf der 
LED-Leiste insgesamt 5 TLCs miteinander kaskadiert sind. Damit alle TLCs 
mit daten gefüttert werden übertrage ich insgesamt 200 Bit und pausiere 
dann erst. Ich kann aber auch dazu sagen das es nicht funktioniert hat, 
als ich nur 40 Bit für die erste LED übertragen habe und die Pause 
direkt danach eingelegt habe. Daher auch meine Frage ob noch jemand eine 
Idee hat, woran es liegen kann... Sieht das Timing denn ansonsten 
akzeptabel aus?!

MfG
Michael

[Lattice User (Gast)]

Michael W. schrieb:
> Das ist mir auch bewusst... Der TLC benötigt ja auch keinen CS, demnach
> ist das eine sehr schlechte SPI-Umsetzung. Zu der Pause: Richtig, so
> habe ich das auch verstanden. Und die Pause ist auch vorhanden, jedoch
> nicht nach 40 Bit sondern nach 200 Bit. Das liegt daran das auf der
> LED-Leiste insgesamt 5 TLCs miteinander kaskadiert sind. Damit alle TLCs
> mit daten gefüttert werden übertrage ich insgesamt 200 Bit und pausiere
> dann erst.

Im Datenblatt steht zwar etwas von unbergrenzter Kaskadierung, ist mir 
aber nicht klar woher jeder TLC weiss welche 40 bit von den 200 für ihn 
gedacht sind.

> Ich kann aber auch dazu sagen das es nicht funktioniert hat,
> als ich nur 40 Bit für die erste LED übertragen habe und die Pause
> direkt danach eingelegt habe. Daher auch meine Frage ob noch jemand eine
> Idee hat, woran es liegen kann...

Wie sind die B Eingänge der TLC angeschlossen?

> Sieht das Timing denn ansonsten
> akzeptabel aus?!
>
Eigentlich schon.

[Michael W. (michael_w85)]

Also den Timings entnehme ich das die Daten direkt weitergeshiftet 
werden. Übertrage ich die ersten 40 Bit, stehen die komplett im Register 
des 1. TLCs. Übertrage ich das 41 Bit, steht das 1.Bit nun im Register 
des 2. TLCs. Und dann immer so weiter. Die ersten 40 Bit von den 200 die 
ich übertrage steen demnach am Ende im letzten TLC.
Mit dem B-Eingängen meinst du denke ich die invertierten Pins. Diese 
habe ich garnicht beschaltet. Ich verwende für die Eingabe SCKA und SDTA 
und Kaskadiert werden die TLCs mit SCKY und SDTY. Quasi genauso wie auf 
dem Titelblatt des Datenblatts.

MfG
Michael

[Lattice User (Gast)]

Michael W. schrieb:
> Mit dem B-Eingängen meinst du denke ich die invertierten Pins. Diese
> habe ich garnicht beschaltet. Ich verwende für die Eingabe SCKA und SDTA
> und Kaskadiert werden die TLCs mit SCKY und SDTY. Quasi genauso wie auf
> dem Titelblatt des Datenblatts.

Welches Datenblatt liegt dir vor?
Bei dem das ich mir vorhin von TI geladen habe, sind die B Eingänge in 
allen Applikations Beispielen angeschlossen, auch auf der ersten Seite.
Ich vermute stark, dass da das Problem liegt.

[Michael W. (michael_w85)]

Dasselbe das du auch vor dir haben wirst. Ich habe nur eins gefunden, 
das es direkt auf der TI-Seite gibt. Das ist eine Interessante 
These...Jedoch ist der Sinn für mich nicht ersichtlich alle 4 Leitungen 
zu beschalten. Sind die Leitungen dann auch mit den entsprechenden 
Signalen zu betreiben, also wirklich der invertierte Takt und die 
invertierten Daten? Ich werde das gleich mal ausprobieren und werde dann 
entweder heute Nacht oder morgen früh mal berichten was sich getan hat. 
Ich bin mir nur momentan auch nicht mehr sicher ob die kaskadierung auf 
der LED-Leiste auch alle 4 Leitungen verwendet, ich meine nämlich dass 
da nur zwei leitungen verwendeten werden, müssten da nicht dann 
theoretisch auch alle 4 Leitungen verwendet werden? Ich werde mal 
nachsehen wenn ich zu Hause bin und auch das nochmal bescheid geben ;)
Danke schon einmal für deine Hilfe und Zeit !! :)
Wenn es wirklich daran liegt, würde  mir ein Stein vom Herzen fallen.

MfG
Michael

[Lattice User (Gast)]

Michael W. schrieb:
> Jedoch ist der Sinn für mich nicht ersichtlich alle 4 Leitungen
> zu beschalten

Störsicherheit, EMC/EMI ......, und damit auch Kabellänge.
Nennt sich differentielle Datenübertragung.

[Michael W. (michael_w85)]

Ahh okay, habe ich wieder was gelernt. Dafür ist dann wohl auch das DSI 
(Differential Signal Interface) zuständig oder? Ist der denn jetzt auch 
"theoretisc" notwendig, dass die kaskadierung ebenfalls alle 4 
Signalleitungen verwendet oder ist das egal, weil die leitungen ja auf 
der Platine liegen und nicht über "Kabel" verbunden sind?

MfG
Michael

[Lattice User (Gast)]

Michael W. schrieb:
> Ist der denn jetzt auch
> "theoretisc" notwendig, dass die kaskadierung ebenfalls alle 4
> Signalleitungen verwendet oder ist das egal, weil die leitungen ja auf
> der Platine liegen und nicht über "Kabel" verbunden sind?

Ja ist notwendig, da beide Inputs auf gleichem Pegel die Schaltschwelle 
darstellen.

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

Michael W. schrieb:
> Ist der denn jetzt auch "theoretisc" notwendig, dass die
> kaskadierung ebenfalls alle 4 Signalleitungen verwendet
Ähm, wie meinst du sollte es denn sonst funktionieren?
Das ist ein differentielles Signal. Das braucht beide Polaritäten. Für 
Takt und Daten zusammen also 4: T+, T-, D+ und D-. Du könntest 
versuchen, einen der Eingänge auf Ub/2 zu legen, aber das ist dann eher 
ein akademische Spielerei.

[Michael W. (michael_w85)]

@ Lothar Miller
Tut mir leid, aber wie bereits erwähnt befasse ich mich erst seit 
einigen Monaten mit diesem Thema und habe von einem Differentiellen 
Signal bisher noch nichts gehört... Daher war mir auch nicht klar dass 
ich bei Pegel benötige.

@Lattice User
Ich habe es nun mit allen vier Leitungen programmiert, es funktioniert 
jedoch leider immer noch nicht. Ich habe nocheinmal die Timings 
hochgeladen und es auf 40-Bit Daten umgestellt, sende also nicht mehr 
sofort alle 200 Bit. Ich habe auch bereits mehrfach die Leitungen 
überprüft, ob alles korrekt angeschlossen ist. Langsam bin ich mit 
meinem Latein am Ende...

MfG
Michael

[Michael W. (michael_w85)]

Hier noch mal ein paar Bilder vom Oszi...
Leitungen:
Gelb:   SCKA
Grün:   SCKB
Rosa:   SDTA
Türkis: SDTB

MfG
Michael

[Lattice User (Gast)]

Warum ist bei 01 - 04.png der Pegel von SDTB zu niedrig?
Ansonsten sieht das ok aus.

Ich fürchte du msst dich nochmal eingehend mit dem TLC5970 
auseinandersetzen,
vielleicht braucht er einen Resetbefehl, oder eine Einstellung falsch?

Um HW Probleme auf den seriellen endgültig auszuschliessen kannst du dir 
noch die Ausgänge am Osci anschauen.

Mehr kann ich leider nicht mehr helfen.

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

Lattice User schrieb:
> Ansonsten sieht das ok aus.
Kommen die Überschwinger im Takt wirklich nur von Messaufbau?
Ich würde mal gerne das Differenzsignal SCKA-SCKB sehen.

[Michael W. (michael_w85)]

Lattice User schrieb:
> Warum ist bei 01 - 04.png der Pegel von SDTB zu niedrig?
> Ansonsten sieht das ok aus.
Das weis ich auch nicht. Auf den späteren Bildern sind diese 
verschwunden, dabei habe ich lediglich ein neues Bild erstellt.

Lothar Miller schrieb:
> Kommen die Überschwinger im Takt wirklich nur von Messaufbau?
> Ich würde mal gerne das Differenzsignal SCKA-SCKB sehen.

Könnten die Überschwinger das Problem sein? Der Versuchsaufbau sieht so 
aus, dass die Leitungen alle über ca. 5 cm kurze Steckbrücken verbunden 
werden. Vielleicht sollte ich einen SPI-Stecker auf eine kleine Platine 
löten und die Pins dann darüber verbinden...
Bei einem Takt von 4,5 MHz kann ich mir gut vorstellen, dass das Signal 
da nicht so optimal durchläuft. Ich kann das Differenzsignal gerne 
nocheinmal darstellen, jedoch bin ich erst am Montag wieder in der Uni 
sodass ich ein Oszi zur Verfügung habe...

Ich habe den Code zudem nochmal "rundum erneuert". Vielleicht ist es 
jetzt etwas einfacher zu lesen und zu verstehen...

`timescale 10ps/10ps

module spi_master(
  input wire clk_9m,
  output wire mosia,
  output wire sclka,
  output wire mosib,
  output wire sclkb
  );

reg [199:0] out_data [2:0];
reg sclka_buffer;
reg mosia_buffer;
reg sclkb_buffer;
reg mosib_buffer;
reg [6:0] state;

reg [199:0] out_buffer;
reg [6:0] NEXT_STATE;
integer counter;
integer data_counter;
integer pos;


/* Parameter Definitionen */
    parameter START =     7'b0000001,
           SEND_FCBC =   7'b0000010,
           SEND_GC =     7'b0000100,
           SEND_DATA =   7'b0001000,
           WAIT_1S =     7'b0010000,
           WAIT_LATTIM = 7'b0100000,
           IDLE =       7'b1000000,
           FCBC =       0,
           GC =        1,
           DOTS =      20;

initial
begin
  sclka_buffer <= 0;
  mosia_buffer <= 0;
  sclkb_buffer <= 1;
  mosib_buffer <= 1;
  counter <= 0;
  data_counter <= 0;
  pos <= 0;
  out_buffer <= 200'd0;
  state <= IDLE;
  
  /* FC/BC */
  //out_data[0] <= 40'b1111000000000000000000000000000101111111;
  /* GC */
  //out_data[1] <= 40'b0000000000000000111111111111000000000000;
  /* DC */
  //out_data[2] <= 40'b1110000000000000000111111111111111111111;
  
  /* FC/BC */
  out_data[0] <= 200'b11110000000000000000000000000001011111111111000000000000000000000000000101111111111100000000000000000000000000010111111111110000000000000000000000000001011111111111000000000000000000000000000101111111;
  /* GC */
  out_data[1] <= 200'b00000000000000001111111111110000000000000000000000000000111111111111000000000000000000000000000011111111111100000000000000000000000000001111111111110000000000000000000000000000111111111111000000000000;
  /* DC */
  out_data[2] <= 200'b11100000000000000001111111111111111111111110000000000000000111111111111111111111111000000000000000011111111111111111111111100000000000000001111111111111111111111110000000000000000111111111111111111111;
end

always@(negedge clk_9m)
begin
  case(state)
  IDLE:
    begin
      mosia_buffer = 0;
      sclka_buffer = 0;
      mosib_buffer = 1;
      sclkb_buffer = 1;
      if(counter == 9000000)
      //if(counter == 9)
      begin
        counter = 0;
        state = SEND_FCBC;
      end
    end
  SEND_FCBC:
    begin
      pos = FCBC;
      out_buffer = out_data[pos];
      mosia_buffer = out_data[pos][199];
      mosib_buffer = ~out_data[pos][199];
      out_buffer = out_buffer << 1;
      data_counter = data_counter + 1;
      state = SEND_DATA;
    end
  SEND_GC:
    begin
      pos = GC;
      out_buffer = out_data[pos];
      mosia_buffer = out_data[pos][199];
      mosib_buffer = ~out_data[pos][199];
      out_buffer = out_buffer << 1;
      data_counter = data_counter + 1;
      state = SEND_DATA;
    end
  SEND_DATA:
    begin
      sclka_buffer = ~sclka_buffer;
      sclkb_buffer = ~sclka_buffer;
      if(!sclka_buffer)
      begin
        mosia_buffer = out_buffer[199];
        mosib_buffer = ~out_buffer[199];
        out_buffer = out_buffer << 1;
        data_counter = data_counter + 1;
      end
      if(data_counter > 200)
      begin
        data_counter = 0;
        mosia_buffer = 0;
        sclka_buffer = 0;
        mosib_buffer = 1;
        sclkb_buffer = 1;
        if(pos == FCBC)
        begin
          counter = 0;
          pos = GC;
          state = WAIT_1S;
          NEXT_STATE = SEND_GC;
        end 
        else if(pos == GC)
        begin
          counter = 0;
          state = WAIT_LATTIM;
        end
      end
    end
  WAIT_1S:
    begin
      if(counter >= 9000000)
      //if(counter >= 9)
      begin
        counter = 0;
        state = SEND_GC;
      end
    end
  WAIT_LATTIM:
    begin
      /* Warte 15 ms für den Internal Latch Pulse */
      if(counter == 140000)
      //if(counter == 14)
      begin
        counter = 0;
        state = WAIT_1S;
      end
    end
  default:
    begin
      counter = 0;
      state = IDLE;
    end
  endcase
  
  counter = counter + 1;
end

assign sclka = sclka_buffer;
assign mosia = mosia_buffer;
assign sclkb = sclkb_buffer;
assign mosib = mosib_buffer;

endmodule

MfG
Michael

[Lattice User (Gast)]

Michael W. schrieb:
> Lattice User schrieb:
>> Warum ist bei 01 - 04.png der Pegel von SDTB zu niedrig?
>> Ansonsten sieht das ok aus.
> Das weis ich auch nicht. Auf den späteren Bildern sind diese
> verschwunden, dabei habe ich lediglich ein neues Bild erstellt.

Also gibt es irgendwo einen HW Defekt.
Das sollte man als allererstes suchen und beheben.