0% found this document useful (0 votes)
57 views18 pages

Ee465 Final

This project designs a circuit for the USDA to monitor temperature readings and calculate statistics. It records the last 12 temperature readings serially using a demux. It then calculates the average and standard deviation using modules. Simulation results and synthesis are shown, along with conclusions about challenges faced.

Uploaded by

api-626683514
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
57 views18 pages

Ee465 Final

This project designs a circuit for the USDA to monitor temperature readings and calculate statistics. It records the last 12 temperature readings serially using a demux. It then calculates the average and standard deviation using modules. Simulation results and synthesis are shown, along with conclusions about challenges faced.

Uploaded by

api-626683514
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

EE/CPRE 465 Final Project

Engineers:

Clayton White - cwhite - Section 4


Olouwole Eteka - ofeteka - Section 2
Alain Njipwo - anjipwo- Section 4

12-12-19
2. Introduction
In this project we are working for theUnited State Department of Agriculture (USDA ) to fix the
temperature issue that are affecting the protein level of their plant in the field. We will design a
circuit that will be constantly recording the last 12 temperature reading to take the average, and
standard deviation. We can then make the temperature readings more accurate. We will follow
the specification, and formulas provided by the project . We will also synthesize our design, and
optimize for power and area.

We had and different approach to this project than others. We decided that our temperature
decoder will take inputs serially instead of parallel. We believe that this is a much more practical
application. To do this, we broke the code in pieces then wrote one main that put them together.
We had a square root function, a MUX function, a standard deviation function, average function,
and the main that brings them all together.

3. Detailed description of the design


As mentioned before, the data is inputted serially. To load this data into their appropriate
registers, we used a 1-to-8 Demux that has a select controlled by a counter. As this counter
iterates, the input fills the 8 registers. Once a register, or multiple registers, are full, we can take
the average and standard deviation. The standard deviation is calculated using the Babylonian
iteration process and the average is calculated by dividing the value of the registers by some
denominator. This denominator is a counter that starts from 1 and counts to 8 and then stays at
8 until the device is powered down. As requested, a mode bit chooses if the output is the
average or standard deviation. We also included a done bit that goes high once the average or
standard deviation is calculated. Since our data is inputted serially, the system is always ready
to take in a new input. The required output “Sample” does not apply to our design strategy and
was therefore left out. After our design was verified via Modelsim simulation, we began the
Synthesizing/Place and Route steps that we have done in previous labs. The results are shown
below.

Timing:

Area:
Power:

Encounter

Area (um^2)
18885

Power (mW)
16.4276
Clock (pS)
1500

Slack (ps)
-280
This was the slack that was achieved at an earlier time. After making changes to the code
and restarting the synthesis on another partners computer, our slack was
(Unconstrained). The screenshot included in the report was taken at an earlier time.

4. Verilog codes design modularity


Figure 4.1: Counter module.
Figure 4.2: demux1_8 module
Figure 4.3: Average Module
Figure 4.4 Guess module and Test Bench
Figure 4.5 Top level design (Demux_Counter_18) module
5. Test benches and simulation results (Appendix)

Figure 5.0 Counter Testbench

Figure 5.1 Counter Test bench Results

Figure 5.1 Guess Testbench


Figure 5.2 Main Testbench (1)
Figure 5.3 Main Testbench (2)
Figure 5.4 Main Testbench (3)
Figure 5.5 Main Testbench (4)
Figure 5.6 Main Testbench (5)

Figure 5.7 Main Testbench Results (Both Average and Standard Deviation)

Figure 5.7 Main Testbench Results (Average, Mode = 0)


Figure 5.7 Main Testbench Results (Standard Deviation, Mode = 1)
Synthesis

Synthesized Circuit
6. Conclusions and Discussions
+
Figuring out the right approach to the design was our first level of difficulty. Writing Verilog isn’t
always that bad but writing Verilog that can be turned into hardware can be a challenge
sometimes. Setting up the modules to behave correctly at the same time was also a challenge
because some modules may be a clock cycle behind and other modules might be a clock cycle
ahead.

Another difficulty was Synthesis and Place and Route. Synthesis required us to change our
code which introduced some errors that we had to fix before our demo. We, unfortunately, could
not get Place and Route to work properly. The error we received is shown below.

To improve power performance, we could have explored clock gating. To improve the area, we
could have used area optimization.

There are more than one ways to complete this project so we are happy that the TA’s were okay
with us choosing a different design strategy than other students.

Showcasing line 7

Error received during Place and Route

You might also like