Showing posts with label Guidelines. Show all posts
Showing posts with label Guidelines. Show all posts

Guides for Writing and Presentations and References


Delay Modelling and Coding Guidelines


Inertial delay models only propagate signals to an output after the input signals have remained unchanged (been stable) for a time period equal to or greater than the propagation delay of the model. If the time between two input changes is shorter than a procedural assignment delay, a continuous assignment delay, or gate delay, a previously scheduled but unrealized output event is replaced with a newly scheduled output event.

Transport delay models propagate all signals to an output after any input signals change. Scheduled output value changes are queued for transport delay models.

Modeling Guideline: Do not place delays on the LHS/RHS of blocking assignments to model combinational logic.
Testbench Guideline: Placing delays on the LHS of blocking assignments in a testbench is reasonable since the delay is just being used to time-space sequential input stimulus events, but on RHS is not. Placing a delay on the RHS of any blocking assignment is both confusing and a poor coding style.

Modeling Guideline:
Do not place delays on the LHS of nonblocking assignments to model combinational logic.
Testbench Guideline: Nonblocking assignments are less efficient to simulate than blocking assignments; therefore, in general, placing delays on the LHS of nonblocking
assignments for either modeling or testbench generation is discouraged.

Modeling Guideline:
Place delays on the RHS of nonblocking assignments only when trying to model transport output-propagation behavior. This coding style will accurately model delay lines and combinational logic with pure transport delays; however, this coding style generally causes slower simulations.
Testbench Guideline: This coding style is often used in testbenches when stimulus must be scheduled on future clock edges or after a set delay, while not blocking the
assignment of subsequent stimulus events in the same procedural block.

Modeling Guideline:
In general, do not place delays on the RHS of nonblocking assignments to model combinational logic. This coding style can be confusing and is not very simulation efficient. It is a common and sometimes useful practice to place delays on the RHS of nonblocking assignments to model clock-to-output behavior on sequential logic.
Testbench Guideline: There are some multi-clock design verification suites that benefit from using multiple nonblocking assignments with RHS delays; however, this coding style can be confusing, therefore placing delays on the RHS of nonblocking assignments in testbenches is not generally recommended.

Modeling Guideline:
Use continuous assignments with delays to model simple combinational logic. This coding style will accurately model combinational logic with inertial delays.Use always blocks with no delays to model complex combinational logic that are more easily rendered using Verilog behavioral constructs such as "case-casez-casex", "if-else", etc. The outputs from the no-delay always blocks can be driven into continuous assignments to apply behavioral delays to the models. This coding style will accurately model complex combinational logic with inertial delays.
Testbench Guideline: Continuous assignments can be used anywhere in a testbench to drive stimulus values onto input ports and bi-directional ports of instantiated models.

Conclusions:
Any delay added to statements inside of an block does not accurately model the behavior hardware and should not be done. The one exception carefully add delays to the right hand side of nonblocking assignments, which will accurately model transport delays, generally at the cost of simulator performance.

Adding delays to any sequence of continuous assignments, or modeling complex logic with no inside of an always block and driving the always outputs through continuous assignments with delays, accurately model inertial delays and are recommended coding styles for modeling combinational logic.

General FPGA based design Guidelines


Based on past experience i had with FPGAs...
  • Flip-flops are almost free in FPGAs, the reason is that in FPGAs, the area consumed by a design is usually determined by the amount ofcombinational circuitry, not by the number of flip-flops.
  • Aim for using 80–90% of the cells on a chip, because if you use more than 90% of the cells on a chip, then the place-and-route program might not be able to route the wires to connect the cells. And if you use less than 80% of the cells, then there are optimizations that will increase performance and still allow the design to fit on the chip, or you spent too much human effort on optimizing for low area, or you could use a smaller (cheaper!) chip.
  • Use just one clock signal because if all flip-flops use the same clock, then the clock does not impose any constraints on where the place-and-route tool puts flip-flops and gates. If different flip-flops used different clocks, then flip-flops that are near each other would probably be required to use the same clock.
  • Use only one edge of the clock signal because there are two ways to use both rising and falling edges of a clock signal, they have rising-edge and falling-edge flip flops, or have two different clock signals that are inverses of each other. Most FPGAs have only rising-edge flip flops. Thus, using both edges of a clock signal is equivalent to having two different clock signals, which is deprecated by the preceding guideline.

Design Guidelines and Criteria for Digital Electronics


..apparently these pages on guidelines and criteria, are from NASA. I think this is a very nice article with good amount discussion on critical aspects of Digital Design.

http://klabs.org/DEI/References/design_guidelines/nasa_guidelines/clocks/clocks.htm