2

Ich bin ein Assertion Verification Newbie versucht zu lernen, wie es richtig gemacht werden soll. Ich habe eine Menge Informationen über die Struktur und die technischen Details der Systemverilog + Behauptungen gefunden, aber ich habe immer noch keine Art von "Kochbuch" -Material gefunden, wie Dinge wirklich in der realen Welt gemacht werden.SVA Annahme/Behauptungen für kontinuierliche Dateneingabe

Die Frage und Abhängigkeiten:

  • Entwurf hat einen Dateneingangsbus mit Daten gültig und ID Eingänge
  • One Daten "Paket" ist 3 Proben
  • nach Kanal n gibt es immer Daten von Kanal n + 1
    • Kanal-IDs werden wickelt, nachdem die größte ID ein beliebige Anzahl von clk zwischen Datenbytes ist Zecken sein kann
  • Es geschickt wurde
  • Folgendes ein einfacher und hoffentlich korrekt mit Kanal-IDs Zeitdiagramm:

    enter image description here

So wie tun Sie dies mit mindestens ammount von Code? Schön und sauber. Zuvor habe ich Dummy-Verilog-Module gebaut, um die Daten zu fahren. Aber sicherlich könnte man einfach die Eigenschaft verwenden, um nur die Kanal-IDs zu beschränken, aber ansonsten die Hände frei lassen für das formale Werkzeug, um zu versuchen, mein Design zu bremsen?

Einfache Vorlage für den Anfang könnte sein:

data_in : assume property (
    <data with some ID>[=3] 
    |=> 
    <data with the next id after any clk tick> 
); 

Ich denke, das Problem ist, dass davon ausgegangen/Behauptungen wie oben neigen dazu, auf jeder Datenprobe auslösen und parallele Threads erzeugen, die sich zeitlich überlappen.

+0

@MatthewTaylor Das OP spricht über formale Verifikation. Die Terminologie bei der formalen Verifikation besteht darin, dass Sie Annahmen über Ihren Input-Stimulus machen und diese seinen gesetzlichen Statusraum einschränken. –

+0

@Tudor Oh - so ist es. Das habe ich vermisst. –

Antwort

1

Das von Ihnen angegebene Beispiel überlappt nicht. Nach drei Proben mit der gleichen ID, sobald ein weiteres Datensample mit der nächsten ID kommt, wird die Folge übereinstimmen und die gesamte Eigenschaft hält.

Überlappende Versuche sind sowieso eine Tatsache des Lebens. Ein Werkzeug wertet immer (behauptete oder angenommene) Eigenschaften in jedem Taktzyklus aus, um herauszufinden, ob eine Übereinstimmung möglich ist. Wenn es entscheidet, dass es ist, dann beginnt es einen neuen Versuch; Wenn nicht, geht es weiter. Es gibt keine Möglichkeit zu sagen: "Versuche nicht, diese Behauptung in Betracht zu ziehen, während sie bereits versucht wird", weil du nie weißt, ob ein Versuch in einem Match enden wird oder nicht.

Wenn man sich eine Welle wie die von Ihnen anschaut, ist es sofort offensichtlich, dass Sie die Eigenschaft nicht während dreier Proben auswerten müssen, sondern nur, weil Sie das ganze Bild sehen können. Dies ist vergleichbar damit, dass das Werkzeug in die Zukunft sehen kann.

Wenn wir uns Ihrer konkreten Frage zuwenden, sagt Ihr Zwang jedoch nicht die ganze Geschichte aus. Es gibt lediglich an, dass, sobald 3 Abtastwerte mit der gleichen ID kommen, die ID für den nächsten Abtastwert inkrementiert werden sollte. Es gibt hier nichts, was besagt, dass die Samples in 3er-Paketen kommen müssen.Sie müssen so etwas wie:

assume property (
    sample_with_some_id_came |-> 
    came_out_of_reset_and_no_samples_were_sent.triggered or 
     one_or_two_samples_with_same_id_sent_after_reset.triggered or 
     three_samples_with_the_previous_id_sent.triggered 
); 

Ich bin auch nicht sicher, ob Ihr würde davon ausgehen, nicht eine Art von „endlos“ Verhalten führen, da Sie sagen, dass es immer eine nächste Probe nach 3 Proben mit der gleichen sein müssen ICH WÜRDE.

2

Glauben, dass Sie über die formale Verifikationsmethode sprechen.

Für die formale Überprüfung müssen Sie kein Modul erstellen, um den Stimulus zu fahren. Stattdessen wird der Stimulus durch das Werkzeug selbst gesteuert und Sie können das Werkzeug mit den Eigenschaften annehmen auf gesetzlicher Stimulus generieren.

Wenn Sie irgendwelche Annahmen nicht angeben, dann kann Werkzeug keine Zufallsdaten treiben und die Behauptungen zu bewerten, wobei in diesem Fall, können Sie falsche Fälschung bekommen. Dieses Szenario ist bekannt als "Under Constraint".

Ähnlich, wenn Sie zu viele Annahmen liefern, dann können Sie einige legale Eingabekombinationen verpassen. Dieses Szenario ist bekannt als "Over Constraint".

So ist es sehr wichtig, genaue Annahmen zu liefern.

Für Ihren Fall Ihre Annahme wie folgt aussehen etwas kann:

property channel_change; 
    // To check the next consecutive ID, after data transfer 
    @(posedge clk) 
    (id) throughout (valid [=3]) |=> valid && (id == $past(id) + 1) 
endproperty 

assume property (channel_change); 

Für detailliertere Informationen über Formal Verification Methodology, Sie mein Blog auf, dass unter: What is Formal Verification? [1/2] & What is Formal Verification? [2/2]

+0

Ihr Vorschlag schränkt die Eingabe so ein, dass, wenn 3 Datenbytes mit derselben ID vorhanden sind, die nächste ID + 1 ist? Aber bleibt die Tür geöffnet, damit das Tool nicht aufeinanderfolgende IDs verwendet? Ich meine, mir scheint, dass das oben Gesagte nicht wirklich verbietet, dies zu tun. Ich bin nicht am Arbeitscomputer, also kann ich das nicht versuchen. – jarno

+0

Ich denke, es wird Tool führen, um aufeinander folgende IDs zu generieren. Um die genaue Implementierung zu überprüfen, müssen wir das Tool selbst ausführen –

1

Ich werde definieren drei sequence, um die gleiche ID bei der nächsten gültigen (same_id) zu erkennen; eine Änderung von id auf dem nächsten gültigen (change_id) zu erkennen; und ein gültiges Paket zu erkennen (packet_id). Dann kann ich eine Eigenschaft hat, innerhalb von vier valid zu überwachen, gibt es nur drei mögliche Fälle: dh

case1: (id, id, id, id+1) OR 
case2: (id, id+1, id+1, id+1) OR 
case3: (id, id, id+1, id+1) 

Bitte meine Codes siehe unten. Ich habe es nicht getestet, das ist nur mein Denken. Hoffentlich wird es funktionieren. Die gute Sache ist die property wird nur für 4 Uhr Ticks dauern und in jedem Takt Tick gibt es nur einen Thread. So können wir Thread-Explosionen vermeiden.

// To detect same id within two non-consecutive valid, 
// (a,a) 
sequence same_id; 
    int prev_id; 
    @(posedge clk) 
    valid, prev_id=id ##1 valid[=1] ##0 id==prev_id; 
endsequence 


// To detect valid packet 
// (a,a,a) 
sequence packet_id; 
    int prev_id; 
    @(posedge clk) 
    same_id, prev_id=id ##1 valid[=1] ##0 id==prev_id; 
endsequence 

// To detect any change of ID 
// any (a,b) 
sequence change_id; 
    int prev_id; 
    @(posedge clk) 
    valid, prev_id=id ##1 valid[=1] ##0 id==prev_id+1; 
endsequence 

// Put all together, in any four non-consecutive valid, there are only three cases: a,b,b,b OR b,b,b,c OR a,a,b,b 
property next_id; 
    int prev_id; 
    @(posedge clk) 
    (change_id ##0 packet_id) or   // a,b,b,b 
    (packet_id ##0 change_id) or   // b,b,b,c 
    (same_id ##0 change_id ##0 same_id); // a,a,b,b 
endproperty