11

I have a table, where each row of the table contains state (registers). There is logic that chooses one particular row. Only one row receives the "selected" signal. State from that chosen row is then accessed. Either a portion of the state is connected as an output to the IO of the module, or else a portion of the IO is used as input to update the state.

If I were implementing this with a circuit, I would use pass-gates. The selected signal would turn on one set of pass-gates, which would connect the row's registers to a bus. The bus would then be wired to the IO bundle. This is fast, small area, and low energy.

There is a straight forward way of implementing this in Chisel. It encodes the selected row as a binary number, and then applies that number to the select input of a traditional mux. Unfortunately, for a table with 20 to 50 rows, and state of hundreds of bits, this implementation can be quite slow, and wasteful in area and energy.

The question has two parts: 1) Is there a way to specify busses in Chisel, such that you have pass-gates or traditional tri-state drivers all hung off the bus?

2) Failing that, is there a fast, small area, low energy way of doing this in Chisel?

Thanks

seanhalle
  • 973
  • 7
  • 27

1 Answers1

5

1) Chisel does not fully support bidirectional wires, but via the experimental Analog type (see example), you can at least stitch a bus through your Chisel code between Verilog Black Boxes.

2) Have you tried Mux1H in chisel3.util? It emits essentially a sum of products of the inputs and their corresponding select bits. I'm not sure how this compares to your proposed implementation. I would love to see a QOR comparison. If this construct is not sufficient and you cannot express precisely what you want in chisel, you can use a parameterized BlackBox to implement your one-hot mux and instantiate it as you please.

Jack Koenig
  • 5,840
  • 15
  • 21
  • Thanks for the link. This actually brings up a persistent and critical point for us. We are not sophisticated coders. But the people implementing Rocket and the Chisel developers are. The level of sophistication in the software coding practices is far above our skills. The learning required to understand the implementation of Mux1H is non-trivial. – seanhalle May 04 '17 at 21:52
  • This impenetrability of the Chisel code has been a persistent impediment. On the one hand, base Chisel is more productive, by far, than Verilog. It takes about a month to two months to be able to deliver usable work in Chisel. About 60% of the people that we have hired, have quit because they couldn't get even to that point. But the level represented by Mux1H, and increasingly by Rocket code, I'm estimating at perhaps 6 mos to a year to get comfortable with that kind of coding practice. It's a real issue, for us, when making a commercial product, employing normal Verilog developers. – seanhalle May 04 '17 at 21:56
  • Getting to the content of the answer.. Thanks for the tip about Analog. In point 1) I wasn't clear about the mention of Verilog Black Boxes. And I wasn't clear about bidirectional. The bus is actually one-directional. It just has multiple sources that can all drive the same wire. A tri-state driver, for example, is one-directional. Also, the logic that puts values onto the bus and receives from the bus are all Chisel. No Verilog Black Boxes are involved.. – seanhalle May 05 '17 at 05:21
  • In point 2), I suspect the Mux1H is what I mentioned as the straight forward way of implementing 1 hot -- a tree of muxes. That approach is quite sizeable and energy hungry. The gist of the question is to find an alternative that has fewer gates and consumes less energy. A standard bus would be one such circuit. Is there any way for Chisel to print out a picture of the nodes that it generates? For example, a visualization of the FIRRTL nodes and how they connect to each other? This would actually help with the code opacity issue, if we could see what the code produces. – seanhalle May 05 '17 at 05:29
  • Update -- checked out the Analog Chisel mentioned, thanks again for the pointer. It turns out that the Analog stuff is about connecting AnalogBlockBoxes that have AnalogPorts.. got it, thanks. Although, it's not clear how that applies.. the question is about how to implement the one-hot _in Chisel_ in an efficient way.. using black boxes means implementing in a different language.. The question is about _Chisel_ features that allow an efficient implementation _within Chisel language_. – seanhalle May 05 '17 at 06:09
  • It appears that Chisel doesn't support tri-state drivers or busses. It only allows those to be implemented in other languages, like Verilog, and then interfaced, via BlackBox. The main issue with this is simulation and verification.. we are still using Chisel 2 because we are working with LowRISC, which hasn't updated yet. (See comment above for why.. July 2016 code base was much more accessible than March 2017 code base). The simulator for Chisel 2 does not include behavior of black boxes.. – seanhalle May 05 '17 at 06:26