Usefulness of internal pins which are (implicitly) buses?

[neophyte]

I have carefully read A.5.3 on Buses, where internal pins with widths greater than one are treated.  It is clearly written; however, I am perplexed as to the *usefulness* of such internal pins implicitly defined with a width greater than one.

The "Example" given in the text, involving a hypothetical CHIP Foo and its invocation as a part of another (hypothetical) chip, is unhelpful in this regard.  Specifically, one wants to see one or two actual examples of code for simple *complete* chips employing the techniques of (a) implicit definition of internal buses and (b) using these internal buses to simplify coding of parts.

I presume that these internal buses are--somehow--supposed to make coding of chips with multi-bit inputs and outputs (and which themselves use multi-bit parts) easier but for the life of me I can't determine how.  I've been unable to cook up my own real-world examples.

For instance, consider the following attempt to code a simple multi-bit chip that flips the outputs of And16:

CHIP FlipAnd16 {
    IN a[16], b[16];
    OUT out[16];

    PARTS:
    // Put your code here:
And16(a[0..16])=a[0..16]), b[0..16]=b[0..16], out[0..16]=vv;
Not16(in[0..16])=vv, out[0..16]=out[0..16]);

}

When I load the chip into The Hardware Simulator, I receive notification of a syntax error.

So can someone kindly (a) explain the problem with this simple chip; (b) if necessary, provide an alternative simple illustration(s) of the relevant techniques; and (c) generally clarify the *usefulness* of internal buses in coding of multi-bit chips (which invoke multi-bit parts).  Thanks.

[neophyte]

(Whoops!  Of course, I meant to type '0-15' in the code above, not '0-16'.  However, the chip still will not load.  So the question/s stand.)

[WBahn]

Consider the instruction decoding process. Your CPU brings in a 16-bit signal and different pieces of that need to be routed to different parts. Six bits of it need to be sent to the ALU to select the operation that it will perform -- well, that's done with a six-bit internal bus. The alternative would be for you to have to define six different signals and connect each of them up to one pin of the CPU's input and one pin of the ALU.

[Lozminda]

Can I offer an alternative senario? (though one that you might not find as satisfying). Don't worry about it too much. You'll come across scenarios when a bus will be handy to use as you work through the book, for the bigger chips, maybe memory (can't remember it'ss been a long time since doing the early chapters so details are a bit hazey) and or the cpu. Don't think you need it for the first chapters...

The authors often throw in stuff before it seems useful, but as you work through the book all becomes clear. I've been in your situation

Lozminda

[neophyte]

Thanks.  I do see how internal buses are useful--as I think you indicate--for routing different chunks of an output outward to different destinations (and chunks from different sources inward into the same, larger multi-bit part).  This much is clearer gestured at in the example from A.5.3:

Foo(in[2..4]=v, in[6..7]=true, out[0..3]=x, out[2..6]=y)

[Where v has already been fixed as a 3-bit internal bus and is fed into Foo as part of the input, and x and y are fixed by this line of code as 4-bit and 5-bit internal buses, respectively, and fed out as separate chunks, presumably to different destinations.]

I gather internal buses can be valuable for routing entire outputs, not just pieces, between parts as well (e.g., one n-bit part's output into the input of another n-bit part).  [Though, I guess this is just a degenerate case of the preceding.]

But, I now take it, internal buses do not obviate the necessity of separate input statements for each bit of an n-ary external input bus, or the necessity of a separate output statement for each bit of an n-ary external output bus.  I gather this is the mistake I made in my chip FlipAnd16.

[neophyte]

Thanks.  I was, in fact, wondering if the technique was more relevant to later chapters.

[neophyte]

An additional comment is needed, I think, in order not to mislead:
The preceding couple comments gave the impression that internal buses don't figure in the earliest chapters.  I don't want to pre-judge that question.  In fact, for all I know, they may figure in, even crucially.

[WBahn]

neophyte wrote

But, I now take it, internal buses do not obviate the necessity of separate input statements for each bit of an n-ary external input bus, or the necessity of a separate output statement for each bit of an n-ary external output bus.  I gather this is the mistake I made in my chip FlipAnd16.

Let's take a look at your original code.

For instance, consider the following attempt to code a simple multi-bit chip that flips the outputs of And16:

CHIP FlipAnd16 {
    IN a[16], b[16];
    OUT out[16];

    PARTS:
    // Put your code here:
And16(a[0..16])=a[0..16]), b[0..16]=b[0..16], out[0..16]=vv;
Not16(in[0..16])=vv, out[0..16]=out[0..16]);

}

And16(a[0..16])

Do you see where your closing paren is. There's where you biggest syntax error is.

On the line for the Not16, you have two right parens but only one left paren. Another syntax error.

These have nothing to do with busses.

Another issue is that you can't do bus notation on internal signals. That is a limitation of this HDL that most "real" HDLs don't have.

If sounds like your FlipAnd16 is really a Nand16, in which case you could implement it like:

    PARTS:
    // Put your code here:
    And16(a=a, b=b, out=and);
    Not16(in=and, out=out);

[neophyte]

Thanks.  This is a tremendous help!

With respect to the parentheses: a rookie mistake (I didn't choose the moniker "Neophyte" for nothing).

More importantly, your illustration of Nand16 is very valuable:  It shows how to handle multi-bit chips that invoke multi-bit parts.  Unfortunately, no such examples are provided in Chapters one and two of the textbook, although, if I am not mistaken, the project for Chapter two depends on this technique crucially!  This mars the otherwise excellent presentation in the text.

Anyway, thanks again.

[WBahn]

Thanks. Glad it was helpful.

In general, this is an extremely well written text, especially for a 1st edition. The outright errors are very few and far between (but not non-existent). But it has a few (again, not that many) shortcomings when it comes to explaining things, especially the mechanics of how to implement concepts with the tools provided. They sometimes assume that something is as obvious to the reader as it is to the people that wrote the tools. This is an easy to make -- and very hard to avoid -- mistake.