The following is a set of design tasks associated with a single specification. The full design is broken into these stages to assist you in the design process; do not attempt to proceed to the next task until the current one is completed and understood.
The assessment (since this topic always looms high) will be based upon your report: another Electronics Letter, and the Verilog code of your design which you will be asked to submit. The code is due by the end of Spring term - and the Electronics Letter is due by the beginning of Summer term.
In the Gateway lab - your time is your own. Help is available during lab hours - but not easily found at other times. You MUST think carefully about making time for your design work based around: a) the lab times, b) the demands of the rest of your third-year course. The wise student might consider it appropriate to do the Gateway exercise earlier rather then later.
As a demonstration of vanity, this year's exercise is based upon one of my own papers: published at the same conference as the Median Filter design. The Bit-serial Correlator is described in a brief paper found here[1] .
It is important at this stage not to panic.
Often, engineers are given design problems in an application area which is unfamiliar to them.
The key is to read the specification several times to identify those parts of it which are relevant to your design task.
Some of you may not have heard of bit-serial arithmetic - and those are strongly advised to do exercises 5 & 7 in the local introduction to synchronous design. .
Design a bit-serial correlator for 16 binary values with 16, 4-bit samples (not 256 as in the paper). The design ideas are the same - but the lower number will help to reduce your simulation times.
To begin with, ignore the question of how to generate a local clock. Assume for initial testing that you can simply drive the clock line and any other control signals.
STAGE 1:
Create (and test) behavioural modules for the bit-serial adder unit and the basic dtype.
STAGE 2:
Create (and test) a module for the "tap" - using a mixture of behavioural code and calls to the modules created in stage 1
STAGE 3:
Create (and test) a hierarchy of modules: a 16-point correlator which is an adder with calls to two 8-point correlators, an 8-point correlator which is an adder with calls to two 4-point correlators etc.
At this stage it is time to test the design. The code provided here may help. There are some problems with this code in general - for instance, it stops one cycle too soon to extract the last data value - but it should be sufficient to verify your design at this stage.
STAGE 4:
Revisit your basic modules: recast the adder design in terms of basic gates - and also parts of the tap module.
Reread the large exercise in session 2 of the autumn term on delays and update your primitive modules to have appropriate delays. These should include a delay on each simple gate (say 4 units), a delay though the dtype (say 6 units) and a setup constraint (say 3 units).
Consider carefully the maximum frequency which your design will permit - and then verify this by rerunning the simulation with the clock changing at both above and below your calculated value [one will fail if you are correct].
Consider also what happens if the hold time is greater than the delay through a dtype - and test your conclusion.
STAGE 5
Consider adding features to the design which will help it to communicate with other parts of a system which works primarily in bit-parallel.
STAGE 6 [Optional Extra]:
Now we look at generating a local clock - you should create this part of the design in isolation from the remainder until it is complete - and only then put the bits together.
The philosophy behind local clock generation is explored in a paper here[2] .
The idea is to generate a local clock using a feedback loop, initiated by the arrival of a word_clock (and the data sample in bit-parallel format) and stopped when the correlation is complete.
Basically you will need to create:
You should ignore members of the digital signal processing group who will suggest you add noise to your data signal. Spread Spectrum communications is a technique for retrieving signals out of noise - HOWEVER the testing of your design does NOT depend upon demonstrating this potential. You should test your circuit using clean signals - whose results you can predict (not random ones). The testing of the system's effectiveness as a spread spectrum receiver should be done by the system designers. Your job is to build a correlator - not to test the Spread Spectrum communication theory.