Build me SSP -- 2
Budget: $30 – $250 USD
https://projects.ece.utexas.edu/courses/fall_21/ee460r382m/ece382m/lab3/lab3a/lab3a.html
Before You Start
Before you start, remember the following.
Think hardware. Remember you are designing "hardware" all the time. Think how your code will be synthesized and check whether it is what you want.
Don't try to code a flip-flop with "asynchronous reset". In the cell library for this lab, there is no flip-flop with asynchronous reset. You will have some problem sooner or later, if you use asynchronous reset flip-flop.
Try to synthesize your code every time you finish one module. If you are new to Verilog, make sure your module is synthesizable before you move forward to next module. It's very easy that your code is un-synthesizable, if you are not familiar with verilog. If you synthesize everything together only at the end, and your code is not synthesizable. It's very possible that you need to re-write your code from scratch.
Tutorial - Verilog
You have to design several modules using Verilog, so you need to learn how to use this language. Many of you may have learned VHDL (another hardware description language) in the logic design course; you will find that Verilog is much simpler. Since Verilog is based on C, you will find it quite natural if you are familiar with C.
Course material covering Verilog can be a good reference to initiate you.
Here is a very good reference book on Verilog,
Verilog HDL : a guide to digital design and synthesis. / Palnitkar, Samir / Mountain View, Calif / 1996
You can also find hundreds of useful sites regarding to Verilog using search engines.
Here are a few online Verilog references.
A Verilog tutorial site
http://www.asic-world.com/verilog/veritut.html
You can find one simple example HERE . We recommend you to follow all the steps before you start lab3 work.
Synthesizable verilog
Your verilog code have to be synthesizable. It doesn't mean that your code should be fully structural. Your code can be behavioral, but still need to be synthesizable. It is very hard to say specifically which features are synthesizable, and which are not. Here are several syntax(or statements) that are not synthesizable with Design Vision. A module with these statements will not be synthesized. There can be more. If you think you're going to use a suspicious statement, make a small test module and synthesize it.
We will synthesize your code with the design vision and grade your design based on this synthesis result. In case of errors, synthesis with other versions cannot be an excuse.
Nested 'always' statements.
'always' statements without sensitivity list. It will put your simulation to infinite loop.
'initial' statement.
Delay construct with non-blocking assignment (assignment with <=). When you need to use delay construct in a module, do not use non-blocking assignment in that module.
Non-blocking assignment used together with blocking assignment.
(Most importantly) A register type variable which is assigned a value in more than one 'always' construct. (This means that the variable is driven by more than one flip-flop, which means the outputs of several flip-flops are shorted together. The correct output is not guaranteed.)
Why do we need to know the things listed above? Because you should not use any one of them in your module.
Your test bench can have 'initial', or 'for' statement, of course. (Test bench is not the actual module you're designing. There's no reason to synthesize the test bench.)
Resources
You can find excellect verilog source codes in opencores.org
Before You Start
Before you start, remember the following.
Think hardware. Remember you are designing "hardware" all the time. Think how your code will be synthesized and check whether it is what you want.
Don't try to code a flip-flop with "asynchronous reset". In the cell library for this lab, there is no flip-flop with asynchronous reset. You will have some problem sooner or later, if you use asynchronous reset flip-flop.
Try to synthesize your code every time you finish one module. If you are new to Verilog, make sure your module is synthesizable before you move forward to next module. It's very easy that your code is un-synthesizable, if you are not familiar with verilog. If you synthesize everything together only at the end, and your code is not synthesizable. It's very possible that you need to re-write your code from scratch.
Tutorial - Verilog
You have to design several modules using Verilog, so you need to learn how to use this language. Many of you may have learned VHDL (another hardware description language) in the logic design course; you will find that Verilog is much simpler. Since Verilog is based on C, you will find it quite natural if you are familiar with C.
Course material covering Verilog can be a good reference to initiate you.
Here is a very good reference book on Verilog,
Verilog HDL : a guide to digital design and synthesis. / Palnitkar, Samir / Mountain View, Calif / 1996
You can also find hundreds of useful sites regarding to Verilog using search engines.
Here are a few online Verilog references.
A Verilog tutorial site
http://www.asic-world.com/verilog/veritut.html
You can find one simple example HERE . We recommend you to follow all the steps before you start lab3 work.
Synthesizable verilog
Your verilog code have to be synthesizable. It doesn't mean that your code should be fully structural. Your code can be behavioral, but still need to be synthesizable. It is very hard to say specifically which features are synthesizable, and which are not. Here are several syntax(or statements) that are not synthesizable with Design Vision. A module with these statements will not be synthesized. There can be more. If you think you're going to use a suspicious statement, make a small test module and synthesize it.
We will synthesize your code with the design vision and grade your design based on this synthesis result. In case of errors, synthesis with other versions cannot be an excuse.
Nested 'always' statements.
'always' statements without sensitivity list. It will put your simulation to infinite loop.
'initial' statement.
Delay construct with non-blocking assignment (assignment with <=). When you need to use delay construct in a module, do not use non-blocking assignment in that module.
Non-blocking assignment used together with blocking assignment.
(Most importantly) A register type variable which is assigned a value in more than one 'always' construct. (This means that the variable is driven by more than one flip-flop, which means the outputs of several flip-flops are shorted together. The correct output is not guaranteed.)
Why do we need to know the things listed above? Because you should not use any one of them in your module.
Your test bench can have 'initial', or 'for' statement, of course. (Test bench is not the actual module you're designing. There's no reason to synthesize the test bench.)
Resources
You can find excellect verilog source codes in opencores.org
Related categories:
Verilog / VHDL