Programmable Logic/Design Process
This page is going to discuss the design process for working with programmable logic devices.
Design Flow[edit | edit source]
Let's talk about the basic flow involved in developing a VLSI chip. Generally this flow is slightly cyclical in nature due to the practicalities of developing a product. Often specifications have to be revisited and reworked throughout the lifetime of a development project which impacts each of the other steps further down the flow.
VLSI Chip Flow[edit | edit source]
Requirements Gathering[edit | edit source]
Products are conceptualized by engineers and sales people who are looking to address a particular market need. They take into account the number of sales, the cost of the product, other products in the market, the company's own line of products, the resources available to the product and many other factors. In fields such as ASIC (Application Specific Integrated Circuits), the engineers often work with potential customers to address their needs.
From this investigation, they come up with the basic requirements of the chip. This will include:
- the packages that the chip will be produced for.
- The power requirements of the chip.
- The speed of the chip.
- Plans for derivatives.
- Requirements for prototyping and samples to send to customers.
Once the requirements are developed, the designers can create the functional specifications for the product. While in theory, functional specifications can be abstract descriptions of the behaviour of the chip, most customers understand beyond just the behavioural level and generally the functional specifications have at least a top level architecture of how the chip is put together.
For VLSI designs, the actual circuit is often built up from existing submodules. For instance, a platform may combine a processor, memory cache, and a bus interface unit. Peripherals and on-board memory can be added. PLLs (phase locked loop circuits) are often placed on the silicon to provide the fast frequencies available nowdays. The functional specification often describes how the various blocks are interconnected and how they will function together. They also describe how the product will interact with connections on the pins.
Establishing a structure[edit | edit source]
Once the functional specifications have be defined, design engineers can begin to fill out the basic architecture of the chip. A HDL (hardware description language) such as Verilog or VHDL is usually used both in the high level conceptual designs and later at the gate-level. At the architectural level, a stub HDL file can describe the module's ports. We can instantiate these stubs in a chip level connection HDL file, in the same way that objects can be instantiated in a object oriented computer program, to define the interconnections between all the modules.
Creating a behavioural model[edit | edit source]
For each module, we can write a behavioural model in a HDL. HDLs can be written much like a computer program. This allows the designer to experiment with the intended behaviour of the module. Simulators can interpret the HDL and show how it interacts with various stimulus. The stimulus can also be written in a HDL or other language. The testbench that is created for testing this module can often be used later on in the design flow on lower level descriptions of the design.
The behavioural models for each module can be used with the top level structural file to imitate the behaviour of the chip in simulation. As the logic design for a module is created, we can replace the behavioural models with RTL and verify the chip's behaviour conforms to the specifications.
Verifying behaviour[edit | edit source]
Functional verification is the process of testing models to determine whether they perform as functionally specified. Tests written to use the testbench can be written by verification engineers to determine whether the behavioural model performs to the specifications created during requirements gathering. A great deel of effort is usually assigned to verifying that the models behave as specified.
At the module level, this is called unit level functional verification. Module designs would need to pass all their functional verification tests before they could be used in a chip level design. It is important that the functional tests cover all the possible functional uses of a module. These tests can often be reused on other models of the design such as RTL and gate level models.