Fork pulp_soc add CV32E40P about core-v-mcu HOT 13 CLOSED

@davideschiavone It would be good to ask Shteryana Shopova and Robert Balas about interrupt mapping, since they have more OS experience.

from core-v-mcu.

@bluewww do you have any suggestions? I don't have Shteryana Shopova GitHub ID, nor Greg Martin's one

from core-v-mcu.

@davideschiavone @shteryona is the GitHub ID you need

from core-v-mcu.

An idea for interrupts. but first a clarification comment. We have irqs 3,7, and 11 and 16-31 supported by the cv32e40p, My understanding is irq3 is a software request, Irq7 is Mtime and irq11 is machine interrupt. Is this correct? Does the core-v-mcu support or should we be supporting an MTIMER for IRQ7? This seems to be a good place for an OS periodic timed interrupt. Could that be a rearrangement of the current timer_unit interrupts? or should it be a new timer entity? (currently irq10 and irq11 are TimerL0 and TimerHI). I would propose we connect irq10 to irq7 for MTIME. IRQ11 would seem to be a good match for the event interrupts. The current system routes the udma (and other?) events through an event fifo that seems appropriate for user expandability. That leaves the higher priority interrupts for real time critical applications.

from core-v-mcu.

@gmartin102 . The interrupt mapping should be decided by you, @bluewww and @shteryona .

What you propose looks fine to me, i.e. mapping

PULP IRQ 10 to CV32E4 IRQ 7.
PULP IRQ 26 to CV32E4 IRQ 11 (i.e. event fifo)
And all the rest in the fast interrupts.
We can also attach
PULP IRQ 0 to CV32E4 IRQ 3 (as PULP 0 to 3 are SW interrupts AFAIK)

Please write a proposal and discuss with the SW team ( @bluewww and @shteryona ) as well to have freeRTOS aligned.

Then we can document it, and I will make the changes in the RTL.

does it sound good for you?

and I can integrate that in the RTL

from core-v-mcu.

@davideschiavone
Yes This sounds good, I'll pull a slide together that outlines the basic plan. I'm not completely familiar with all the events -- I count 168 of them and most seem to be place holders? and we seem to have half a dozen or so fast interrupts defined. should have this available in a the next day .. certainly before Friday's discussion

from core-v-mcu.

@davideschiavone I think this is a reasonable mapping.
One thing we have to check yet if the timer that is currently mapped to PULP IRQ 10 can fulfill the properties outlined in the riscv-privileged document with respect to mtime, mtimecmp. Shteryana has made some arguments that this might be the case.

from core-v-mcu.

Attached is a proposal for the interrupt mapping.
Core-Interrupt.pdf

from core-v-mcu.

@davideschiavone I think this is a reasonable mapping.
One thing we have to check yet if the timer that is currently mapped to PULP IRQ 10 can fulfill the properties outlined in the riscv-privileged document with respect to mtime, mtimecmp. Shteryana has made some arguments that this might be the case.

I think lowRISC's OpenTitat has exactly the TIMER you are looking for:

https://github.com/lowRISC/opentitan/blob/master/hw/top_earlgrey/rtl/autogen/top_earlgrey.sv#L816

Here the RV TIMER is attached directly to the Ibex core

Here the Timer: https://github.com/lowRISC/opentitan/blob/master/hw/ip/rv_timer/rtl/rv_timer.sv

It probably needs some hack to translate the input and output port registers:

input  tlul_pkg::tl_h2d_t tl_i,
output tlul_pkg::tl_d2h_t tl_o,

Here the definition of this interface protocol

https://docs.opentitan.org/hw/ip/tlul/doc/index.html

If one can do the TUL2APB and APB2TUL bridges or directly modify their core (which I would not recomend)
that would be perfect

from core-v-mcu.

Just came to my mind that as Ibex speaks OBI, there must be an adapter OBI2TUL, and indeed

https://github.com/lowRISC/opentitan/blob/master/hw/ip/rv_core_ibex/rtl/rv_core_ibex.sv

It's not the best, but one can use this, or starting from that, developing the TUL2APB and viceversa.

from core-v-mcu.

Re: integrating CV32E40P, it appears there is a file reference to ./rtl/include/cv32e40p_fpu_pkg.sv missing in the cv32e40p/src_files.yml file.

I added the following to core-v-mcu/ips_list.yml:

cv32e40p:
  commit: master
  server: https://github.com
  group: openhwgroup

and ran update-ips, and it adds the source files for the core in core-v-mcu/ips and updates the core-v-mcu build scripts, but when running synthesis there are errors with missing fpu package. When I add cv32e40p_fpu_pkg.sv to the src_files.yml file, re-run update-ips, and then proceed to the FPGA flow, everything builds. I guess that should be a issue for cv32e40?

from core-v-mcu.

Hi @hpollittsmith , the cv32e40p integration is on me and it is tracked in this pull request:
MikeOpenHWGroup/pulp_soc#1

once this is done I will issue a PR against the core-v-mcu branch that @zarubaf created that is aligned to PULPissimo.

Please let's not duplicate tasks. I will handle this tasks as I assigned them to me so that we keep aligned and fresh with PULPissimo

from core-v-mcu.

Guys, the module should now be flattened inside the rtl/ directory with the changes applied.

from core-v-mcu.