Lazy evaluating mux inputs

[kevinburke]

Hi, I'm working on an implementation written in Go instead of HDL. That is, I defined nand() as

func nand(x, y bool) bool {
	return !(x && y)
}

and proceeded to define the rest of the functions from there. However I'm now trying to implement the ALU - specifically, conditionally zeroing a function. I think I want something like this

func ALU(a, b [16]bool, zx, nx, zy, ny, f, no bool) ([16]bool, bool, bool) {
    a = mux(zx, a, zero(a))
    ...
}

Where a is zeroed if zx is 1. However the semantics of Go mean that zero(a) will be evaluated before mux is called, zeroing the array whether zx is true or not... Has anyone tried to implement the logic here in a higher level language? How should I structure the code to work around this problem? I suppose I could pass a function or use an if statement, but that doesn't seem true to the HDL implementation...

[cadet1620]

Hardware doesn't do lazy evaluation; it operates in parallel. In effect, the "arguments" to mux are both "evaluated" before the mux makes it choice.

The easiest way to do the conditional zeroing in hardware is to wire one of the mux inputs to 0.  The software equivalent would be passing a constant array of 16 0s as one of the mux parameters.

--Mark

[kevinburke]

> The easiest way to do the conditional zeroing in hardware is to wire one of the mux inputs to 0.  The software equivalent would be passing a constant array of 16 0s as one of the mux parameters.

Thanks! Though I am guessing I will run into problems later on down the line... for example, to implement negation I'd want to XOR the array with 1's and then subtract 1, and that can't be done by passing a static array.

Has anyone had luck with this approach in general? Or maybe I should just use the programs included in the book's packages.

[cadet1620]

kevinburke wrote

Has anyone had luck with this approach in general? Or maybe I should just use the programs included in the book's packages.

You should use HDL and the HardwareSimulator.

Hardware is fundamentally different than software. In software, you test conditions and conditionally execute code based on those conditions. In hardware, you produce every signal that you might need and then choose which one you want to pass along to the next stage.

The circuits if project 3 are synchronous sequential circuits and are event driven which adds a whole layer of complexity to the software implementation.

The other reason to use the HardwareSimulator is that there are test scripts to help you develop and prove your circuits.

--Mark