PlayStation Vita: various comments

[CreepNT]

There are a few inaccuracies, errors, or other things to comment in the PS Vita Part 1 article:

Multi-use Port on marked motherboard

N.B.: the internal name for this port is MultiCn, a.k.a. MultiConnector.

The Slim revision retains the same architecture, but exchanges the OLED screen for an LCD to reduce costs. Furthermore, it doesn’t offer a 3G-capable variant anymore. It does, however, feature a bigger eMMC chip… only 52 MB larger! For some strange reason, that was enough to provide an internal 1 GB memory card. In any case, I’ll explain more in the ‘Games’ section.

I guess the Games section is missing, so maybe you planned to mention what follows there, but either way:

1. I'm not sure the 52MB increase is a reliable Fat->Slim metric - IMO, this is just a detail due to slight vendor/SKU differences
2. The internal 1 GB memory card can be enabled on Fat models as well, it's just that SCE never did so (all eMMCs are ~4GB)

The PlayStation TV is just a Slim motherboard adapted for the non-portable setting.

The PSTV motherboard is actually something unique. It lacks hardware found on the Fat or Slim (e.g., Fuel Gauge), but also has exclusive hardware (e.g., Ethernet adapter). If any comparison should be made, the PSTV would be "closer" to a Fat, as it shares many ICs with it (Kermit, PMIC, ...).

Many accelerators (some proprietary, others off the shelf), including an ‘AVC Decoder’

The AVC Decoder is not a dedicated hardware block, but a software decoder running on VIP (presumably Venezia Image Processor - it's a sort of Venezia-based DSP, but not much is known about it).

Cache coherency among the cores is automatically handled by the Snoop Control Unit, previously featured in the ARM11MpCore.

N.B.: the SCU only maintains coherency of Data Cache, not Instruction Cache

By the way, in the case of the Cortex brand, only the ‘Cortex-A’ profile includes this package (the ‘Cortex-R’ bundles an MPU instead and the ‘Cortex-M’ includes neither).

Cortex-M actually also features an MPU (see for example https://developer.arm.com/documentation/dui0552/a/cortex-m3-peripherals/optional-memory-protection-unit)

TrustZone: A new security subsystem that adds a dimension to the privilege levels of the MMU. It’s implemented on both the hardware level (by segregating buses between non-secure and secure peripherals)

On Vita, there is no "Secure" and "Non-Secure" bus - all memory transactions are performed on the same bus fabric (but transactions contain a "tag" indicated whether they are secure or not).

Now, the Cortex-A9 (found in the PSVita) improves the original design by applying significant enhancements [8]:
Multi-core support. This is most evident by looking at Sony’s choice of a quad-core package.

Did you mean to write Cortex-A9 MPCore?

On the other side, it’s worth mentioning that Thumb-2EE, the successor of the deprecated Jazelle, has been left unused or even excluded from many Cortex-A CPUs. I don’t think the Vita’s SoC even bothers implementing this.

1. The correct name is ThumbEE, not Thumb2-EE
2. While ThumbEE was initially advertised as Jazelle RCT, it is more than just a successor of Jazelle DBX (or simply Jazelle)
3. According to CPUID registers, Kermit implements both ThumbEE and Jazelle (and the Jazelle implementation is not trivial)
4. The OS implements the bare minimal support code for both (but as far as I know, no application makes use of either)

The master bus
Another popular product from ARM, the AMBA protocol designed for interconnecting components, carries forward with the Cortex-A9. Still in its third revision, the AXI subset was selected for interfacing the cores and external components outside the MPCore cluster. Curiously enough, it’s the same choice found in the ARM11 and its well-known adopter, the Nintendo 3DS.

AMBA is not a protocol in itself but a specification that describes various protocols, such as APB, AHB and AXI. While AXI was introduced in AMBA 3, the the third AMBA specification, there is no "third revision" of the AXI protocol.

Also note that the PS Vita interconnect fabric does not use AXI but Open Core Protocol (OCP).
The Cortex-A9 is presumably connected to the interconnect via AXI2OCP adapters.

An ‘Image Processing’ co-processor that executes 64-bit SIMD instructions. It can operate different packs of data, from eight 8-bit integers to two 32-bit ones.

N.B.: the coprocessor is called IVC2 (forgot what the abbreviation stands for).
Another important feature is that it has two 256-bit accumulator registers.

There’s another large block of 128 MB of Cached DRAM (CDRAM) predominantly connected to the GPU. CDRAM is yet-another type of RAM that combines the traditional (and cheap/slower) DRAM with a bit of SRAM [23]. The latter acts as cache to speed up frequent memory access.

CDRAM stands for Custom DRAM, not Cached DRAM. The CDRAM is just DDR2 SDRAM connected via a wide bus
to the SoC (similar to how VRAM is connected in GPUs).

Last but not least, the SoC also fits 16 KB of SRAM, but it’s reserved for system functions [24]. You may want to know that it’s the exact amount of SRAM also found in the PlayStation Portable, you’ll soon see why.

From reliable sources, I'm told that the 16 KiB Scratchpad is built in the Allegrex CPU (and thus only visible by it).
I'm not sure whether it's worth mentioning here; I think the following would be more fitting

Last but not least, legacy PlayStation Portable circuitry (the [MIPS CPU](https://www.copetti.org/writings/consoles/playstation-portable/#cpu) **- including its 16 KiB scratchpad -** and the [Graphics Engine](https://www.copetti.org/writings/consoles/playstation-portable/#graphics)).

On the other hand, there are various additional pieces of memory not mentioned (Camera SRAM, Spad32K, Spad128K, CompatSharedSram)

For the remaining I/O, MIPS is not physically connected to the rest of the hardware, only the Cortex-A9 is. Thus, the PSP emulation software (running on the MIPS CPU) requests services to the ARM CPU by following a protocol called ‘Remote Procedure Call’ (RPC) [27] [28].

RPC is not per-se a protocol name (see https://en.wikipedia.org/wiki/Remote_procedure_call)

[flipacholas]

Thanks for the corrections, I'm working on them now.

The CDRAM is just DDR2 SDRAM connected via a wide bus to the SoC (similar to how VRAM is connected in GPUs).

Do you know how wide (in terms of bits) the bus is?

[CreepNT]

Thanks for the corrections, I'm working on them now.

The CDRAM is just DDR2 SDRAM connected via a wide bus to the SoC (similar to how VRAM is connected in GPUs).

Do you know how wide (in terms of bits) the bus is?

According to https://web.archive.org/web/20150425204407/http://www.chipworks.com/en/technical-competitive-analysis/resources/blog/sonys-ps-vita-uses-chip-on-chip-sip-3d-but-not-3d/:

Close examination reveals that there are 1080 pads in two blocks of 540 (2 sub-blocks of 45 rows of 6 pads), so likely 2 x 512 bit I/O operation, possibly sub-divided into 4 x 128.

[CreepNT]

Looking at the first round of correction:

• The PSVita deviates a bit from the official hardware implementation of TrustZone. Instead of using dedicated buses, its model relies on a single bus and 'tagged' transactions to indicate whether they are secure or not [@cpu-dmac].

Where is this official hardware implementation information from? The ARM Cortex-A Programmer's Guide says:

The memory system is similarly divided [between Normal and Secure world]. An additional bit, indicating whether the access is Secure or Non-Secure (the NS bit) is added to all memory system transactions, including cache tags and access to system memory and peripherals. This can be considered as an additional address bit, giving a 32-bit physical address space for the Secure world and a completely separate 32-bit physical address space for the Normal world.

(This bit is in fact AxPROT[1] - although we don't know yet what it is translated to at OCP level)

While the last sentence can be understood as saying "you have two separate buses", nothing in the rest of the paragraph seems to go against a shared bus with tagged transactions.

[flipacholas]

I think the 'separate bus' idea just got stuck with me while I was reading how TrustZone works. I've improved that section now and also included the rest of your corrections. Thanks again.

[bythos14]

The CDRAM is just DDR2 SDRAM connected via a wide bus to the SoC (similar to how VRAM is connected in GPUs).

If we're using the chip works article as a reference point, the CDRAM, if it is the Samsung Wide I/O memory it's speculated to be, is SDR, not DDR

[flipacholas]

The CDRAM is just DDR2 SDRAM connected via a wide bus to the SoC (similar to how VRAM is connected in GPUs).

If we're using the chip works article as a reference point, the CDRAM, if it is the Samsung Wide I/O memory it's speculated to be, is SDR, not DDR

Which source do you think is closer to the truth?

[bythos14]

I don't know of any source for Creep's wide bus DDR2 claim. I'm personally inclined to believing the chipworks article though, not many reasons not to.

[CreepNT]

My source was the Chipworks article but I have misread the relevant section:

(I treated the DDR2 SDRAM as applying to all memories, but the semicolumn clearly indicates it's only applicable to the conventional memory - which the firmware refers to as LPDDR{SUB/TOP/0/1} so there's no ambiguity on that one)

The Samsung paper mentioned says the implementation was SDR, and CDRAM is thus most likely SDR as Bythos mentioned:

(good catch! thanks @bythos14)

[flipacholas]

Thanks again @CreepNT and @bythos14 . I have amended that line.

[flipacholas]

I think this completes the list, but feel free to re-open this issue if you want to flag something else!