2. Dynamic Traffic Control Group 2 Chun Han Chen Timothy Kwan Tom Bolds Shang Yi Lin Manager Randal Hong Wed. Dec. 3 Project Objective : Dynamic Control of Traffic Lights

3.  Marketing  Project Description  Design Process  Floor Plan Evolution  Layout  Verification  Issues Encountered  Specifications Presentation Outline

4. Marketing / Description Tom Bolds

5. Current System  The current system has sensors that detects cars leaving their lanes  Induction loops under the pavement  Video cameras  Depending on the time of day, the intersection lets each arm go for a set amount of time  If no cars are present in one arm, the other arm is green  It cannot learn or adapt  Cost for entire system: $35,000

6. A Better System  This system detects cars entering and leaving each arm  The time that an arm is green is determined in part, by past traffic  Exceptional traffic flow will change the system immediately  Cost for entire system: $24,000

7. Market  4 Million traffic lights in the US  A few user inputs lets the system be adjustable for different situations  Roads of different sizes  Different space constraints  Price goes down and quality goes up

8. Goals  When the government is involved, cost needs to be low  Only 4 metal layers used  Optimized for small size  Could have gone the “all pseudo-nmos” route  We don’t want to use megawatts on a traffic light  Cmos logic to minimize size and power consumption

9. Goals  Even if it causes just a few accidents nobody will buy it, and we get sued  Design needs to be robust  Handle power failures  Return to a known state  Predictable behavior  People are used to driving a certain way  No accidental switching  Minimum time for lights to change

10. Installation  The only change necessary would be the detectors for entering/leaving cars  Current system has ground sensors or video camera to detect the first car at an intersection  Could add another detector farther back, or use video/sound detection to determine where cars are

11. Traffic Flow Sensors (Blue) To detect the car entered Sensors (Red) To detect the car leaved

12. Traffic Light Flow Whenever pedestrian push the button, then this light will insert in the end of this cycle. ARM 1 ARM 2 Red GreenY Green (S traight + R ight )YRed+Green(L eft ) Red Y Green (S traight + R ight )YRed+Green(L eft )Y Phase A Phase C Phase BPhase APhase B ARM1 ARM2 PED We define three phases (A,B,C) for different operations.

13. Hold until n 1 or n 2 changes Light favors n 1 or n 2 ? n1n1 n2n2 T<r 1 ? T<r 2 ? T>= R 1 ?T>= R 2 ? n 1 =0? n 2 =0? f 1 <=0? f 2 <=0? Switch Light Reset T = 0 No Yes No Yes No Light favors arm 1 or arm 2 ? n1n1 n2n2 T<r left ? T>= R left ? No Yes No Yes No n 1 not change in T = 5? No Control reset Pedestrian For Green light For Red + Left T>= R p ? Yes No For Pedestrian n 2 not change in T = 5? n 1, n 2 :# of cars T :Time spent in this phase R i, r i : Max. and Min. time for each phase f i : the control function f 1 = α 1 *n 1 + β 1 – n 2 f 2 = α 2 *n 2 + β 2 – n 1

14. SW – Switch light G – Green R – Red Y – Yellow T – Time for Yellow PED – Pedestrian SW (1bit) ARM (1bit) PED(1bit) T (2bits) Phase(2bits) FSM Initial G.R Y.R R+L eft.R Y.R R.G R.Y R.R+L eft PED SW = 0 SW = 1 T < 2 T = 2 SW = 1 SW =0 PED = 1 T = 2 PED = 1 T = 2 T<= 2 SW = 0 SW = 1 T = 2 PED = 0 T = 2 PED = 0 ARM = 0ARM = 1 Init. Ped = 0 Choose the Phase

15. Learning?  The way we learn is by changing beta   To take out the division, multiply everything else by Q len   We are actually calculating f*Q len, but it works since it only matters if it’s < 0

16. Data Input Initial Values Clock Operation T, Left-Turn Counter R, r, R_ L, r_ l Flow Control FSM Light Contro l FSM Selection

17. Design Process Shang-Yi Lin

18. Design Process – Objective  Goal - Compact Area - Low Power  Trade-Off - Performance

19. Behaviors / Flow Charts Behavior Verilog / JAVA Structural Verilog / Structure Schematic / Cadence Layout / Virtuso Extracted RC / Simulation Design Process - Overview

20.  Finalize Chip Functionality - Make behaviors, function clear  Feasible & Reasonable Algorithm - Complex & Fast != Good Design Design Process – Behaviors Order of Traffic LightTraffic Light FSMFlow Control FSM

21. Design Process – Verilog / JAVA  Behavior Verilog & JAVA

22. Design Process – Structure  Block Diagram : - Behavior Verilog to Structural Verilog - Data path and function blocks are determined - Initiate Floorplan  Floor Plan : - Routing Issue  Re-Use of Components : - Decrease Chip Area

23. Design Process – Schematic  Compact Design : - Minimize transistor count  Transistor Sizing : - Minimize transistor size - Equivalent Pull-Up & Pull-Down ability  Implementation : - Put reasonable output loads for simulation - Sized buffers for global control signals

24. Design Process – Layout  Defined the Metal Directionality : - M1 & M2 : Local, power rails - M3 & M4 : Global, Control, Clock - Special Case : Depended  Focus on Compact Layout : - Floor plan keeps updating - Consider the interconnect between blocks  Global Routing : - Fixed height for most blocks - Use wider global wires - Leave wiring space

25.  Block Level - Extracted RC simulation for each block - Combine multiple blocks to simulate  Chip Level - Ensure global signals integrity - Whole chip simulation Design Process – Extract RC

26. Floorplan Evolution Shang-Yi Lin

27. Floor Plan  First Version - Block Diagram - Sample Layout Size  Routing Issue  Re-Use Components Register (1bit)2X1 MUX 16.6 13.5 6.5 6.6

28. Input Get q0 q1 s0 s1 Avg. q ½, Q_L FPUOutput Reuse F, Ni Give R,r Input PED, CLK Compare T Control Light Floor Plan – 1st Version

29. Floor Plan – Update  Structure : Logic components are determined

30.  Layout : Refined Function Block Floor Plan – Update

31. Refined Layout  More Precise Layout Shape & Size

32. More and More

33. More and More…

34. Doing Global Routing

35. Final Layout

36. Layout / Verification Chun Han Chen

37. Layout - ALU InputOutput

38. Layout – FSMs Timing Control FSM Light Control FSM

39. Counters Shift Registers MUX Layout – Memory Devices & Interconnection Parts Counters Shift Registers and MUXs Counters Shift Registers 2:1 MUX

40. 11-bits 16:1 MUX Layout – Memory Devices & Interconnection Parts Input Select Output

41. Layout – Memory Devices & Interconnection Parts Real time counter, MUX, and, Comparator Output to Timing Control FSM

42. Layout – Memory Devices & Interconnection Parts Control + Registers Control Logic Output Input from ALU

43. Layout – Whole Chip

45. Verification – Methodology  Functionality Validation -Java V.S. Behavioral Verilog -Behavioral Verilog V.S. Structural Verilog  Schematic Checks -Structure Verilog V.S. Schematic  Layout Verification 1.Whole chip extracted RC simulation by using Ultrasim 2.Comparing the results with schematic simulation 3.Separated simulations for pedestrian signal

46. Verification – Methodology  Extracted RC for the whole chip

47. Verification – Light Switching Switch Continue

48. Verification – Pedestrian

49. Specification Issues Encountered Timothy Kwan

50. Specifications  Area =.146270 mm 2  498.69 x 293.31 um^2  1:1.7002 Aspect Ratio  Transistors 18834 Total  8613 pmos  10221 nmos  Density .1288 transistors / um^2  Speed  10 MHz  I/O’s  74 inputs  5 outputs

51. Issues Encountered  Muxzilla  Large consecutive pass transistor muxes  Floor plan  Increasing number of transistors led to larger blocks  12000 => 18834  Wire Routing  Metal Directionality  Large Number of Wires  I/Os  Complicated FSM Logic and glitches

52. Issues Encountered  Large Fan Out in Some Blocks  System Clock and Real Time Clock Timing Issues  Arithmetic Unit or Floating Point Unit  Simulation Issues  New vs. Old Cadence  Ultrasim vs. Spectre

53. ?