联合体在高层次综合应用(三)

一、union联合体在c语言中使用，和vivado hls高层次综合说明
1.vivado hls对union的综合是有限制的，这个限制的根源在于c语言设计和高层次综合设计
对资源的分配逻辑和思想是不一样的；其中，高层次综合设计属于硬件，其是静态的，强类型的设计，
所有的接口需要确定，接口的位宽，接口的时序，接口的握手协议，这个在综合的时候必须确定，
并且是唯一的，不能具有二义性。

2.联合体在传统设计的作用是为了做不同类型的双关设计，联合体的不同成员共享同一块存储空间，
这个引入了类型的模糊和动态行为，但是这个和硬件综合的"编译期间就确定一切"的理念是相冲突的，
所以综合工具对union的综合是存在一些问题的。

二、顶层函数的接口上不支持对union联合体的使用
union MyUnion {
int i; // 32 位
short s[2]; // 32 位，但布局可能填充不同
char c; // 8 位
};
void top(union MyUnion arg); // 禁止
1.上述案例，union使用在顶层接口是不被允许的。
因为union有多种解读方式，造成综合工具蒙圈了，综合工具综合策略有多种，但是这多种综合策略的硬件
和功能可能不一样，这就是问题。工具不知道接口该是32bit,还是16bit，还是8bit，也无法确定应该映射
为AXI-S,还是ap_none，还是ap_memory接口协议。
并且，不同的uninon成员，可能需要不同的接口协议。联合体的存在会使单个物理接口需要多种支持协议，这个从
物理的角度是不可实现的。

2.工具需要在顶层生成 RTL 端口列表，联合体的每个成员如果被访问，理论上要分出多套控制逻辑，但物理上它们共享引脚，无法复用。

三、联合体指针
union {
float f;
int i;
} u;
u.f = 1.0f;
int x = u.i; // 类型双关，Vivado HLS 不支持这种访问
1.在 C 仿真中，这种写法通过共用内存实现比特级重解释。但在硬件中，f 和 i 是两个不同的逻辑路径，数据只能通过写入某一成员，再以同一成员读出才能保证行为正确。
2.HLS 综合会为每个成员生成独立的写入逻辑，但物理存储（寄存器或 BRAM）只有一份。当通过 i 读取时，工具无法判断应该输出 “f 的原始比特” 还是 “上一次 i 写入的值”，因为在硬件时序上它们是同一组寄存器。这会导致多驱动冲突——不同数据路径争抢同一个物理存储的写入控制。
3.更根本的是，HLS 综合必须保证每个周期行为确定，而类型双关依赖软件的内存重叠，硬件中实现需要额外的仲裁或时序隔离，超出工具自动推断能力。

四、总结
Vivado HLS 不支持上述联合体用法，本质上是：

硬件强类型 vs 软件弱类型：硬件端口需要固定位宽和协议，联合体破坏了这种确定性。

编译期静态分配 vs 运行时动态解释：指针重新解读要求硬件在运行时改变数据处理方式，HLS 综合只能生成固定数据通路。

多驱动冲突与别名分析：联合体多成员共享存储，加上指针别名，使工具无法安全地分配读写端口和调度操作，可能导致功能错误。