How do I combine 2 sperate bits in a 2bit input

[Malco]

I'm writing the ALU and I'm stuck into an HDL syntax doubt.

So I want to use a 4 way 16 bit multiplexer and feed nx and zx into sel[2]. How do I achieve that?

Mux4Way16(a=a,b=b,c=c,d=d,sel=??????,out=out);

how do I squeeze two bits from different origins there?

[Malco]

Ok, I figured it out.
In case someone has a similar question here's the answer

Mux4Way16(a=a,b=b,c=c,d=d,sel[0]=s0,sel[1]=s1,out=out);

This does feel a bit 'funny'.Just out of curiosity, is this syntax common among real world HDL languages?

[rogerdodger91]

The syntax makes perfect sense.

Remember that a byte is just an array of 8 bits.

In Hardware you cant use a 16 bit value as an input to a 1 bit gate.

However there is nothing stopping you from inputting a single bit into a multi-bit gate.

Remember that each N-bit chip you implement is just a combination of multiple more primitive versions of said chip.

Here is an example of whats legal and whats not.

CHIP Foo
{
In = a[16], b[16];
Out = low_16bit_out[8], high_16bit_out[8]; //We have split the Out=out[16] into two values of 1byte in length.  

PARTS:
And16(a=a, b=b, out=andAB);

//Remember the HDL will implicitly fill in the arrays for you if the sanity of your logic is in check.
//You can imagine this being, And16(a[0+1+2..15]=a[0..15], b[0..15]=b[0..15], out[0..15]=andAB[0..15]  
//Its just alot harder to read that way so the language does it for us.

//Now lets explore something that isnt logically sound.

And(a=a[0], b=a[6], out=Buggy_1BIT_AndAB);

//See the problem here that isnt obvious, that tends to confuse alot of people is the fact that logically //speaking, your trying to pass an individual bit from a 16 bit byte magically.

//Think of it like this, A building is on fire and you have 16 people desperately trying to fight their way //through a door that only has room for one person at a time. These people are crazy and scared, and lets //just add retarded to the mix. They arent thinking logically. So somebody (you) needs to pull them back in //the hall that they all fit in and let each person go through one by one.

And16(a=a, b=a, out[0]=person1, out[6]=person2); //ect
And(a=person1, b=person2, out=Saved_People);

//Notice how I And a with itself. I do this because i know i will get the same value back. However now im //outputting multiple 1 bit pins. The 1-5, and 7-15 bits are simply ignored and forgotten. However you //shouldnt ever have to actually use the And16 method to split up a multi bit number. There is a more //effective way that i wont reveal.

//Now to finish the tutorial.
And16(a = andAB, b[0..15] = Saved_People, low_16bit_out=sum[0..7], high_16bit_out=sum[8..15]);  
}  


Now there are a bunch of SYNTAX errors in this chip. I just went through and debugged it and posted the correct results below. (I also showed a way to convert a 1 bit value into a 16 bit value. Something that might not be so obvious).

CHIP tutorial{
IN a[16], b[16];
OUT low16bitout[8], high16bitout[8];

PARTS:
And16(a=a, b=b, out=andAB);

And(a=a[0],b=a[6],out=Buggy1BITAndAB);
 
And16(a=a, b=a, out[0]=person1, out[6]=person2);
And(a=person1, b=person2, out=SavedPeople);

Mux16(a=true, b=false, sel=SavedPeople, out=people);

 
And16(a = andAB, b = people, out[0..7]=low16bitout, out[8..15]=high16bitout);  
}

Make sure the chip name = the name of your hdl file. Or else it will yell at you. For instance, i named the chip foo originally, yet saved it as tutorial.hdl < NOTE: on windows .txt can and will most likely be hidden from your file extension leading to a bunch of headaches. Should you not know how to fix that, heres a link with an easy fix microsoft button. http://support.microsoft.com/kb/865219 

[Malco]

I didn't said it didn't make sense, I said it felt funny.

I'm not very familiar with hardware description languages. But I think anyone familiar with programming will find this unusual. A parameter can be passed to a construct split across multiple... well, 'parameters'. Maybe that's  how most description languages do it. Is it?

As for the clarifications, thank you for the effort but they are pretty obvious.

[cadet1620]

Malco wrote

I'm not very familiar with hardware description languages. But I think anyone familiar with programming will find this unusual. A parameter can be passed to a construct split across multiple... well, 'parameters'. Maybe that's  how most description languages do it. Is it?

What you need to do is to realize that HDL is a wiring diagram, not a program.  Each line of the PARTS section says "hook these wires to this part this way," not "call this function with these arguments."

Declaring an input or and output as a bus is just a shorthand to save typing a lot of almost identical wire connections.  Sometimes, like for the various mux select inputs, it is not obvious if the part will be more easily used with the pins broken out as in sel0, sel1, sel2, or as a bus sel[3].  In this case, you'll be using the muxes a lot in chapter 3 in an application where it is convenient that the sel inputs are buses.

Also, there is no problem hooking more than one wire to an output pin.

It also doesn't matter in what order you have the statements in the PARTS section, just like it doesn't matter which part of a schematic diagram you draw first.  As long as you eventually draw the entire diagram, somebody else can build the circuit.

--Mark

[cadet1620]

rogerdodger91 wrote

//Now lets explore something that isnt logically sound.

And(a=a[0], b=a[6], out=Buggy_1BIT_AndAB);

//See the problem here that isnt obvious, that tends to confuse alot of people is the fact that logically //speaking, your trying to pass an individual bit from a 16 bit byte magically.
...

And16(a=a, b=a, out[0]=person1, out[6]=person2); //ect
And(a=person1, b=person2, out=Saved_People);

These two statements are in fact logically equivalent, the version using And16 and And is, however, a lot less hardware efficient, both in space and time.

You will do much better to NOT think of buses as arrays.  Buses are just collections of wires that contain related information.  It is often useful to process all the data on the bus at the same time but is not required; the electrons will not jump out of unused wires (at least at the voltages used in computers).

When you get to chapter 5 and are designing your ALU, one of the requirements is to decode the instructions that come in on the instruction bus.  You will have many lines that look like
    And(a=instr[15], b=instr[0], out=jmpEQ)
that decode the individual control signals used by the ALU.

--Mark