• Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 503 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Guaranteeing Single Memory Access

MattB
Expert 2025 points

Hi,

Our FPGA has an interrupt status register that resets on read. I have to read the register and decode the value to decide what events have occurred. In other words I have written an ISR that looks something like:

Void IsrFxn(Void)

{

    const Uint16 interruptStatus = *(Uint16*)0x64000012;        // read clears value

    if (interruptStatus & 0x0001)

    {

        ...

    }

    if (interruptStatus & 0x0002)

    {

        ...

    }

    // and so on for all 16 bits

}

I know that the compiler (CGT C6x) attempts to reduce memory accesses and the code I've generated (CGT V6.1.13 with -o3) is okay because it reads the value of 0x64000012 into a register and keeps it for the whole function.

But is it guaranteed to work?

If not, is there away to ensure only one access?

Alternatively I could talk to the FPGA designer and come up with a different way of dealing with this i.e. write to clear or have clear register.

Any thoughts greatly appreciated!

Thanks,

Matt

  • TI__Guru* 84285 points

    You want to use the volatile keyword here.  The C standard requires that the compiler accesses volatile variables exactly as written, no more and no less.  The volatile keyword must also be used for variables where there is some external agent or side effect that is not expressible in C, such as if an access clears the memory location.

    Void IsrFxn(Void)
{
    const Uint16 interruptStatus = *(volatile Uint16*)0x64000012; // read clears value
  • in reply to Archaeologist
    Expert 2025 points

    Archaeologist said:
    You want to use the volatile keyword here.

    Yeah, okay!

    I thought about volatile and wasn't sure if it would do what I wanted because explanations of volatile tend to describe it the other way around i.e. a loop waiting for something to change. Because the compiler is doing the right thing without volatile it is difficult to prove that I need it!

    But you've convinced me!

    Now I'm just unsure about "read to clear" and what happens if the FPGA decides another event has occurred when I'm half way through the ISR but I don't think this is your problem!

    Thanks,

    Matt

  • in reply to MattB
    TI__Guru* 84285 points

    There are different ways of looking at how volatile works, but it all boils down to telling the compiler that something unpredictable is going on, and so the compiler shouldn't try to be over-clever .  In the case of a loop waiting for a variable to change, volatile tells the compiler that something out-of-line (perhaps an I/O device, perhaps an interrupt function) may suddenly change the variable, so the compiler will not attempt to optimize it away.

  • in reply to Archaeologist
    Expert 2025 points

    Archaeologist said:
    but it all boils down to telling the compiler that something unpredictable is going on, and so the compiler shouldn't try to be over-clever

    I like that explanation, thanks!

    I think what confused me was that I used volatile the other day to ensure multiple accesses (like in the loop example) and I had the idea of more accesses in my head.

    But really it's not about more or less accesses it's about the right amount of accesses!

    Hopefully I've got it now! It helps to talk!

    Thanks,

    Matt