Do it again, but this time spent fifteen minutes.(A*B)' comes out to A'+B'
Combined with the other A we get:
A*(A' or B') => A*B'
(A*B')' => A' or B
(A' or B)' => A*B'
That's the first AAB expression. Took less than 5 minutes.
To get the hole thing, replace the first A in the first step with B and repeat.
If we did that for the ABB expression we'd get a simillar result:
(A*B)'*B => A'*B
(A'*B)' => A or B'
(A or B')' => A'*B
now together:
(A*B'*A'*B)' => A'or B or A or B'
A'or B or A or B' => true
So the logic circuit could be just a wire connected to +Vcc, or the fastest CMOS would be an inverter with the input tied to ground (only a pdelay at power on).
The whole thing took about 10 minutes but I haven't done this in a long time.
These days I would use software though to help avoid mistakes, and also check it before programming a ROM.
I actually had to do this in one project I had done for a company. We were developing a static switch and there were a lot of measurements to check before switching from one input to another. I did it all by hand with pen and paper (yikes) but that was many years ago. Now we have software.
I did use a program to generate the ROM programming though and we sent it to a service that programs the ROM's.
Since this resulted in a static output there would be nothing to program. If it resulted in say just A*B' we would have run through all the combinations with a program (Basic, C, etc.) and the output would be programmed into the associated address location.
It's easy to mess up Boolean manipulations, but that wasn't the point.
HINT: You inverted something and then, for some reason, went and inverted it again, yielding what you already had as a prior partial result.
Also, a LUT-based solution is off the table -- You said, "then choose the gates that those expressions represent."
My response is that this is easier said than done.
The reason is that Boolean expressions using AND, OR, and NOT are not good fits for expressions that represent minimal logic circuit implementations.
If you are just going to do a LUT, there's no reason to do the prior step of your suggested approach, which was, "you can then go on to simplify those expressions." Why bother to simply the expressions? Just write a program to walk through all of the combinations and generate the table that needs to be programmed into the LUT.
Plus, if the goal is to get the smallest and/or fastest possible implementation, the access time for a LUT has to be considered as well as the physical size that is going to be required to hold it. That might or might not result in the fasted implementation, but it is virtually guaranteed that it won't result in the smallest.







