Seeing red

[emjay]

No no, just improve my implementation of the chips. The project just gives you the truth table for each gate and specifies the input and output pins, but leaves the implementation up to you... only giving vague hints of how to do it. So it's not me trying to improve their built in chips - I haven't looked at them - but rather just my own.

Ah, roger.  I thought you'd checked the archives against your own.  To me, it sounds like you're doing fantastically.  I have a considerably thicker skull, I constantly referred to pre-built chips when I was going through that project.  

Thanks for the encouragement   I didn't want to do that because I wanted to figure it out for myself. But it didn't occur to me to compare them afterwards as a way of 'marking' them and looking now, the builtin HDL files all just say 'BUILTIN chip-name' in the body section where the full circuit would be defined in mine, so I couldn't have used them to help even if I had wanted to. But maybe by 'archives' you're referring to something else, which I could still compare against my chips?

It made no mention of this at all in the first chapter... that you had to go beyond the truth table comparison as you're suggesting. So are you saying that the best way to implement the Mux chip is indeed by using And, Or, and Not gates to represent the unreduced canonical representation... so that my implementation used too few gates rather than too many?

There is no best, that's the reason that there was no mention made of it.  The best way to follow -any- textbook, however, is to have canon reps available.   That way you always have a solid point to refer back to when you encounter a mystery problem.  Which you will as the system grows increasingly complex.  Basically, the only time it matters whether you use the canonical representation is when you troubleshoot, and even then, if you've satisfied the table and the pins, shouldn't be a problem with reference to the -system-.  

I understand... canonisation is like standardisation so that everyone knows what to expect, and that any difference in implementation from that would require extra documentation for people to troubleshoot effectively, whether physically if say a sub-component in the chip fails, or in design where it would be like returning to a program that you hadn't commented very well after a year But one difference here is that - at present at least - I'm only working with a virtual system with each chip as an object in that system, so I can change any of these gates at any time, right up to the last chapter of the book and beyond, and I'll only need to make changes in one place and the effects will propagate through the whole system. So it's a bit different from a physical system... but it's probably best to get into good habits now in case I ever build a physical system   So I'm prepared to modify my chips to strictly adhere to the canonical representation, but we're only talking about simple gates here right? Not composite gates that consist only of other composite gates that do not include And, Or, or Not (such as my DMux8Way which only uses two DMux4Ways and a DMux)? Because if you tried to implement those in terms of just And, Or, and Not, it would seem to me to defeat the whole purpose of abstraction.

And do you think I've used too few on any of the other chips? I didn't do all of them using the canonical form... some of them I just did by instinct... and some of them, particularly the later, more complex ones, I'm not sure how useful it would be because it only reduces down to ands, nots, and ors so wouldn't say anything about how to use any of the more complex gates you've since created... ie it will show you how to design the chip using only Ands, Ors, and Nots but (presumably) has nothing to say about how to include any composite gates you've created... which I thought was the whole point of this... so you could reuse components in ever increasing levels of abstraction?

It is the point and you will be able to reuse anything you make which satisfies the truth table, the pins.  I'm not concerned at all by your implementations on their own merits (with the exception of abstract principles of utility vs elegance).  My only concern with breaking from canonical representations is at the point in which you find yourself lost in a project.  When you ask yourself "did I build that chip wrong somehow and not realize it" that the canon reps are extremely useful.

I'm just recalling the places where I got stumped precisely -because- the projects are open ended..which, as you've noticed, is the point and the strength of the projects as well.  Ultimately, implementation is an exercise in creative problem solving, a skill you pick up by solving problems in different ways, assessing them by different metrics.  That you've chosen elegance (in your reduction) will directly translate into speed and economy in your composite gates.  My comments on your implementations are irrelevant with regards to their ability to perform their function.  I'm just excited, and jumping ahead of you, lol.  I see the extra lines in on the initial solution (unreduced) and think of them in terms of the control over the machine they might offer (at the expense of speed and economy).  I think that you're on the right track, coming up with the simplest and most direct solution will save you work and cycles.

As I said, at this point I can't understand how additional gates inside essentially a black box chip with defined inputs and outputs that match an exhaustive truth table, and do not store internal states (as is the case with these early chips), could offer additional control (what you refer to as utility rather than elegance) over the machine, but I'll take your word on it that it will all become clear in the next chapter

You're about to build some memories in the next section, literally and figuratively, yeah?

Certainly memories in the mental sense   but not so sure if it will be the computational type... the next chapter is about Boolean Arithmetic and building an ALU.

-In the spirit of reduction.  The system you are being taught is designed to execute a specific machine language.  If you were being taught to build a different system you might have reason to prefer the un-reduced implementation.  Does that bring clarity to my comments?

Not yet, but I'm sure it will