L16 FPGA Technology III

References

• † Some slides (blue-frame) developed by Jim Plusquellic
• ‡ Some images credited from Book: Maxfield, Clive. The design warrior’s guide to FPGAs: devices, tools and flows. Elsevier, 2004.

Mux vs LUT (repeat)

Mux

• Any logic can be built from only muxes when “1” and “0” inputs are also available.
• For review: implement (a ^ (~b) ) using a 2-input mux
  

LUT

• The depicted transmission gates are basically switches implemented with FETs.

LUT as RAM (LUTRAM)

• LUTRAM: Basically, memory functionally can be used instead of use as a logic:
  

• As described,LUT is more versatile for feature expansion than Mux:
  

Heirarchy: LC, Slice, CLB

• FPGA IC designers have to design local and global routing (and switches) and decide how much space to allocated to each

Complex Logic Block Cells (repeat)

• the CLB used in the XC4000 series of Xilinx FPGAs. This is a fairly complicated basic logic cell containing 2 four-input LUTs that feed a three-input LUT. The XC4000 CLB also has special fast carry logic hard-wired between CLBs. MUX control logic maps four control inputs (C1–C4) into the four inputs: LUT input H1, direct in (DIN), enable clock (EC), and a set / reset control (S/R) for the flip-flops. The control inputs (C1–C4) can also be used to control the use of the F’ and G’ LUTs as 32 bits of SRAM.

“Hard” IP vs “Soft” IP vs “Firm IP” (repeat)

• Soft IP or a soft hardware core is “compiled hardware” programmed into the FGPA
• Sometimes it is not possible or best to implement required hardware as a “soft” hardware core
• Factors for inclusion of hard IP core as a market advantage:
  • Does a Hare IP represent significant performance advantage over soft IP?
  • Sometimes implementation in the FPGA fabric is too big, slow, etc…
  • Is a soft implementation not possible and is outside the bound of performance programmable fabric can achieve: e.g. high-speed IO
  • Would multiple customers would utilize it? meaning sufficient market demand
  • Cost – what area does is consume and how much does it negatively impact the overall FPGA performance?
• Sometimes, we will characterize specialized hardware as a feature added to the programmable fabric (e.g. carry-chain adder support) or a separated hardware like high-speed IO
• A common characteristic of any specialized hardware on FPGAs is some level of configuration. e.g. high-speed IO hardware should at least support different rates, voltage levels, etc….

Block RAM (repeat)

RAM / ROM with FPGA Designs

In addition to registers, there are three primary choices for implementation of large memories:

1. Register Memory Slice/Logic Blocks have a number of inbuilt slice registers (slice is a Xilinx term)

   • fast
   • allows collocating memory and computation
   • can reduce routing
   • can serve as a local buffer for block RAM and external memory
   • DISADVANTAGE: limited number available

2. Distributed RAM

   • LUT (normally used for logic) or any other memory within a configurable cell used as a distributed RAM
     • LUTRAM: LUT as used RAM
   • fast
   • allows collocating memory and computation
   • can reduce routing
   • can serve as a local buffer for block RAM and external memory
   • DISADVANTAGE: consumes resources for otherwise used for logic implementation

3. Block RAM

   • High-Density Dedicated RAM
   • less flexible
   • limited access, e.g. dual read port allows reading only two-values at a time
   • may require large routing and/or copying contents repeated to/from distributed RAM for many types of computations
   • may have registered and non-registered (e.g. for large combinatorial LUT) options

4. External RAM

   • large capacity SDRAM (synchronous DRAM) can be used off-chip
   • large memory applications require this
   • route and multiplex, cache into local memory
   • usually a synthesized or HARD memory controller for interfacing with memory is available on an FPGA platform

Depiction of small region of an FPGA with Block RAM and and Slices with LUTs:

Example Report Showing LUT used as Memory, and Block Ram utilization:

...

1. Slice Logic
--------------

+----------------------------+-------+-------+------------+-----------+-------+
|          Site Type         |  Used | Fixed | Prohibited | Available | Util% |
+----------------------------+-------+-------+------------+-----------+-------+
| Slice LUTs*                | 18777 |     0 |          0 |     20800 | 90.27 |
|   LUT as Logic             | 18629 |     0 |          0 |     20800 | 89.56 |
|   LUT as Memory            |   148 |     0 |          0 |      9600 |  1.54 |
|     LUT as Distributed RAM |   148 |     0 |            |           |       |
|     LUT as Shift Register  |     0 |     0 |            |           |       |
| Slice Registers            | 17050 |     0 |          0 |     41600 | 40.99 |
|   Register as Flip Flop    | 16916 |     0 |          0 |     41600 | 40.66 |
|   Register as Latch        |   134 |     0 |          0 |     41600 |  0.32 |
| F7 Muxes                   |   671 |     0 |          0 |     16300 |  4.12 |
| F8 Muxes                   |    30 |     0 |          0 |      8150 |  0.37 |
+----------------------------+-------+-------+------------+-----------+-------+

...
 
2. Memory
---------
+-------------------+------+-------+------------+-----------+-------+
|     Site Type     | Used | Fixed | Prohibited | Available | Util% |
+-------------------+------+-------+------------+-----------+-------+
| Block RAM Tile    | 36.5 |     0 |          0 |        50 | 73.00 |
|   RAMB36/FIFO*    |   36 |     0 |          0 |        50 | 72.00 |
|     RAMB36E1 only |   36 |       |            |           |       |
|   RAMB18          |    1 |     0 |          0 |       100 |  1.00 |
|     RAMB18E1 only |    1 |       |            |           |       |
+-------------------+------+-------+------------+-----------+-------+

...

Block Ram:

Global view highligting used cells:

Enlarged View the same with individual BMEM cells outlined next to the areas of programmable fabric:

Sync/Async Reads

• on Xilinx, distributed RAM reads are asynchronous

  • although, either
    output registers
    or
    input address/data/control registers
    can be added to a design to achieve synchronous behavior

  Distributed RAM versus Dedicated Block RAM:

  Action	Distributed RAM	Dedicated Block RAM
  Write	Synchronous	Synchronous
  Read	Asynchronous	Synchronous

• this means that LUTRAM can be used like combinatorial logic

  • can be cascaded with other combinational logic and other LUTRAMs to perform operations in one cycle

Memory Inference Capabilities

(xilinx:)
Memory inference capabilities include the following:
https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/Choosing-Between-Distributed-RAM-and-Dedicated-Block-RAM

• Support for any size and data width. Vivado synthesis maps the memory description to one or several RAM primitives
• Single-port, simple-dual port, true dual port
• Up to two write ports
• Multiple read ports

Provided that only one write port is described, Vivado synthesis can identify RAM descriptions with two or more read ports that access the RAM contents at addresses different from the write address.

• Write enable
• RAM enable (block RAM)
• Data output reset (block RAM)
• Optional output register (block RAM)
• Byte write enable (block RAM)
  • ability to mask writes, updating only some bytes of a register
• Each RAM port can be controlled by its distinct clock, port enable, write enable, and data output reset
• Initial contents specification
• Vivado synthesis can use parity bits as regular data bits to accommodate the described data widths

Dual-Port RAM

(https://docs.xilinx.com/r/en-US/ug958-vivado-sysgen-ref/Dual-Port-RAM)

Modes for how synchronous writes affect reads from the same address in the same cycle

(based on Xilinx documentation)

1. Read-first (old data read)
   When a read and a write occur at the same address, old content is read before new content is loaded.
2. Write-first (new data read)
   • data written is immediate available in the same cycle for read
   • also known as read-through.
3. No-change
   • active data write prevents read data output updates
   • must be followed by explicit read operation in a following cycle to see the result

RAM/ROM Coding and Intialization

• In addition to using IP blocks, RAM and ROM types can be inferred from standard HDL which has the benifit of universally working with various design and verification tools

• Specification of stored values for ROM or initial values for RAM is handle with various methods

• Be sure to check tool documentation for recommended coding styles and vender-specific pragmas that can be used to control memory inference

• Specifying ROM Values directly in code

  • Here values are providd in the verilog code

    module rom_8x16b (dout, addr, clk);
      input clk;
      input [2:0] addr;
      output [15:0] dout;
      reg [15:0] dout;
    
      always @(posedge clk) begin
        case (addr)
           0: dout <= 16'd0;
           1: dout <= 16'd1;
           2: dout <= 16'd4;
           3: dout <= 16'd9;
           4: dout <= 16'd16;
           5: dout <= 16'd25;
           6: dout <= 16'd36;
           7: dout <= 16'd49;
        endcase
      end 
    endmodule
    
    

  • Here values are initiazed in the verilog code

    module rom_8x16b (dout, addr, clk);
    input clk;
    input [2:0] addr;
    output [15:0] dout;
    reg [15:0] ram [0:3];
    reg [15:0] dout;
    
    initial begin
      ram[0] = 16'd0;
      ram[1] = 16'd1;
      ram[2] = 16'd4;
      ram[3] = 16'd9;
      ram[4] = 16'd16;
      ram[5] = 16'd25;
      ram[6] = 16'd36;
      ram[7] = 16'd49;
    end 
    
    always @(posedge clk)
    begin
      dout <= ram[addr];
    end 
    endmodule
    

• RAM: Here values are initialized using an external file read using native Verilog features
  Source https://docs.amd.com/v/u/2014.4-English/ug901-vivado-synthesis

  // Initializing Block RAM from external data file
  // Binary data
  // File: rams_20c.v
  module v_rams_20c (clk, we, addr, din, dout);
    input clk;
    input we;
    input [5:0] addr;
    input [19:0] din;
    output [19:0] dout;
    reg [19:0] ram [0:63];
    reg [19:0] dout;
  
    initial begin
      $readmemh("v_rams_20c.data",ram);
    end
  
    always @(posedge clk)
    begin
      if (we)
        ram[addr] <= din;                     
      dout <= ram[addr];
    end 
  endmodule
  

• Using vendor-specific memory content file specification

  simple .coe file

  memory_initialization_radix=2;
  memory_initialization_vector=1111 1111 1111 1111 1111 0000 0101 0011 0000 1111 1111 1111 1111 1111 1111 1111;
  

  specificed in gui
  

  • Vendor tools will also support combining a presynthesized design configuration file with a memory contents file to create a final bitstream without having to reimplement the design with each respecification of initial memory contents

Hardware Multipliers (repeat)

• Many FPGA include large number of dedicated hardware blocks for multipliers (18x25)

Accumulators and MAC (repeat)

• In DSP and ML, common to perform dot products, point by point multiply of two series of numbers followed by sum
  • dot product of two vectors: $A_1 \cdot B_1 + A_2 \cdot B_2 + A_3 \cdot B_3$
  • FIR filter: $\text{a} \cdot 0.5567 + \text{a\_prev} \cdot 0.25325 + \text{a\_prev\_prev} \cdot 0.1255$
• MAC: Multiply-Accumulate
• Adder and Accumulator Register alongside hardware multipliers support DSP operations (and these days we might say Machine Learning).

DSP slices (Xilinx)

source: https://docs.amd.com/r/2021.2-English/ug1483-model-composer-sys-gen-user-guide/DSP48E1

The Xilinx DSP48E block is an efficient building block for DSP applications that use supported devices. The DSP48E combines an 18-bit by 25-bit signed multiplier with a 48-bit adder and programmable mux to select the adder’s input.

Embedded Processors (repeat)

Support Implementation of processing using traditional software (C code)

• Hard-Processor: dedicated silicon hardware, ARM is a very popular option
  • Good for high-performance general code execution
• Soft-Processor: Customizable Processor synthesized and programmed into the configurable fabric
  • Can be specialized to fit needs, optional program/memory cache, hardware multiplier, hardware break points for debugging
  • Can instantiate many soft processors as needed

General Purpose IO (repeat)

• I/O is organized into banks
• Typically banks can be driven with separate power-supply voltages from the core voltage VCCCORE and each other
• Configurable Voltage Standard (requires correct corresponding power-supply voltage VCCIO)
• Configurable pull-up/down resistance
• Configurable Slew-rate (Drive Strength)
  • Fast Slew supports fast signaling
  • Slow Slew limit high-frequency effects like reflections
• Differential Pair
• Configurable connection to High-Speed I/O hardware
• Some pins support direct configurable input to clock network (should not just route clock to any pin)
• Configurable Termination Resistance for Transmission Line Interfaces

Gigabit Transceivers (repeat)

• Hard IP Gigibit Transceivers support serialization of parallel-bit data words to a high-speed serial data-stream, and de-serialization to reconstruct the parallel bits in a lower-freqeuncy clock domain

• Serialization: parallel-load in FPGA slow clock domain, serial send at high-speed

• Deserialization: high-speed serial receive, parallel-unload

• Support one or more communication lanes: high-speed differential signaling pairs (pos and neg)

• Commonly have multiple transceivers per block to support multiple synchronized
  channels.

• Support for PCI, Ethernet,DVI/HDMI, etc…

What needs to be configured? (repeat)

The bitstream contains the data that is loaded to configure the FPGA.
this includes

• IO pin configuration
• Routing
• Logic Cells
  • LUT contents, configuration
  • if LUTRAM – each can be initialized at start-up (post-config) to to 1s or 0s
  • mux controls and io connections
  • FF/latch sensitivity (rising or falling edge or high or low level
• post-configuration, startup values of FF
• Any configurations bits for Hard IP

Configuration Files

FPGA Configuration

• JTAG

  • standard named after the Joint Test Action Group that codified the standard
  • industry standard for testing and configuration of ICs and PCBs
    
  • Test Access Port (TAP) Controller’s state machine

    • a standardize 16-state state machine definines interaction with debugger/programmer modules using standard commands

      • for more detail see: https://support.xilinx.com/s/article/3203?language=en_US
      

      https://support.xilinx.com/s/article/3203?language=en_US

Clock Trees and Clock Managers Overview (repeat)

• Clock network: Flip-Flop (FF) clock inputs are driven by special dedicated buffering circuity  and routing lines for clocks with the primary purpose to ensure minimal clock skew within a clock domain
  • Clock skew is the difference in clock edge arrival times at different endpoints (Ffs)
  • A clock domain is characterized by the set of FFs connected to a given clock signal (and the associated combinatorial circuity connected to it)
• Several pins with special clock circuitry are designated per chip (designated as “global” clock input pins) as best for clock input
• Special Configurable circuits, generally called clock managers on some FPGAs, allow for
• generation of faster and slower clocks from input clocks, changing clock delays, removing jitter (cycle-to-cyle variation), and clock recovery from high-speed serial data that is input to the FPGA without a clock signal, etc…

Clock Tree and Manager Features Details (mentioned earlier)

• Several pins with special clock circuitry are designated per chip (designated as “global” clock input pins) as best for clock input
• Multiple clock input pins can be used and multiple clock domains can exist
• Alternatively, many daughter clocks might be generated from one master clock using a clock manager creating multiple clock domains
• Each generated daughter clock might have a different configurable rate and phase lag (delay)

(crop to image:)

• Daughter clocks will drive different clock trees or even off-chip (board-level or system-level) circuity through buffers located near output pins

• Clock managers can “clean” input clock signals by with jitter removal, which is defined as the variation in inter arrival times of clock edges

  

• Frequency Synthesis is the capability of clock manager to create daughter clocks with frequencies that are rational fractions (eg 1x ,2 x,1/2 x, 4/5 x) of the master input clock frequency

  

• Phase shifting is the ability to generate clocks with defined relative delays (inverted (180 degrees) and 90 degree offsets are common)

  

• Autoskew Correction: the ability to detect and adjust individual daughter clock delays on-line using feedback and measurement of the clock near an endpoint. In particular use of off-chip board-level feedback accounts for unknown board loads and is used for high-speed memory interfaces

  

• “Analog” Phase Locked Loops (PLLs) and “Digital” Delay-Locked Loops are two circuit variants for frequency synthesis and phase/skew adjustment. The difference is outside the scope of this lecture and involves characteristics of precision, stability, and noise.

Sample Listing of FPGA Features (repeat)

Text/table/image contents from https://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf

FPGA is more than a sea-of-gates (repeat)

• FGPAs are programmed with software, though we want to think of it as hardware for most design purposes in this class

  • HDLs are software programming languages whose functionality is mapped to a hardware implementation
  • don’t think of the FPGA as “running” the code or as a simulator
  • want to consider the hardware the HDL code maps to

• At a high-level, an FPGA is like a “sea of gates” that we wire up but there are nuances that make some functionality descriptions map to better implementations

  • Nuances to the “sea of gates” generalization include
    • Dedicated carry-chain support between blocks, dedicated hardware Multipliers and DSP Slices and other HARD IP CORES, Block RAM vs Distributed (LUT) RAM
    • Understanding of limited dedicated clock routing and clock domains
    • Increasing role of soft and hard processors in FPGA design
    • Understanding of additional FPGA features like high-speed IO

• A regular processes early in ASIC physical design is to estimate the size based on “design complexity”

• In ASICs, “design complexity” is mainly quantified by a design’s “gate count” which is used to estimate the required chip size

  • A gate is not well-defined, but but for the purpose of the estimate it could be defined as a 2-input nand gate equivalent
  • The complexity could also be measured by “transistor count” and divided by 4 to generate an equivalent nand-gate count
  • The combinatorial circuit could be distinguished from the sequential elements resulting in an estimate based on combinatorial “gate count” and sequential “register count”

• FPGAs don’t actually directly implement gates.

  • Instead they provide another manufacturer specific functional blocks (e.g. logic cells/logic blocks/slices) and provide an average equivalent gate count to help estimate the supported design complexity
  • This feature measure (e.g. # of logic cells) along with the other specialized features listed on a product sheet (help consumers understand the comparative size and capabilities of the various FPGAs sold by that manufacturer

• FPGA features to consider when estimating design “size”:

  • Number of logic cells/logic elements/things equiv. to 4-input LUTs+LATCHES+ETC
  • Count and Size of embedded RAM blocks (block RAM)
  • embedded multipliers – sometimes marketed as DSP blocks/slices or multiply-accumulate (MAC) blocks
  • hard-embedded adders (accumulators)
  • Number of any other special hardware that represents a significant equivalent gate count for your design

IP-Centric Design

• Considering early slides for examples of common IP cores.
  • Building block approach tasks a designer with understanding existing micro and macro blocks and augmenting with minimal custom design
• Hard IP Cores vs Soft IP Cores
  • Hard IP Cores – hardware built into FPGA
  • Soft IP Cores – Typically not Pre-synthesized Module to reside in the FPGA fabric, often highly-customizable
• Firm IP Cores
  • Soft IP Typically Presynthesized,
  • potentially already partial mapping, placement, contrains set, etc., less ability to customize
• Encrypted IP Unplaced and unrouted
  • encrypted netlist provided
  • Functional simulation model provided
  • Placed and routed
    • encrypted netlist with placement provided already mapped to LUTs
    • Design is already tweaked and may include placement of pins, otherhard IP cores
  • Functional simulation model provided (not to be used for synthesis)

SoC Design (repeat)

Soft Processor Development

• A soft- or hard-processor facilitate running traditional sequential code
• A Soft Processor is a compiled, customizable processor (not to be confused with fixed processors sometimes provided on FPGAs)
• cannot be seen by looking at the FPGA silicon
• examples of options and parameters:
• cache size, #bits,
• on-FPGA RAM,
• external RAM controller
• branch prediction…
• Some offer even more features typical
• on microcontrollers like
• SPI (serial peripheral interface)
• pulse width modulators
• Custom instructions
  • hardware accelerate frequently executed code
• IDE provides
  • editor,
  • debugging gui,
  • on-chip debugging, variable monitoring
  • code alteration, and execution control
  • Advanced features like on-the-fly hardware break-points depend on processor configuration

Configuration and Loading

A Typical SoC-FPGA-based System

• Most basic user interface is a terminal hosted on PC but interaction with host software written in Python, C++, Matlab, Labview, etc… is common too.
• USB, USB-JTAG, and Ethernet would be the most typical conduits

Modern SoC-Centric Design Software

• Whereas previous FPGA developent software approaches considered a processor as one component in a design, modern approaches view the processor as the central element and additional logic as an addon
• Emphasiszes SOC,
  • Processor and IP-Centric Design (maximaly using pre-built cores)
  • co-development of C/C++ (soft procesors) and other IP-based design

High-Level C/C++ -like Design Flow

• One of the problems with HDL, specifically RTL, is that the design time is very long. Updating the code can be time consuming. Verifying the code can be time consuming. This limits design iterations and therefore the ability to make high level optimizations or explore different designs.
• High level languages aim to solve this problem, but hiding the concepts of parallelism and timing is difficult. Hiding the issue or having users unaware of them is problematic.
• Functional simulation is an inherent feature of sequential code approaches and typically runs very fast. (compiling of C and execution of code is the functional validation of the code)
• To produce hardware from software either a to-HDL or direct-to-hardware path can be taken.
  

Hardware Implications in Coding

• Hardware resources with optimizations: A*9 vs A<<3+A

  • Verilog allows more control over hardware description and C, but experiment with various implementations and check the RTL to learn what to and how much to expect from your synthesizer.

• Resource sharing

  Key resource sharing hint is assignment to the same named value
  Xilinx Recommends
  verilog Y = (B>C) A+B:A+C
  If in a statemachine,
  assign to the same named reg from different states.

  S1:  temp = A+B;
  S2:  temp = B+C;
  

  

  The Design Warror's Guide to FPGAs, ISBN 0750676043, Copyright© 2004 Mentor Graphics Corp

• Priority structures

  • Mutually exclusive condition matching implies that the progation test is self-contained in each conditional expression

  • Priority structors refer to cascade or redundancy of logic, can’t infer logic of each test from a single conditional expression

    

    The Design Warror's Guide to FPGAs, ISBN 0750676043, Copyright© 2004 Mentor Graphics Corp

  • if statements with simplest condition expressions may be recommended for coding priority structors while case (switch) statements for non-priorty

• Latch/memory inferences

  • for C to hardware, the partitioning of a set of operations defines accross cyles defines what is a memory and what is just a wired output of a combinational circuit
  • uncovered conditions in iterative code can lead to unintended memories

• If using C/C++ to synthesize hardware, check documentation on pragmas to control hardware synthesis

Embedded Processor-Centric Design Flow

• If processor running sequential code makes sense, it can be added to a design which allows directly integrating software in an FPGA Design
• Hard vs soft processor cores
  • Today ARM processors are commonly found in FPGAs – hard processor
  • Customizable processors can also be synthesized – soft processors
• Hardware/Software Partitioning
  • Control vs processing
  • Processing speed
  • Lots of high speed parallel timing required vs multiplexing hardware
  • Ease of coding

Hardware Software Codesign

The Design Warror's Guide to FPGAs, ISBN 0750676043, Copyright© 2004 Mentor Graphics Corp

DSP Design Flows

• Centered around Commonly used blocks and techniques
• Emphasize use of
  • dedicated hardware macro blocks, FFT, DSP cores
  • dedicated low-level hardware features (e.g. carry add-logic)
• Data Flow Programming: Specialized description tools (DSP-block-level diagramming provided in Labview, Simulink, etc…) e.g. draw pictures
• Floating-point versus fixed-point often becomes topic in DSP hardware implementation

Silicon Virtual Prototyping

• FPGA design can be a useful part of and ASIC Design Flow
• FPGAs as prototyping:
  • Ability to implement hardware design in system and perform in-system design test
• Cost of FPGA tools is much less
  • Ability to design with cheaper tools first
• Iterations can be over hours vs days or weeks or even months for a silicon rerun

Board and multi-FPGA development

• Some modern tools handle synthesis to multiple FPGAs and handle modeling of components in a verity of languages including C
• Working with multiple clocks, data serialization and deserialization, delay modeling, and constraints become more critical

Concluding Points on Developement Flows

• As synthesizers improve, less dependence on the coding style may be possible.
  • General conversion of of C-like software without regard to hardware or how synthesizers work might still lead to an optimal solution
• Reliance on IP blocks (predesigned blocks) is increasing. Goal of some high-level design tools and synthesizers is to allow designer to use them.
• Hardware isn’t best for everything, can use general purpose processors.
  • Hardware software design is becoming increasingly important with many soft and hard processor cores available as options