Virtex4+PPC+ext. RAM: Problems generating ACE files (solved!?)

Hi *,

[Warning: Long post, includes patch for genace.tcl]

I am working with a custom Virtex-4 based board design using an internal PowerPC core and external SDRAM for code and data. Using the standard EDK flow, all is well: I can download the bitstream, use the PPC JTAG interface to upload and debug the software application.

Now, for making my tests reproducible, I wanted to generate an ACE file containing both the FPGA and the software configuration. After going through the documented steps to create an ACE file using genace.tcl, the resulting ACE file loaded fine. However, the software did not start running.

Connecting with XMD revealed that the software was loaded correctly both into the SDRAM and the internal data memory. However, the instruction memory - connected via an isbram_if_cntrl - was not correctly set up. Which is unfortunate as the start vector points to that memory type.

I spent a lot of time with analyzing the situation. Maybe I am doing something wrong but I am having trouble accessing the instruction memory from XMD even after having the system.xmp imported using

load xmp system.xmp

in xmd. It's just not working reliable. I tried loading the FPGA design with just the bootloop inside the BRAMs but was unable to see the branch instruction doing the infinite loop. However, I could write new data to the instruction memory to jump into my application which then works fine.

So I thought I had to mark my applicationt to initialize BRAMs in XPS. This solution leads to another problem: After configuration of the FPGA and before the System ACE controller load the application code to the SDRAM memory, the PowerPC inside the FPGA starts running and jumps into the uninitialized SDRAM.

As I was able to load the program correctly using xdm in interactive mode, I figured I could get it running by loading the system.xmp while creating the ACE file. This indeed helped, and my ACE files are now running fine.

What I did is a quick hack that works for me (tm), but I think this should be fixed in EDK as well. Here is the diff on genace.tcl:

--- /opt/Xilinx/EDK/data/xmd/genace.tcl 2006-06-30 03:26:56.000000000

+0200 +++ genace.tcl 2007-08-14 11:09:33.729977014 +0200 @@ -209,6 +209,11 @@ puts "Converting ELF file '$elffile' to SVF file '$svffile'"

set tgt 0

+
  • if { [catch { xload_sysfile xmp system.xmp } retval] } {
  • puts "$retval"
  • error "ERROR: Unable to load system.xmp"
  • } if { $target_type == "ppc_hw" } { set a "xconnect ppc hw -cable type xilinx_svffile fname $svffile $xmd_options" } else {

As I understand, the configuration flow now goes as follows:

- System is powered on / reset

- SysACE controller clears the FPGA configuration

- SysACE ctrl. waits for FPGA to get ready for conf

- SysACE downloads the logic and BRAM configuration to the Virtex4

- ### In an ideal world, the PPC would wait until the software was downloaded ###

- instead: SysACE senses that FPGA is configured (DONE pin goes high), PowerPC starts executing instructions (from BRAM)

- here: instruction BRAM just contains here: b here so PPC loops

- SysACE halts the PowerPC using JTAG, uploads program via JTAG through the PPC's memory interfaces (this is only done correctly if xmd had the right memory map while creating the svf file)

- SysACE sends "continue" command to PPC via JTAG

- Configuration is complete, PPC application up and running

Can somebody tell me if I got it right? Does the patch make sense or is there a better way to load instruction memory from System ACE? I tried using

xmd -xmp system.xmp -tcl genace.tcl -opt genace.opt

but it seems the "-xmp" option is ignored when running a script.

Hoping for a bit of feed back,

Torsten

Reply to
Torsten Landschoff
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.