Get Lattice Mult + ALU workloads synthesising

[gussmith23]

Originally I thought there was a deeper issue why e.g. https://github.com/uwsampl/lakeroad/blob/97f006e270b243c6decd60e124332d73add21f35/integration_tests/lakeroad/three_stage_mul_add_lattice.v wasn't working (see #284). I don't think there's a deeper issue now. I think it's just a bug somewhere.

[gussmith23]

One weird thing: we mention rst in the yaml file, but it's not defined anywhere. Why isn't that throwing an error?

[gussmith23]

Oh, rst is on the mult, first of all, and second of all, it's a valid input!

[gussmith23]

Here's a test: what happens if we plug the C value in to the MB input, instead of into C? Does it work then?

[gussmith23]

Remember: there was also some curiosity about whether the ALU could hold the C value for a few cycles before operating on it. That may still be the issue. That is, A and B go into the multiplier and are used right away, but C goes into the ALU and so it has to be stalled until the multiplier is done.

[gussmith23]

Okay, I've been on quite the rollercoaster. First, I thought I'd figured this out: i thought I'd realized that the workloads I was trying to synthesize onto the Lattice DSP just couldn't go onto the DSP. When I changed the initiation interval, it started synthesizing. This all came after some debugging, in which I realized that our imported semantics don't actually have the issue I hypothesized in #284. The semantics seem to work as you'd expect. However, it turns out I changed the initiation interval such that I just started synthesizing 0 as mentioned in #294 . So, while we discovered the bug wasn't a bug, we're still not synthesizing! So there's still debugging to be done.

[gussmith23]

Running combinational, one, two, and three stage multiplier synthesis to see which works.

Combinational, one stage, two stage, three stage all synthesize.

[gussmith23]

Here's something weird I just noticed: it seems like the ALU doesn't have any parameters once compiled. That's not right!

[gussmith23]

I fixed that, but it wasn't the issue.

[gussmith23]

Okay, I think I figured out the issue. Equally stupid but hearteningly simple. The ALU can do logic operations over B and C. I was wiring C into C, but I was wiring the mult output into A. I think I remember writing that and expecting a bug down the road...

[gussmith23]

Okay, that wasn't the only bug. That got some stuff working (one stage mul + or), but didn't get two stage things working.

[gussmith23]

I also realized that the clock wasn't wired into the ALU. I changed that, but that not only didn't fix things, but it also re-broke the mul+or test by making it spin forever. This is immensely frustrating...

[gussmith23]

I added some constraints to the opcode to shrink the search space. Weirdly now it's only integration_tests/lakeroad/two_stage_multiplier_lattice.v (I think) that's spinning on boolector. Two stage mul+logic ops still not working, though one stage is. (Why would one stage work and not two?? Maybe it's because C can't be held that long?)

[gussmith23]

Yup, confirmed it's the 2 cycle that's spinning. So strange.

[gussmith23]

It may just be the case that 1 cycle or combinational ALU usage is all that's possible. Some facts I know from looking at the ALU and mult Verilog:

• The ALU C input has 0 or 1 registers, i.e. can be delayed for up to 1 cycle before entering ALU
• The ALU B input has no registers, so it can't be delayed
• The mult A input is very strange and seems to either have 0 or 2 pipeline registers before it. That seems weirdly not useful (and also different from their documentation). Maybe it can have 1 pipeline stage if CAS_MATCH_REG is FALSE and CLK is not NONE.
• Meanwhile, the mult B input can have 0 or 1 pipeline registers.
• There can also be a single register on the output of the ALU.
• There are 0, 1, or 2 registers after the multiply.

But all of this is adding up to the fact that 2-cycle should be possible.

[gussmith23]

tried commenting out all constraints, still no luck.

[gussmith23]

Also tried commenting out basically everything except the data inputs, to give the solver full reign. Still no luck. It's very convinced that this isn't possible.

[gussmith23]

I also started to look directly at the bitvector expression output.

[gussmith23]

One thing to try: (Almost) anything it returns for 1-cycle mul-or should work for 2-cycle as well, because we can just turn on the output register on the ALU. So let's see what it does for 1-cycle mul-or and try to adjust it.

[gussmith23]

Ah, seems like the output register is already being used. So why does that have to be the case? Why doesn't it work if we try to do the ALU combinationally while delaying the C value?

[gussmith23]

Seeing what happens if we force the C register to be used.

Interesting. It's just hanging in boolector. It's not failing yet though.

[gussmith23]

I really can't figure this one out. I tried a few things: removing the unnamed inputs from ALU, messing with solver flags. It just spins when I force the C register to be used.

[gussmith23]

There's a few entangled issues here.

• The main issue that keeps popping up is the solver scaling issue: we're very likely to end up spinning in boolector when doing synthesis to the Lattice MULT+ALU. This might be solved with some spelunking on the ALU, e.g.
  • why does it still have unnamed inputs? Could eliminating those help?
  • Are there any "pathological" patterns in the Verilog that generate obviously bad SMT queries?
  • Could just re-importing the models with the updated verilog-to-racket script help?
• There's a secondary, very interesting issue of the solver not being able to do two-cycle designs on the DSP. Two-cycle multiplies spin forever, while two-cycle mul+logic just fails. Meanwhile, it seems like one-cycle mul and mul+logic works, while three-cycle mul (but maybe not mul+logic) works. Part of it seems to be the optional C register in the ALU; if we force it to be used, the solver spins forever, but it must be used for two-cycle designs as far as I can tell.

[gussmith23]

293 will get at least zero- and one-cycle mult+alu workloads synthesizing, which may actually still be good enough for our eval.

[gussmith23]

This isn't actually fully fixed by #293