Showing posts with label RTL. Show all posts
Showing posts with label RTL. Show all posts

Functionally debug in RTL source using Identify RTL Debugger

The Identify RTL Debugger lets FPGA designers and ASIC prototyping designers to functionally debug their hardware directly in their RTL source code. This allows functional verification with RTL designs 10,000 times faster than RTL simulators, and enables the use of in-system stimulus for applications like networking, audio and video, and HW/SW designs. Identify software allows designers to directly select signals and conditions in their RTL source code for debugging and the results are viewed directly in the RTL source code. The Identify tool can also save results in standard VCD format that can be used with most waveform viewers.

Key Features:
* Allows the designer to insert debug logic and view results directly in the RTL source code.
* Allows FPGA to run at normal design speed, but still allows debug access.
* Allows the designer to set triggers on signals and their values (data path), as well as trigger on RTL code branches such as CASE and IF statements.
* Allows the designer to view the captured data from the FPGA in almost any waveform display. Provides standard VCD output for results.
* Provides VHDL models for waveform data with all the type information and data included allowing the designer to view results in a waveform display complete with all the VHDL type information that they want to see.

SPARK: A Parallelizing Approach to the High-Level Synthesis of Digital Circuits

SPARK is a C-to-VHDL high-level synthesis framework that employs a set of innovative compiler, parallelizing compiler, and synthesis transformations to improve the quality of high-level synthesis results. SPARK takes behavioral ANSI-C code as input, schedules it using speculative code motions and loop transformations, runs an interconnect-minimizing resource binding pass and generates a finite state machine for the scheduled design graph. Finally, a backend code generation pass outputs synthesizable register-transfer level (RTL) VHDL. This VHDL can then by synthesized using logic synthesis tools into an ASIC or can be mapped onto a FPGA.

Boosting RTL Verification with High-Level Synthesis

Instead of prolonging the painful process of finding bugs in RTL code, the design flow needs to be geared toward creating bug-free RTL designs. This can be realized today by automating the generation of RTL from exhaustively verified C++ models. If done correctly, high-level synthesis (HLS) can produce RTL that matches the high-level source specification and is free of the errors introduced by manual coding.

Comparison of VHDL to Other Hardware Description Languages

VHDL Disadvantages
  • VHDL is verbose, complicated and confusing
  • Many different ways of saying the same thing
  • Constructs that have similar purpose have very different syntax (case vs. select)
  • Constructs that have similar syntax have very different semantics (variables vs signals)
  • Hardware that is synthesized is not always obvious (when is a signal a flip-flop vs latch vs combinational)
VHDL Advantages
  • VHDL supports unsynthesizable constructs that are useful in writing high-level models, testbenches and other non-hardware or non-synthesizable artifacts that we need in hardware design.
  • VHDL can be used throughout a large portion of the design process in different capacities, from specification to implementation to verification.
  • VHDL has static typechecking—many errors can be caught before synthesis and/or simulation.
  • VHDL has a rich collection of datatypes
  • VHDL is a full-featured language with a good module system (libraries and packages).
  • VHDL has a well-defined standard.
VHDL and Other Languages
  • VHDL vs Verilog
    • Verilog is a "simpler" language: smaller language, simple circuits are easier to write
    • VHDL has more features than Verilog
      • richer set of data types and strong type checking
      • VHDL offers more flexibility and expressivity for constructing large systems.
    • The VHDL Standard is more standard than the Verilog Standard
      • VHDL and Verilog have simulation-based semantics
      • Simulation vendors generally conform to VHDL standard
      • Some Verilog constructs don't simulate the same in different tools
    • VHDL is used more than Verilog in Europe and Japan
    • Verilog is used more than VHDL in North America
    • South-East Asia, India, South America - More Democratic
  • VHDL vs SystemC
    • System C looks like C —familiar syntax
    • C is often used in algorithmic descriptions of circuits, so why not try to use it for synthesizable code as well?
    • If you think VHDL is hard to synthesize, try C....
    • SystemC simulation is slower than advertised
  • VHDL vs Other Hardware Description Languages
    • Superlog: A proposed language that was based on Verilog and C. Basic core comes from Verilog. C-like extensions included to make language more expressive and powerful. Developed by the Co-Design company, but no longer under active development. Superlog has been superseded by SystemVerilog, see below.
    • SystemVerilog: A language originally proposed by Co-Design and now standardized by Accellera, an organization aimed at standardizing EDA languages. SystemVerilog is inspired by Verilog, Superlog, and System-C. SystemVerilog is a superset of Verilog aimed to support both high-level design and verification.
    • Esterelle: A language evolving from academia to commercial viability. Very clean semantics. Aimed at state machines, limited support for datapath operations.

behavioral & RTL

Multi-cycle functionality:
It is a fundamental characteristic of synthesizable RTL code that the complete functionality of each clocked process must be performed within a single clock cycle. Behavioral synthesis lifts this restriction. Clocked processes in synthesizable behavioral code may contain functionality that takes more than one clock cycle to execute.

The behavioral synthesis algorithms will create a schedule that determines how many clock cycles will be used. The behavioral synthesis tool automatically creates the finite state machine (FSM) that is required to implement this multi-cycle behavior in the generated RTL code.

In a traditional RTL design process, the designer is responsible for manually decomposing multi-cycle functionality into a set of single-cycle processes. Typically this entails the creation of multiple processes to implement the finite state machine, and the creation of processes for each operation and each output.

A behavioral synthesis tool performs this decomposition for the designer. The multi-cycle behavior can be expressed in a natural way in a single process leading to more efficient design specification and debug.

Most algorithms include looping structures. Traditional RTL design imposes severe restrictions on the use of loops, or prohibits them outright. Some RTL logic synthesis tools permit for loops with fixed loop indices only. The loop body is restricted to being executed in a single cycle. Parallel hardware is inferred for each loop iteration.

These restrictions require the designer to transform the algorithm into a multi-cycle FSM adding substantial complexity to the designer's task. Behavioral design manages this complexity for the designer by permitting free use of loops. "While" loops and "for" loops with data-dependent loop indices are fully supported in a behavioral design flow. Loop termination constructs such as the C language "break" and "continue" keywords are permitted.

Memory access:
In general, reading and writing to memories requires complex multi-cycle protocols. In RTL design these are implemented as explicit FSMs. Worse, these accesses must usually be incorporated in an already complex FSM implementing an algorithm.

Behavioral synthesis permits them to be represented in an intuitive way as simple array accesses. An array is declared in the native syntax of the behavioral language in use, tool directives are provided to control the mapping of the array to a physical memory element, and the array elements are referenced using the array indexing syntax of the language. The behavioral synthesis tool instantiates the memory element and connects it to the rest of the circuit. It also develops of the FSM for the memory access protocol and integrates this FSM with the rest of the algorithm.

"Latch" Vs "Flip Flop"

A flip-flop is Edge sensitive: Output only changes on rising (or falling) edge of clock.
A latch is Level sensitive: Output changes whenever clock/Enable is high (or low)

A common implementation of a flip-flop is a pair of latches (Master/Slave flop).

Latches are sometimes called “transparent latches”, because they are transparent (input directly connected to output) when the clock is high.

The clock to a latch is primarily called the “enable”.

For more information have a look at the picture below.

Deprecated Hardware:

  1. Use flops, not latches
  2.  Latch-based designs are susceptible to timing problems
  3. The transparent phase of a latch can let a signal “leak” through a latch — causing the signal to affect the output one clock cycle too early
  4. It’s possible for a latch-based circuit to simulate correctly, but not work in real hardware, because the timing delays on the real hardware don’t match those predicted in synthesis
  1. Limit yourself to D-type flip-flops
  2. Some FPGA and ASIC cell libraries include only D-type flip flops. Others, such as Altera’s APEX FPGAs, can be configured as D, T, JK, or SR flip-flops.
  • For every signal in your design, know whether it should be a flip-flop or combinational. Examine the log file e.g. dc shell.log to see if the flip-flops in your circuit match your expectations, and to check that you don’t have any latches in your design.
  • Do not assign a signal to itself (e.g. a <= a; is bad). If the signal is a flop, use an enable to cause the signal to hold its value. If the signal is combinational, then assigning a signal to itself will cause combinational loops, which are very bad.
If you are looking for code snippets for the following types of hardware, please leave a comment.
  1. Flops with Waits and Ifs
  2. Flops with Synchronous Reset
  3. Flops with Chip-Enable
  4. Flops with Chip-Enable and Mux on Input
  5. Flops with Chip-Enable, Mux's, and Reset

Glitches, Hazards and Lizards

A glitch is a momentary error condition on the output of a circuit due to unequal path delays in a circuit. It is seen as an additional pulse or pulses on the output. Between a time the input signals are settled and the output signals are being established a glitch can occur if there is an hazard(functional or logical).

Glitches due to functional errors can occur when two input signals or more change in values at the same time. It is related to the function that is being implemented and cannot be removed by adding extra circuit.

Glitches due to logical hazard can occur only when one i/p signal changes it value. A logic hazard can be removed by add extra circuit. A logic hazard can be static or dynamic.

Glue Logic

glue logic is the circuitry needed to achieve compatible interfaces between two (or more) different off-the-shelf integrated circuits.

An example of glue logic is the address decoder which with older processors like the 6502 or Z80 had to be added externally to divide up the addressing space of the processor into RAM, ROM and I/O. Newer versions of the same processors (such as the WDC 65816 or Zilog eZ80) instead have internal address decoders so glueless interfacing to the most common external devices becomes possible.

Sometimes, glue logic is used to encrypt the proprietary electronics circuitry by the vendor and to prevent the product from being illegally counterfeited.

Application Specific Integrated Circuit ( ASIC )

An application-specific integrated circuit or ASIC comprises an integrated circuit (IC) with functionality customized for a particular use (equipment or project), rather than serving for general-purpose use.

For example, a chip designed solely to run a cash register is an ASIC. In contrast, a microprocessor is not application-specific, because users can adapt it to many purposes.

The initial ASICs used gate-array technology.

The British firm Ferranti produced perhaps the first gate-array, the ULA (Uncommitted Logic Array), around 1980. Customisation occurred by varying the metal interconnect mask. ULAs had complexities of up to a few thousand gates. Later versions became more generalized, with different base dies customised by both metal and polysilicon layers. Some base dies include RAM elements.

In the late 1980s, the availability of logic synthesis tools (such as Design Compiler) that could accept hardware description language descriptions using Verilog and VHDL and compile a high-level description into to an optimised gate level netlist brought "standard-cell" design into the fore-front. A standard-cell library consists of pre-characterized collections of gates (such as 2 input nor, 2 input nand, invertors, etc.) that the silicon compiler uses to translate the original source into a gate level netlist. This netlist is fed into a place and route tool to create a physical layout. Routing applications then place the pre-characterized cells in a matrix fashion, and then route the connections through the matrix. The final output of the "place & route" process comprises a data-base representing the various layers and polygons in GDS-II format that represent the different mask-layers of the actual chip.

Finally, designers can also take the "full-custom" route in implementing an ASIC. In this case, an individual description of each transistor occurs in building the circuit. A "full-custom" implementation may function five times faster than a "standard-cell" implementation. The "standard-cell" implementation can usually be implemented quite a bit quicker and with less risk of errors, than the "full-custom" choice.

As feature sizes have shrunk and design tools improved over the years, the maximum complexity (and hence functionality) has increased from 5000 gates to 20 million or more. Modern ASICs often include 32-bit processors and other large building-blocks. Many people refer to such an ASIC as a SoC - System on a Chip.

The use of intellectual property (IP) in ASICs has become a growing trend. Many ASIC houses have had standard cell libraries for years. However IP takes the reuse of designs to a new level. Designers of most complex digital ICs now utilise computer languages that describe electronics rather than code. Many organizations now sell tested functional blocks written in these languages. For example, one can purchase CPUs, ethernet or telephone interfaces.

For smaller designs and/or lower production volumes, ASICs have started to become a less attractive solution, as field-programmable gate arrays (FPGAs) grow larger, faster and more capable. Some SoCs consist of a microprocessor, various types of memory and a large FPGA.

So having said, this blog is dedicated to Digital Electronics, VLSI, ASICs, SOCs etc.