View Single Post
  #13 (permalink)  
Old 04-29-2006, 05:12 PM
Brian Drummond
Guest
 
Posts: n/a
Default Re: Xilinx Virtex-4 OCM Usage Issues

On Fri, 28 Apr 2006 13:01:57 +0100, "Ben Jones" <[email protected]>
wrote:

>Hi Brian,
>
>"Brian Drummond" <[email protected]> wrote in message
>news:[email protected] .


>> IMO this limitation COULD have been more clearly documented, as well as
>> trapped by the tools...

>
>Good point. As far as documentation goes it took me a while to find where
>this is explained (PowerPC Processor Reference Guide, Chapter 7 "Exceptions
>and Interrupts", section "Interrupt-Handling Registers", EVPR, page ~204,
>and also mentioned in the OS and Libraries Documentation, Standalone PowerPC
>BSP section). :-) Do you have a suggestion as to where else you think this
>should be mentioned, to make it more obvious?


I confess I haven't been through every page of documentation ...
I'd have to think to recreate the places I looked unsuccessfully.
XAPP778 page 14 was where I found it. It took a while searching the
support site on things like "PPC interrupts".

>The EDK tools do the Right Thing when generating the default linker script -
>and Base System Builder will notify you if you don't have room for the
>vector table in your project due to this limitation (e.g. you have < 64KB of
>BRAM).


Good to hear ... 7.1 didn't (at least, not in my hands).

I had a 32K plb_bram at ffff8000, and a 16k one at ffff4000. I inherited
the project (so no BSB phase), and in ignorance, moved the lower from
ffff0000 to make them contiguous, and wrongly assigned segments in
"Generate Linker Script". This dialog could warn; but that wouldn't
cover hand edited scripts.

> I guess the linker could be modified to check what it's being asked
>to do with the "vectors" section and barf (or at least issue a warning) if
>the alignment is wrong, but this would be a bit of an ugly "special case"...


IMO it *is* an ugly special case already. I don't believe telling the
user about it is uglier than linking non-functional code.

- Brian
Reply With Quote