EN 001-4: Introduction to Computational Design Spring 2016 Tufts University Instructor: Joel Grodstein joelg@eecs.tufts.edu Discrete-event simulation EN001-4 Joel Grodstein
EE194/Comp150 Joel Grodstein What's in a gate? A gate has a voltage transfer function, but we'll ignore that here. Inputs and outputs are just 0 or 1. EE194/Comp150 Joel Grodstein
Real life is not just 0 and 1 The glitch response never reaches Vdd before it heads down to Vss. It's not a full-rail signal, but neither is it no response at all. All models are wrong – some are still useful. in out time delay Δt = gate delay. EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein Delay is a bit trickier. There are multiple models: Inertial delay. The gate smooths out short glitches Transport delay. The gate passes all glitches. EE194/Comp150 Joel Grodstein
Model #1: transport delay The output is simply a delayed copy of the input. Period. You may have a different delay for rising vs. falling transitions. What's wrong with this? Infinite bandwidth is not realistic! in out time delay Δt = gate delay. EE194/Comp150 Joel Grodstein
Model #2: inertial delay Short glitches get suppressed. Reasoning: wires have capacitance. Infinite bandwidth doesn't exist in the world. What's wrong with this? Even if those glitches don't have time to rise fully, they still exist; and still affect the next gate. in out time delay Δt = gate delay. EE194/Comp150 Joel Grodstein
What sucks with our algorithm Cannot simulate all input patterns of a 64x64 multiplier Or any circuit with lots of inputs What can we do about this? We could try and optimize our simulator code… but eventually we will lose against exponential growth. Lookahead to a later topic: formal validation. It’s inefficient: takes more time to schedule & process an event than to execute it. many events don’t affect the final settled value at any output Let's look at two really bad examples (examples #5 and #6 from Lecture 2.docx). EE194/Comp150 Joel Grodstein
Can we overcome these inefficiencies? Thought question: what if we didn't care about timing at all? Could we take advantage of that? We really do care about timing, but what if we didn't? EE194/Comp150 Joel Grodstein
Levelized compiled code (LCC) A AA 7 D 2 BB B 3 Q 5 C The good: only 4 machine instructions! The bad: no timing Is there an output glitch? Who knows? AA=A BB=B D=AA & BB Q=D | C EE194/Comp150 Joel Grodstein
What about our bad cases? 1 1 1 D 1 2 AA 4 BB CC AA=A B=A ^ AA BB = B C = B ^ BB CC = C D = C ^ CC Our bad example that was exponential in the number of levels is now linear Now it's really just a toy: it just computes a constant 0. EE194/Comp150 Joel Grodstein
LCC: what are the problems? It's not always efficient 1000 gates A B AA BB 7 3 2 D Q 5 C What if the only thing that changes is node C? LCC will still simulate every single gate DES will only simulate the OR gate Q. Crossover point: if >3-5% of gates toggle every cycle, then LCC is faster. EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein But what about loops? 1 S_L 1 1 Q How do you turn this into LCC? Which gate do you execute first? Do you do it this way? Q=!(S_L&Q_L) Q_L=!(R_L&Q) No, doesn't work. Q_L R_L 1 1 EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein But what about loops? S_L Q What if you execute everything twice? Q=!(S_L&Q_L) Q_L=!(R_L&Q) Does that work? Is it a general solution? Q_L R_L EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein But what about loops? Another option: remove the loop. S_L Q Q_L R_L The SR latch is just one component. Its internal model is if (!S_L && R_L) Q=1, Q_L=0; if (S_L && !R_L) Q=0, Q_L=1; if (!S_L && !R_L) Q=1, Q_L=1; The loop is gone! S_L Q R_L Q_L EE194/Comp150 Joel Grodstein
But what about big loops? D Q Q1_B D Q Q1_A D Q Q2_B D Q Q2_A CLK A state machine is a big loop (actually, multiple loops). How might LCC deal with that? EE194/Comp150 Joel Grodstein
But what about big loops? D Q Q1_B D Q Q1_A D Q Q2_B D Q Q2_A CLK=1 CLK Break the system into two phases EE194/Comp150 Joel Grodstein
But what about big loops? D Q Q1_B D Q Q1_A D Q Q2_B D Q Q2_A CLK=0 CLK Break the system into two phases EE194/Comp150 Joel Grodstein
But what about big loops? D Q Q1_B D Q Q1_A D Q Q2_B D Q Q2_A CLK if (CLK) green logic; if (!CLK) blue logic; EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein One final problem What happens if you have a circuit with multiple clock domains? No simple answer. You can implement LCC independently in each clock domain. But then you need another scheme to tie them together. EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein What problems are left? We decided to ignore timing – but haven't dealt with the consequences of that. Our next topic is static timing analysis We still haven't solved the problem of validating a 64x64 adder or multiplier (or any circuit with lots of inputs) Topic #4 may be formal validation. EE194/Comp150 Joel Grodstein
EE194/Comp150 Joel Grodstein