Jump to content


  • Posts

  • Joined

  • Last visited

AgentSmith_l's Achievements


Member (1/2)



  1. Hey guys, I am using incisive 9.20.031 till now I have been using irun to run my uvc's for testing. But now it is required to integrate these UVC's in the existing vhdl TB. So now, each time I change a UVM file, will the entire TB with the DUT have to be elaborated. What is the recommended approach
  2. Yes Uwes agreed it does looks little more complicated in this simple examples. But according to me, when we are talking about requirement of large number of interfaces to verify passively (in various active testcases) in a large DUT in one simulation it becomes more convenient to bind it in the DUT rather than individually supplying the interfaces from various places in DUT.
  3. Thanks Erling... Got this Idea from your reply.. I just concatenated the names of each of the UVM components with %m.. This will create unique names of the components for each instance of enet_monitor...
  4. Thanks uwes and erling for your replies.. I figured out the problem (or rather a way out ). The error was appearing while elaborating some internally generated Top level unit.. Just gave -top to solve the issue.. Neway a new query/limitation/problem: I am Binding the enet_monitor module to an entity in the DUT. But as you have seen the module enet_monitor has UVM components created under UVM_root. So I cannot have more than one instance of the entity cos we cannot have components with same names under UVM_root. So currently the workarround I am using is to bind enet_monitor to each instance(instead of entity) and pass a unique int id for each bind. I am using id in enet_monitor for naming those components differently. Ne better way out?
  5. Yes the following is the only message I get: ncelab: *F,INTERR: INTERNAL EXCEPTION ----------------------------------------------------------------- The tool has encountered an unexpected condition and must exit. Contact Cadence Design Systems customer support about this problem and provide enough information to help us reproduce it, including the logfile that contains this error message. *and some more date/time etc details** So as I said I started by commenting out code to find out wats giving the problem.. So 1st I removed all code in enet_monitor.. conclusion: binding is workin fine finally the conclusion: instance of the interface is causing the error. so heres a simple enet_monitor: module enet_monitor( input tx_clock, input rx_clock, input tx_enable, input tx_data, input rx_data, input rx_enable); skel_enet_bus uvc_enet_bus(rx_clock, tx_clock); skel_enet_monitor uvc_enet_monitor; assign uvc_enet_bus.tx_data = tx_data; assign uvc_enet_bus.rx_data = rx_data; assign uvc_enet_bus.rx_enable = rx_enable; assign uvc_enet_bus.tx_enable = tx_enable; initial begin uvc_enet_monitor = skel_enet_monitor::type_id::create("uvc_enet_monitor", uvm_root::get() ); uvc_enet_monitor.assign_vi(uvc_enet_bus); end endmodule : enet_monitor So if I comment out all code involving the interface uvc_enet_bus the error is eliminated... But I am not able to understand why..
  6. So on further investigation, I found that: The error appears as soon as even a declaration of any UVM component (or even instantiation of an interface) exists in the module enet_monitor which is being bound into the DUT. It seems UVM components can not be instantiated in modules bound in the DUT using bind statements. So what am I missing here?
  7. Okay guys thanks a lot for your replies. from what I understood, It's possible to have uvm components bound in various places in a DUT Design. Working on these lines I tried a simple experiment in which I have top tb something like this: module test(); dut_top dut(); bind enet_bus enet_monitor monitor(.rx_clock(rx_clock), .tx_clock(tx_clock), .rx_enable(rx_enable), .tx_enable(tx_enable), .rx_data(rx_data), .tx_data(tx_data) ); initial run_test(); endmodule enet_bus: is the name of the basic ethernet module instantiated at various places in the DUT. enet_monitor: is a verilog module which contains my UVM_monitors, SVA etc. The parent of all the UVM components are specified as uvm_root. nc_elab on running this gives a fatal erorr "an unexpected situation encountered".. I think I'm missing something very basic.. Any Ideas??
  8. For my application, various UVM components are instantiated at various levels in the DUT using Binding Method. Hence these components are distributed at various levels and in different places in the DUT. I am assuming that UVM would be suitable for this application. Alternative suggestions are welcome. I have the following queries: 1)Will all these components be elaborated under the same uvm_root? 1a) If yes, then any specific things I should keep in mind? 1b) If not, Is haveing multiple uvm_roots in a simulation legal? 1bi) If No then is there a workarround? 1bii) If yes then how do I control the phases of these components since more than one run_test is not legal?
  • Create New...