Question: is TH1520/Meles silicon derived from this openc910 RTL, and what is the RAS-miss/underflow fetch behavior?

[Phobia-Cosmos]

Hello,

I am trying to understand the relationship between the public openc910 RTL and real C910-based silicon used in TH1520 boards (for example Meles / other TH1520 development boards).

From the public materials, I can see that TH1520-based boards are described as using XuanTie C910 cores, but I am not sure whether the taped-out microarchitecture is directly based on this repository, or whether the production silicon contains private changes / implementation differences.

I have two questions:

1. Is real TH1520/C910 silicon based on the microarchitecture in this repository?
   More specifically, should this repository be treated as:

   • the actual basis of the taped-out C910 frontend/microarchitecture, or
   • only a public/open version that is functionally similar but not cycle-identical to production silicon?

2. What happens when RAS is invalid / underflows / overflows for a return instruction?
   My reading of the public RTL is that the frontend may temporarily follow the default/sequential VPC path before redirecting:

   • In ct_ifu_ipdp.v, ras_target_pc falls back to ras_default_vpc when ras_ipdp_data_vld is not set.
   • In ct_ifu_ibctrl.v, there is a comment saying: if RAS not valid, take next 128 PC as predict PC.
   • The user manual also says the RAS supports up to 12 nested calls, and overflow can cause target prediction errors.

So my current inference is:

• for the public openc910 RTL, a RAS-invalid case may transiently fetch the next/default VPC path;
• but I do not know whether real TH1520 silicon behaves the same way.

Could you please clarify:

• Is this inference correct for openc910?
• Is TH1520/Meles silicon behavior the same?
• If yes, what is the typical correction window in cycles (best case / worst case, or the stage where it is resolved)?
• If no, what are the main frontend / predictor differences between the public RTL and production silicon?

Relevant references I checked:

• C910_RTL_FACTORY/gen_rtl/ifu/rtl/ct_ifu_ipdp.v
• C910_RTL_FACTORY/gen_rtl/ifu/rtl/ct_ifu_ibctrl.v
• C910_RTL_FACTORY/gen_rtl/ifu/rtl/ct_ifu_ibdp.v
• C910 user/integration manuals under doc/

Thank you.

[Phobia-Cosmos]

A follow-up question related to return prediction / RAS behavior:

On some C910-based Linux systems, lscpu (or /sys/devices/system/cpu/vulnerabilities/retbleed) reports:

Vulnerability Retbleed: Not affected

Could you please clarify why it is reported this way?

More specifically:

1. Is Not affected coming from a Linux kernel classification / whitelist for this core family, or does it reflect a real microarchitectural protection in C910 itself?
2. If it is protected in hardware/microarchitecture, could you describe at a high level how the protection works for return prediction / RAS / return-target speculation?
3. In particular, when RAS becomes invalid (underflow/overflow/miss), what prevents a Retbleed-like transient path from being exploitable?

A high-level explanation is enough; I am mainly trying to understand whether the lscpu result should be interpreted as:

• “the kernel marks this CPU as not vulnerable by design”, or
• “the C910 microarchitecture includes return-speculation protections, so the kernel can safely report not affected”.

Thanks again.