FPGA R&D and design related specifications (very practical in enterprises)

大辉哥0614

FPGA R&D and design related specifications (very practical in enterprises) [Copy link]

Hello everyone! It's time for daily learning again. Today we will talk about the design specifications for FPGA development, from documentation to project establishment, etc. You may learn a lot and avoid many detours! In team project development, in order to make the development efficient, consistent, and correct, the team should have a standardized design process. Complete the design and development work of the project according to the specifications, and classify the project folder level clearly; the project should have a good style and complete documentation, such as design ideas and debugging records and device selection; the code should be written efficiently, that is, unified writing specifications, and the information contained in the file header is complete, so that it is clear at a glance whether you or others in the team read it. 1. Document Naming: Clear document naming can make our thinking very clear, so the directory of the FPGA project folder requires a clear hierarchy and clear classification. A project must have a strict framework structure to store related documents and designs, which is not only convenient for yourself to view, but also improves the work efficiency of the project team. Let's take an example: The first-level folder is the project name Multiple secondary folders: Used to store source files Used to store Testbench files Used to store files related to design ideas Files used to store IP cores And so on… 2. Design documentation: Recording your design ideas and debugging in documents will help add and maintain module functions in the future, and will make it easier for other project team members to read the code during project joint debugging. It will also facilitate the migration between FPGAs from different manufacturers, and from FPGA to ASIC. The following figure is an example of design documentation. The document introduction is clear and the functional analysis is clear, which is conducive to the addition and maintenance of module functions in the future. Design idea: According to the requirements of the project, it is divided into several modules from top to bottom, and the functions are written separately. The top layer should only do behavioral descriptions, and the logic description is written at the bottom layer. The writing of modules should have the thinking mode of hardware circuits. The design of each module should consider whether the hardware circuit exists, and try to use synchronous design. 3. Programming style: Each module should exist in a separate source file, and the source file name should be the same as the module name it contains. Each design should have a complete file header, including company name, designer, design time, file name, project, module name and function, modification record and version information. The identifiers in the code use the traditional C language naming method, with underscores separating words, and using meaningful words that can reflect the characteristics, functions and properties of the object to name the identifiers, so as to enhance the readability of the program. To avoid identifiers being too long, longer words can be appropriately abbreviated. 4. Code standards: For signals with valid low level, the suffix name should be “_n”, such as the valid low level reset signal “rst_n” Module names and signal names should be unified in lowercase Variable names should be lowercase, such as wire, reg, input, output, etc. Variable names should be concisely expressed in English according to the function of the variable, “xxx_xxx_xxx”, avoid being too long Use uppercase letters to define constant parameters, and the parameter name should be less than 20 letters, such as parameter TIME=20 The clock signal should be prefixed with “clk”, and the reset signal should be prefixed with “rst” The output signals of the top-level module should be registered as much as possible Avoid using tri-state logic in sub-modules, but can be used in the top-level module The interface signals to other modules should define the ports in the order of input, (bidirectional), and output A module must have at least one input and output. Avoid writing empty modules The expression of clock events should be in the form of "posedge" or "negedge" Do not nest too many If statements It is recommended not to use include statements It is recommended to add a timescale for each module Give necessary comments in the code Each file has a header file Each file contains only one module Keep the module name and file name consistent For asynchronous reset, use if(xxx==1'b1) or if(xxx==1'b0) There is only one clock signal in the always block of the synchronous timing logic, and it acts on the same edge Use synchronous design and avoid using asynchronous logic Generally, do not use the clock signal as the input of the data signal Do not add any buffer on the clock path In the top-level module, the clock signal must be visible Do not use a vector definition to define a group of clock signals Do not generate clock signals inside the module, use pll to generate them Try not to use tasks Do not use event variables Do not use system functions Do not use disable statements Try not to use loop statements such as forever, repeat, while, etc. Do not use non-synthesizable operators There can be only one event list in an always statement The shift variable must be a constant Use non-blocking assignments in sequential logic blocks Use blocking assignments in combinational logic blocks

cdl511

Come and have a look, thanks!