pass through?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

pass through?

Stephen Davies
In the hardware simulator, is there any way to indicate that a chip input should be simply "passed through" to an output? In some circumstances, the value of a certain output pin is precisely that of an input pin. And it seems silly to say:

CHIP Silly {
    IN a;
    OUT b;

    PARTS:
    Not(in=a,out=x);
    Not(in=x,out=b);
}
Reply | Threaded
Open this post in threaded view
|

Re: pass through?

ybakos
Perhaps you could suggest a syntax that would allow you to do this? I think you'll find it challenging, but would love to see what you come up with.

Now I'm curious, why do you find the existing approach "silly"? Imagine how you'd describe wiring things up to a friend:

Connect the input wire labeled "a" to a Not gate's input. Take the output of the not gate and connect a "green wire" to it. Connect the "green wire" to the input of another Not gate. And so on.

To me, this is exactly what the your HDL states (substituting my "green wire" for your "x").

Reply | Threaded
Open this post in threaded view
|

Re: pass through?

cadet1620
Administrator
I would do this by adding a new primitive:
/**
 * Wire. out = in.
 */

CHIP Wire {

    IN  in;
    OUT out;

    BUILTIN Wire;
}
In fact, I wrote this part using Not-Not, as above, to get around the "sub-bus of an internal bus" problem before I realized the correct way to solve that problem.

--Mark

Reply | Threaded
Open this post in threaded view
|

Re: pass through?

milythael
In reply to this post by Stephen Davies
Before happening on alternate solutions, I came very close to adding an Identity(in=a, out=b) chip.

A possible syntax for adding this to HDL would be:

PARTS:
a:b;


or
PARTS:
(a=b);

I admit, my desire for this as a circuit or feature of HDL comes from a software development / literate programming bias.  I like semantic names for things that help the human reading the code understand it.  I find ZeroNot(in=x, z=zerox, n=notx) to be preferable to ZeroNegate(in=x, z=zx, n=nx).  Writing code is an art as much as poetry and our audience is as much human as computer.
Reply | Threaded
Open this post in threaded view
|

Re: pass through?

rekoil
I did this a few times by using a "fake Mux". For example, to make x=y:

Mux(a=x, b=false, sel=false, out=y);

The main application for doing this, in my experience, is to have a second wire carry the same value as an existing wire. HOWEVER, I later learned that you don't ever need to do this - you can simply go back to the function that assigned the wire and add a second assignment to it, effectively teeing the output pin to multiple wires.

So, instead of:
Foo(in=in, out=x);
Mux(a=x, b=false, sel=false, out=y);

You can do:
Foo(in=in, out=x, out=y);

This works with bus subscripts as well - let's say I want to copy the LSB of a 16-bit bus to a different wire:
Foo16(in=in, out[0] = lsb, out=out);

It's never mentioned explicitly that "teed" output pins are legal in the HDL - I figured it out by accident - but after that realization, I was able to go back and reimplement every "fake Mux" I'd put in my code.
Reply | Threaded
Open this post in threaded view
|

Re: pass through?

cadet1620
Administrator
rekoil wrote
This works with bus subscripts as well - let's say I want to copy the LSB of a 16-bit bus to a different wire:
Foo16(in=in, out[0] = lsb, out=out);

It's never mentioned explicitly that "teed" output pins are legal in the HDL - I figured it out by accident - but after that realization, I was able to go back and reimplement every "fake Mux" I'd put in my code.
It could be more prominent, but Appendix A.5.3 does say "In that case, the connections out[0..3]=x and out[2..6]=y will yield" which shows out[2] and out[3] connected to both x and y.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: pass through?

rekoil
Yes, that example is there, which is why I noted the lack of an *explicit* note. It's there, but (possibly intentionally) hidden.

I'll also note that the only point where I've needed this behavior has been where I've needed to re-use the value of a chip's output pin, since the HDL doesn't allow you to use an output as an input in the same chip.