Home‎ > ‎

Top down design with free form logic

Top down design involves creating a higher level block first and then creating the lower level blocks inside the higher level block. Then the designer goes into each of the lower level blocks and creates the next lower level blocks. The designer keeps going down till he arrives to a block that he does not need to expand any further. These blocks are called the leaf level blocks. When all the leaf level blocks are defined, the hierarchy of the design essentially has been solidified. This works very well when the architecture relatively well defined or have already been proven through existing working chips.

A leaf level block will have to be connected to other leaf level blocks. These connections may be confined within the same parent block or could span across several levels of hierarchy. Once connections are all defined, it also defines the ports of the leaf level blocks. This is very convenient for the leaf blocks that are to be developed subsequently. The designers of the leaf level blocks can then be handed with an empty Verilog module that is populated with the ports so that the designer can start on the leaf block. Meanwhile, the RTL for the parent modules can be produced in parallel based on the connectivity information. These leaf modules are termed as free form logic since the actual logic comes after the port definition is firmed up.

Once the leaf block designer is done with RTL implementation of the desired function then the leaf block just fits without any hiccups. Instead of the leaf level block designer providing the port details to the chip integrator or the top level designer, the top level designer or the chip architect provides the port details to leaf level block designer. For some organizations this methodology offers better productivity.

Connecting the free form logic blocks in a chip or SoC to develop port definitions could involve many wires. Connecting them manually could be tedious and error prone. However if we use protocol based connections, we can make the task quite simple.

So, what really is a protocol based connection? >>

Composer IDE simplifies the entire process of top down design for your team with it's SoCBuilder language. You can easily create the free form logic blocks. Connecting the free form blocks with protocol based connection is quite straight forward. The Composer will create the Verilog RTL of the top level and all the intermediate levels for your design in a push button effort. The IDE will also generate the Verilog with all the ports for the leaf level blocks that are free form logic. You can hand them to your leaf level block designers without worrying about it's quality.

Let us examine an example SoC called orion. The chip architect has decided on the following architecture.


Examining the diagram we can conclude that the hierarchy will look like the following, where the blocks with blue background represent the leaf objects. 
    orion : {
        comm : {
             gpio_ctl 
             uart_ctl 
        }
         padring 
        proc : {
             intr_ctl 
             bridge 
             proc 
        }
        storage : {
             sram_ctl 
             dma 
             sdio_ctl 
             sram_ctl 
             sdram_ctl 
        }
    }
In Composer IDE we will declare all the leaf modules as free form logic blocks as following,

SoCBuilder code

glue logic gpio_ctl;
glue logic uart_ctl;
glue logic padring;
glue logic intr_ctl;
glue logic bridge;
glue logic proc;
glue logic sram_ctl;
glue logic dma;
glue logic sdio_ctl;
glue logic sram_ctl;
glue logic sdram_ctl;

The following code exemplifies how we would connect the leaf modules to hook up the IPB and SPB bus signals.

SoCBuilder code

// connect ipb masters
route ipb as dma_ipb_bus from dma to bridge;
route ipb as proc_ipb_bus from proc to bridge;

// connect ipb slaves
route ipb as sram_ipb_bus from bridge to sram_ctl;
route ipb as sdram_ipb_bus from bridge to sdram_ctl;
route ipb as sdio_ipb_bus from bridge to sdio_ctl;

// connect spb slaves
route spb as intr_spb_bus from bridge to intr_ctl;
route spb as dma_spb_bus from bridge to dma;
route spb as uart_spb_bus from bridge to uart_ctl;
route spb as gpio_spb_bus from bridge to gpio_ctl;
route spb as padring_spb_bus from bridge to padring;
...
...

As you can see, we have used protocol based connections in the above code. For instance, we hooked up the entire SPB bus between bridge and interrupt controller with a single statement. The SPB bus consists of the following signals yet we did not have to hook them up individually,
  • spb_active_n
  • spb_address[15:0]
  • spb_write_en
  • spb_read_data[7:0]
  • spb_write_data[7:0]
  • spb_done

We will define all the IO pad connections to the chip boundary by exporting the protocol based connectivity as shown in the following,

SoCBuilder code

export interface gpio as pad_gpio1 and route from padring;
export interface gpio as pad_gpio2 and route from padring;
...
...
export sdio as pad_sdio and route from padring;
export sdram as pad_sdram and route from padring;
...
...

But we havent defined the hierarchy yet. We can define the hierarchy by arranging the leaf modules in a hierarchy statement as shown in the following code,

SoCBuilder code

hierarchy {
    comm : {
        gpio_ctl 
        uart_ctl 
    }
    padring 
    proc : {
        intr_ctl 
        bridge 
        proc 
    }
    storage : {
        sram_ctl 
        dma 
        sdio_ctl 
        sram_ctl 
        sdram_ctl 
    }
}

The above code will take care of creating all the hierarchical levels and route all the signals through the levels between the leaf modules. The Verilog code for the leaf modules with ports will also be generated. For instance the Verilog code generated for the padring showing the ports are show below. You can see the signals for the SPB bus correctly expanded in the Verilog code by Composer. At this point you can simply hand off the Verilog code files to the leaf level block designers.

Verilog code

module padring (
  padring_spb_address,
  padring_spb_write_en,
  padring_spb_read_data,
  padring_spb_active_n,
  padring_spb_done,
  padring_spb_write_data,
  storage_sdram_int_cs_n,
  storage_sdram_int_ba,
  storage_sdram_int_clk_en,
  storage_sdram_int_a,
  storage_sdram_int_dq_in,
  storage_sdram_int_dqm,
  ...
  ...
  pad_sdio_dat,
  pad_sdio_cmd,
  pad_sdio_clk,
  pad_sdram_cs_n,
  pad_sdram_ba,
  pad_gpio1_io,
  pad_gpio2_io,
  ...
  ...
);

  input [15:0] padring_spb_address;
  input  padring_spb_write_en;
  output [7:0] padring_spb_read_data;
  input  padring_spb_active_n;
  output  padring_spb_done;
  input [7:0] padring_spb_write_data;
  input  storage_sdram_int_cs_n;
  input [1:0] storage_sdram_int_ba;
  ...
  ...

/* @@BEGIN_GLUE_BODY@@ */

/* @@END_GLUE_BODY@@ */
endmodule //padring

What happens if we need to change the hierarchy?

Composer IDE provides an easy way to accomplish this without changing any of your existing SoCBuilder code except only the hierarchy statement.

Adjust RTL hierarchy to meet your need >>

Composer IDE is packed with even more capabilities to improve chip design productivity. Contact us to arrange for a demo to go over the full capability of Composer IDE.