Search the Community
Showing results for tags 'Interface'.
Found 9 results
-
Hi there, i'm currently building a host-compiled cpu/os simulator in systemC. I therefore have defined an OS interface like this: class OS_API : virtual public sc_core::sc_interface { public: virtual void task_create() = 0; virtual void task_end() = 0; virtual void CPU_WAIT_TIME(double t) = 0; }; And implemented it using: class RTOS : public sc_core::sc_module, public OS_API { public: sc_core::sc_export<OS_API> os_export{"os_export"}; RTOS() : sc_core::sc_module(sc_core::sc_gen_unique_name("RTOS")) { os_export.bind(*this); } private: // from OS API void task_create() override; void task_end() override; void CPU_WAIT_TIME(double t) override; }; So i use this whole interface / channel design in the Tasks, that are supposed to be scheduled. I defined the abstract task like this: enum State { waiting, ready, running }; struct TCB { sc_core::sc_event wakeup_event; int pid; State state; }; class OS_Task : public sc_core::sc_module { public: SC_HAS_PROCESS(OS_Task); OS_Task(sc_core::sc_module_name name_); sc_core::sc_port<OS_API> os{"os"}; struct TCB tcb; virtual void run() = 0; }; and then i have a subclass that actually implements the task: class Hello1 : public OS_Task { public: Hello1() : OS_Task("Hello1"){}; virtual void run() { cout << "running Task Hello1 \n"; os->task_create(); for (size_t i = 0; i < 20; i++) { os->CPU_WAIT_TIME(120); cout << "hello from 1: " << i << "\n"; } os->task_end(); } }; My question is, how can I access the callers information (OS_Task or its subclass Hello1) in the RTOS that implements the interface? Specifically i need access to the callers TCB struct so i can put it to sleep, and the be able to wake it up later (from the RTOS)
-
I have a DUT which will require multiple BFMs to handle the pin-wiggling of different sets of pins of the DUT. What I am wondering is whether it is possible to write just one driver class (monitor may be a different story), but then instantiate it for each of the BFMs. I have explored the technique of Polymorphic Interfaces to allow Drivers to hold a handle to the base abstract class for which each BFM interface will instantiate a "concrete" class inheriting from the abstract class in order to be type compatible. The uvm_config_db could be used to help each Driver "get" their respective "config", which will be set properly by the environment so that each Driver is talking with a different interface, but the same Driver code can be used for each instance of the agent. The goal of all of this is to make the agent/driver/monitor "generic" enough so that I don't have to write a new agent/driver/monitor class for each BFM. Assuming I can get the handle of the BFM to the Driver, then the only other problem to reconcile is how to send transactions. I could make every transaction (to all of the interfaces) a child of a parent "sequence_item" class so that the method could take in an entire Transaction of type "sequence_item" and then have each BFM cast the transaction to their child-type of sequence_item, but I don't know if BFMs are supposed to have the scope of sequence_items... In my case I would need the Driver to call the send_op() command and have each BFM override that command to process the incoming signals appropriately for their respective interface. Is any of this possible? I apologize if I have confused terms, please let me know if I can clarify what I mean on any of this. -
Q1) I'd like confirmation that the following waits for a posedge of clk are identical. (The code it refers to is far below.) 1) @(posedge my_play_if.clock); or @(posedge clk); 2) @(my_play_if.cb1); Q2) I'd also like to confirm that input and output clocking_skew of a clocking block have no effect on the inputs of the interface. They only affect the inputs and outputs of that clocking block. I'm pretty confident about both of these and the SystemVerilog LRM seems clear, but I want to confirm while I am cleaning up some inherited code which is not currently working. Reference: SystemVerilog Standard 1800-2012.pdf, Section "14. Clocking blocks" Below is some sample code I was hacking around with. //Interface, clocking blocks, and waiting for clock edge interface play_if(input bit clock); clocking cb1 @(posedge clock); default input #2 output #2; //clocking_skew is irrelevant to interface inputs, right? endclocking endinterface module top; bit clk; play_if my_play_if(.clock(clk)); always #5 clk=~clk; initial begin $monitor($time," clk=%1b",clk); clk=1; #100 $finish; end task tclk(); $display($time," pre-clk"); @(posedge my_play_if.clock); $display($time," post-clk"); endtask task tcb1(); $display($time," pre-cb1"); @(my_play_if.cb1); $display($time," post-cb1"); endtask initial begin #23; $display($time," --------------START"); tclk(); @(posedge my_play_if.clock); tclk(); #3; tcb1(); tcb1(); @(posedge my_play_if.clock); tcb1(); tclk(); tcb1(); #3; @(posedge my_play_if.clock); $display($time," --------------FINISH"); end endmodule : top -
Dear all, I'd like to access a register via multiple physical interfaces (bfm). Is it possible to set 2 different sequencers to the registers with same address? I have read this is a known issue from this forum. Could anybody give me a good example? I'm looking for a solution that there is no problem in prediction as well as write/read of UVM_REG. Thanks & Regards, -
Hello, The question is SystemVerilog specific, not related to UVM. I was wondering if it is possible to initialize an interface inside an internal module A and further pass it to an another module B, which is at the same level of hierarchy as the module A. interface Inter (input logic clk); logic a; endinterface module A(Inter inter); logic clk; Inter inter(clk); endmodule module B(Inter inter); always_ff @(posedge inter.clk) ..... endmodule module top; A a( .* ); B b( .* ); endmodule Let's assume module A is a master of some Stream interface (like AXI4-Stream), B is the slave. The signal clk could be a regular variable inside the Inter, however, clk must be connected to the interface, so it seems logical to me, that it's on the port list, so developer will not forget to provide it. Therefore (port assignment of inter), the inter has to be initialized inside the module A, not in top as it would be done in case of regular interface usage. The code is for synthesis and my compiler doesn't support virtual interfaces. Does it exist any elegant solution for the described issue ? Thanks, Adrian -
Hi, I have a question when I use uvm_config_db for interface connection. Generally, I know we use set() and get() function of "uvm_config_db" when we connect interface instance with virtual interface. As I know, uvm_config_db#(virtual aaa_intf)::set() is described inside top testbench module. And uvm_config_db#(virtual aaa_intf)::get() is some phase of inside class. What I want to do is to move set() function into some phase of class. Is it possible? If possible, which phase can I use not to be no problem in topology? Could you give me an example? I generally descirbes uvm_config_db#(virtual aaa_intf)::get() in connect_phase. Thanks & Regards, YYN
- 1 reply
-
- 1
-
-
- interface
- uvm_config_db
- (and 1 more)
-
Hi In System Verilog the recommended approach to create interfaces is through modport suppose I have an interface like interface axi_if(input clk, input rst); logic arlen; clocking mclk@(posedge clk); output arlen; endclocking modport Master(clocking mclk, input clk, input rst); endinterface In Bind we can bind a module to an interface if all the ports are in the portlist. So is there someway I can bind arlen though it is not defined in the interface port list?-
- 1
-
-
- systemverilog
- modports
- (and 1 more)
-
May a module or interface have default 'no-connect' port connections, for ports that we don't need to connect? I need to use an interface which is shared between testbenches. I instantiate it a lot and don't use many of the ports (i.e. they can be 'no connects') Using Cadence irun, I get this warning when I don't connect inputs to the interface: ncelab: *W,CUVWSI With tasks/functions, I can have a default value for an input argument. Is there anything similar for interfaces (or modules for that matter)? Rather than creating a bunch of dummy inputs for these ports that are not relevant to me, I'd like to change the interface somehow to clear up the warnings for cases where I don't want to use them. trying to clean up some warnings, thanks Note: the interface inputs mentioned are being used for a small piece of internal control logic in the interface. I suppose someone might suggest using parameterized interfaces. I don't recall offhand, but believe there is a reason that we are not using a parameterized interface for this. I'll have to check with the original developer.
-
Hi, I have a interface monitor where i am capturing data from the interface. I need to pass valid data captured from the interface to the scoreboard for comparison. But the behaviour of interface signals and the way they are asserted depends on the register configuration. Now this config info is not known to the interface or the interface monitor. So while implementing the monitor, should i define two monitors 1) interface monitor which just samples all the data from the bus. 2) process data got in 1) furthur depending on the register config & then pass it on the scoreboard for comparison. Also should this be done using analysis ports? I think this is the right way but wanted to know if there is anything that UVM recommends in such cases. Thanks in advance. Parag
