EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: jeremy on December 29, 2014, 07:26:30 pm
-
Hi all,
I'm looking for something like an OR gate, but that needs at least N inputs to be high for the output to be high. N would be something like 2-3 and the number of inputs would be about 10. I am curious about doing it in discrete gates, not HDLs.
Is this is a solved problem? Or perhaps it is one of those problems with a solution so complicated that it is useless?
-
EPROM as a lookup table: 10 inputs go to the address lines and the precomputed lookup-table for every input combination stored into EPROM output the desired result at the data lines.
Edit: Maybe this cannot be classified as combinatorial logic, but at least the solution is quite flexible. For example, with 1Kx8 EPROM you can provide easily eight different outputs from which the user may select how many inputs 2 .. 9 need to be active in order the output to become "1".
-
If your requirement doesn't change, you can try solving it by writing out the entire Boolean representation (likely SOP form) and minimize the expression either by hand or using software such as Wolfram's Boolean algebra calculator.
-
If an analogue solution is ok then buffer your 10 inputs, sum them with resistors and feed into a comparator with an apropriate threshold.
-
Hi all,
I'm looking for something like an OR gate, but that needs at least N inputs to be high for the output to be high. N would be something like 2-3 and the number of inputs would be about 10. I am curious about doing it in discrete gates, not HDLs.
Is this is a solved problem? Or perhaps it is one of those problems with a solution so complicated that it is useless?
https://en.wikipedia.org/wiki/Majority_function
-
Do it the same way you'd do it in VHDL.
Remember, when writing VHDL, you're writing a description of RTL (register transfer level logic). If you ever forget this, and you write nonsense instead... well, yeah. The practical difference between VHDL and traditional procedural languages like C is more than just when a statement is relevant: it's that C is compiled to sequential software, whereas VHDL is synthesized to static logic. To do a very good job of C, you need to know what it compiles to; to do a very good job of VHDL, you need to know what it synthesizes to.
Anyway, last time I did that, it was:
Input debounce circuit. Majority voting method. Input is sampled at system clock frequency (which is several times the bitrate expected for this input; the input should also be analog filtered to a similar rate -- because after all, just because it's a 1-bit DAC doesn't mean sampling theory just goes out the window!), and sent through N shift registers. The bits are added up as unary. This looks something like, "q <= bit[0] + bit[1] + bit[2] + ... ;". Q needs LG(N) bits to account for carries, and you use a comparison of Q > N/2 to determine if it's up or down. (To enhance the input-debounce-iness of my circuit, I also added hysteresis, so that the output only gets set to '1' when Q > N/2 + E, or '0' when Q < N/2 - E, where E is some value less than N/2. Example: if N = 3 to 6, E = 0 to 2 is reasonable.)
The direct RTL implementation is a bunch of 1-bit adders chained together. The carries, in turn, get summed, and so on, until all LG(N) bits of Q are formed.
Whether this finally synthesizes to chained logic (as the above RTL description suggests -- implementing each 1-bit full adder as the traditional XOR + AND), or something more complex and compact (carry look-ahead, array logic, look-up tables?) depends on the required timing constraints and available logic structure. A CPLD would probably use a couple macrocells to do it in array logic, without much wiggle room on timing. An FPGA would use quite a few more LUTs to do much the same thing with varying amounts of chained or parallel activity, depending on timing.
Implementing it in SSI (small scale integration -- the three elementary logic gates and their complements), you'd have to run through the logic tables to see how many minterms and maxterms are needed. I don't know offhand.
You could even implement an even more compact solution with analog: each input connects through a resistor R to the summing junction (virtual ground) of an inverting amplifier. Thus, each input delivers a constant current, the total of which counts the number of inputs, independent of order. A comparator on the output then determines count against a reference. (To implement the debounce circuit I was talking about earlier, a pair of comparators at the respective thresholds, feeding an R-S flip-flop, would complete the logic.)
Tim
-
Note that there is also a part, not sure the eaxct partnumber, as a 8bit comparator.
74*688 is an magnitude comparator (equality detector), and a few numbers around there is the desired function: less than /same or higher comparator. I think it is 74*684, but not sure. Try wikipedia and 7400 logic family.
688 is/was quite often used part, so it is still possible to get them cheap. Instead of your "greater than" function, which is hard to get and these chips are quite expensive.
-
You could even implement an even more compact solution with analog: each input connects through a resistor R to the summing junction (virtual ground) of an inverting amplifier. Thus, each input delivers a constant current, the total of which counts the number of inputs, independent of order. A comparator on the output then determines count against a reference. (To implement the debounce circuit I was talking about earlier, a pair of comparators at the respective thresholds, feeding an R-S flip-flop, would complete the logic.)
This. If you're doing it in discrete gates, a few resistors and a comparator should be much simpler than a bunch of logic devices. You don't even need the inverting amplifier - just tie them all together, it becomes a voltage divider with R/N on top and R/(total-N) on the bottom. Use a reference voltage divider to compare the two ratiometrically.
-
You can treat the N input as zero/one values, construct a tree of adders that will sum them and then add a detector (that simple) for N>=2 or N>=3. Constructing adders from gates is straight forward. This will give you and easy to understand circuit but not necessarily optimize (for number of gates or propagation time).
Another option is to compute it serially using a clock and down counter. Start with 3, each each cycle decrement the counter if the next input is high (e.g. using a shift register or multiplexer), at the end check if the counter had underflow.
Another options is to use a small microcontroller that will do the same in software.
-
1) Examine your inputs one by one using a 4017 counter and a series of AND gates.
2) If the output of an AND gate is high then it increments a second 4017
3) Examine the result of your operation by reading the output of the second counter
4) Reset all counters and go back to step one
This first guess is a bit messy but you've given me something interesting to think about whilst I'm dragged around various clothes shops this afternoon, thanks for an interesting exercise.
-
If an analogue solution is ok then buffer your 10 inputs, sum them with resistors and feed into a comparator with an apropriate threshold.
+1
-
Your task was familiar and I have just remembered what it is called, you're seeking to build something called a Hamming decoder and doing this in discrete logic will be very hard. Here's an example using only four bits.
1) Start by dividing your inputs into pairs of bits and wire each pair into an AND gate and an XOR gate. If the AND gate is high then you have two high bits, if the XOR is high then you have one high bit. Note that there is no output from either gate if both bits are at zero.
You now have two 'two bits high' outputs and two 'one bit high' outputs
2) Connect both 'two bits high' outputs into both an AND gate and an XOR gate. If the AND gate is high then you have four high bits and if the XOR gate is high then you have two high bits (but see later)
3) Connect both 'one bit high' outputs into both an AND gate and an XOR gate. If the AND gate is high then you have two high bits (but see later) and if the XOR gate is high then you have one high bit.
4) Connect the XOR gate output in step (2) and the AND gate in step (3) to an OR gate. If this gate goes high then you have two high bits.
I haven't figured out in my head how to account for three bits high and this is for only a four bit input, now imagine how complex it would be for ten :scared:
Being an Aspie I carry logic designs like this around in my head for fun, some regard it as torture. YMMV
-
or just do it in a MCU :D you just need to make sure the clock speed and "sampling" rate of the MCU will be fast enough and it will not interfere with other stuff ;) ot you can even make it interrupt driven (PIN change interrupts).
-
Being an Aspie I carry logic designs like this around in my head for fun, some regard it as torture. YMMV
Aren't using terms like that considered politically incorrect? :) https://www.eevblog.com/forum/projects/my-new-favorite-opamp-tda1308/msg576953/#new (https://www.eevblog.com/forum/projects/my-new-favorite-opamp-tda1308/msg576953/#new)
I agree that for 25 cents or less and dozen or so lines of code an MCU is the only reasonable solution. Unless of course this is another one of those "educational exercises".
-
Draw out your Truth Table, then use a Karnaugh Map
http://electronics-course.com/karnaugh-map-b?utm_expid=62927315-1.bej7MhpPSKGZZ9PUdQa-Vg.1&utm_referrer=http%3A%2F%2Felectronics-course.com%2Fboolean-algebra (http://electronics-course.com/karnaugh-map-b?utm_expid=62927315-1.bej7MhpPSKGZZ9PUdQa-Vg.1&utm_referrer=http%3A%2F%2Felectronics-course.com%2Fboolean-algebra)
to reduce the table down to an expression, then use boolean-algebra
http://electronics-course.com/boolean-algebra (http://electronics-course.com/boolean-algebra)
to convert your and/or's to either all and's or all or's. job done.
:)
-
...You now have two 'two bits high' outputs and two 'one bit high' outputs ...
Will be useful to mention throughout the expansion 'exactly' or 'at least'.
-
I made this out of a bunch of half and full adders, and it does the trick. It's a 4-of-12 detector. A high on any 4 of the 12 inputs will make the output go high. If you only want to have a 10 input detector, then just connect the extra two inputs to ground. Want to make it a 3-of-10 detector? Connect one of the extra inputs to Vcc. Connecting both extra inputs to Vcc makes it a 2-of-10 detector.
-
Hi all,
Thanks for your responses. I understand that this could be easily done with a micro, I was just curious. Basically, my question was "am I being stupid for doing that" and I think the answer seems to be a resounding no. I just wanted to make sure that there wasn't a secret 74HCXXX that completely solved it or something.
Bonus points for the analog comparator answer though, didn't think about that one!
-
Bonus points for the analog comparator answer though, didn't think about that one!
I frankly don't understand why any discrete-gates solution would ever be preferable to a few resistors and a single comparator! Maybe if there were a single 7400 chip that could do it, but these days many of the cool ones are obsolete... all of the proposed discrete logic solutions involve multiple chips and a bunch of wiring!
Of course, if something programmable like a MCU or FPGA is available, connecting them all to that and doing it in software is the obvious solution - it's by far the most flexible.
-
Connect one of the extra inputs to Vcc.
That's a nice trick. Didn't occurred to me. Also using CIN as a third input.
-
all of the proposed discrete logic solutions involve multiple chips and a bunch of wiring!
The adders can be reduced to gates as requested in the original request. The resistors do not. ;-)
-
Connect one of the extra inputs to Vcc.
That's a nice trick. Didn't occurred to me. Also using CIN as a third input.
Yep. When the OP mentioned he wanted either a 2 or 3 out of 10 detector, it occurred to me, making this circuit configurable would be difficult, unless it was designed with extra inputs, which, depending on their tied value, results in the whole circuit being "reconfigured". Also, the full adders can essentially just be thought of as a 3-term half-adder (no carry capability).
Of course, my solution would be hell to actually implement with discrete gates. Mainly, I just like designing those types of circuits just to see if I can do it.
Edit: Also, going with an analog comparator solution defeats the purpose of having a digital circuit. True, something this simple could probably be reliably implemented with resistors, however, the intention should be to keep it digital, as it's a digital problem and making it analog just introduces an opportunity for error due to noise.
-
Edit: Also, going with an analog comparator solution defeats the purpose of having a digital circuit.
What exactly is that purpose? Unless there's other programmable logic in the circuit, it seems to me to be something akin to beating in a screw with a hammer.
as it's a digital problem and making it analog just introduces an opportunity for error due to noise.
Nah, it's easily a digital or analog problem. Digital circuits can count things, but electric currents flowing into a junction are quite good at summing all by themselves!
As for noise - that could be an issue if you're building something really low-power where you end up using insanely large resistors to avoid wasting current, or if you have a vast number of switches such that the voltage step for each one becomes tiny, but otherwise, you'd have to try terribly hard to have noise issues with this...
-
making it analog just introduces an opportunity for error due to noise.
according to this logic DACs and ADCs should be highly unreliable ;)
one good example when analog is preferable in digital circuitry - interfacing a 4x4 keypad with a single ADC input on a micro... the savings are simply huge - 1 ADCpin instead of 8 digital pins....
the very same is valid for the solution of the topic with summing currents followed by a comparator - the amount of components and complexity is at least order of magnitude less than the implementation with adders and gates.
-
summing currents followed by a comparator - the amount of components and complexity is at least order of magnitude less than the implementation with adders and gates.
Using a PIC or AVR with ZERO external components is an order of magnitude less parts than the comparator solution.
-
summing currents followed by a comparator - the amount of components and complexity is at least order of magnitude less than the implementation with adders and gates.
Using a PIC or AVR with ZERO external components is an order of magnitude less parts than the comparator solution.
"components and complexity", unless your comparators have to be programmed ::)
-
For 3 of 10 then a circuit with 12 resistors and a comparator is about as simple as it gets, but it gets clumsy if 1) the driving logic doesn't have tightly defined voltages requiring you to buffer first or 2) you have so many inputs you run into component tolerance problems. A micrcontroller is potentially less board space (but maybe not, 16 pin micro vs a sot-23-5 comparator and some passives) but definately more design time in writing the code. The pure logic solutions are instructive to think about but the counter ones offer little advantage over a microcontroller, still being sampled. The gate only solutions could be the fastest way for many inputs but will be massive implimented as separate chips.
-
The problem with this kind of circuits is that the matrix is so sparse or dense you cant form clusters to minimize logic away.
The only real way of doing it is to solve it numerically. Adding the pins until you get a 4 bit representation and then sending that through a magnitude comparator. Like a 7475 .
For a 10 pin input you would need a pretty long ladder of adders ...
-
A 1M * 8 EPROM costs less than a $1 in ebay which will perform quite well for this kind of application, and will provide you with two 10-bit comparators or one 20-bit comparator or anything between. Some EPROMs can be configured for 8-bit or 16-bit devices, which will provide quite nice combinatorial logic possibilities: 1M*8/512K*16 EPROM can provide a combination logic for 20 inputs and eight outputs or 19 inputs and 16 outputs. The EPROM solution is somewhere between the discrete logic and CPLD/FPGA. Of course, one should provide necessary flip-flops for the inputs/outputs if synchronous design is desired.
-
Exactly, ten bits is 1024 combinations so you just feed your input into the address pins and take your output from the data pins. At a thousand or so addresses I would be tempted to program it by hand and it is certainly much easier than wiring dozens of gates together.
-
I would do it with an EEPROM. It's just so much simpler, having just one device, that's dead-easy to program correctly.
A PIC or AVR MCU would be acceptable too, as paulie pointed out. Both devices need to be mass programmed, so on that bullet point neither one is better than the other. However, the EEPROM wins out because it's just a memory map to be programmed, whereas the MCU solution needs a software programmer to write the code that does the majority function, and that code can be written incorrectly, and/or could have subtle timing errors that are hard to track down. There's no need to introduce that extra risk.
-
I would do it with an EEPROM. It's just so much simpler, having just one device, that's dead-easy to program correctly.
A PIC or AVR MCU would be acceptable too, as paulie pointed out. Both devices need to be mass programmed, so on that bullet point neither one is better than the other. However, the EEPROM wins out because it's just a memory map to be programmed, whereas the MCU solution needs a software programmer to write the code that does the majority function, and that code can be written incorrectly, and/or could have subtle timing errors that are hard to track down. There's no need to introduce that extra risk.
MCU can do other things such as independent debouncing on the inputs, identifying the first N active inputs (e.g. as a game controller, etc), have state memory, short output pulse on change, etc. It depends what the rest of the circuit need to do.
-
MCU can do other things ....
Sure. If the OP needs it to do other things or can use it for other things in the overall design then perhaps the MCU makes sense. That need wasn't specified up front. But I agree, the MCU + cost of software development might outweigh other seemingly simpler solutions if it the right fit and can be put to extra uses in the entire system design at less overall cost.
As engineers, we routinely make these kinds of cost/benefit decisions.
... It depends what the rest of the circuit need to do.
Unfortunately, we don't know what the rest of the OP's circuit needs to do. Perhaps the OP's circuit needs to have such high reliability and low failure rate that only a hard-wired solution will suffice. Or perhaps a mask programmed PROM is OK. Or perhaps that's not needed and an in-circuit programmed EEPROM will do. Or perhaps an MCU is just fine. We don't know, but if an MCU is a good fit then it should be used, I'm all for it. It's all about using what's right for the job at hand and when.
-
What hasn't been stated, I think: any kind of memory is relatively expensive and slow. MCUs are not only atrociously slow, but often nondeterministic as well.
True, memories are only a buck or two, but a discrete logic function (which since it's not standard logic, I guess, means an ASIC... so, this is a pretty bad example, isn't it?) would be cents on the dollar in a fair comparison. It's also on the order of 50-200ns response time, whereas the optimal solution would be on the order of the logic family's characteristics (say, 20-50ns for 74LS or HC, down to a few ns or sub-ns for LVC, ECL and so on). Or without an ASIC, implementing it with a standard logic family (using discrete gates and adders and such) might have comparable delay to the memory (i.e., several times the logic family's basic delay, so ~100-200ns for HC), but could still be quite a bit faster in other families (<10ns for LVC, ECL, etc.?).
And, true, you probably don't even need that kind of speed. Say this were part of a classical microprocessor system, where you're monitoring a peripheral input, and communicating with a parallel bus. Perhaps the input is merely polled every so often: it might be perfectly reasonable to have the processor wait a few cycles (potentially several us) before releasing the data bus. In that time, you could implement not only a static (combinational) solution, but an iterated solution as well (i.e., accumulating "register <= register + bit[N]" -- only need a register, counter and mux, and lg(N) full adders, to complete in N cycles), or even use a secondary MCU for the same computation.
The absolute worst part about using an MCU is timing. You cannot build a digital logic circuit to any kind of performance, if you can't count on the timing characteristics of the logic you're using. Can you imagine building a computer out of gates, where the RTL* is implemented as software loops on individual MCUs?
*Register Transfer Level, i.e., more or less, a high level / MSI/LSI building block implementation. Registers, adders, muxes, those sorts of things.
Even if you are careful with your software implementations, the best you can do is trigger an interrupt from a given event (say a clock edge). And even in the lowest latency MCUs, this burns many cycles. True, those cycles may be at 50 or 100MHz internal clock, but even just reading ports will take more and more cycles, and pretty soon, by the time you've finished implementing your function and written it to the output ports, it's taking 10 or 20us, and probably the elapsed time varies nondeterministically, too! (I.e., the result doesn't arrive consistently following the 'request' event.) Trying to inspect the results with traditional methods (logic source, analyzer) will be maddening, because you'll have some ports changing before others, and the delay is flopping around, and...
True, you can very easily make something that behaves like, say, an LED display driver. And it'll work statically. And often times, that's all that matters. But that's no challenge. That's trivial, and hardly worth discussing. If something is computable, Turing Completeness guarantees that it can be done, eventually (given enough memory, anyway). Where the challenge lies, is in doing it quickly. And more practically, computer engineering has to do with doing it, and quickly, AND cheaply.
To put it another way, I'd be impressed if that little PIC-faking-a-display-driver (different thread) were capable of being used in a muxed display. Can it change state, coherently, in under a millisecond? How about in ten microseconds or less?
Not to demean the fake-display-driver project, because it's still interesting. But for other reasons. The software is likely wholly unremarkable (as stated on the project page by its own author, no less -- not in the same words, but I expect this statement would not be found untrue, either).
Tim
-
Like I said before this would only take a dozen or so lines of code. And consider that you can program a $1 MCU with nothing more than a serial port instead of $200 prom programmer. Anybody that is not able to implement this in a few minutes or unable to avoid bugs in a program that small is in the wrong hobby.
Though I guess it could just be an emotional issue. MCU-phobia!
-
Like I said before this would only take a dozen or so lines of code. And consider that you can program a $1 MCU with nothing more than a serial port instead of $200 prom programmer. Anybody that is not able to implement this in a few minutes or unable to avoid bugs in a program that small is in the wrong hobby.
Though I guess it could just be an emotional issue. MCU-phobia!
I don't consider myself MCU phobic. They have their place. In this case they may be OK to use too, as I already said.
My position is simply that there are conditions under which an MCU may not be appropriate, and we don't know in this case.
It's not about being able to write bug-free code, but rather what are the system requirements, as that dictates to me what is appropriate to use here. Previously I posted that a (EE)PROM seems like the best solution. I said that in absence of any other knowledge about the system, to provide a black-box solution to a majority-N decoder where N=10. The PROM provides guaranteed timing and will be bug-free and completely deterministic. It can be proven to be correct. It will not glitch. This is the right solution if we know nothing else about the system.
If glitches don't matter, if timing is not a problem, if the system is "slow" enough, if it doesn't need to be deterministic (in both output and timing relationships), and doesn't need to be provably correct, then an MCU is probably a better solution, as it's likely much cheaper and easier to program as you've said.
My opinion on this matter is simply that cheaper isn't always better and that there are other considerations too.
Cheers!
-
It's not about being able to write bug-free code, but rather what are the system requirements, as that dictates to me what is appropriate to use here. Previously I posted that a (EE)PROM seems like the best solution. I said that in absence of any other knowledge about the system, to provide a black-box solution to a majority-N decoder where N=10. The PROM provides guaranteed timing and will be bug-free and completely deterministic. It can be proven to be correct. It will not glitch. This is the right solution if we know nothing else about the system.
If you don't know nothing else about the system you can't say if it is the right solution or that one solution is better than the other. Period.
It may very well be that are other criteria that make that solution unacceptable. For example with (E)PROMs you have to consider access time, during which the data outputs are undefined, thus potentially incorrect for some time after the inputs have changed. Is that acceptable? Who knows? It might be that the inputs come from switches, in that case one has to consider debouncing, which (E)PROM don't do. There might be size (footprint), power, flexibility and/or cost constraints for which (E)PROM memory might be suboptimal or even unacceptable...etc.
The bottom line is that it is important for the TS to provide criteria, or at least provide relevant context from which criteria can be derived, so people can assess if a potential solution is acceptable and/or optimal for the problem. Often the "why" is more useful information than the "what".
-
If you don't know nothing else about the system you can't say if it is the right solution or that one solution is better than the other. Period
True. I concede that.
Yes, the TS (or in this case OP) needs to provide the details needed to make the best decision.
-
Considering all solutions, and in the absence of additional constraints, I agree: the ROM solution is an excellent way to go. Generally fast enough to interface with most glue logic applications, without adding too much in timing constraints or losing deterministic behavior (given that the outputs may glitch during the propagation delay -- which is explicitly stated in the datasheet, so that's foreseeable and can be addressed).
Using the microcomputer example -- you could put it on the bus, without having to add too much logic for wait-states. Not that this example is relevant anymore, as 4MHz parallel-bus microprocessors have gone the way of the dodo for >30 years now in embedded applications -- but, if you're familiar with the tech, it's still a good reference to measure against.
The worst part about MCUs, to me personally, is the lack of consistent timing (just try to do precision real time DSP with an average MCU core*), the massive number of permutations through which code can be written, tested (and left untested!), and pass or fail; and therefore the lack of provable correctness and performance.
*Using a real DSP core is probably cheating, because they would provide DMAs for consistent timing. If you removed that, and still drove the output timing directly from software, you would have the same problems as with any other core.
Information and bandwidth are much the same thing, and this point should never be forgotten: as I have said before, use only the bandwidth [or information] that you require! If you provide unlimited bandwidth from the outside world, into a jellybean op-amp for example, expect problems (e.g., an LM358 will rectify RF on the input and output pins!). Analogously for digital design: provide only as many logic states or inputs/outputs as required! An MCU with a mere 128 bits of memory (including registers) has a potential 2^128 states -- how can you ever possibly ensure, within the present age of the universe, that every one of those states is recoverable? And that's not even to count hidden states (anything not explicitly in the datasheet?) like stuck latches and incomplete powerup (example: apparently ATmegas were notorious for POR/BOD problems under some conditions, like slow voltage rise/fall?).
Tim
-
Given the same constraints, I would do this using 6 x 74LS83.
IC1 - 7483,
Connect I1, I2, I3 to the adders C0,A1 and B1. The outputs S2:S1 will contain the number of inputs that are high. Call this D2 and D1.
IC2 - 7483,
Connect I4, I5, I6 to the adders C0,A1 and B1. The outputs S2:S1 will contain the number of inputs that are high. Call this E2 and E1
Connect D2:D1 to A4:A3. Connect E2:E1 to B4:B3. The outputs of C4:S4:S3 will be the the number of inputs in I6:I1 that are set. Call this F3:F2:F1.
IC3 & IC4 - 74LS83.
Wire them as above, to count I12:I7 giving G3:G2:G1.
IC5 - 74LS83
Wire it to add 0:F3:F2:Fa and 0:G3:G2:G1, giving the count of up to 12 input bits as H4:H3:H2:H1.
IC6 - 74LS83
Add H4:H3:H2:H1 to a constant, and use C4 as the "exceeded count" output The constant should be 16-n, where n is the number of inputs you want to trigger the overflow. For example, the constant of 13 (0b1101) will overflow when any three inputs are asserted. If you wanted to avoid this magic constant you could use four inverters plus the carry input on IC6 to calculate the "16-n' constant from a four bit input.
All the usual provisos apply
-
Analogously for digital design: provide only as many logic states or inputs/outputs as required! An MCU with a mere 128 bits of memory (including registers) has a potential 2^128 states -- how can you ever possibly ensure, within the present age of the universe, that every one of those states is recoverable?
Come on, MCUs and computers run the world as we know it, from car engines to this very forum.
-
Analogously for digital design: provide only as many logic states or inputs/outputs as required! An MCU with a mere 128 bits of memory (including registers) has a potential 2^128 states -- how can you ever possibly ensure, within the present age of the universe, that every one of those states is recoverable?
Come on, MCUs and computers run the world as we know it, from car engines to this very forum.
And how often do those systems need to be restarted on various levels (resetting program state, rebooting computers, clearing network states..)? If the answer is something other than "never", I think you've illustrated my point. :)
Tim
-
Analogously for digital design: provide only as many logic states or inputs/outputs as required! An MCU with a mere 128 bits of memory (including registers) has a potential 2^128 states -- how can you ever possibly ensure, within the present age of the universe, that every one of those states is recoverable?
Come on, MCUs and computers run the world as we know it, from car engines to this very forum.
And how often do those systems need to be restarted on various levels (resetting program state, rebooting computers, clearing network states..)? If the answer is something other than "never", I think you've illustrated my point. :)
Tim
Look at the big picture, not just the failure. Overall MCUs and computers bring plenty of good in all aspects of our lives, including mission critical applications despite the ginormous 2^n number of unique states in the various memory layers.
-
Hi all,
I'm looking for something like an OR gate, but that needs at least N inputs to be high for the output to be high. N would be something like 2-3 and the number of inputs would be about 10. I am curious about doing it in discrete gates, not HDLs.
Is this is a solved problem? Or perhaps it is one of those problems with a solution so complicated that it is useless?
Of all the answers given, has nobody noticed that an OR gate won't do what he wants, you only need a single high on any input to give a logic high out.
To answer the question we have to see the truth table.
Also he's talking 'about' x inputs, with his x being about 11, about not being a logical and definitive number; even so, for a micro your looking at two 8 bit ports.
:)
-
Analogously for digital design: provide only as many logic states or inputs/outputs as required! An MCU with a mere 128 bits of memory (including registers) has a potential 2^128 states -- how can you ever possibly ensure, within the present age of the universe, that every one of those states is recoverable?
Come on, MCUs and computers run the world as we know it, from car engines to this very forum.
And how often do those systems need to be restarted on various levels (resetting program state, rebooting computers, clearing network states..)? If the answer is something other than "never", I think you've illustrated my point. :)
Tim
Look at the big picture, not just the failure. Overall MCUs and computers bring plenty of good in all aspects of our lives, including mission critical applications despite the ginormous 2^n number of unique states in the various memory layers.
That doesn't change the fact that MCUs aren't always the best solution, especially for parallel processing where they're very slow. Given no other information a ROM is definitely the best solution in this case.
-
That doesn't change the fact that MCUs aren't always the best solution, especially for parallel processing where they're very slow. Given no other information a ROM is definitely the best solution in this case.
Of course not. ROM output take time to stabilize which means that the output is undefined for some period after an input change. This can result in false positives or false negatives.
Also, ROM size grows exponentially with the number of inputs. Not scalable.
Engineering is not a white and black thing.
-
MCUs aren't always the best solution
True.But these days with quite fast chips available for as little as 15 cents they are ALMOST always the best solution. Certainly with no timing constraints specified in the OP they are the cheapest, easiest to program (no $200 prom or fpga burner required), lowest component count, i.e. BEST solution here.
And all things being equal the CHEAPEST solution IMO is also always the best one. Of course there are those who will insist a more costly item is better even if there is no performance, quality, or reliability advantage. Apparently the word "expensive" just automatically means it's better.
It's hard to tell if people here really believe some of the things they are saying or just typical internet argumentation. I've recently gotten into similar discussion on another forum for insisting an MCU was better choice in a certain NE555 application. It was cheaper and fewer parts than the proposed NE555 circuit but that nasty "c" word (coding) reared it's ugly head again. LOL
-
Look at the big picture, not just the failure. Overall MCUs and computers bring plenty of good in all aspects of our lives, including mission critical applications despite the ginormous 2^n number of unique states in the various memory layers.
My point isn't about pictures, big or small: you also seem to be giving it much more breadth than it concerns, too!
Regarding mission-critical applications: they work very hard to attempt to prove, or at least verify, the correctness of their code. It's very hard work, but an excellent example of well disciplined design process.
Sometimes, they'll also use redundant or lock-stepped cores, just in case the hardware itself isn't all there, either! (Radiation damage and bit-flipping and such.)
Done very carefully, those 2^N states can be pared down substantially, making testing nearly practical (for instance, certain memory addresses may be provably inconsequential, where they're simply not read at all, or the value that is read is handled in a complete manner, along with everything else relating to it).
In the end, even mission-critical applications rarely achieve such level of testing; more than a few probes and landers have flown in space, and some retarded bone-up floored them when it came time to operate! Even as hard as they try, it's simply not possible to prove correctness. Which was the point: provably correct is an exceeding narrow subset of "practical programs". For those rare occasions where you need it, you're probably better looking at a different architecture altogether, because so many states floating around is just a bad idea. Fortunately, most applications don't, and we're just stuck with dealing with the occasional (sometimes more frequent than we'd like) bugs and resets and such.
Tim