[hw,dma,rtl] Add STATUS.chunk_done bit

[Razer6]

This PR adds a new STATUS.chunk_done bit to the status register to determine the cause when the DMA stopped an operation. In multi-chunk mem2mem transfers, where each chunk is transferred with a separate SW-go, chunk_done goes high when finishing every chunk, except the last chunk, where done goes high. The done interrupt fires for every chunk for now.

[alees24]

I think this does essentially what's intended, but there are issues with the interrupt-handling at present. The OpenTitan project was changed a few months ago so that Status type interrupt are specified explicitly in the IP block description and all blocks were updated accordingly; see my comments below, please.

[alees24]

With the present logic the dma_done and the dma_error interrupts should be declared as Status type interrupts in the dma.hjson file since the only way to deassert these interrupts and clear their bits in the intr_state register is to clear the bits in the status register, because dma_done|error.de is driven by reg2hw.status.done|error.q:

  interrupt_list: [
    { name: "dma_done"
      desc: "DMA operation has been completed."
      type: "status"
    }
    { name: "dma_error"
      desc: "DMA error has occurred. DMA_STATUS.error_code register shows the details."
      type: "status"
    }

This is a requirement of comportable IP blocks, for the CIP base tests to pass.

The present behavior of the 'intr_test' register will also be subtly incorrect, in that Status type interrupts should remain assert whilst the 'intr_test' bit is asserted. It would be simpler/easier to use the prim_intr_hw submodule to implement the interrupt lines.

Alternatively: It may have been intended that the intr_state bits be set in the event of the status.dma_done|error bits rising, ie. Event-type interrupts, although in this case the bits in the status register are somewhat redundant since the intr_state register shall capture that information too.

[Razer6]

@alees24 Thanks for the review. Could you take another look? CI is currently failing because the integrated_dev branch is not able to correctly create the auto-generated unittests for status interrupts, which is fixed on master. The plan is to rebase that PR on top of master and merge it there once the DMA is in there.

[alees24]

Thanks for making the changes to the interrupt handling, and using the prim_intr_hw module. That looks fine.

If you resolve the issue with the default hw2reg assignment and are happy to sign off the compatibility breakage by inserting a bit into the status register then I will approve this.

[alees24]

It is not safe to drop this assignment at present because the following signals will be left undriven/undefined:

hw2reg.control.initial_transfer.d
hw2reg.control.initial_transfer.de
hw2reg.sha2_digest[i].d

In particular the control.initial_transfer signals must be driven at all times; simulations fail presently because initial_transfer.q becomes undefined as soon as a transfer starts.

It is perhaps worth leaving the default assignment in place (I may have missed other signals) and annotating that it is required for driving the above signals, as well as avoiding latches/other undriven signals.

An alternative would be to ensure that the above signals are always driven explicitly.

[Razer6]

Right, I had to explicitly drive these signals since the the prim_intr's added a second driver to the hw2reg. Thus, the default statement would cause a conflicting driver.

[Razer6]

With the new status interrupts, I had to re-predict the interrupts when writing the status register, ie., clerating the status.

[Razer6]

@alees24 Thanks for the review. Could you take another look to get this merged?

I updated the DV environment to deal with the status interrupts. All tests except the automated dma_intr_test (comfortable test) fail. Could you take a look into this one? Otherwise, maybe. @rswarbrick. Note, tests need to include #24962 to pass.

[alees24]

The RTL changes look okay, thanks, but I'm seeing more than just dma_intr_test failing presently:

0.dma_abort.88760512117758134865029955350941779515590544128422615357238515974507785526752\
0.dma_intr_test.67386857437561253008700698343085724055010273966100030887847157593273296727411\
0.dma_memory_region_lock.62058440537178885937077771562078581177386725377790603349600473204830182595305\

I'll try to investigate these shortly, but if you happen to get to it before I do, please try those seeds; busy with another project release right now.

[Razer6]

It seems there is an issue on how predicted interrupts are getting cleared. When a DMA gets aborted, the interrupt prediction queue is left untouched. After some while, a previously predicted interrupt expectation gets asserted.

There is a second issue where the abort occurs just before a done. It seems there is an interrupt predicted although the abort has higher preiority.

[alees24]

With the proposed DV changes to fix dma_abort and dma_intr_test, I'm seeing only:

Assertion range_regwen_rd_A has failed

For dma_memory_region_lock, and by inclusion dma_stress_all, which is because the autogen FPV is unaware of MuBi regwens on master at present. I think we can defer that issue for now.

[Razer6]

Thanks @alees24 for looking into this. I cherry picked your changes into that PR.

[alees24]

Thanks for the changes. LGTM.