VR5000/A..( uPD30500/A )

There is a board for which boot access intermittently does not occur.
I checked the AC characteristics such as the boot mode and reset rise time, but found no problem.
The power supply rises slowly in approximately one second.

If VDD does not rise within a maximum of approximately 10ms, the VR5000 may not start.
Shorten the power supply rise time at startup.

Is it all right to assume the following? "The cache error register (27) contents are undefined, and there is a possibility that the ER, ED, ET, and EE bits are set to 1, causing jump to a cache error vector."

No, this is incorrect.
During normal operation after reset, the result is undefined even if the cache error register is read, so please ignore it.
When a cache error exception occurs and a cache error exception vector is jumped to, the contents of the cache error register are valid.
Read this register and investigate the cause following jump to the cache error vector.
The processing does not jump to the cache error vector when a reset register is set to 1, as you worried.

These questions are about section 7.2.10 Cache Error (CacheErr) Register (27) in the User's Manual.

(1) If a source occurs in the cache error register, is an interrupt generated for the VR5000 ?

If a cache error exception occurs, the processing jumps to the vector described in section 7.3.9 Cache Error Exception in the VR5000 User's Manual.

(2) Can cache error register sources be cleared?
If yes, what is the clearing method?

No, they cannot be cleared.
A cache error exception is a parity error exception.
The source is a fatal problem in the hardware, such as noise.
Check for problems in the hardware, such as the voltage having become unstable.

A floating-point exception has occurred in a system incorporating the VR5000.
It occurs for the
instructions, but under which conditions does it occur?

This problem occurs because the instruction and operand formats do not match.
The following explanation is for

Regarding "mul.fmt fd, fs, ft"> Note:
fmt can only be S or D, and fd, fs, ft are correctly handled only with the fmt operand as described in the VR5000/VR10000 Instructions User's Manual.

In other words, in the case of "mul.d $f16, $f10, $f8" as here, $f16, $f10, and $f8 all need to be double-precision.
If the values of the $f10 and $f8 registers are single-precision, and unless converted to double-precision with the cvt.d.s instruction, $f10 and $f8 are perceived as denormalized numbers, so an unimplemented operation exception occurs.

When a parity error occurs during execution of the Fill cache instruction, does a cache exception occur?

Yes, a cache exception occurs.

During read from the secondary cache, even if a parity error occurs for the first two words, are all 8 words of the read data saved to the primary cache and valid?
(Must data for which a parity error occurs be discarded by software?)

In this case, the corresponding cache line becomes invalid in terms of hardware.
There is no need to make it invalid through software.
Moreover, a cache error exception occurs.

When a parity error occurs other than for the first two words during read from the secondary cache, is the error data (with the error left unhandled) written to the primary cache as is? Or is it replaced?

In the VR5000 Series, a parity check of the data stored in the L1 cache is implemented only for the first input data (double word).

Even if there is an error for the remaining 3 double words, the data is saved in the L1 cache, and when the CPU accesses these error data, a parity check is performed for the first time and a cache error exception occurs.

Moreover, when writeback to the primary cache is performed, is a parity check of all the words performed in the CPU? Or is it not performed?

The parity is checked, and if an error is discovered, a cache error exception occurs.

If a parity error occurs in the primary cache, are the lines where a cache error occurred all made invalid by hardware?
Or must they be made invalid by software?

In the VR5000, a parity error is simply detected and reported.
Nothing more is performed in terms of hardware.
Therefore, subsequent processing must be performed by software.

Reading the VR4400 manual, I see that there is an explanation regarding the virtual coherency exception, but I cannot find any explanation about it in the VR5000 manual.

The virtual coherency exception is supported only for the VR4000/VR4400.
Therefore, it does not occur in the VR5000.

Can the RTOS of VxWorks, etc., be used?

Yes, VxWorks, pSOS, RX4000 (NEC Electronics), etc., can be used as the RTOS of the VR5000.

Are there recommended secondary cache devices (TAGRAM, SRAM)?
(Also, field-proven parts, etc.?)
If yes, could you tell me their part numbers, etc.?

As TAGRAM, MCM68T618C is recommended.
Moreover, as data RAM, MCM69P536C, uPD4382362, etc., can be used.
(An additional circuit is required for the CE signal.)

I have purchased the uPD30500A and am using it in a development project.
At what times does block write occur?

Block write occurs when, using the cache, a miss-hit occurs for a given cache line, and that cache line is written back to the external memory.

The transfer rate for block write was set in boot mode (XmitDatPat), but can't it also be controlled by External Agent?

The transfer rate for block write can only be set via the boot mode bits during a power-on reset or cold reset.

What is required for supporting block write for high-speed devices and low-speed devices?

In the case of a product with an extremely short access time to external memory, set the transfer rate to "DDDD", etc., and write data in the order VR5000 -> EA -> memory.

Conversely, for a product with a long access time, set the transfer rate to "DxxxDxxxDxxxDxxx", or provide a buffer in EA, and hold the data until the access time is satisfied.

Physical addresses kseg0 and kseg1 are the same, but why?

This is in order to use an external device (memory, etc.) mapped to the same physical address with the cache on/off.

Is it possible to allocate different memory devices (each having a capacity of less than 512 MB) to kseg0 and kseg1 ?

It is impossible to allocate different memory devices to the same physical address.
For example, make physical addresses 0x0000_0000 to 0x0800_0000 SRAM, and physical addresses 0x1F00_0000 to 0x1FFF_FFFF ROM.