next up previous
Up: ECE532S Digital Systems Design 2010 Previous: ECE532S Past Projects

Project Tips

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 their reports. 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.

  1. Software is much easier to debug, change, and upgrade. If you can do it in software, do it in software.

  2. If you have not simulated your design, it will not work. If you have simulated your design, it might work.

  3. 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.

  4. 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.

  5. This is a corollary to Tip 3. There is nothing more discouraging than having nothing working at the time of your demonstration. There is no reason why you should not have something working at your demonstration.

    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.

  6. 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.

  7. 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 interfaces. 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.

  8. 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.

  9. Related to Tip 8, it is important to communicate. 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.

  10. Memories are a good way to cross clock domains, but watch out for read and write conflicts.

  11. 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.

next up previous
Up: ECE532S Digital Systems Design 2010 Previous: ECE532S Past Projects
Paul Chow 2010-01-04