Graphical Programming System for Processor-Hardware Partitioning
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems for processor-centric design flows in programmable hardware elements, such as FPGAs, face challenges in precisely specifying and controlling timing and I/O constraints, which are crucial for applications like real-time control and automation, as text-based programming languages lack the necessary mechanisms.
Innovation Solution
A graphical programming system that allows for the creation and deployment of processor-centric flows by mapping a graphical program with performance criteria onto a programmable hardware element, either by intrinsic or extrinsic processors, enabling the partitioning and retargeting of code to optimize resource use and meet timing constraints through iterative refinement.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If text-based programming languages are used for processor-centric design flows, then implementation simplicity is improved, but the ability to precisely specify and control timing and I/O constraints deteriorates
Solution Approach 1:
The patent introduces a graphical programming language as an intermediary between the designer's intent and the hardware implementation. This graphical language serves as a mediator that enables precise specification of timing and I/O constraints while maintaining ease of use through visual interfaces, thus resolving the contradiction between implementation simplicity and specification precision.
Solution Approach 2:
The patent changes the parameter representation from text-based to graphical-based. By transforming the programming interface from textual to visual form with dedicated graphical elements for timing and I/O constraints, the system achieves both ease of implementation and precise control over critical parameters simultaneously.
2Manufacturing precision
If graphical programming language is used to specify performance criteria, then timing and I/O constraint control is improved, but device complexity increases
Solution Approach 1:
The graphical programming language is designed to be universal, handling multiple functions including timing specification, I/O constraint definition, and performance criteria setting within a single integrated framework. This multi-functionality reduces the need for separate tools and interfaces, thereby managing complexity while maintaining precision.
Solution Approach 2:
The patent segments the programming system into distinct graphical elements and constructs, each handling specific aspects of timing and I/O constraints. This segmentation allows for modular development and easier management of complexity, as each graphical element can be independently understood and manipulated.
3Manufacturing precision
If iterative refinement process is used for mapping graphical program to hardware, then performance criteria achievement is improved, but development time increases
Solution Approach 1:
The iterative refinement process incorporates feedback mechanisms where the system automatically evaluates whether the mapped hardware configuration meets the specified performance criteria. This feedback loop enables efficient iteration by providing immediate information about compliance, reducing unnecessary development cycles and optimizing the balance between precision and time.
Solution Approach 2:
The patent performs preliminary actions by automatically generating initial hardware mappings from graphical programs before iterative refinement begins. This preliminary mapping provides a starting point that is already close to the final solution, reducing the number of iterations needed and thereby decreasing overall development time while maintaining performance criteria achievement.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Implementing a design flow for a programmable hardware element (PHE) that includes or is coupled to a processor. A graphical program (GP) that includes performance criteria is received, and mapped for deployment, with a first portion targeted for processor execution, and a second portion targeted for implementation in the PHE. A determination is made as to whether the graphical program meets the performance criteria. If not, the GP is remapped for deployment, including identifying and specifying a sub-portion of the first portion for implementation in the PHE, thereby moving the sub-portion from the first to the second portion, and/or identifying and specifying a sub-portion of the second portion for processor execution, thereby moving the sub-portion from the second to the first portion. The determining and remapping is repeated one or more times until the performance criteria are met. The first and second portions are deployed to the respective targets.