Interrupt Vector Table Placement on the TI 64x

[Randy Yates]

Does it ever make sense to place the interrupt vector table
in cacheable SDRAM? If the vector table is loaded into L2
SRAM, interrupts run quickly. If the vector table isn't
loaded into L2 SRAM, then you're going to take a bit
hit in interrupt processing time while the cache unit
loads the miss. So why not just keep it in SRAM?

--Randy

[Jerry Avins]

Randy Yates wrote:
> Does it ever make sense to place the interrupt vector table
> in cacheable SDRAM? If the vector table is loaded into L2
> SRAM, interrupts run quickly. If the vector table isn't
> loaded into L2 SRAM, then you're going to take a bit
> hit in interrupt processing time while the cache unit
> loads the miss. So why not just keep it in SRAM?

Randy,

Why do you want slow interrupts (or is it long latency)? That's a new
one on me, but I'm sure there's a good reason. Thanks.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Carlos Moreno]

Jerry Avins wrote:
> Randy Yates wrote:
>
>> Does it ever make sense to place the interrupt vector table
>> in cacheable SDRAM? If the vector table is loaded into L2
>> SRAM, interrupts run quickly. If the vector table isn't
>> loaded into L2 SRAM, then you're going to take a bit
>> hit in interrupt processing time while the cache unit
>> loads the miss. So why not just keep it in SRAM?
>
>
> Randy,
>
> Why do you want slow interrupts (or is it long latency)? That's a new
> one on me, but I'm sure there's a good reason. Thanks.

I do not believe that's what Randy said or implied. In
fact, the way I'm reading his message, he's saying exactly
the opposite...

Am I the one misunderstanding the message?

Carlos
--

[Randy Yates]

Jerry,

I don't. What makes you think I did?

I'm looking at someone else's code and
this is exactly what they did (put the
interrupt vector table in slow, cacheable
SDRAM). I'm asking if there's a reason
for it, cause it sure looks to me like a
stupid thing to do.

--Randy

[Jerry Avins]

Carlos Moreno wrote:
> Jerry Avins wrote:
>
>> Randy Yates wrote:
>>
>>> Does it ever make sense to place the interrupt vector table
>>> in cacheable SDRAM? If the vector table is loaded into L2
>>> SRAM, interrupts run quickly. If the vector table isn't
>>> loaded into L2 SRAM, then you're going to take a bit
>>> hit in interrupt processing time while the cache unit
>>> loads the miss. So why not just keep it in SRAM?
>>
>>
>>
>> Randy,
>>
>> Why do you want slow interrupts (or is it long latency)? That's a new
>> one on me, but I'm sure there's a good reason. Thanks.
>
>
> I do not believe that's what Randy said or implied. In
> fact, the way I'm reading his message, he's saying exactly
> the opposite...
>
> Am I the one misunderstanding the message?

Probably I am. Thanks.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Carlos Moreno]

Randy Yates wrote:

> I'm looking at someone else's code and
> this is exactly what they did (put the
> interrupt vector table in slow, cacheable
> SDRAM). I'm asking if there's a reason
> for it, cause it sure looks to me like a
> stupid thing to do.

Well, or an oversight, could be?

Carlos
--

[Bhooshan Iyer]

Randy--

>Does it ever make sense to place the interrupt vector table
>in cacheable SDRAM?

I dont know for sure but what if you are being forced to relenquish th
entire L2 as a 4-way set associative cache? Then you are left with n
piece of SRAM left free. Possible.

>If the vector table is loaded into L2
>SRAM, interrupts run quickly.

The convention in a C6000 system is to place the vector table starting a
address "0". (Anything else is ACTUALLY a pain!)

And another longshot:

And in older C6x0x devices addresses starting at address "0" wher
actually SDRAM(external memory/CE0 Space)and they never had two level(L2
memory hiererchy either. In contrast to the newer C6x1x devices which hav
2-level memory and have internal(fast memory) starting at address "0". S
is it possible that the code you are looking at were written for the olde
C6x0x(C6701/C6201) devices? Would that explain it?

--Bhooshan


This message was sent using the Comp.DSP web interface o
www.DSPRelated.com

[Randy Yates]

"Bhooshan Iyer" <[email protected]> writes:

> Randy--
>
>>Does it ever make sense to place the interrupt vector table
>>in cacheable SDRAM?
>
> I dont know for sure but what if you are being forced to relenquish the
> entire L2 as a 4-way set associative cache? Then you are left with no
> piece of SRAM left free. Possible.

Yes, that's a good guess, but the fact is they only use half (128 kB)
for the L2.

>>If the vector table is loaded into L2
>>SRAM, interrupts run quickly.
>
> The convention in a C6000 system is to place the vector table starting at
> address "0". (Anything else is ACTUALLY a pain!)

Not really - just change the ISTP (interrupt service table pointer),
no?

> And another longshot:
>
> And in older C6x0x devices addresses starting at address "0" where
> actually SDRAM(external memory/CE0 Space)and they never had two level(L2)
> memory hiererchy either. In contrast to the newer C6x1x devices which have
> 2-level memory and have internal(fast memory) starting at address "0". So
> is it possible that the code you are looking at were written for the older
> C6x0x(C6701/C6201) devices? Would that explain it?

It's remotely possible, I suppose. In any case, when I get free of my
current major code task, I'm going to try relocating it back to SRAM
and see if performance changes.
--
% Randy Yates % "Remember the good old 1980's, when
%% Fuquay-Varina, NC % things were so uncomplicated?"
%%% 919-577-9882 % 'Ticket To The Moon'
%%%% <[email protected]> % *Time*, Electric Light Orchestra
http://home.earthlink.net/~yatescr