What is the downside of implementing interrupt service routine in a component?

UVM
, ,
1

For implementing ISR, our team has proposed two ways of doing this:

  1. Trigger a uvm_event when interrupt is asserted, wait for the trigger in a sequence that runs throughout the simulation. When an interrupt is triggered the sequence does the usual ISR steps of reading status, enable and resetting the status.
    Here the argument is uvm_event is unmanageable and not re-usable.
  2. Monitor the interrupt assertion and send it to a uvm_component via uvm_analysis_port. In the component run task, implement the ISR. Question here is, is it okay to do register write/read from a component and if so how will the priority be handled.

Please discuss the pro and cons of either method. which is mostly used across industry?

Thanks

2

In reply to manon:

I’m not sure I can answer your question directly but I can give you some thoughts to consider.

Your two proposals are not mutually exclusive. Either way you need to have a process that gets blocked waiting for something to happen. It’s created by the run_phase of a component, or a fork/join_none in a sequence. An either can be triggered by uvm_event or an analysis port.

If you do a search for “UVM interrupt service routine” you should get pointers to many conference papers and other posts that many contain more ideas.

3

In reply to dave_59:

Thank you dave. I will explore this further.