IntroductionBefore You StartSpecification DocumentDesign DocumentCVS and Team WorkVerificationDirectory structureGeneral Design GuidelinesGeneralStrong Recommendation: Write descriptive comments. Try to make a habit to comment every assignment or block.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.Good Practice: Keep the same signal name through different hierarchies.Good Practice: Try not to mix active low and active high logic in your core. Stick just to one. Preferred is active high.ResetRecommendation: Make asynchronous active high reset for all flip-flops. Such reset must be synchronized with the clock on SOC top level and it does not require a multiplexer at every flip-flop data input.Recommendation: At reset time, all bi-directional ports should be in input state.ClocksStrong Recommendation: Signals that cross different clock domains should be sampled before and after crossing domains (double sampling is a MUST). See synchronizer_flop in OpenCores CVS in module common.Recommendation: Do not use gated clocks unless you have thorough understanding what is the proper way to implement clock gating and what are the consequences for testing and verification.Recommendation: Do not use clocks or reset as data or as enables. Do not use data as clocks or as resets.Good practice: Use minimum number of clock domains per core.BusesStrong Recommendation: Compare buses with the same width.Recommendation: Start buses with bit index 0.Recommendation: Use MSB to LSB convention. Bit 0 is LSB.Recommendation: Try to design with minimum number interconnecting wires on core interfaces. Do not make buses wider than it is necessary. If possible make data bus narrower and increase address bus width instead.Recommendation: Use WISHBONE SOC interconnect bus to connect your core to other OpenCores’ cores.Tri-StateRecommendation: Generally avoid using internal tri-state signals. However for internal monitors tri-state is recommended.MemoriesRecommendation: 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 OpenCores CVS under moCoding for SynthesisStrong Recommendation: Use synchronous design practice.Strong Recommendation: Do not use delay elements.Recommendation: All core’s external IOs should be registered.Recommendation: Avoid using latches.Good Practice: Avoid using flip-flops with negative edge clock.Good Practice: Core’s internal interfaces should be sampled.Core I/O portsRecommendation: Name core’s ports by following conventions from Table 1. This simplifies the SOC integration process and backend process and allows automation.Recommendation: Use *n to mark active low signals. Do not use *_.Verilog GuidelinesGeneralRecommendation: Try not to use `include command. Instead load all files as modules or load them as libraries (-y –v).Recommendation: Use non-blocking assignment (<=#1) in synchronous process, and blocking assignment (=) in asynchronous process.Recommendation: If possible, use parameters instead of definitions (`define).Recommendation: Put all definitions (‘define) that cannot be changed into parameters, into one global file.Good Practice: Try to write one module in one file. The filename should be the same as the module name. Module name should be composed out of the block name and local module name.Good Practice: Try to use instantiation by name (explicit instantiation) and not by place.Recommendation: Use lower case letters for all identifiers. Use upper case letters for definitions (‘define).Coding for SynthesisStrong Recommendation: Do not use statements such as ‘assign #X a = b;’ or ‘#X;’ where X is a number of time units of delay.Good practice: Do not use statements that assign initial values to signals and variables (wire b=1’b0;).Coding for Simulation and DebuggingStrong Recommendation: All system tasks for simulation should be contained in a separate file from the core source code.Good Practice: Create a separate timescale.v file, put `timescale command in it and include this file in all RTL source code files. Include command should be wrapped with // synopsys translate_off and // synopsys translate_on directives.Good Practice: Try to write '%m' in 'display' command (shows the instance name).File HeaderRecommendation: Use our standard header at the beginning of each file. The header is available from the OpenCores CVS under module name common.VHDL GuidelinesGeneralStrong recommendation: Use std_logic type for external ports type.Strong recommendation: Do not assign value of unknown 'x' or check for do not care '-'.Strong recommendation: Do not use default values (or initialization) for signals and variables. Use reset to initialize all signals and variables.Strong recommendation: Do not use ports with type buffer to read output value within the code. Instead use out type and add another variable or signal and assign to it the same output value.Recommendation: Define components and constants for each core in a single package.Good Practice: Do not mix between VHDL coding standards for the whole project (i.e. do not mix between VHDL 87 and VHDL 93 constructs).Good Practice: Try to write one VHDL design unit in one file. The filename should be the same as the unit name. For example entities and architectures are placed in separate files, the same applies for package and package bodies.Good Practice: Try to use instantiation by name (explicit instantiation) and not by place.Good Practice: Try to use configuration to map entities, architectures and components (i.e. to define such mapping explicitly).Good Practice: Try to compile each block in a separate library.Good Practice: Make use of constants and generics for buffer sizes, bus width and all other unit parameters.Coding for SynthesisStrong recommendation: Read variables then write to them (Read before write) unless you know what you are doing.Strong recommendation: Include all signals that are read inside the combination process to its sensitivity list. (i.e. Signals on Right Hand Side RHS of signal assignments or conditions.Recommendation: Avoid using long if-then-else statements and use case statement instead.Strong Recommendation: Do not use statements such as ‘(b <= a after X ns)’ or ‘wait for X ns;’ where X is
View Full Document
Unlocking...