I'm going over every operator that's mapped to the CGRA and it seems like currently the mapper doesn't care about whether the operator is signed or not. As a result, given the suggestions #68, the bitstream generated directly from alu_op and signed is completely wrong. That is, using the op name in the prefix of each instance combined with alu_op_debug can produce correct harris bitstream, whereas using opcode + signed cannot.
In this case, most operators are still functional with either singed or unsigned inputs, but ashrs behavior is different. The current implementation will fail when the input is larger than 0x8000.
I will also talked to @jeffsetter to see which operator used in Halide behaves differently with signed or unsigned inputs.
See https://github.com/StanfordAHA/CGRAMapper/blob/b9ab9079e46dfe9c89b09f33f7bcce5566c5ae11/src/definitions/cgralib_def.h#L182
I'm going over every operator that's mapped to the CGRA and it seems like currently the mapper doesn't care about whether the operator is signed or not. As a result, given the suggestions #68, the bitstream generated directly from
alu_opandsignedis completely wrong. That is, using the op name in the prefix of each instance combined withalu_op_debugcan produce correct harris bitstream, whereas usingopcode+signedcannot.In this case, most operators are still functional with either singed or unsigned inputs, but
ashrs behavior is different. The current implementation will fail when the input is larger than0x8000.I will also talked to @jeffsetter to see which operator used in Halide behaves differently with signed or unsigned inputs.