Understanding Computational Design and Gate Functionality at Tufts University

en 001 4 introduction to computational design n.w
1 / 21
Embed
Share

Delve into the world of computational design through the lens of gate functionality at Tufts University in this insightful course taught by Instructor Joel Grodstein. Explore topics such as voltage transfer functions, glitches in signals, delay models, and the limitations of simulating complex circuits. Discover the challenges and potential solutions in computational design and simulation.

  • Computational Design
  • Tufts University
  • Gate Functionality
  • Simulation
  • Joel Grodstein

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. 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 1

  2. 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 2

  3. 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 3

  4. 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 4

  5. 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 5

  6. 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 6

  7. 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 7

  8. 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 8

  9. 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 9

  10. What about our bad cases? A B C 1 1 D 1 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 10

  11. LCC: what are the problems? It's not always efficient A 7 AA D 1000 gates 2 BB B 3 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 11

  12. But what about loops? 0 1 1 1 S_L 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 0 1 R_L 1 0 EE194/Comp150 Joel Grodstein 12

  13. But what about loops? S_L Q What if you execute everything twice? Q=!(S_L&Q_L) Q_L=!(R_L&Q) 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 13

  14. 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 14

  15. But what about big loops? Q1_B Q1_A D Q D Q Q2_B Q2_A D Q D Q CLK A state machine is a big loop (actually, multiple loops). How might LCC deal with that? EE194/Comp150 Joel Grodstein 15

  16. But what about big loops? Q1_B Q1_A D Q D Q Q2_B Q2_A D Q D Q CLK=1 CLK Break the system into two phases EE194/Comp150 Joel Grodstein 16

  17. But what about big loops? Q1_B Q1_A D Q D Q Q2_B Q2_A D Q D Q CLK=0 CLK Break the system into two phases EE194/Comp150 Joel Grodstein 17

  18. But what about big loops? Q1_B Q1_A D Q D Q Q2_B Q2_A D Q D Q CLK if (CLK) green logic; if (!CLK) blue logic; EE194/Comp150 Joel Grodstein 18

  19. 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 19

  20. 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 20

  21. EE194/Comp150 Joel Grodstein 21

Related


More Related Content