Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


ruchir.bharti last won the day on October 1 2015

ruchir.bharti had the most liked content!

Profile Information

  • Gender
    Not Telling

Contact Methods

  • Skype

Recent Profile Visitors

665 profile views

ruchir.bharti's Achievements


Member (1/2)



  1. EDA vendor provides adapter layer to connect UVM_TLM <-> SystemC_TLM like ML-UVM from Cadence, UVM Connect from Mentor and TLI from Synopsys. /Ruchir
  2. To my understanding, your system requirement is to have slave model which can : - receive AXI transaction from DUT/master. - perform read/write operation to connected memory depending upon type of transaction. - response back to DUT/Master. if it is, then possible solution is to create transceiver + monitor + config block as slave agent , where : transceiver : convert signal2trasaction and transaction2signal depending upon config. config : config block will control delays on request-response path and controlling error response. monitor : will checks the signals protocol and transferred transaction to scoreboard or functional coverage monitor. else you need to work hard on creating sequence+sequencer+driver.
  3. Hey Nhat, Thanks for sending reset agent link, I haven't check it all but looks good. Regarding Coverage on SPI protocol, to my best understanding there are 9 parameters through which we can complete SPI interface coverage : 1) Operation direction - { IN, OUT} // Direction wrt to memory device. 2) Operation on - { MEMORY, REGISTER} // memory or device register operation 3) PAD - { SINGLE, DUAL, QUAD, OCTA} // pad in use during operation 4) operation flow - { OPC, ADDR, DUMMY, MODE, DATA} // 5) data size - { SMALL_PAGE, SINGLE_PAGE, MULTI_PAGE} // small_page == {1-255 bytes}, single_page == 256 bytes, multi page == 256 x n[2-10] 6) addr size - { 3BYTE, 4BYTE} // 7) addr pointer - { START, MIDDLE, END, RANDOM} // address pointer 8) addr alignment - { PAGE_ALIGNED, PAGE_UNALIGNED} // address is page aligned or not 9) edge type - { SDR, DDR} // Single edge data capture or Dual edge From above enum, you can customize your stimulus generation and protocol coverage. I hope that would help you. Regards /Ruchir
  4. Life is an AnAlOg ! But im digiTAL !!

  5. There is another drawback of using "phase jump" : in case of Multi language verification env, when user jump phases then there might be synchronization issues with different scheduler.
  6. Reset @ DUT : during hard reset DUT or any digital design will restore to its initial predefined condition. which means all internal register, fifo, state machines are reset to its predefine or known state, or in short to its reset state. In addition to this, all output port are also reset`d, which means verification engg also need to check the reset value of output port using assertions( which i normally do or suggest ) apart from register values. Reset model : to apply reset you can create a interface which contain all reset signals (as some design have more than 1 reset signal+ test reset signals). This reset interface handle passed to your uvm_env by config_db. And finally in your uvm_env you can create task api which controls the reset with predefined intial state. Now test can call this reset API to drive reset condition as per requirement with time as parameter. CAUTION : If you want to apply reset multiple times during same simulation cycle, then you must take care of sequence should not block any sequencer. And reset information should be pass to all agent. so to answer your query regarding new reset agent, i would suggest a task would gives more flexibility and assertions will help in checking default state of DUT signals(so no need to create separate scoreboard). Im also assuming in your case you are validating spi slave device which might not have reset port, so initially you can just check the default state on spi line like weak pull up/down or 'Z', then start driving signal with different opcodes. I Hope that helps!! If i still not clear, please let me know. Regards /Ruchir
  7. well brian, i agree with you if clock doesn't change much from test to test then there is no such requirement agent. Here drawback is on any change in testbench user need to recompile for every test. But the idea of having clock agent is to have complete solution for control-ability and observability. Also its a one time effort to create agent and this agent can be plug-in to any UVM verification environment. secondly having a monitor in clock_agent will helps in getting clock frequency which further can be used for coverage sample( basically help in capturing functional coverage where verification objective is to check whether verification have test the design with different clock ranges). in the end its a trade off between QUALITY vs COST vs TIME. user need to balance as verification is never ending process.
  8. my initial suggestion was if you could eliminate use of "wait" statement, that would definitely increase your run time performance and secondly 'if`s ' statement doesn't affect much in model activity, but yes, if you ask for this to embedded programmer. As every `if`s' break down to branches in assembly code and each "branch True" and "branch false" will have different cycle consume by CORE. So to improve performance programmer should predict flow in terms of utilization and provide condition in IF statement.
  9. Well c/thread is always performance killer... so i would request to you if possible use method with static or dynamic sensitivity. Like : if(!vga_controller::fetch_done) { wait(vga_controller::vga_done_trig); } and wait(delay);
  10. Hello Nhat, An Ideal testbench should be fully controllable, modular and interoperable, which includes test should control generation of kind of stimulus, clock frequency, reset control, test signal. So to attain this i would recommend to have agent for each kind of signal ie 1) bus agents( data exchange bus like AXI, AMBA): normally drives/monitor bus signal and controlled by sequence. 2) Clock Agent : which generates all system clocks and clock frequency can be controlled by test/virtual sequence. here agent config is useful to control agent/clock for example : // Virtual Interface virtual clock_interface CLOCK; //------------------------------------------ // Data Members //------------------------------------------ // Is the agent active or passive uvm_active_passive_enum active = UVM_ACTIVE; // default clock Period in Mhz int unsigned clock_period = 30; // default duty cycle in terms of %age int unsigned duty_cycle = 50; // default start latencies in NS int unsigned start_latency = 100; // default clock state bit default_state = 0; // default jitter percentage int unsigned jitter = 0; // is clock stall during reset bit is_clk_stall_at_reset = 0; // ID flag int id=0; so when multiple clock_agent[x] is instantiated in uvm_env then id is used to configure agent as clock_agent[x].clock_period = XXX Mhz. so if uvm_env didnt program clock_period then default value will be consider. Also test/virtual sequence can override clock_period value as per requirement. 3) reset agent : similarly reset agent will control reset generation as a default value from agent config or controlled/overridden value from test/virtual sequence. I think this approach might you!! Regards Ruchir
  11. Hello Tudor, Thanks for sharing your thought, But what i understood from initial question is development of monitor when UVC as master. ( i might be wrong) still if UVC as Master( which i assume SPI Controller) then it can control the respective signal and give flexibility to implementer to drive 'Z' on ports and monitor can capture 'Z', but if UVC as slave( Which i assume SPI Memory device) then i think it have to sample all/selected signal as per memory device behavior. Which means read and decode commands/Addrress/data of SPI protocol and sample/drive line accordingly. Since SLAVE dont know what kind of command will controller initiate. Regards Ruchir
  12. Hello, In general in any uvm_agent, driver and monitor are bind with interface, an interface which declares signal, clocking block, function, task many more.. for SPI bus, data transfer can be done in any mode as you said SPI,DPI(Dual), QPI, OPI(Octa) also there is flexibility of cmd-addr-data can be send different fashion as per memory device support. for verification purpose what i can recommend you is : when spi controller running in SPI mode which mean only 2 pins are supposed to toggle(im ignoring cs and clk for this discussion), then driver can drive other 6 pins to 'High-Z' so that monitor can identify running mode. generally signal defined in interface are of type "LOGIC", it have 4 values(0,1,X,Z) in which monitor logic can work on signal value. Similarlly for QPI, drive remaining 4 pins to 'High-Z'. I hope that help!! With Best Regards Ruchir
  13. Hello Arya, Well unfortunately i don't have code handy with me right now. As this issues faced more than a year back and i changes my organisation in between, so don't have updates/code with me now. Thanks for understanding!! Regards Ruchir
  14. Hello, Please check following link to find difference between two ; https://verificationacademy.com/forums/uvm/what-difference-between-uvmconfigdb-and-uvmresourcedb Thanks Ruchir
  15. Hello Arya, Yes if you have verified RTL and need to reuse test sequence from UVM-SV testbench, you directly use adapter layer to interact with both worlds. for Eg of UCM Connect : in UVM-SV( connect Phase ): // Here SV agent is my TLM2.0 compliant intiator socket ie "tlm2_bsocket" // "bus_stimulus" -> is tag thru which uvm connect will bind with uvmc_tlm #()::connect(tlm2_bsocket, "bus_stimulus"); in TLM-SC Module Constructor : // here SC module is my TLM2.0 compliant target socket ie "tlm_target_socket" // "bus_stimulus" -> is tag thru which uvm connect will bind with uvmc_connect(tlm_target_socket,"bus_stimulus"); But please make sure that packet weight should be match between the 2 worlds. packet weight means size of each data variable should be matched. OR best recommendation i could give is if you could use TLM-GP between UVM-SV and TLM-SC which increase interoperability. To best of my knowledge, UVM-SC is under development phase, document draft is ready and SystemC verification group is available for everyone contribution. But no public release yet. UVM-SV : is provided by all vendors and documentation is available in there installed area. So if you still required please let me know. So now there is trade off between UVM-SC vs UVM-SV ie Open source vs EDA controlled. Both have advantage and disadvantage in use, in support and in future enhancement. Currently i cant put much comments, but I wish UVM-SC is fully adopted by industry SCV : SystemC verification Library is good, but personally i didn't try much over it. Still i feel SV have more powerful over constraint and coverage. UVM Connect is open source you can compile and link to any simulator. On my last usage of UVM Connect there are some memory leakage issues i faced, which is correct it on my local copy. Please note : above are purely my thoughts and experiences, nothing to do with discouraging use of different tools and methodology. Please feel free to use as per need. Thanks Ruchir
  • Create New...