peakRDL : Interrupt support

[martin-tanguay]

Hi,

Playing around with PeakRDL and the interrupt support. It looks like there is interrupt support, which is nice. However, one thing that appears to be valid in SystemRDL 2.0 but not in PeakRDL is parameterizing a module. According to the spec I should be able to create a generic interrupt.rdl with a param that defines the number of bits. When I instantiate that in another rdl I should be able to override the param and even assign names to each bit. This doesn't appear to be supported in PeakRDL though. Can you confirm if that's true ?

I should be able to instantiate a generic interrupt module like this. This is all based on ChatGPTs interpretation of the 2.0 spec so it may be incorrect.

Thanks for your help !

Martin

[martin-tanguay]

Hi,

Is anyone here experienced with interrupt support in peakRDL ?

Thank you in advance for your help :-)

Martin

[amykyta3]

Not sure what ChatGPT is doing there. That is definitely not even close to valid RDL 😆!

Generally I've found interrupts to be more useful as individual 1-bit fields. SystemRDL's semantics for interrupts generally work more cleanly this way.

Heres a simple example of a level-sensitive interrupt with a corresponding enable:

reg {
    field {
        sw=rw; hw=w;
        level intr; // Is a level-sensitive interrupt
        stickybit; // Is sticky if input sees a '1'
        woclr; // Software has to write 1 to clear the interrupt flag
    } interrupt_flag;
} ifg;

reg {
    field {
        sw=rw; hw=na;
    } interrupt_enable;
} ien;

ifg.interrupt_flag->enable = ien.interrupt_enable; // Masks the interrupt if interrupt_enable==0

In addition to the interrupt flag/enable behavior, the above infers an interrupt output that ORs the resulting interrupts defined in the ifg register.

[martin-tanguay]

Thanks for the reply. I've opened the discussion, but I will let me colleagues answer as they are more into the interrupts implementation that I do.

[erikliljey]

Ya. ChatGPT really struggles with this stuff.

I've made some progress on this front and have figured out how to properly code the interrupts so that it produces what we need. Using individual fields makes sense and also allows us to dynamically assign names/descriptions to each interrupt.

The only missing piece is there's no way to parameterize the number of fields in a register, but it looks like that's a limitation of the language itself. My intention, based on a previous tool, was to have a general interrupt.rdl file that could be completely customized, including the number of interrupts, when included in another rdl. The other tool used tricks with perl to make this work. We're trying to go with pure rdl, so at the moment I have a generic 32 bit interrupt.rdl file and we only use the bits we need. Not exactly what I had in mind, but it gets the job done. We've also experimented with using the perl stuff with peakRDL. That also looks promising if we really need to go that direction.

[amykyta3]

Not sure if you thought of this yet, but one way you can get around the language limitation and get a parameterizable number of 1-bit fields is using the ispresent property along with comparison with a parameter. This avoids using the Perl preprocessor which is pretty awful in terms of flexibility:

reg my_interrupt_reg #(longint N=4) {
    field {} f1;
    field {} f2;
    field {} f3;
    field {} f4;

    f1->ispresent = (N >= 1);
    f2->ispresent = (N >= 2);
    f3->ispresent = (N >= 3);
    f4->ispresent = (N >= 4);
};

Ugly, but it should work.

[erikliljey]

Interesting. I'll have to dig into that. Thank you!