Advanced Features

Physical metrics, behavioral modeling, and expert optimization techniques.

Introduction

Beyond functional and electrical modeling, SIMIC provides advanced features for tracking physical design metrics, integrating high-level behavioral models, and optimizing simulation performance. These capabilities support complete design flows from initial concept through physical implementation.

Physical Size Metrics

SIMIC tracks three physical metrics to assist in estimating circuit size and resource requirements. These metrics are automatically totaled during compilation and reported with circuit statistics.

Supported Metrics

Syntax

Physical metrics can be placed in any PART or TYPE statement:

PADS=<integer>
TRANS=<integer>
WIDTH=<integer>

Example: Standard Cell Methodology

* Define cell with physical metrics:
type=full-adder i=ia,ib,c-in o=sum,c-out trans=26 width=50

* Instantiate four times in a four-bit adder:
type=four-bit i=a[3:0],b[3:0],carry-in o=s[3:0],carry-out

p=a0 t=full-adder i=a[0],b[0],carry-in o=s[0],c[0]
p=a1 t=full-adder i=a[1],b[1],c[0] o=s[1],c[1]
p=a2 t=full-adder i=a[2],b[2],c[1] o=s[2],c[2]
p=a3 t=full-adder i=a[3],b[3],c[2] o=s[3],carry-out

SIMIC reports accumulated totals:

>>: get type=four-bit

Main Get Network : FOUR-BIT
GET completed, Circuit totals: Parts = 21; Signals = 32
Inputs = 9; Busses = 0; Outputs = 6

Physical Totals:
    Width = 200
    Transistors = 104

Methodology Guidelines

Standard Cell Designs: Place metrics in TYPE statements for each cell. PART statements should not contain them. SIMIC totals reflect physical contributions of all instantiated cells.
Custom Designs: TYPE statements can contain metrics for the smallest cell variant. PART statements can specify deltas from the base values for specific instances (e.g., sizing variations).

Behavioral Modeling

For complex algorithms, microprocessors, or custom timing models, SIMIC supports behavioral descriptions written in C, Python, or compiled into shared libraries. This provides the highest level of abstraction.

Behavioral Abstraction Level

The BEHAVIORAL abstraction level sits alongside MACRO, BOOLEAN, and PRIMITIVE in the SIMIC hierarchy.

type=custom_processor i=clk,reset,data[31:0] o=result[31:0],ready $ model=processor_sim.so

The model keyword specifies the external behavioral model file (shared library or script). SIMIC loads this model and interfaces it with the circuit netlist.

When to Use Behavioral Models

Development Flow: Start with behavioral models for early system verification, then progressively replace with gate-level implementations as the design matures.

Model Selection with COMPOSITION

When multiple implementations of a component exist at different abstraction levels, the COMPOSITION keyword explicitly selects which variant to instantiate.

Abstraction Search Order

Without explicit specification, SIMIC searches for type definitions in this order:

  1. MACRO - Gate-level structural description
  2. BOOLEAN - Behavioral functional equations
  3. BEHAVIORAL - High-level external model
  4. PRIMITIVE - Built-in SIMIC element

Explicit Selection

* Force behavioral variant:
p=cpu1 t=processor i=clk,reset o=addr,data composition=behavioral

* Force macro (gate-level) variant:
p=cpu2 t=processor i=clk,reset o=addr,data composition=macro

Variant Management Strategy

Place variants at the same abstraction level in separate files, then select using GET FILE: 

>>: get type=alu file=alu_fast.net       $ Fast variant
>>: simulate

>>: get type=alu file=alu_lowpower.net  $ Low-power variant
>>: simulate
Warning: Defining a MACRO or BOOLEAN with the same name as a SIMIC primitive is poor practice. Always use COMPOSITION=PRIMITIVE to ensure the built-in is used when needed.

Performance Optimization

For large designs, simulation performance depends on abstraction choices, model complexity, and compilation strategies.

Abstraction Trade-offs

Abstraction Simulation Speed Timing Accuracy Best For
BEHAVIORAL Fastest Approximate Early system verification
BOOLEAN Fast Functional only Logic verification
MACRO Moderate Detailed Pre-silicon validation
Transistor-level Slow Most accurate Critical path analysis

Optimization Techniques

1. Hierarchical Compilation

Compile large subcircuits separately and reuse compiled versions:

>>: get type=cpu file=cpu.net save
>>: get type=system file=system.net   $ References precompiled CPU

2. Selective Abstraction

Use gate-level detail only where needed, behavioral models elsewhere: 

* Critical timing paths at gate level:
p=datapath t=alu composition=macro

* Non-critical blocks at functional level:
p=control t=controller composition=boolean

3. Incremental Simulation

Leverage checkpoint/restart for long test sequences:

>>: simulate
>>: checkpoint file=midpoint.chk
>>: continue                $ Resume from checkpoint if needed

4. Event-Driven Optimization

Mixed-Abstraction Design Example

A system-on-chip verification testbench using multiple abstraction levels:

!BEHAVIORAL
* High-level processor model for fast simulation:
type=arm_core i=clk,reset,irq b=axi_bus composition=behavioral $
    model=arm_iss.so

!LOGICAL
* Top-level SoC with mixed abstractions:
type=soc i=clk,reset o=gpio[31:0] b=ddr_bus

* CPU at behavioral level (fast):
p=cpu t=arm_core i=clk,reset,irq b=axi

* Critical peripheral at gate level (accurate timing):
p=uart t=uart_16550 i=clk,reset,axi.addr,axi.data composition=macro

* Simple peripherals at functional level:
p=timer t=timer_block i=clk,reset composition=boolean
p=gpio t=gpio_block i=clk,reset o=gpio composition=boolean
Verification Strategy: Start with all behavioral models for bring-up, then progressively swap in gate-level implementations as RTL stabilizes. Run final gate-level simulations only on critical tests.

Best Practices

Physical Metrics

Behavioral Models

Abstraction Management