硬件描述语言Coding规范.pdf经常看到C、C++等高级语言有很多规范，实际上在编写硬件描述语言

文件名称: 硬件描述语言Coding规范.pdf

所属分类: 硬件开发

开发工具:

文件大小: 290kb

下载次数: 0

上传时间: 2019-08-24

提供者: dua****

下载 (290kb)

不能下载？报告错误

详细说明：经常看到C、C++等高级语言有很多规范，实际上在编写硬件描述语言程序的时候，如果按一定的规范去做，会减少很多错误的发生，起到事半功倍的效果。Opencores HDL modeling guidelines Table of contents Introduction Before you start Specification Document Design Document. Subversion (SvN) and Team Work Verification Directory structure General design guidelines General 55568888 Reset Clocks Buses Tri-State 10 Memories 10 Coding for synthesis Core l/0 ports Verilog guidelines 12 Gener coding tor synthesis Coding for simulation and debugging 13 File header VHDL guidelines 15 General Coding for synthesis 16 Coding for simulation and debugging File header Preprocessors 19 vppreproc-Preprocess verilog code using verilog- perl 19 Verilog preprocessor 20 Examples Modular design Build environment 24 Example: variants from common code base 24 Use case: versatile io 25 Revision history Recommended resources 28 ORSoC Back to TOC Copyright o 2009 Open Cores Page 3/28 vendor specific floorplan, place and route directory structure +-sim Top level simulations directory +- rt sim RTL simulations + bin RTL Simulation scripts I- run For running rtL simulations +-sro Special sources for RTL simulations +-out dump and other useful output from RTL simulation +-log Log files + gate sim Gate-level simulations t- bir Gate-level simulation scripts +-run For running gate-level simulations +-src Special sources for gate-level simulations t-out dump and other useful output from gate-level simulation +-log Log files t- syn Synthesis +- Each synthesis tool has separate directory +-bin For synthesis scripts +-run For running synthesis scripts +-src Special sources for synthesis out For generated netlists (Synopsys db, verilog +-log Log files (including reports) RTL sources +-verilog For verilog sources vhdl For Vhdl sources +- bench Bench sources 1 +- verilog For verilog sources +-vhdl For Vhdl sources +-doc ut specification design and other pdf documents here + src Source version of all documents(Open Office, Frame Maker) + SW Put sources for utilities or software test cases here If your core requires additional directories, try to add them by following ORSoC Back to TOC Copyright o 2009 Open Cores Page 6/28 Open Cores Open Cores HDL modeling guidelines conventions in the suggested directory structure. For example it is very common that sw will require several subdirectories Subdirectory lib should contain vendor target libraries. For example for a standard cell asIC with a hard block SRAM, this directory should contain two subdirectories. Each subdirectory should contain complete set of library files for front-and backend design process(behavioral models, timing models, LVS netlists, layout abstracts, gDSll layouts). For FPGa at least behavioral models of FPGA primitives should be included here In order to provide vats(automated verification System)all the needed data script file run sim must be provided in sim/rtl sim/bin/, VatS will call this script with"-r"parameter to check if design is working against regression test when CPUs are idling, usually overnight. the test will pass only if the last line is"OK The rest of the output is ignored by vats, but it should be as informative as possible, in order to track possible errors Directory structure for backend is not precisely defined because it is out of scope of this document. Usually for FPGa backend you will have FPga vendor specific subdirectory structure with several revisions of mapping, floorplan, place and route. For asIC subdirectory structure will usually consists of subdirectories pre p&r, post p&r, post scan etc ORSoC Back to TOC Copyright o 2009 Open Cores Page 7/28 Open Cores Open Cores HDL modeling guidelines General design guidelines General yy, nabit to comment every assignment or block Comments. Try to make a Strong Recommendation: Write descriptive You will make life much easier for someone who would like to add additional functionality or fix a bug. Not to mention it is good for you as well if you try to change the code after a few weeks 2. Recommendation: If your core is complex and has several submodules in hierarchy, it is recommended that top level module is for connectivity only without any logic Makes design cleaner and gives an instant insight what are major blocks Also try to bring all memories and other hard blocks on top level. If you need some glue logic, create separate module for glue logic 3. Good Practice: Keep the same signal name through different hierarchies Tracing a signal will be easier. Enables easy netlist debugging 4. Good Practice: Try not to mix active low and active high logic in your core stick just to one Preferred is active high Reduces confusion Reset Reset makes a design more deterministic and easier to verify. It prevents reaching prohibited states in state-machine at power-up 1. Recommendation: Use asynchronous active high reset Using asynchronous reset could result in a smaller core. Using an active high reset makes the core compatible with wishbone spec 2. Recommendation: At reset time all bi-directional ports should be in input state Scan expects this and it prevents X values Clocks 1. Strong Recommendation: Signals that cross different clock domains should be double sampled after crossing domains (double sampling is a MUST Prevents meta-stability state To make netlist verification easier, you should use one module (i.e sync.v, sync. vhd) that will have in, out and clock interface and the first flip-flop should have a unique name as this flip-flop will have timing violation, If it has unique name it is easier to trace it and change it to not pass Xs ORSoC Back to TOC Copyright o 2009 Open Cores Page 8/28 Open Cores Open Cores HDL modeling guidelines Also it should be clear that you pass oNly the control signal and not the data bus etc 2. Recommendation: Do not use gated clocks unless you have thorough knowledge about the proper way to implement clock gating and the consequences for testing and verification Usually the system integrator and the backend are responsible for clock gating. If target application is required to operate in low power, clock gating can be a powerful feature to achieve that if low power is not required, explicit clock gating in RTL can cause much longer development because backend must eliminate possibilities for glitches in the clock More proper way instead of explicit clock gating in rtL is to use clock enables. If you use clock enables, certain eda tools such as synopsys Power Compiler(ASlc) can be used to transform a design with clock enables into a design with gated clocks. This way target application that does not require low power operation and can still use your core without dealing with clock gating problems in explicit rtl clock gating 3. Recommendation: do not use clocks or reset as data or as enables do not use data as clocks or as resets Synthesis results may differ from RTL. Higher chances for timing verification problems In certain cases you might need to use clocks/resets as data or data as clocks/resets. In such a case provide two signals. for example clk and clk data, where clk drives flops clock inputs and clk data drives combinatorial logic 4. Good practice: Use minimum number of clock domains per core For example, a UaRT only needs one clock domain- not two or three-to function properly Buses 1. Strong Recommendation: Compare buses with the same width Buses must be of equal width so that comparison works properly. 2. Recommendation: Start buses with bit index o Some tools don't support buses that don 't start with bit index o 3. Recommendation: use msb to lsb convention bito is lsB This is to avoid misinterpretation through the design hierarchy 4. Recommendation: Try to design with a minimum number of interconnecting wires on core interfaces. do not make buses wider than necessary. If possible make data bus narrower and increase address bus Width instead Lack of routing resources can cause serious problems in the backend and ORSoC Back to TOC Copyright o 2009 Open Cores Page 9/28 Open Cores Open Cores HDL modeling guidelines it can affect both timing and area 5. Recommendation: Use wishbone Soc interconnect OpenCores selected WISHBONE Soc interconnect as our Soc interconnect. Most our new cores support WISHBONE. To get more information about WISHBONE and to find out why WiSHBONE is the only trulyfreeSocbusseehttp://www.opencores.org/do=wishbone Tri-state 1. Recommendation: Generally avoid using internal tri-state signals However for internal monitors tri-state is recommended Generally tri-state increases power consumption It also makes the backend tuning more difficult However in certain cases such as in case of internal bus monitors tri state implementation might result in much smaller monitor than multiplexer implementation. But using tri-state monitors with scan can create complications since only one tri-state driver can be enabled and his must be considered when testing the design with scan Memories 1. Recommendation: Use synchronous single-port or dual-port generic memory blocks such as generic spram and generic dpram. these blocks already support several asic memory vendors as well as several different FPGA vendors. They are in Open Cores Cvs under module common This will automatically mean that your design supports several ASIC and FPGA memories and that you do not have to deal with various kinds of memories to support various target technologies Simply enable the target vendor and link with his target library Also using synchronous memories instead of asynchronous memories might allow you to meet timing constraints easier. Coding for synthesis 1. Strong Recommendation: Use synchronous design practice It avoids problems with synthesis, timing verification and in simulation 2. Strong Recommendation: Do not use delay elements It causes synthesis and timing verification problems If you use delay elements you MUST consider worst and best case timing and not be happy with the delay in nominal case. this will make your core reuse unfriendly since it will have to be characterized for every target technology/ process 3. Recommendation: All cores external los should be registered It prevents long timing paths and allows you to meet timing constraints easier t also allows easier verification of the entire soc However in certain case you cannot register outputs such as in case of ORSoC Back to TOC Copyright o 2009 Open Cores Page 10/28 Open Cores

(系统自动生成,下载前可以参看下载内容)