Welche TimeQuest Constraints brauche ich noch?

[Stefan (Gast)]

Hallo,

Ich habe ein Design in Quartus gemacht (streng synchron aufgebaut, 
~10000 LEs), welches leider manchmal nach dem Compilen korrekt 
funktioniert und manchmal nicht, was mich auf Timingprobleme schliessen 
lässt. Laut Timing analyzer müsste aber alles OK sein. Ich habe auch 
alle Clocks mit 'create_clock' und 'create_generated_clock' definiert. 
Weiss jemand welche zusätzlichen Constraints noch hilfreich sein 
könnten?

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

> streng synchron aufgebaut
Sieh mal deine Resets an.
Sind die asynchron?
Ist da evtl. sogar Kombinatorik drin?

[Stefan (Gast)]

Meine state machines, FIFOs etc. haben zwar asynchrone resets, aber das 
Signal wird vorher gelatcht, also sollten glitches ausgeschlossen sein. 
Tja...

[Ras F. (rasfunk)]

Ein wenig mehr Infos wären schon hilfreich, z.B. welcher Art der Fehler 
ist, ob er bei einem einzigen Build mal auftritt und mal nicht, oder ob 
es erst nach einer neuen Synthese wieder geht.

Zu den Constraints muss noch gesagt werden, dass neben den Clocks auch 
IOs constrained werden sollten - bei SOPC-Komponenten wie PCI oder 
DDR-Speicher wird das halbwegs automatisch per Skript gemacht.

[Mathi (Gast)]

> Ich habe ein Design in Quartus gemacht (streng synchron aufgebaut,
> ...alle Clocks mit 'create_clock' und 'create_generated_clock' definiert.

Wie passt das zusammen?
Hast Du nun mehrere Clocks, dann muss das Design als asynchron behandelt 
werden, oder nicht?

[Stefan (Gast)]

Also ob es funktioniert scheint reine glückssache zu sein und hängt von 
minimalen Änderungen ab (z.B. hinzufügen eines monitoring Pins). 
Ausschlag gebend scheint mir zu sein, dass das Zeug neu gefittet wird...
Was die IOs angeht, kann ich das mit dem Oszilloskop verifizieren.

Ein Beispiel eines sporadisch auftretenden Problems:
Ich weiss z.B. dass meien Ethernet-Schnittstelle funktioniert, da 1 mal 
pro Sekunde ein Watchdog-Packet übermittelt wird und das Paket korrekt 
ankommt. Wenn ich nun per Befehl eine Funktion im Design aktiviere, die 
Daten eines ADCs zum PC schicken soll kriege ich zum Beispiel nur Nullen 
en masse und das Paket wird falsch "verpackt", d.h. die Datenübertragung 
ist fehlerhaft, weil ein datenbyte als Paketgrösse interpretiert wird. 
Das könnte z.B. heissen dass die Paketgrösse am anfang des Pakets falsch 
geschrieben wird, oder dass das Paket zu lang oder zu kurz ist. 
Irgendwie ist das Problem logisch nicht erklärbar, oder ich bin zu blöd.
Hier mal ein Ausschnitt aus dem Code, der ein Paket macht und vom einen 
FIFO in den anderen schaufelt. Man muss dazu sagen, dass das Ziel-FIFO 
einen 16 Bit Eingang hat und einen 8 Bit Ausgang:

--  Get scope data
      
    when s_get_scope_data0 =>
      if scope_fifo_usedw[] >= 16 and w5100_tx_fifo_free_space[] >= 19 then 
        state = s_get_scope_data1;
      else
        state = s_get_meas_data0;
      end if;
      
    when s_get_scope_data1 =>
      -- Write packet size
      w5100_tx_fifo_din[] = 36;
      w5100_tx_fifo_write = vcc;
      
      state = s_get_scope_data2;
        
    when s_get_scope_data2 =>
      -- Write packet type
      w5100_tx_fifo_din[] = DATA_SCOPE;
      w5100_tx_fifo_write = vcc;
      
      state = s_get_scope_data3;
    
    when s_get_scope_data3 =>
      -- Write packet flags
      if scope_packet_counter[].q == 0 then
        w5100_tx_fifo_din[] = PACKET_FLAG_IS_FIRST;
        scope_packet_counter[].d = scope_packet_counter[].q + 1;
      elsif scope_packet_counter[].q == 15 then
        w5100_tx_fifo_din[] = PACKET_FLAG_IS_LAST;
        scope_packet_counter[].d = 0;
      else
        w5100_tx_fifo_din[] = 0;
        scope_packet_counter[].d = scope_packet_counter[].q + 1;
      end if;
      
      scope_packet_counter[].ena = vcc;
      w5100_tx_fifo_write = vcc;
      
      reg_a[].d = 16;
      reg_a[].ena = vcc;
      
      state = s_get_scope_data4;
      
    when s_get_scope_data4 =>
      if reg_a[].q != 0 then
        -- Write curve point
        scope_fifo_read = vcc;
        w5100_tx_fifo_din[] = scope_fifo_dout[];
        w5100_tx_fifo_write = vcc;
        
        reg_a[].d = reg_a[].q - 1;
        reg_a[].ena = vcc;
        
        state = s_get_scope_data4;
      else
        state = s_get_scope_data5;
      end if;
    
    when s_get_scope_data5 =>
      state = s_get_scope_data6;
    
    when s_get_scope_data6 =>
      state = s_get_scope_data7;
    
    when s_get_scope_data7 =>
      state = s_get_scope_data0;

[Stefan (Gast)]

>> Ich habe ein Design in Quartus gemacht (streng synchron aufgebaut,
>> ...alle Clocks mit 'create_clock' und 'create_generated_clock' definiert.

>Wie passt das zusammen?
>Hast Du nun mehrere Clocks, dann muss das Design als asynchron behandelt
>werden, oder nicht?

Die anderen Clocks werden per Divider aus dem master clock generiert.

[Mathi (Gast)]

Also ist das Design asynchron... Hast Du die Taktdomänen-Übergänge 
abgesichert?

[Stefan (Gast)]

>Also ist das Design asynchron... Hast Du die Taktdomänen-Übergänge
>abgesichert?

Wo nötig setze ich DCFIFOs ein... aber das Design ist trotzdem synchron.