Module 1 focuses on the basics of project development, in general, and design for reuse projects, in particular. In it you will learn the rules for creating reusable HDL code and how to define an architecture and partition your project; develop a project skeleton; create a preliminary test bench; use definitions and parameters to control and enhance modules and project compiles; and design parameterized modules for generic functions. You will also learn about different multiplexer arrangements and dividing a periodic signal by an odd number.
Before we can begin our lessons, we need a design project. A coding for reuse design only differs from any other design project in its design capture and coding style. There are additional constraints required to make the code reusable; but it still conforms to the same basic best practices as any other design.
Any design project may be split into 5 phases:
Although some of you may have heard the alternative 5 phases:
- Search for the guilty
- Punishment of the innocent
- Praise and reward for the non-participants
The former list, when properly followed, can prevent items 2-4 of the latter list from ever occurring. Coding for reuse starts during the definition phase, is implemented in the development and verification stages, and simplifies all subsequent phases.
Project definition normally produces a customer specification document. The customer specification document is agreed upon by all parties and used in turn to produce the design specification document. Some of the items to consider when developing a customer specification for an embedded microprocessor include:
- Interrupt and I/O architecture
- Data bus structure
- Memory map/architecture
- Instruction cycle times (speed)
- Instruction set
- Existing product offerings
- If the microprocessor you are developing is targeted to a programmable device, size and resources are also factors.
You, as the intellectual property developer, should be prepared to negotiate the hardware architecture with the customer and his agents:
- The embedded software development team.
- The peripheral hardware and interface design team.
- The manufacturing test team.
Although the customer's legitimate requirements are primary, and must be met; given the chance, some players will make un-realistic or impossible requests for functions that are seldom, if ever, used. Believe me. I once had to write software code in assembly language that featured a lunar calendar, to schedule a task for execution at 12:00AM on the day of the second full moon in the same month; literally 'Once in a Blue Moon.' Remember, even one of these type requests could lock you into a specific device or vendor and preclude development of reusable code. This, in turn, can lead to increased cost; which could possibly be a concern.
Since our project requirements and constraints were already set in the Course Introduction; we will not detail them any further here.