Here are some tips you should read carefully and consider for your
project, in no particular order.
These include comments from previous students that they provided in
The most valuable input you can get is from those that have already
gone through the experience.
A good designer is an experienced designer that learns from their own
previous work and the experience of others.
We build ever more complex widgets.
There is no time to rediscover what others have already done and learned.
Software is much easier to debug, change, and upgrade.
If you can do it in software, do it in software.
If you have not simulated your
design, it will not work. If you have simulated your design, it might
Do your work incrementally.
Do not expect to put together the whole design at once and expect it
to work without having tested the individual components first.
Debug individual pieces first.
An added benefit of following Tip 3 is that you
will save a lot of time doing synthesis, place and route.
The tools are slow, and get ever slower with big designs.
By debugging the pieces first, you save a lot of time.
This is a corollary to Tip 3.
There is nothing more
discouraging than having nothing working at the time of your
There is no reason why you should not have something working at your
For example, if you are building something using video, you should
first get a simple design that takes in video, stores frames in
memory, and then displays the frames.
Once that is working, then you can start doing things to process the
frames knowing that you have the basic input and output working.
This way you can also see what effects you are having on the video by
the processing that you are doing.
Your project comprises many pieces.
When designing modules in a multi-person project, it is important to
have all of the interface details figured out before starting the
actual implementation of the design.
Every byte alignment, endian convention, signal assertion polarity,
number of bits counts.
This tip is a continuation of Tip 6, but goes
further and suggests that you actually build and test the interfaces
first before doing the rest of the design.
A common source of problems is at the interfaces, which can be
hardware/hardware, hardware/software, and software/software
These problems are often not revealed until you try to integrate the
pieces of your design, which means you are already late in your design
cycle, and panicking to get your project done.
The software/software interfaces are usually easier to deal with
because there it is much easier to debug.
The interfaces involving hardware are much more difficult.
Get your interfaces working first!
Even if you intend to build some custom block of hardware, you can
usually figure out a way to build and test the interface using some
simple dummy internal logic first.
Once the interfaces have been developed and tested, it makes it much
easier to work on the separate pieces and be confident that the
integration will work later with little difficulty resulting in much less panic!
It is very difficult to isolate problems when testing an entire system.
It is important to get the high-level design done carefully.
Our high-level design kept changing right up to the last week of the
project as various issues came up.
This hampered progress on our custom logic.
Related to Tip 8, it is important to
We needed to communicate more effectively, as I do not think we spent
enough time discussing the overall design.
Instead, we dove into designs as soon as something was put on paper.
Memories are a good way to cross clock domains, but watch out for read
and write conflicts.
HDL coding can be problematic.
Behavioural simulations and post-synthesis simulations may not give
the same results.
Post-synthesis simulations reflect the circuit that will be implemented.
Post-synthesis simulations are the best way to see whether you have
coded the circuit that you really want.