google / google/xls

Lint errors for self-determined bit length for concat operands

Open
#1,704 0 comments 0 reactions 0 assignees View on GitHub
bug codegen
Dominant language
C++
Stars
1.9k
Forks
283
Avg merge
2d 10h
Merged PRs (30d)
135

Description

**Describe the bug**

I'm not exactly sure how to repro in a minimal DSLX example since when an expression is inlined is a bit of a mystery to me, but in certain circumstances, codegen will emit a bit concatenation with under-specified operand sizes, e.g. something like:

```
reg [32:0] concat;
assign concat = {x[0], p1_y >= 32'h0000_0020 ? 32'h0000_0000 : p1_x << p1_y};
```

In Verilog, per Table 11-21, all the operands in a concat are self-determined. This means that if `p1_x << p1_y` is under-/over-sized, the concatenation could be as well and then padded/truncated to achieve the assignment.

In other cases, XLS will codegen a function as the operand (e.g. shra, priority_select), and the bitwidth is no longer self-determined (dictated by the function return bitwidth).

**To Reproduce**

I played around with it but couldn't generate this with a small minimal test case. However, the above pattern is generated from valid DSLX code.

To repro, I manually modified pipeline stage 2 generated by:

```
%%dslx --top=shll --pipeline_stages=2

fn shll(x:u32, y:u32) -> u32 {
x << y
}
```

**Expected behavior**
All operands in the concatenation should be explicitly sized, either locally or by factoring out the operand in a function or separate reg.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.