What do we know about VME ?

[AudioMonster]

That one seems to be the most exciting chip on the PSP ! :o)

Has anybody done even a simple operation with it ?
I cannot find any documentation on it, any suggestion ?

[AudioMonster]

Just to refresh your memory about the 'Virtual Mobile Engine' :

- Reconfigurable DSPs
- 128bit Bus
- 166MHz @1.2V
- 5 Giga Operations /sec
- CODEC Capability
- 3D Sound, Multi-Channel
- Synthesizer, Effecter, etc

5 Giga Operations / sec @ 166 MHz ? ... wow :)

There is an interesting article about the VME here :
http://www.sony.net/Products/SC-HP/cx_n ... eview.html

' in 2002, Sony developed the Virtual Mobile Engine™ as a method for achieving significant power reductions and miniaturization in LSIs for audio/visual products. This circuit technology, which can reduce power consumption by approximately 1/4 over conventional general-purpose digital signal processors (DSP), was adopted for use in the CXR704060 LSI used in the Network Walkman "NW-MS70D". '

It would be nice to have the user manual for that CXR704060 to get an idea on how to use the VME. I was only able to find a datasheet here :
http://www.sony.co.jp/~semicon/english/ ... 806322.pdf
.. which does not teach too much about the VME itself.

An other article here gives very little amount of information:
http://www.extremetech.com/article2/0,1 ... 233,00.asp

My guess is that the VME is close to a FPGA. At least, it partially retained the "reconfiguration" capability of the FPGAs, without being as versatile.

I don't know if a lot of you guys are familiar with FPGA ( i am not an expert at all too ), but those chips are completely reprogrammable at power-on ( the right term is "configurable" ). You could recreate a full CPU ( some people even recreated a full computer ) in an FPGA. So, it goes beyond emulation as the FPGA can behave *exactly* as the original chip(s).

Also, a FPGA can achieve very high parallelism.
If the VME of the PSP can really do 5 GigaOp / sec by running at 166 MHz, it means it can achieve 30 parallel instructions per cycle.

Now, the question is, which instructions would you like to run in parallel and on what data should they operate ?
I presume it is what the reconfigurable capability of the VME is all about. The chip probably features a certain number of blocks which can achive a particular function, like a multiplication, or an addition, or a multiply-accumulate, and so on ...
And you, the user, can tell the VME what functions you want to execute during the next cycle and can also reconfigure the data path so the functions can operate on the data you want. This is super powerful.

Ok ok ... all this may be completely wrong and total bullshit. But i think that makes complete sense especially when reading the first article i mentioned from sony.net

I would love to have feedback on this, please tell me what you think.

The Virtual Mobile Engine does not seem to have been explored at all.
For sure it is a difficult task to find out how this monster works, but to me, it has incredible potential !

[PspPet]

> ...An other article here gives very little amount of information...
That's the general trend. Sony doesn't give out detailed technical information for their proprietary chips (other than vague slideshow content for hype)

---
There are minimal system APIs for the VME (disable/enable reset).
It appears the VME software is tied into the ME (Media Engine).

Suggestions/speculation:
If interested in the ME software, take a look at the "mebooter.prx" and "mebooter_umdvideo.prx" system files. Both of these files contain a GZIP copy of the ME software at the end (the mebooter.prx version is bigger, over 800KB).
(ie. the ME code is unziped, saved to memory, and the ME is reset).
You can disassemble this with a MIPS disassembler (the ME is the 2nd MIPS CPU). About half of it is MIPS code. The other half is data, some of which looks like it *might* be FPGA initialization data for the VME. It could also be general data tables (for the ME CPU), and/or code/data for the AVC (MPEG4 decoder).
A lot of reverse engineering required to figure it out.

[laxer3a]

Hi,

I am actually playing with FPGA on my free time...
And what you are describing about "reconfigurable DSP" sound fairly like a FPGA to me but it could be also simply the "assembly program for a DSP".

But reading about power consumption and feature, it seems like an hybrid between a DSP and a FPGA :-)
Basically you would have some "feature" that are hardcoded into the silicium while allowing some part to be dynamically modified into the chip.
(then yes, it cost far less energy to run a function as you dont need a CPU to execute software code to do the same thing)

But I have one thing to say : if you dont know the type of FPGA, there is no way you can write a "feature" from scratch.
Moreover, to create something you would need to use a VHDL compiler and routing software for the VME chip.
It is also possible that this part of the chip is very limited in his modification and standard way of making this stuff may not be possible too.

Each FPGA has its own architecture and protocol to be uploaded.
If it is a custom chip from Sony, it is most likely that nobody will be able to figure it out from scratch.

Now a question comes to my mind then :
Does Sony allow programmers on PSP to get their hands on the VME ?

Personnaly, I dont think so... There would be so few software engineer in game company able to write a hardware chipset :)

They probably keep it internal and change the features with bios update.
Sony is probably saying : play with ME. VME is our stuff.

[jsgf]

A couple of points:

The data sheet is very interesting. For one thing, it says the CPU core is ARM based (ARM7TDMI). This doesn't sound like a match for the PSP's hardware, unless this is another CPU doing something completely different (since we know that the PSP has at least two independent MIPS cores, right?). Or maybe the data sheet is another chip using the same VME core as the PSP's chip (since the chip in the data sheet has a massive number of GPIOs and analog channels, which the PSP doesn't seem to make any use of). Either way, a lot of that "data" in mebooter*.prx might be ARM rather than MIPS machine code.

(Edit: The Sony article mentions that VME is used in Network Walkman, so I'm guessing that's the datasheet you've found.)

The ExtremeTech article mentions the VME can reconfigure in a single cycle. This is unlike any FPGA I've heard of, which typically take a long time to load a new configuration. I think its probably a lot less general-purpose than a full FPGA.

Is the a similar data sheet for the other chip (the one containing GE)?

[cheriff]

CPU core is ARM based (ARM7TDMI). This doesn't sound like a match for the PSP's hardware, unless this is another CPU doing something completely different

That is correct, from what i recall when the PSP was brand shiny new in japan, is that there is an arm chip in there and the speculation was that it most likely looks after the low level wifi stuff.

[laxer3a]

Hi

I dont think ARM has anything to do with the VME, it does not match any of the description done before in term of energy, power, feature.

A mips or ARM cpu is quite expensive in term of electrical power for a given output. But it is versatile... Which is the opposite of the VME.

I heard also about that ARM stuff, would not it be just a simple cpu like ARM7 somewhere running at low speed clock to handle I/O like USB, serial port or whatever ???

[AudioMonster]

Sorry, i guess i confused you a little bit.

That datasheet is indeed for the chip which is inside their network walkman.
I think that the only thing that the PSP and this chip have in common is that they both embed the VME, but that's it.
I wish i could have the User Manual for that chip because it will *probably* give us some hints on how to use the VME ! It seems this chip is "public" so there may be a way to get the manual (?)

Also, i don't think that the VME is just an FPGA and can be completely reprogrammed to make a new function ( like a 64x64 bits multiplier for example :P ). It sounds like it is just a bunch of "hard-wired" functions blocks that you cannot touch, but for which you can change the route.
I expect those functions to be strongly Digital Signal Processing oriented, to suit the need of the CODECs.

Also, I would expect Sony to give the developpers the opportunity to change the route, so they probably give full access to their VME. If you cannot change the route and use this and that function block in parallel as you wish, then the VME is probably kinda useless !

Still, i am not positive about all that ... but still very intrigued by that huge processing power potential :)

[laxer3a]

Yes, you are right AudioMonster.

It could also be possible small unit doing "heavy" data processing which are reconfigurable in terme of connection...
But then you would need a kind of "main cpu" to control the flow
(take data here, move it there...), which does not match the spec so much in term of power consumption.

Anyway that VME seems quite mysterious !!! :)

[cheriff]

Hmm. I was under the impression that even official devs cannot play with it. When playing a game it is configured (whatever that may entail) to be an ADPCM decoder and the kernel audio functions work through that.
When playing mp3's the kernel configures it into a mp3 decoder, and same again for umd videos. So if devs could play with it, it might break existing functionality? Unless they want to do audio decoding in SW and deal with raw PCM...

But I dunno. thats just my guess about the way things are.

[shifty]

If it's an FPGA, then I could understand why most devs cannot use it.
FPGA code is described at a level even lower than assembly language.
Sophisticated tools are necessary to ensure that all gates have
received their electrons on time!

Nevertheless, there are plenty of competent FPGA programmers out
there! Reverse-eng of something like this is very difficult, though.
As many examples of VME code should be discovered as possible.
Probably, not every game is using the exact same routines from
Sony...probably the code evolves.

I'm going to speculate: I think by reconfigurable DSP, it means there
are already large computational blocks on there, such as multipliers,
adders, exp/log units, etc. There may also be the capability of
designing custom opcodes. I'm sure another important part of it
is the scheduler to move blocks of memory back and forth to the ME.

And yes, some FPGAs exist that can change their programs very quickly.
A friend of mine designed one for a high-profile client!

I'm not sure if the fast program changing is intended for multiple
processes to use simultaneously? Often DSPs have small
memories, because they're built of very small, fast sram memories.
This means large programs, like MPEG encoders, can't fit in RAM
at once. There are two strategies for working around this. One
way is to DMA the following part of the program into a section of
memory not currently used, then jump to that, and fill the previous
section of memory with the next piece of code. The other is to
have the FPGA cells switch their functions and routing quickly.

A good example of a reconfigurable DSP is the mp3 decoder chip
inside some players, i think including the Archos? Its mp3
decoder is implemented as a very short program, about 50 opcodes.
Each opcode does a very large amount of processing, like
"arithmetric decode buffer" and "synthesize block from spectral coefficients." The chip has a switch for the default mp3 program,
or you can write your own sequence of mega-opcodes. In theory,
one could write e.g. an ogg vorbis decoder using these opcodes,
but last i knew, no one had, due to incomplete specs released.

I have used a reconfigurable ASIC that had 96-bit opcodes!
The main program it ran was two instructions long! It was only
when there were exceptions that other parts of the program were
used. I think the max program size was 128 or 256 words, but
our program was only about 30-40.

Since the number of VME gigaflops is quite large, I'm confident it's
due to a large number of parallel operations. The AMD64
chip, for example, has a single "correlation" instruction to find the differences between 8 pairs of 8-bit integers, take the absolute magnitude,
and sum them. That might count as 17 opcodes. If such an
instruction were to execute at 166MHz, it would mean 2.8 Gflops.

There's one other possibility...based on what I understand of some of
the newer techniques. I think it might be possible to assign
"microstrips" of code to every object in a virtual world. For example,
at 60 fps per second, you might swap in 1,024 different programs. Each
program computes the physics for some small part of the world, such
as the velocity/acceleration/gravity for physical objects, or sample playback/filter/volume for sound objects or collision detection etc. This
would require the fastest possible context switching. The good news
is that it's very deterministic, so caching can deliver ideal performance...

[Wally]

Are there any new findings in relation to the VME yet?

Just curious!

[hlide]

ME code is using "ldl" and "sdl" instructions (normally 64-bit version of lw/sw) heavily and in a way suggesting they are used for a very different purpose : testing if a controller is busy and transferring data from/to a controller. I wouldn't be surprised if it were a special interface between MIPS part and VME part.

And I was told by a friend who knows a game developer that even official developers cannot use the second MIPS processor (ME) for their own purposes. The only thing they could use that much is an API for codec.

[cualquiercosa327]

some new about mebooter.prx disasm file?
I asked because hlide coments.

thanks

[cualquiercosa327]

Hello.I have readed this post in the past and i am very interested on vme.


Recently i am investigating about fpga for acelerating code,and i found a great book:Wiley-Practical_FPGA_Programming_in_C

it is a book about fpga/dsp programing in c,with a compiler which translate to
VHDL's fpga is able to use .

It describe the use of impulse-c
http://www.impulseaccelerated.com/
It is a set of tools for creating c code an executing in dsp/fpga.


I thought it could be interesting for someone here


(i have the book,and also after found it is available on pdf on the net )