Bit counter assignment (VLSI ) curse

COE 415

(VLSI CMOS Design Circuit)

Course Integrative Project Report*

Semester xxx

Project Title:

Submitted

by

Team Members
#	Name	Stud. ID

Course Instructor: Dr. M. El Aidy

Abstract

<<Write an abstract of the contents of this report, citing the following information: the objective of your design project (given the makeup of your team and the aspect of the design application on which you have focused), any specific problems you were presented with to solve, and some summary of the results of your work (without rattling off everything in the report). This is a summary, so as to give the reader of your report a sense of what is contained in your research and engineering effort. Please keep the abstract under 200 words. Also, maintain this formatting when you replace this text with the actual text of your abstract. Usually, the abstract is written last, after the report is put together. >>

Table of Contents

<<After you have made the final edits and pagination of your report: Insert -> Index and Tables -> Table of Contents (use default format). Delete this text once you have done >>

AUTONUM Introduction

<<This section should state the objectives, assumptions and desired outcomes of the project. This means the set of system behaviors your specific functionality is targeted to achieve in the model development effort undertaken by your team. Note that, since team sizes are different, I’ll expect more from you in regards to the scope of what you are taking on as opposed to what I’d expect from a team of smaller size.>>

AUTONUMLGL Statement of Problem

<<This will be the problem context of the model’s overall functionality that your team has taken on. >>

AUTONUMLGL Design Objectives

<< Here you can state any known requirements, some discussion of your interpretation of the objectives. >>

AUTONUM Functional Description

<<This section should state the functional description of each element in the design. This will include: (1) input-process-output of each block (stated in detail in sub-sections under Section 2 herein), (2) signal/interface definitions (entities/architectures, functions, procedures, components, etc., (3) model hierarchy and diagram of what you’ve implemented (attach the details as a figure, if possible)>>

AUTONUMLGL <<entity/component/feature #1 name>>

<<Edit the titles of these subsections with your specific names>>

AUTONUMLGL <<entity/component/feature #4 name>>

<< For any figures, number them sequentially, and copy/paste them into the document. If possible, use Visio for drawing diagrams instead of Word’s drawing tools. Otherwise, use Word. >>

AUTONUM Behavioral and RTL Description

<<This section should describe the architectural detail of each block, module or design element presented in the previous section. This will include: (1) any state machine descriptions, state tables, state equations, or other means of characterizing the behavior of each block (stated in detail in subsections in this section), (2) timing characteristics, including critical timing or clocking data or constraints, clocking scheme, etc. This could be abstract descriptions that would help in the understanding of your design. Describe how you’ve created your behaviors.

AUTONUMLGL <<VHDL code description of your design #1 name>>

<<Edit the titles of these subsections with your specific names>>

AUTONUMLGL <<timing description #2 name>>

AUTONUMLGL <<other behaviors or detailed constraints #3 name>>

<< For any figures, number them sequentially, and copy/paste them into the document. If possible, use Visio for drawing diagrams instead of Word’s drawing tools. Otherwise, use Word. >>

AUTONUM Design Verification of system blocks

<<This section should describe the design verification strategy your team has undertaken as a basis for defining your test bench. It should include a list of the operating scenarios you are testing as part of your test bench, and what are the data sets for each test. Preferably, you should include these in a table, listing (1) test name/number, (2) functionality being tested, (3) test data set, (4) expected result, (5) any observations from the actual simulation of the design mode under test. You should provide documentation of the architecture of your test bench, indicating what functions each unit of VHDL code in the test bench carries out. >>

AUTONUMLGL Verification Test Objectives

<<Herein, describe the objectives of your testing and verification of your mode and how you have gone about the process of creating the test bench, i.e., what specifically your test bench does. >>

AUTONUMLGL Test Bench Architecture and Functionality

<<Herein, describe the functionality and architecture of your test bench, i.e., its structure and function, and how it carries out the testing objectives identified in the previous subsection of the document. You might include a block diagram of your test bench units, and how they fit together, communicate, etc. The functionality of the test bench can be listed in a table according to the module within the test bench architecture. Also describe the interfacing between the test bench and the model under test (MUT). >>

AUTONUMLGL Test Bench Input & Output

<<Herein, describe the data set for each of the test conditions you have covered, and also describe for the data set, what are the expected results of the specific test case. You should put these in a list, indicating the input data for a given test case, the signals or named data you are examining, and the expected values. This is part of the planning exercise. Your simulation results would ultimately support this test planning. If your simulation doesn’t agree with your expectations, then you will want to make some statements about the discrepancy. >>

AUTONUMLGL Simulation Runs

<<Here you would describe the results of the simulation runs themselves. How many runs do you have? This is based on what you’ve told me in the previous sections. You need to (1) give the reader some indication of what they are looking at when they look at the waveforms in the Appendix 3, and (2) given some interpretation of the outcome of the verification runs. Here, you might have uncovered problems when you first ran the simulation; what did you do? Fix the model? Fix the test bench? This is a description of your simulation results so the reader can understand what’s in Appendix 3. >>

AUTONUM Physical Layout of your System

<<This section is concerned with implementation of physical layout to your design. You can use Tanner Tool L-Edit, or Student version of the L-edit, or any other tool. drawings must strictly conform to a set of layout design rules.>>

AUTONUMLGL DRC

<<Herein, you should make Design Rule Check in order to insure that your design is in compliant with design rule>>

AUTONUMLGL Extraction

<<Once you have laid out a circuit and made sure no error for Design Rule Check, you need to extract its electrical properties to make sure that you drew the correct functionality and to estimate the actual transistor sizes, and more importantly, the parasitic resistances and capacitances that degrade circuit performance. The extracted view can be sent to the simulator>>

AUTONUM Simulation of your Layout

Simulation Program with Integrated Circuit Emphasis

• Hspice is Avanti’s version

• OrCAD is for the PC

• PSPICE is the spice algorithm for the PC

• We will use spice to do analog simulations of a digital circuits

• Most accurate method for circuit simulation used in this class

– We will use extracted parameters from real process lines.

• We will use the nominal values

– We still can not do a simulation with a random distribution of parameters across a die.

Spice Levels

There are accuracy levels within spice!

• Level 1

– Square-law current voltage

• Level 2

– Detailed analytical model

• Level 3

– Semi empirical model

• BSIM4

– sub-micron

• EKV

– sub-micron

AUTONUM Summary and Conclusions

<<This section should summarize what you have accomplished on your project. It should restate the key points of your design. Use this section to sell me on the value of the work that your team has done. Don’t “bullshit” me, but provide some solid statements about what your team has accomplished, its relevance and why it is important to the endeavors we have discuss throughout the semester in this class. >>

AUTONUM References

<<I expect your team’s work to make appropriate citing of relevant literature—whether it is product manuals, the text, or other works you have read or consulted in order to do the project. If you don’t have any references, then leave the section blank. >>

Appendix A – <<VHDL Model Source Code>>

<< Here, I’d like you to insert your model code. The test bench code goes in Appendix B. The code should be formatted such that it can be read easily. I’m also hoping each team managed to remember to use the VHDL Style Guide posted earlier in the course. Also, please us some indentation, and try to group units on a single page (such as Architectures, or Procedures, etc.). Comments in code are a good thing. I am also hoping the teams made use of the language features we discussed regarding Assert statements and the like. >>

<< Make sure to copy/paste this Appendix section and rename it for each type of artifact. In this way, it will show up in the listing in the Table of Contents page when you format it (by the method I explained earlier in this document. >>

<< If you have questions, please, please, please contact me. >>

<< Lastly, when drafting your report, please remove all of my commentary inside of the <<>> marks. >>

Appendix B – <<VHDL Test Bench Source Code>>

<< Here, I’d like you to insert your test bench code. As for the model’s VHDL, the code should be formatted such that it can be read easily

<< Delete this text when you insert your test bench code>>

Appendix C – <<Simulation Waveform Output>>

<< Here, I’d like you to insert your simulation waveform output, try and print, or screen capture, only those signals that are relevant to a given simulation run supporting verification of a particular model feature pr function. If you can copy/paste into this document, turn the waveforms sideways, label the output as to which test scenario, function block and data set it belongs to.>>