Theory
अब engineer आप हैं
College की lab में एक smart door लगती है। Rule बहुत सीधे शब्दों में ऐसा है:
"Open only for someone with a valid ID card who has morning or evening slot permission."
अब इस sentence और door के अंदर लगे wires के बीच में एक translation का काम होता है। उसी काम को design कहते हैं, और इस topic के आखिर तक आप ये पूरा काम खुद करेंगे: sentence से लेकर circuit तक।
Theory
एक gatekeeper के लिए rulebook
Output को एक ऐसा gatekeeper समझिए जो खुद कुछ सोच नहीं सकता, बस rulebook follow करता है। Design का मतलब है वो rulebook इतनी precisely लिखना कि conditions के हर एक combination के लिए जवाब पक्का हो: या तो open (1) या फिर बंद रहो (0). English इसके लिए बहुत loose है, Boolean algebra ही precise language है।
Theory
Step 1: inputs और output को नाम 2
हर condition को एक 0/1 variable में बदल दीजिए:
- A = 1 जब ID card valid हो
- M = 1 जब morning permission हो
- E = 1 जब evening permission हो
- F = 1 जब door खुलना चाहिए (यही output है)
ये step देखने में मामूली लगता है, लेकिन ज्यादातर गलत answers यहीं से पैदा होते हैं। अगर variable धुंधला हो ("A = the card"), तो आप उससे computation कर ही नहीं सकते। हर variable को एक yes/no test की तरह define कीजिए।
Theory
Step 2: sentence को translate करो
"Valid ID and (morning or evening permission)" ये बन जाता है:
F = A·(M + E)
- "and" → · (AND)
- "or" → + (inclusive OR: जिसके पास दोनों slot हैं वो भी अंदर आ जाएगा)
- brackets sentence की grouping के हिसाब से लगते हैं
अब distribute करने पर SOP वाला view मिलता है: F = A·M + A·E, यानी entry के 2 cases, और दोनों में ID तो चाहिए ही।
Quiz
F = A·(M + E) लेकर देखिए: एक student के पास valid ID है (A = 1), morning permission नहीं है (M = 0), evening permission है (E = 1). क्या door खुलेगा?
- हाँ, F = 1
- नहीं, F = 0 क्योंकि M = 0
- नहीं, दोनों slot चाहिए
- Expression से पता नहीं चल सकता
Show the answer
हाँ, F = 1
M + E = 0 + 1 = 1, फिर F = 1·1 = 1: door खुल जाता है। Options B और C में OR को AND की तरह पढ़ लिया गया है, और यही सबसे common translation गलती है। Inclusive OR में कम से कम एक चाहिए, सब नहीं। इस तरह values डालकर देखना ही किसी भी design को verify करने का तरीका है।
Theory
Step 3: इसको gates की तरह बनाओ
F = A·(M + E) सीधा wire हो जाता है:
- एक OR gate M और E को लेता है, और (M + E) बनाता है
- एक AND gate A और उस result को लेता है, और F बनाता है
कुल 2 gates। लेकिन expanded form A·M + A·E के लिए 2 AND gates और एक OR gate चाहिए: यानी same function के लिए 3 gates। Truth table वही, पर cost अलग। इसीलिए wiring से पहले simplification (पिछला topic) मायने रखता है।
Think first
नया brief: "A machine runs only when the power is on, the cover is closed, and there is no fault."
Variables define कीजिए और expression मन में लिख डालिए: P = power on, C = cover closed, F = fault present, R = machine runs.
Show the answer
R = P·C·¬F
तीनों conditions AND से जुड़ती हैं, और "no fault" F का complement है, जो एक NOT gate से बनाकर AND में feed होता है। यहाँ बारीक बात ये है: F को हमने "fault PRESENT" define किया था, इसलिए rule में ¬F चाहिए। Expression लिखने से पहले हमेशा अपनी ही variable definitions दोबारा पढ़ लीजिए।
Quiz
Machine वाले example में expression F की जगह ¬F क्यों use करता है?
- क्योंकि NOT gates, AND gates से सस्ते होते हैं
- क्योंकि F को "fault present" define किया था और rule चाहता है कि fault ना हो
- क्योंकि outputs को हमेशा complement करना पड़ता है
- ये गलती है; R = P·C·F सही है
Show the answer
क्योंकि F को "fault present" define किया था और rule चाहता है कि fault ना हो
Variable में "fault present" store है, पर rule उसका उल्टा माँगता है, इसलिए complement दोनों को जोड़ देता है। अगर F को "no fault" define किया होता, तो सादा F ही सही होता। सीख ये है: expressions पूरी तरह इस पर depend करते हैं कि variables कैसे define हुए, इसीलिए step 1 लिखा जाता है, मान नहीं लिया जाता।
Formula
Exam की 4-step recipe
हर design question इन्हीं moves से हल होता है: (1) 0/1 inputs और output को एक-एक line में define करो, (2) sentence को ·, + और ¬ से, उसकी grouping follow करते हुए translate करो, (3) simplify तभी करो जब वाकई terms कम होते हों, और साथ में laws का नाम लो, (4) gates को describe या sketch करो। इन चारों steps को headings बनाकर लिखिए, marks अपने आप आएँगे।
Watch out
English में छुपे translation traps
Rules में "or" inclusive होता है, जब तक sentence "but not both" ना कहे (वो XOR होगा). "Only if" एक requirement बताता है, guarantee नहीं: "opens only if ID is valid" का मतलब है बिना ID entry नहीं, पर सिर्फ valid ID होना काफी हो भी सकता है और नहीं भी। और negative words (no, unless, without) लगभग हमेशा complement का इशारा देते हैं।
Theory
ये आपको फिर कहाँ मिलेगा
बिल्कुल यही flow असली hardware बनने का तरीका है: engineers conditions को Verilog जैसी language में लिखते हैं और tools उन्हें minimize करके wire कर देते हैं। Software की side पर, हर access-control check जो आप code करेंगे (user.isValid && (slot === 'AM' || slot === 'PM')) वो असल में आज की door ही है, बस JavaScript के कपड़ों में।
Summary
Key takeaways
- Design एक ही रास्ते पर चलता है: 0/1 variables define करो, sentence translate करो, useful हो तो simplify करो, फिर gates पर map करो।
- "and" → ·, "or" → + (inclusive), "no/not" → complement, brackets sentence की grouping follow करते हैं।
- F = A·(M + E) में 2 gates लगते हैं; इसका expansion A·M + A·E 3 gates लेता है: function बराबर, पर cost अलग।
- Expressions अपना meaning variable definitions से पाते हैं, इसलिए definitions पहले लिखिए।
- याद रखने का hook: sentence, symbols, simplify, circuit।