Questions on alu generator user guide

UVM
1

hi sir,
i’m using UVMF 2022.03 release to do some UVMF study.
under ${UVMF_HOME}/docs/generator_tutorials/alu_with_qvip_and_uvm_reg_model/ALU_UVMF_Step_By_Step_Guide_with_YAML_2020.pdf, page 63,
it shows how to connect alu_in_monitor_bfm in top_hdl.sv

  1. original code (generated by yaml2uvm.py with no modification) instantiate
 alu_in_monitor_bmf alu_in_agent_mon_bfm(alu_in_agent_bus.monitor_port)
  1. modified code is as follow
alu_in_monitor_bmf alu_in_agent_mon_bfm(alu_in_mon_bus.monitor_port)
... alu_in_mon_bus connection ...

here I have two questions:

  1. the added code contains “pragma begin/end” without using existing “pragma begin/end” label. so user could add “pragma begin/end” label at will, not only add code in the generated pragma?
  2. why we should replace alu_in_agent_bus with alu_in_mon_bus, and do the alu_in_mon_bus connection again? is this for better separation like in/out agent?
2

In reply to zxwbobo:

by the way, i also previous user guide for alu without apb qvip, which seems you do not instantiate another alu_in_if as alu_in_mon_bus.
so i guess the extra instantiation must have special use.
thanks a lot!

3

In reply to zxwbobo:

Hi Sir,

 Regarding your first question:  Users can add their own pragma blocks.  However, the merge feature will not know where to place this new pragma block in the newly generated code.  A list of these pragma blocks that are unknown to the uvmf generator can be displayed by the generator when performing the merge.  This list identifies the user created pragma blocks that the user must manually place into the newly generated code in the correct location.  I recommend viewing the video on uvmf code generation merging:

https://verificationacademy.com/sessions/uvmf-code-generation-merging

 Regarding your second question:  Page 63 references the block diagram on page 3 to show each of the ALU inputs have a mux that selects between driver BFM outputs or register outputs that are set through the APB protocol via QVIP.  In this case the driver BFM is connected to one of the mux input channels and the monitor BFM is connected to the mux output.  This is because prediction must observe the same input as the ALU regardless of the source of that data, driver BFM or register output.

  The ALU without APB QVIP does not have a mux to select between driver BFM and register outputs.  In this case the monitor BFM is connected to the same signals as the driver BFM.  This is why another alu_in_if is not needed.

Thank you,
Bob

4

In reply to bob_oden:

hi Bob,
thanks for your explanation.
for the 1st question, i have viewed the video before, and being aware the code merge function will not work. i diffed the generated code and modified code, and found the examples add following code, without being encapsulated in “pragma begin/end” block


// pragma uvmf custom alu_in_monitor_bus_connections begin
alu_in_monitor_bmf alu_in_agent_mon_bfm(alu_in_mon_bus.monitor_port)
... alu_in_mon_bus connection ...
// pragma uvmf custom alu_in_monitor_bus_connections end

though the above code seems to be encapsulated by the “pragma begin/end” block, however, in the original generated code, there even does not exist the “pragma begin/end” comment, let alone the assignment connection.
maybe your provided alu_bench_cfg.yaml should add interface_params alu_in_mon_bus? so that yaml2uvmf.py could generate alu_in_mon_bus related code in hdl_top.sv.
currently, the docs/generator_tutorials/alu_with_qvip_and_uvm_reg_model/alu_bench_cfg.yaml only specifies two interface_params: alu_in_agent/alu_out_agent, so there is nothing about alu_in_mon in the generated hdl_top.sv