FPGA-911 part 2

Summary:  

In this episode, we will start going deep into digital design flow using FPGA. The design flow involves many activates and practices that a designer should follow to start and finish a design. We will use the design flow as a roadmap to tell you everything about FPGA.

Welcome! This is the second episode of FPGA 911 series. In the previous episode, we got quick introduction about FPGA and the rapid adoption of FPGA in the design of new electronic products.

In this episode, we will start going deep into digital design flow using FPGA. The design flow involves many activates and practices that a designer should follow to start and finish a design. We will use the design flow as a roadmap to tell you everything about FPGA. We will reinforce this with many design examples and tips just to make sure that all aspects of FPGA design are probably covered.

Design Flow

 

Figure-1: A complete and generic FPGA design flow

 

FPGA is a programmable logic device, it use the similar modeling and design flow like those used in ASIC. Differences between ASIC and FPGA are usually related to design implementation stage, the toolset and concepts are quite different. Figure-1 shows a complete and generic FPGA design flow.

Design Requirements

Design requirements are the seeds of any engineering work. First, you need to define what you need to do. This can be customer requirements or might be an idea came to your mind that have a market value. Usually design requirements are generic and do not tell the exact specifications required to start design implementation. An example of this is a customer came to your company and asks to design an industrial controller to manage an assembly line of some other product. A block diagram of a typical FPGA implementation of an industrial controller shown in figure -2.

 

Figure-2: A typical FPGA implementation of an industrial controller

 

Design Specifications

Now you need to define the exact specifications of your design. Usually the exact specifications are ambiguous in very early design phase and requires some time for clarification. Design specifications defined by a thorough study of design requirements by experts in similar designs. Given the industrial controller example, we might need to define some important points like:

1- The capacity of the assembly line in terms of how many pieces it process per minute, hour, day, etc.

2- What are the controllable operations? Moreover, how should be controlled?

3- How many points the controller should concurrently control?

4- What are the feedbacks from the assembly line back to the controller?

5- What are the programmable features and all relationships and dependencies between all system aspects?

6- How does site operator manage the controller? Will we need a user interface like a display, keyboard and such?

7- Will the controller communicate to a central operations monitor using some standard industrial communication protocols as industrial Ethernet, fieldbus, CAN, etc.?

Design Architecture

Once design specifications defined, a design architect needs to put the top-level architecture of the design. A top-level architecture is a non-trivial task and cannot skipped in any design. The top-level architecture requires very well understanding of many things like:

1- Cost. An architecture should implement required functionality with minimum complexity and resources. Complexity means extra logic, longer design time and difficult verification, all cost a lot of money.

2- Power consumption. An architecture should use minimum frequencies and area.

3- Target performance. An architecture should allow maximum performance with available resources and power budget.

4- Technology dependent features like embedded hard IPs inside FPGA. Always try to utilize all features in a device, if you are not using them then device utilization is low. This is not a good design practice.

5- System integration with other external components. Think about integrating your design with other standards and third party designs. Give the customer more freedom and simple integration so he comes to buy your products/services repeatedly.

6- Re-use of pre-designed IPs and components. Look inside your stock and make sure you are not re-inventing the wheel. In many cases, we can reuse other design components with few or no changes. If a design architect does not know about company’s stock then he will come up with an architecture requires more an unjustified design efforts.

7- Scalability and future expansions. In most cases, a successful product redesigned many times to support more features and new standards. Think about an architecture that is capable to adopt new features and new standards seamlessly and with minimum efforts.

8- Implementation issues. Think about integration, multiple clock domains, expertise of design team, design tools, debugging complexity, and all those issues that might make your design architecture quite difficult to implement and maintain.

A design architecture is a set of documents and schematics describe different design components, and integration of those components into a single design. The level of details given in an architecture document varies by design but in general, it describes the functionality of different components without digging into internal details. An architecture document might specify protocols and standards used in a design without too much of details regarding their implementation.

Microarchitecture

Many engineers asking, what is the difference between architecture and microarchitecture in a digital design process? Microarchitecture is the detailed specification of each module/component within a top-level architecture. In a microarchitecture document, designer should specify:

1- Accurate specifications of the interface of each component. This includes pin names, pin function, buses widths, timing diagrams, allowed and non-allowed inputs/outputs combinations, etc.

2- Specifications of logic structure, pipelining stages, state machines, buffers, memories, etc. that are internal to any component in the design.

3- Algorithms implemented inside design component and implementation notes like possibility to sacrifice some accuracy in order to optimize area, power, speed or all.

4- Performance requirements like minimum or maximum allowed clock frequency, required throughput, etc.

5- Components integration requirements like any required glue logic, handshaking, synchronization between multiple clock domains, etc.

6- Any reference documents or reference designs that a designer can utilize to help him implementing required design.

Algorithm Development

In case that a custom algorithm required for designing a specific function or featuring in a system, then a designer might need to develop this custom algorithm using mathematical analysis, Matlab, electronics simulation packages, etc. You should always use such kind of algorithm development techniques and do all required analysis before starting a real design implementation. Many designers skip this and start endless trials directly on FPGA and in most cases they fail to end a design on time moreover they never get the best design possibilities.

Figure-3: Example of PID modeling in Matlab.

 

An example of algorithm development is setting coefficients of PID digital controller. To accurately set them, you will need to model all environment and system parameters in a modeling tool like Matlab or LabView and analyze your controller response to make sure there are no scenarios or conditions can cause a serious system failure.

System Modeling

System modeling is the stage in which you are using a high abstraction level to model and analyze your system design before going to implement it on the target. With the increased complexity and the significant increase in design cost, it’s a good practice to spend enough time trying to fix all system issues in a system model before moving to behavioral or a prototype based verification. There are many reasons for doing that including:

1- A high abstraction language/environment like Matlab, Labview or C/C++ is easier to develop and debug than a low-level abstraction like HDL or embedded programming.

2- Tools like Matlab or Labview have numerous set of visualization tools that will help you precisely analyze all system variables and states with fewer efforts than doing this yourself in a lower level verification environment.

3- Usually system modeling tools and languages have huge libraries of components and modules that you can use to quickly model your system and try many different design options in a shorter development time. Doing the same in HDL or embedded language consumes a lot of time and has very lower yield.

4- In most cases, coefficients and parameters that you will use in a design are fixed however choosing the correct values requires some kind of tuning and trials. A system model will enable you to vary different system parameters quickly and analyze results before going to hard code them in your actual design.

It is known by experienced designers that a well-developed system model can safe days of implementing designs using wrong algorithms and architectures. In most cases, a system model can be developed in parallel to other system design tasks. For example, if we are sure that a microcontroller is required in a certain design then we can start developing things like bus connections and other peripherals and delay custom algorithms development until they proved in a system model.

Conclusion

In this episode we started to explain FPGA design flow in details. In the very early stages, FPGA design flow is very similar to a general digital design flow. We will continue using the design flow as a roadmap to explain all aspects of typical FPGA design. Wait for the next episode as will start talking about design entry and how your coding style could affect your design quality and the whole project feasibility. Stay tuned!

Muhammad Abdulghany
Digital Design Manager
Silicon Vision LLC

Related posts:

 

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

Facebook Comments