Imperative Function Translation to Parameterized Hardware

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing tools lack an effective method to translate imperative-language functions into parameterized hardware components, as they fail to distinguish between formal function arguments intended as component inputs and parameters, limiting the practicality of translating templated functions into hardware.

Innovation Solution

A method that uses formal imperative function arguments to represent both component inputs and parameters, distinguishing between them to generate hardware components that can be instantiated, combined, and simulated, allowing for dynamic operation selection and masking of unnecessary output ports.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional HDL parameterization mechanisms are used, then hardware components can be parameterized to implement ranges of functionality, but the translation from imperative-language functions remains impractical due to lack of distinction between formal arguments as inputs versus parameters

Engineering Contradiction:

Improveparameterization capabilityVSAvoidtranslation practicality

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent introduces a formalism as an intermediary layer between imperative-language functions and HDL parameterization. This formalism serves as a mediator that captures the dual nature of formal arguments (as either inputs or parameters) and translates them into appropriate HDL constructs, enabling practical translation while maintaining parameterization capability

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent changes the status of formal arguments from fixed inputs to parameterizable entities. By allowing formal arguments to be interpreted as either component inputs or component parameters based on context, the system enables flexible parameterization that maintains translation practicality from imperative languages

Inventive Principle:

Principle #35Parameter changes

2Ease of manufacture

If all formal function arguments are treated as component input ports, then the translation is straightforward, but the component cannot be parameterized to implement different functionality

Engineering Contradiction:

Improvetranslation simplicityVSAvoidparameterization capability

Core Design Contradiction:

Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent introduces dynamic interpretation of formal arguments. Instead of fixed treatment as inputs, the system dynamically determines whether a formal argument should be treated as an input port or a parameter based on the function signature and context, enabling both straightforward translation and parameterization capability

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent makes formal arguments universal by allowing them to serve multiple roles: input ports, parameters, or both. This multi-functionality enables the same formalism to handle both straightforward translations and parameterized components without requiring separate mechanisms

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If all formal function arguments are treated as parameters, then the component can be parameterized, but the translation becomes complex and loses the intuitive mapping from imperative language

Engineering Contradiction:

Improveparameterization capabilityVSAvoidtranslation complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the treatment of formal arguments into distinct categories based on their role in the function. By segmenting formal arguments into input-port candidates and parameter candidates, the system maintains intuitive mapping from imperative language while enabling parameterization, avoiding unnecessary complexity

Inventive Principle:

Principle #1Segmentation

4Reliability

If multiple output ports are generated from all function returns, then complete functionality is provided, but the hardware description becomes cluttered with unnecessary outputs

Engineering Contradiction:

Improvefunctionality completenessVSAvoidoutput port quantity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts and removes unnecessary output ports from the hardware description. By analyzing the function signature and intended usage, the system identifies and extracts only the necessary output ports, eliminating clutter while maintaining complete functionality for the intended operation

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS7620942B1Method and system for parameterization of imperative-language functions intended as hardware generators

Publication Date: 2009.11.17 XILINX INC

AI summary

A method (100) of translating an imperative language function into a parameterized hardware component can include the steps of using (102) formal imperative function arguments to represent at least one among a component input port and a component parameter and distinguishing (104) between formal imperative function arguments intended as component parameters from formal imperative function arguments intended as component input ports. The method can generate (106) hardware description by providing a framework where imperative language functions can be translated into hardware components by being instantiated, combined and simulated. Arbitrary code can be associated (108) to a function-importing block as parameterization code and enabling an assignment of arbitrary code to actual imperative function arguments. The arbitrary code can be executed (110) in an interpreter that analyzes assigned variables by name and compares variable names with the formal argument identifiers in an imported function.