Add tb_mlkem_two_inst_xsim: runs the hello_world protocol across TWO mlkem_top
instances, modeling the real two-party split:
* u_genenc: KeyGen THEN Encaps on one instance. KeyGen writes ek into its own
ek_bram and Encaps reuses it directly (no re-streaming) -> shared_key, ct.
* u_dec: Decaps on a separate instance, receiving dk + ct streamed over from
u_genenc via the input ports.
Verifies A.shared_key == B.recovered_key and 'hello world' round-trips. Output
matches the single-instance TB and the Rust reference (key=ced0c031a4bee34a...).
run_hello.sh gains a 'two' arg to select this TB; default stays single-instance.
Mirror of ml-kem-r examples/hello_world.rs on the mlkem_top DUT (ML-KEM-512):
1. Alice KeyGen(d=0x42.., z=0x77..) -> ek (800B), dk (1632B)
2. Bob Encaps(ek, m=0xDE..) -> shared_key, kem_ct (768B)
3. Bob XOR-encrypt "hello world"
4. Alice Decaps(dk, kem_ct) -> recovered_key
5. Alice XOR-decrypt -> "hello world"
The whole protocol runs on ONE DUT instance: ek/dk are read out of KeyGen via
the dbg taps and fed back into Encaps/Decaps through the streaming input ports,
just as the keys/ciphertext would cross the wire between Alice and Bob. Each
step prints its inputs and outputs.
Output is byte-identical to the Rust example: shared_key=ced0c031a4bee34a...,
encrypted=a6b5ac5dcb9e9425b9e3b8, decrypted="hello world", keys match.
run_hello.sh compiles the RTL + TB and runs it. Cycle counts (K=2): KeyGen
~22.9k, Encaps ~32.5k, Decaps ~50.8k.
