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

一、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 综合只能生成固定数据通路。多驱动冲突与别名分析联合体多成员共享存储加上指针别名使工具无法安全地分配读写端口和调度操作可能导致功能错误。