Add width and binary point to fixed point names

[grebe]

@shunshou mentioned in ucb-bar/dsptools#94 that it can be tricky to debug a circuit with fixed point signals in a verilog simulator.

Ideally, there would be some way to communicate to the waveform viewer that a particular signal is fixed point with a certain binary point, but support for this seems to be very lacking. GTKWave has a very barebones ability to set a binary point, but I don't see a way to use it programmatically. It doesn't look like simvision has any support for this. I'm not sure about DVE.

One idea is to embed the binary point information in the names of variables in the emitted verilog. For example "node x" might become "node x_q3", where q3 means binaryPoint=3. The q is in reference to this common way of writing fixed point numbers.

Having the binary point information embedded in the name prevents you from having to look between waveform outputs and firrtl to figure out what the binary point is supposed to be (in some cases it may be inferred, so you'll have the added annoyance of needing to run firrtl on your firrtl another time).

As written, this code is doing some dumb things. One obvious one to me is that it will rename port names on blackboxes- it shouldn't do that. I'm not really sure how to special case that out. I'm also not sure what signals get added by firrtl after this pass is run and if it is worth trying to add _qXXX suffixes to them too. I'm sure there are other consequences I'm not thinking of.

@shunshou @chick @azidar what do you think?

[azidar]

I'd recommend making this a separate pass from ConvertFixedToSInt, so that you can easily turn it off and on. It would also make it easier to special case the black boxes when it isn't tied up in the logic of the conversion.

If you make it a transform, you can make an annotation to turn it on (like InlineInstances) and set a commandline option to turn it on.

Otherwise, I'm happy with the idea, if this will ease debugging.

[shunshou]

It would significantly ease debugging.

[azidar]

Now that the annotations are more fleshed out, perhaps this is worth another visit with a chisel API?

[grebe]

Close in favor of #1036