Lits not being marked as lits + LUTs

[shunshou]

Basically, DspReal relies on a node inside a bundle that is declared as an output, and therefore, even if you're creating a constant that's of type DspReal, x.isLit() will return false. That's inconsistent with Data behavior in the rest of Chisel3.

The same goes for DspComplex.

Granted, even in Chisel3, if you have a Vec of Lits, it seems like Lits aren't registered as such.

Therefore, when I peek one of the aforementioned types, I get "Can't find SimpleModule.lutGen_4 in the emulator..." b/c the isLit check in peek returns false, but Lits aren't actually handled w/ the emulator...

I'll probably go ahead and add some isLit flag for DspComplex and DspReal (not sure if I can just turn something on for DspReal.node to make it indicate it's a Lit or if I need to make an outside val to do that...). I am not really sure how to resolve this issue for Vec.

---

Also, re: LUTs, I'm not sure if Verilog like

  assign lutGen_0 = 4'shd;
  assign lutGen_1 = 4'she;
  assign lutGen_2 = 4'shf;
  assign lutGen_3 = 4'sh0;
  assign lutGen_4 = 4'sh1;
  assign lutGen_5 = 4'sh2;
  assign lutGen_6 = 4'sh3;

would lead to tools not being able to do some optimization as opposed to the more conventional (at least for FPGAs) way of:

http://www.csee.umbc.edu/~tinoosh/cmpe415/slides/Rom-LUT-verilog.pdf

I have yet to test out any hypothesis regarding this, but it'd suck if we find out last minute that tools are less good about P&Ring or w/e with this kind of output vs. something more standard.

[shunshou]

@chick @grebe do you have opinions on how to deal with this?

[shunshou]

Ok, I fixed the problem for DspReal and DspComplex. Now their components show up as Lits if they're meant to be Lits.

For Vec, I guess, b/c it's supposed to be dynamically addressable, you wouldn't consider its constituents Lit's anymore. Which is weird b/c that logic is inconsistent with the Verilog that's printed out... Dynamically addressable stuff that's not considered a Lit should be implemented more like the stuff in the pdf.

Otherwise, it makes no difference to use Seq or IndexedSeq instead for a LUT?

[grebe]

I believe this is related to chipsalliance/chisel#418 and to an extent chipsalliance/chisel#417. @ducky64 talked about it at the recent chisel meeting. It's not at all clear to me what the right thing to do is, especially with Vecs (which I think are inconsistent in dealing with literals). @ducky64, can you chime in?

[ducky64]

There's currently no resolution to those issues (and we didn't get around to discussing those at the last meeting). If you can come up with a consistent solution, that would be great. But I think it's a hard problem.

[shunshou]

I think the best way to go about it is:
Vec of all Lits -> ROM (!)
Where the ROM output looks more like example 5.10 in http://www.csee.umbc.edu/%7Etinoosh/cmpe415/slides/Rom-LUT-verilog.pdf
If you construct it like that, then it matches with the behavior of doing lut(0).isLit reporting false and therefore having peek/poke tester crap out. :D

For the DspReal and DspComplex cases, I'd argue that they just weren't designed to be super compatible with the intention of Chisel UInt, etc. Lits... but that's fixed in my PR.

[ducky64]

The main problem (as per the linked issues) is that it's not possible given the current structure to statically resolve whether a Data is a literal. cloneType makes this especially difficult since it returns this.type, whereas you want ULit.cloneType (for example) to return a UInt.

It would seem reasonable for a Vec of Lits to generate a ROM, perhaps as a FIRRTL pass? @azidar ?

Your link also gives me a forbidden error...