Embedded ppc405 w/o RAM?

All,

Is it possible to run programs on the embedded PowerPC in the Xilinx chips without external RAM and/or operating system? The PPC will only be doing some minor work and it would be much better if we can get away with not putting any RAM on the boards. The ideal would be to store the instructions in block RAM on the FPGA and then trigger the PPC to run. Is this possible?

Thanks!

Eric

Reply to
reidek
Loading thread data ...

schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

sure, look at the ultracontroller II at xilinx website !

Antti

Reply to
Antti Lukats

Ultracontroller II runs code out of the processor cache and not the Block RAMs. You can easily create PPC405 systems using only BRAMs using Base System Builder. However, If you are looking to do something simple with the PPC405, Antti's suggestion (Ultracontroller II) is best. Besides the appnote, there is a video demonstration of Ultracontroller I at

formatting link
by Glenn Steiner.

Kunal

Antti Lukats wrote:

Reply to
Kunal Shenoy

It is the first entry under "embedded processor solutions" . UltraController is mentioned in the text, but not in the title.

formatting link
Peter Alfke

Reply to
Peter Alfke

Excellent, thanks for the suggestions. I should be getting my eval board in the next couple of days, so this will get me going in the right direction.

While I'm waiting, I do have another quick question. Can I write to BRAM when using the Ultracontroller? Part of the working I'm hoping to have the PPC do is calculating calibration data that the FPGA will use. Will I have to use the Base System Builder to do something like this?

Thanks again!

Eric

Reply to
reidek

Eric,

The Ultracontroller II runs on a small c-program that you write, and then compile, and gets placed in the cache. If you also use less than

16 kbytes of memory space for some data (in the form of an data array), then if you can fit the program in 16 kbytes, and the data in 16 kbytes (the space alloted by the Ultracontroller II caches), it should work fine.

There is a fixed 32 bit input/output port (one) associated with the Ultracontroller, so the I/O is pretty thin as well.

The intent was to be able to use the PPC for simple tasks that didn't require a lot of code space, I/O space, or data space without using up FPGA resources.

Ultracontroller I (the original) used BRAM for code and data, which meant that the 18 Kbit memory when used 32 bits wide held very little code (data) without piling up a lot of BRAMs.

formatting link

Aust> Excellent, thanks for the suggestions. I should be getting my eval

Reply to
Austin Lesea

Austin,

If it's not obvious, I'm new to this, so bear with me. :)

One of the things that I need to be able to do is create a calibration table. The PPC would read a few values from the FPGA, and create a 8K or so table, which seems to be within the limits of the ultracontroller II. What I'm not sure of is whether the FPGA has access to the caches, or whether I can write to some other block RAM with the PPC that the FPGA would have access to.

Sorry if this isn't quite making sense. I'm a software guy and haven't worked with this stuff in a few years. Eventually, another team member will be writing the VHDL/firmware and I'll be writing the software that runs on the PPC. I've been tasked with figuring out how to program the PPC and interface it with the firmware. No one at the company has done this type of thing before, so I'm breaking "new ground".

Eric

Reply to
reidek

Eric,

Ultracontroller II uses the I cache (instruction cache) for the program, and the D cache (data cache) for the data. The script will place the code, and the data in the right places (the internal PPC caches) for you (if you have written the program properly).

It will execute entirely inside the PPC.

I don't see an issue here. The BRAM won't be involved at all. Other than the clocking to the PPC, and the one 32 bit I/O port, it shouldn't require connecting up anything else (pretty small verilog or vhdl description of the hardware needed along with the UCII core: pretty much which pins go to which IO bits, and where does the system clock go into the chip).

As soon as you want to go beyond the Ultracontroller II, you pretty much have to go into some depth, as you are then going to have to choose what kind of buses to use, and what kind of memories to add, along with what kind of IO.

Decoding addresses, bus widths, connections, etc. gets busy quickly if you wish to "roll your own" PPC system. Which is why the UC II is so useful to so many. For those that like to build their own computer systems, the PPC + FPGA offers some real advantages as all the pins are there, all 1000+ of them. A bonded out PPC part will have less than 200 wires to connect, so the FPGA version is really much more versatile, and you can be doing both instruction and data fetches at the same time as the buses are all brought out separately. I suggest starting with UC II, and then seeing where is goes from there.

You can easily end up with a uLinux system, flash cards, DDR2 memory, VGA, sound, UART, etc. if you go all out....

formatting link

or

formatting link

which is also useful if you are developing a more complex embedded system.

Aust> Austin,

Reply to
Austin Lesea

You might want to look at XAPP807 for an example application where UltraController-II is used in combination with the Virtex-4 Tri-Mode Ethernet MAC to run a web server completely from the PPC caches.

This application uses the data side OCM port on the PPC for communication with the TEMAC and could, in your application, be replaced with BRAMs for the parameters.

- Peter

formatting link

snipped-for-privacy@gmail.com wrote:

Reply to
Peter Ryser

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.