Stats

  • Locked Locked
  • Replies 2
  • Subscribers 65
  • Views 14038
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

event on combination of VHDL and verilog RTL path

Ravisinha
Hi All, I am making one event like : event collect_cover_done_e is rise('~/ve_top_tb_sn.DUT.ve_core_inst.pss_top_inst.pss_ring_inst.pss_core_inst.pss_arcss_core_inst.ipss_dma.done_w')@sim; Here the issue i am getting is : *** Error: From NCVHDL adapter: Missing access rights. No read/write access rights were specified for the VHDL signal ':DUT:ve_core_inst:pss_top_inst:pss_ring_inst:pss_core_inst:pss_arcss_core_inst:ipss_dma:done_w' accessible from Specman. This is because i hope my testbench is in VHDL and the path which i am accessing at the last is verilog.. Basically our RTL is combination of VHDL and verilog. Please let me know what is the issue over here. Thanks
Parents

  • Hi.

    Firstly you should not be using tick accesses these days. You should be using simple ports instead, as they have better performance and give less flow problems such as the VHDL/Verilog binding that you're seeing.

    dma_done_w : in simple_port of bit is instance;
    keep dma_done_w.hdl_path() == "~/ve_top_tb_sn.DUT.ve_core_inst.pss_top_inst.pss_ring_inst.pss_core_inst.pss_arcss_core_inst.ipss_dma.done_w";
    keep dma_done_w.agent() == "Verilog";
    event collect_cover_done_e is rise(dma_done_w$)@sim;

    This gives you other benefits because each port in a unit can have a different language agent set, which avoids the limitation of tick accesses where the entire unit has only one language agent.

    Now, the other common mistake people make is thinking that they don't need to load their e code when generating the stubs file.
    You MUST load your e code before generating a stubs file, otherwise the simulator doesn't know which RTL signals you wish to connect to. This is important because the simulator tends to optimise away some signals (e.g. feed-throughs) to improve performance. It must know during elaboration that you want access to the signal, and the stubs file tells it that information.

    After generating a stubs file, you only need to regenerate it if the signal connections change, i.e. adding ports or changing hdl_paths.

Reply

  • Hi.

    Firstly you should not be using tick accesses these days. You should be using simple ports instead, as they have better performance and give less flow problems such as the VHDL/Verilog binding that you're seeing.

    dma_done_w : in simple_port of bit is instance;
    keep dma_done_w.hdl_path() == "~/ve_top_tb_sn.DUT.ve_core_inst.pss_top_inst.pss_ring_inst.pss_core_inst.pss_arcss_core_inst.ipss_dma.done_w";
    keep dma_done_w.agent() == "Verilog";
    event collect_cover_done_e is rise(dma_done_w$)@sim;

    This gives you other benefits because each port in a unit can have a different language agent set, which avoids the limitation of tick accesses where the entire unit has only one language agent.

    Now, the other common mistake people make is thinking that they don't need to load their e code when generating the stubs file.
    You MUST load your e code before generating a stubs file, otherwise the simulator doesn't know which RTL signals you wish to connect to. This is important because the simulator tends to optimise away some signals (e.g. feed-throughs) to improve performance. It must know during elaboration that you want access to the signal, and the stubs file tells it that information.

    After generating a stubs file, you only need to regenerate it if the signal connections change, i.e. adding ports or changing hdl_paths.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.