Warum uvm_transaction-Klasse, wenn wir immer von uvm_sequence_item erweitern?

Question

Ich ging durch die Grundlagen der UVM-Tutorials. Überall lese ich die Transaktionsobjekte werden immer von uvm_sequence_item erweitert und nicht uvm_transaction seit uvm_sequence_item verfügt über zusätzliche Funktionen wie Transaktions-ID, etc. Wenn das der Fall ist, warum ist die uvm_transaction Klasse gibt es auch in der UVM Klassenhierarchie?

Wer benutzt uvm_transaction anderes als uvm_sequence_item, die davon ausgehen?

Ist es wegen des Vermächtnisses?

Answer 1

Dies ist, was die UVM Class Reference sagt dazu:.

„Die uvm_transaction Klasse ist die Wurzel Basisklasse für UVM-Transaktionen alle Methoden von uvm_object Vererben, fügt uvm_transaction ein Timing und Recording-Interface

diese. Klasse

Die Verwendung dieser Klasse als Basis für benutzerdefinierte Transaktionen ist veraltet.Sein Subtyp, uvm_sequence_item, soll als Basisklasse für alle Benutzer verwendet werden -definierte Vorgangsarten "

Answer 2

Wenn Sie UVM Klassenhierarchie (Link: [https://www.google.co.in/search?biw=1366&bih=620&tbm=isch&sa=1&btnG=Search&q=uvm+class+hierarchy#imgrc=Laxc9UWNpnGTpM%3A][1]) beziehen.. Dann finden Sie, dass uvm_transaction Elternklasse, während uvm_sequence Kind Klasse ist

So können Kind-Klasse alle die Eigenschaft der übergeordneten Klasse zugreifen aber Elternklasse kann nicht untergeordnete Klasse Eigenschaft zugreifen.

uvm_sequence_item seine eigene Funktionalität wie get_sequencer_id hat, set_sequencer_id, get_root_sequence.

diese durch Sequenzer Methoden intern bei Schichtfolgen.

Sie rufen Sequenz durch Startmethode, uvm_do Familie oder config_db auf.

Jede dieser Methoden ruft start_item (req) und finish_item (req) auf.

task start_item(uvm_sequence_item item) 
task finish_item(uvm_sequence_item item) 

Wenn Sie den Datentyp im ersten Argument in beiden Funktionen beobachten, ist uvm_sequence_item.

Es gibt insgesamt acht uvm-Klassen.

(1) uvm_driver.svh 
(2) uvm_push_driver.svh 
(3) uvm_sequencer.svh 
(4) uvm_push_sequencer.svh 
(5) uvm_sequencer_library.svh 
(6) uvm_sequencer_analysis_fifo.svh 
(7) uvm_sequence.svh 
(8) uvm_sequencer_param_base.svh 

Diese Klassen sind parametriert mit uvm_sequence_item nicht mit uvm_transaction.

Wenn Sie uvm_transaction statt uvm_sequence_item verwenden dann ti einen Fehler rufen (set_sequence_id nicht gefunden, welche Eigenschaft von uvm_sequence_item nicht uvm_transaction ist) von uvm_sequencer_param_base.svh.

Die Kommunikation zwischen Sequenz, Sequenzer und Treiber ist damit nicht abgeschlossen.

In den meisten Fällen, die ich beobachte, wenn Sie einen Code haben, in dem Sie nicht gehen, um uvm_sequencer zu verwenden, können Sie uvm_transaction verwenden, es wird kein Fehler schreien.

Aber wenn Ihr Code uvm_sequener enthält und Sie uvm_transaction dann wird es einen Fehler rufen (konnte nicht finden Mitglied ‚set_sequence_id‘).

Answer 3

Beachten Sie, dass von der uvm_transaction-Klasse uvm_sequence_item sowie uvm_objects geerbt werden. Die Klassenhierarchie für das statische Verhalten und das nicht statische Verhalten (sozusagen) beginnt also mit uvm_transaction.

Jetzt kann ich die Funktionalität, die ich möchte, zu uvm_sequence_item hinzufügen, so dass jeder Erben von uvm_sequence_item das bekommen kann. Ich kann dies ohne Änderung von uvm_transction_item tun. Andernfalls würde jede Änderung von uvm_transaction zu unerwünschter Funktionalität in der Komponentenklassenhierarchie (statisches Verhalten) führen und sogar zu unbeabsichtigten Nebenwirkungen führen.

PS: Einer der Unterschiede zwischen anderen OOP-Sprachen und SV ist, dass Mehrfachvererbung in SV nicht erlaubt ist. Zum Beispiel kann ich im Fall von C++ von zwei Klassen in einer neuen Klasse erben. Dies ist in SV nicht erlaubt. Die einzige Möglichkeit, die Eigenschaften von uvm_transaction sowie von uvm_sequence_item zu erhalten, besteht darin, von uvm_sequence_item zu erben. Das ist vielleicht die Quelle deiner Verwirrung.