Frage zu Benutzung des CLK beim CPLD im Vergleich zu einem FPGA

[Michael F. (mifi)]

Hallo zusammen,

ich habe vorher nur FPGAs verwendet, und hier den CLK bei einem echten 
CLK Eingang für ein echtes synchrones Design mit nur einem CLK. Als FPGA 
wurde hier ein CycloneIV verwendet.

Nun habe ich eine Frage zu einem MAX V, CPLD.
Darf man hier ein normales Signal als CLK verwenden, Beispiel:

always @(negedge nRead)
begin
  case(Addr)
      .
      .
      .
  endcase   
end

Normalerweise benutz ich VHDL, und im FPGA würde ich erst mal das nRead 
Signal einsynchronisieren, auf eine fallende Flanke prüfen und das mit 
dem allgemeinen CLK bearbeiten:

   signal rd_sr        : std_logic_vector(2 downto 0);
   signal host_read    : std_logic;


   process(clk_i, rst_i)
   begin
      if (rst_i = '1') then
         rd_sr <= (others => '0');
         
      elsif rising_edge(clk_i) then
         rd_sr <= rd_sr(1 downto 0) & NOT rdn_i;  
      end if; 
   end process;
   
   
   process(clk_i, rst_i)
   begin
      if (rst_i = '1') then
         host_read  <= '0';
   
      elsif rising_edge(clk_i) then
      
         -- Default
         host_read  <= '0';
         
         if ((host_rd_sr(2) = '0') AND (host_rd_sr(1) = '1')) then
            host_read <= '1';
         end if;
      
      end if; 
   end process;

host_read ist jetzt nur noch für einen Takt aktive, und synchrone mit 
clk_i.

Braucht man das bei einem CPLD nicht mehr machen?

Viele Grüße,
Michael

[Duke Scarring (Gast)]

Michael F. schrieb:
> Braucht man das bei einem CPLD nicht mehr machen?
Prinzipiell gilt auf dem CPLD die gleiche Physik, wie auf dem FPGA.
Allerdings sind auf dem CPLD die Ressourcen doch echt eingeschränkt, so 
das man auf 'schmutzige' Tricks zurückgreifen muss.

Die Frage ist: Was soll passieren, wenn die Host-Adresse gültig ist?

Duke

[Schlumpf (Gast)]

Du synchromisierst ja ein, weil das externe Signal keinen Phasenbezug 
zum internen Takt hat und deswegen am Register die Einhaltung von Setup- 
und Holdzeiten nicht garantiert werden kann.

Diese Tatsache ist unabhängig von der gewählten Technologie.

[Michael F. (mifi)]

@Schlumpf,
davon bin ich auch ausgegangen, es konnte ja sein das es hier noch etwas 
besonderes gibt.

D.h. jetzt aber, alle Regeln die man für die Entwicklung bei FPGAs 
verwendet müssen auch für CPLDs angewendet werden.

@Duke,
die schmutzigen Tricks dienen hier dann aber nur zur Reduzierung der 
Ressourcen mit dem Nachteil der Stabilität.

Ich bin gerade in der Softwarearchäologie" unterwegs. Und wenn ich auf 
der CPU Seite Funktionen sehe die in einer FOR Schleife mehrfach auf ein 
Register den selben Werte schreiben, frage ich mich warum? Wenn ich dann 
aber im CPLD Source sehe das hier die Signale nicht synchronisiert 
wurden, und direkte Signale als CLK benutzt wurden, kann ich mir schon 
vorstellen das dies der Grund ist.

Man wußte wohl nicht warum es ein Problem gab, und hat einfach mehrfach 
auf  das Register geschrieben. In einer externen Schulung vor vielen 
Jahren sagte der Trainer das man mit solchen Designs der Kunden viel 
Geld bei der Fehlersuche und Behebung als externe "Feuerwehr" verdienen 
kann...

Wenn so etwas z.B. im Flugzeug verwendet wird, möchte ich nicht damit 
fliegen, Du etwa?

Danke,
Michael

[Schlumpf (Gast)]

Michael F. schrieb:
> D.h. jetzt aber, alle Regeln die man für die Entwicklung bei FPGAs
> verwendet müssen auch für CPLDs angewendet werden.

Ja wobei das jetzt hier keine Regel für CPLD/FPGA ist, sondern ein 
Effekt, der in der Digitaltechnik generell auftaucht.
Also auch, wenn du deine Schaltung komplett diskret mit Transistoren 
aufbauen würdest.

[Michael F. (mifi)]

Hallo Schlumpf,

mit "Regeln" meine ich solche Punkte wie z.B. das Synchronisieren der 
Eingänge, und wie Lothar immer so schön sagt das ein Design für den 
Anfang nur einen Takt haben sollte, und das man Variablen erst mal nicht 
braucht :o)

Ich sehe das Problem bei der Herangehensweise. Wenn jemand noch nicht 
mit CPLDs und FPGAs gearbeitet hat, aber Kenntnisse der 
Schaltungstechnik besitzt dann passiert so etwas. Es wird überlegt wie 
man das mit diskreten Bauelementen aufbauen würde, und dann wird das 
nRead Signal auf den Takteingang eines Latch gelegt um die Daten zu 
speichern. Und wenn dieser "Jemand" dann gesagt bekommt, "CPLD" sind 
doch auch nur "Dinger" wo man Logikbausteine plazieren kann, dann wird 
er ohne eine entsprechenden Schulung das so machen wie ich das in dem 
Design vorgefunden habe. Aber das ist ein anderes Thema...

Gruß,
Michael

[Klakx (Gast)]

Michael F. schrieb:
> [..] Und wenn ich auf
> der CPU Seite Funktionen sehe die in einer FOR Schleife mehrfach auf ein
> Register den selben Werte schreiben, frage ich mich warum? [..]

Es gibt auch Register mit Auto-Clear. Vielleicht werden mehrere Aktionen 
damit ausgelöst. Z.b. "Messe Daten und speichere diese im FIFO"

[Schlumpf (Gast)]

Hallo Michael,

Genau da liegst du falsch.
Denn es ist so, dass auch in diskret aufgebauter Logik die identischen 
Problem auftreten, wenn man diese Regeln nicht beachtet.
Daher auch meine Aussage, dass sich diese Regeln nicht nur auf FPGA/CPLD 
beschränken.

Eine Verletzung der Setupzeit führt beim diskreten FF genauso zu 
Metastabilität, wie beim Register im FPGA.

[Michael F. (mifi)]

Hallo Schlumpf,

>Eine Verletzung der Setupzeit führt beim diskreten FF genauso zu
>Metastabilität, wie beim Register im FPGA.

Das ist mir schon klar.

[Duke Scarring (Gast)]

Michael F. schrieb:
> die schmutzigen Tricks dienen hier dann aber nur zur Reduzierung der
> Ressourcen
Ja.

> mit dem Nachteil der Stabilität.
Das muß nicht zwingend sein.
Ich würde es eher so formulieren:
Tricks zur Reduzierung der Ressourcen, mit dem Nachteil beim externen 
Timing viel gewissenhafter arbeiten zu müssen.

Zumal CPLD tendenziell eher die Peripherie zu 'etwas' sind, während FPGA 
tendenziell eher 'Host' sind (und damit der Master über das Timing).

Duke

[Schlumpf (Gast)]

Michael F. schrieb:
> Das ist mir schon klar.

Warum fragst du dann?