Hardware Module Interconnection via Inhibit Signal Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing hardware description languages for programming FPGAs and ASICs require precise knowledge of hardware modules' implementations and fixed interfaces, limiting module reusability and portability, and resulting in complex programming and potential data loss issues due to unclear data flow control.

Innovation Solution

A method that classifies modules into types based on specific properties to define permissible interconnections, using inhibit signals for data flow control, allowing modules to be connected without detailed knowledge of hardware design, and ensuring self-regulating data flows through structured interfaces and latency management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If hardware modules are connected using traditional hardware description languages with fixed interfaces, then data flow control can be achieved, but module reusability and portability are limited and programming complexity increases

Engineering Contradiction:
Improvemodule reusabilityVSAvoidprogramming complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces universal interface components (source interfaces, sink interfaces, data flow components) that can be used across different module types and applications. These standardized interface elements enable modules to be connected and reused in various configurations without requiring custom interface design for each connection, directly improving module reusability while maintaining manageable programming complexity through standardization.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If exact implementation of hardware modules is known before connection, then compatible interfaces can be ensured, but code portability between different hardware is hindered

Engineering Contradiction:
Improveinterface compatibilityVSAvoidcode portability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the interface design into separate, standardized components (source interfaces, sink interfaces, data flow components) that can be independently defined and combined. This segmentation allows modules to be connected based on their interface contracts rather than implementation details, ensuring interface compatibility through standardized components while enabling code portability since the segmented interfaces can be independently adapted to different hardware platforms.

Inventive Principle:
Principle #1Segmentation

3Ease of operation

If data flow control is implemented using traditional enable signals, then some data flow control is achieved, but complete self-regulating data flow cannot be achieved and data loss may occur

Engineering Contradiction:
Improvedata flow controlVSAvoiddata loss prevention
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent implements feedback mechanisms through sink interfaces that monitor data consumption and generate control signals back to source interfaces and data flow components. This feedback loop enables complete self-regulating data flow control where the system automatically adjusts data production and transmission rates based on actual consumption, preventing data loss by ensuring data is only produced when it can be consumed, thereby improving both ease of operation and reliability.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP1927063B1Hardware programming and layout design
Publication Date: 2016.03.30 SILICON SOFTWARE
  • EP1927063B1 patent drawingFigure 1~2
  • EP1927063B1 patent drawingFigure 3~4
  • EP1927063B1 patent drawingFigure 5~6

AI summary

The invention relates to programming hardware for useful data processing also used in the form of a suitable graphical editor. The inventive method consists in providing a plurality of modules (200), wherein each module can carry out at least one function for useful data processing, in defining the module connecting interfaces (202, 210), in establishing, by a user, an additional connection of modules (topology) corresponding to a sequence of functions suitable for the useful data processing, in classifying the modules into a plurality of module types according to predefined properties, in defining connection rules indicating admissible connections for different module types according to said types of modules and in programming the hardware according to said topology.