|
Verilog And Synthesis |
| Status |
Closed |
| Budget |
$100-300 |
| Posted |
09 May 2008 11:42 PM |
| Expires |
23 May 2008 11:42 PM |
| Posted By |
lndsey |
| Service buyer Rating |
 |
| Description |
Submission Instructions:
Project Plan. Paper report.
Project Verilog and synthesis files. Submitted electronically. Please turn in the following:
All Verilog files
Synopsys view_command.log file from complete synthesis run
Simulation results file showing correct functioning
Project report
Project Report. Submitted electronically at the same time.
Project Description
The purpose of this project is to find matching 5-character words in a two serial incoming string sequence. You are to report a match if a word on one port appeared on the other port, as one of the previous three words to appear there. Your I/O will be as follows:
Inputs
Clock
DataIn1[7:0]; // Input ASCII port #1
DataIn2[7:0];; // Input ASCII port #2
Go; // High when DataIn is changing
Outputs
Match; // = 1 on cycle match is found
The operation will be as follows:
An ongoing (never ending) stream of ASCII characters will be presented at DataIn while Go is high. (i.e. If Go is low, DataIn is not changing). Each word will be 5 characters long with no separators (i.e. no spaces or punctuation) and will take 5 clock cycles to be “entered”. All words will be lower case. When a match is found, match should go high within two clock cycles of the last character of the matching word appearing on the input. Match should stay high for 5 cycles. For example consider the following sequence….
Clock Go DataIn1 DataIn2 Match (1 to 2 cycles later)
0 0
1-5 1 first third 0
6-10 third dirty 1
// DataIn1 found a match in previous DataIn2
11-15 found found 0
// not a match in same cycle
16-20 asics bases 0
21-25 rough first 0
// not a match – “first” is fourth previous word
26-31 moron asics 1
The approach you use is up to you. However, to me, this screams for a couple of FIFOs as part of the core of the datapath.
General Instructions
Project Plan
Items to be included in this report include the following:
Block diagrams of your design, clearly identifying any design hierarchy, all registers, all module I/O. Neat block diagrams are expected, not rough hand-drawn sketches. Include a written description of the function of each module. E.g. For a multiplier, which multiplier algorithm are you planning to use.
Any appropriate high-level (e.g. C) code showing the algorithm has been correctly captured.
A project execution plan, including the following:
Who is responsible for each module
A verification plan. How do you intend to verify that the design works correctly? Who will be responsible for system verification?
A risk assessment plan. Where are the greatest risks in this project? E.g. What areas of the design are you unsure of? Where are your greatest concerns in executing this project? Note, this section is intended for your benefit (so you can focus your efforts on the parts you are least sure of). Do not expect written feedback on your risk assessment plan. However, feel free to ask questions of the teaching team.
A milestone chart, including anticipated dates for completing module design, design integration and design verification.
Grading for this report will be as follows (out of 10):
9-10 : All major design elements correctly identified; behavioral code complete with test cases. Neat and clear documentation.
7-8 : At least one major design element missing, or C code incomplete, or confusing and poor documentation.
5-6 : Scrappy, but honest, capturing some elements but conveying no real understanding of the design.
0-4 : Extremely poor attempt.
Do not wait for feedback from us before proceeding with the project. If you need feedback, bring a copy of your report to myself or the TA for discussion. The main purpose of this milestone is to get you going early.
Main Project Report and Demo
Your project report is to include the following:
- Written description of your approach, including block diagram of your design, description of your verification strategy and a discussion of any part of the design, synthesis or verification that you consider “tricky”, novel or noteworthy.
- Specifically note and document your area and your throughput
- Full listings of the following:
- Verilog files, including test fixture
- Synthesis scripts
- Extracts from View_command.log generated by design_analyzer, including the results from the read command and timing verification. (If you use dc_shell, you will have to rerun the script in design_analyzer in order to obtain this).
- Plots from the final design.
- Simulation run results (waveforms or equivalent)
- High level model of the design, if appropriate
You will be graded on the following factors (roughly in order of importance):
- Design correctness in terms of correct functionality
- Design correctness in terms of using good Verilog and Synthesis strategies, structuring, coding approach, etc.
- Correctness of synthesis approach
- Design elegance in terms of Verilog readability, and “coolness” factors
- Design efficiency – performance and area
- Completeness of Verification – do you just simulate a handful of cases, or has some thought and effort gone into it?
- Quality of reporting
The grading scale will be roughly as follows:
100 Excellent job. Several special features. The performance per unit area will determine these points in most cases.
95 Very good job. At least one special feature. The performance per unit area will determine these points in most cases.
90 Works properly. Good basic design. Full points from partner gives you 10 of these points. Partner point count submitted in confidence.
80 - 89 Some significant problems that have a good probability of meaning this design would not be acceptable to an industrial team. e.g. Synthesis problems, features that did not work or poor documentation, partner dis-illusionment.
70 - 79 Major problems but made a good attempt, or understood very little of a
working design. This includes a terrible report but design that would otherwise get an 80.
0-60 Some fraction of the above. Give something if they made an attempt.
Other Instructions
You are NOT required to run the verify command in Synopsys. This takes lot of time and adds no educational value to the project (obviously in real life, you would run this command.)
Make sure to use the 0.25 mm library, so we can compare area and performance accurately.
An SRAM .v file is provided. Use this for any SRAMs required. DO NOT SYNTHESIZE ANY SRAMS. To account for the performance and area of the SRAM, use the following formulas:
Read/Write Delay = a * #rows + b * #columns;
a = 0.25ps b = 0.08ps
Area = c * #rows + d * #columns + e ( peripheral circuits);
c = 4.4um; d = 5um; e = 10% of (c * #rows + d * #columns);
Note, #columns does not have to be equal to the #bits in the word, but can be a multiple of that.
Note the sum of input_delay and output_delay of the logic connected to the SRAM must equal the delay
Add the area to the result from synopsys report_area and include in your report
Checklist For Neophyte Verilog Designers
Module Design
Did you DESIGN BEFORE CODING?
Have you clearly identified the purpose of each register (flip-flop)?
A common beginner error is to have unnecessary flip-flops. (This is usually a symptom of NOT designing before coding). A flip-flop is only needed when data is stored between clock cycles. Excessive flip-flops makes a design LARGE and SLOWS down synthesis.
Do you use non-blocking assignment when assigning to flip-flops?
Do you make sure that every variable is only assigned within ONE procedural block or continuous assignment statement?
This will cause a LINT warning from Synopsys.
Do you make sure that you have NO feedback within combinational logic.
This will cause “timing arcs” in synthesis. An example is…
always@(B or C)
A=B+C;
always@(A or E)
C=A+E
Instead A or C must be registered.
Do you avoid unintentional latches by having no implied memory in combinational logic?
Do you avoid having 2D arrays (register arrays) in your modules?
Put large 2D arrays into your SRAM. Put smaller ones into their own register file module.
Did you “right-size” the module?
i.e. Make it as small as reasonable while containing critical paths, sharable logic, registered paths (see 9) and being “reasonable” to understand.
Does every path connecting input and output go through a flip-flop?
Are critical paths contained within one module, not split across two of them?
Did you have any while or FOR loops?
The ONLY valid construct is to use a for loop to iterate through an array of bits. Most attempts by neophytes to use these constructs are invalid.
Did you DESIGN BEFORE CODING?
Design Hierarchy
Did you avoid “glue” logic in modules containing other modules?
Did you bring all signals connecting to things outside your design up through the ports of your “top” module?
Did you instance your SRAMs only in your test fixture?
Simulation
1. If saving the variables takes too much disk space, save a .trn file instead …$shm_open("count.shm"); $shm_probe(test, "AS"); (later $shm_close this). You can also choose to only save a subset of variables – see the manuals.
Synthesis
Did you set “current_design=top” before running “compile”?
Did you set “current_design=top” before running “report_area”?
If the compile is slow try setting “map_effort = low” and try a much slower clock.
Make sure you have a correct synopsys setup file and correct references to design ware, if used. (See
http://www.synopsys.com/products/designware/buildingblock.html
and for the Verilog files, refer to
/afs/bp/dist/synopsys_syn/dw/sim_ver )
Did you look at the warnings and errors after the “read” statement?
Did you look at the timing reports?
If resest global signal has a high “fan-out” that is OK. This signal can be asynchronous.
|
| Categories |
|
| Database |
N/A
|
| Operating System |
- -
|
|
|
|
|
| |
| Service provider |
Bid |
Delivery Time |
Bid Time |
Rating |
|
| |
|
