Transaction History for EDA Operation Rollback
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Electronic-design-automation (EDA) software lacks the ability to effectively capture and manage transaction histories of sequences of operations, leading to increased design time and cost, as well as a degraded user experience due to the absence of high-level transaction information and implicit operations in log files.
Innovation Solution
A computer system that maintains a transaction history by receiving and associating user inputs with sequences of EDA operations, automatically detecting transactions, and displaying this information in a graphical user interface, allowing for undo and redo operations without user input and providing automatic rollback in case of errors.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If log files are used to record EDA operations, then a record of operations is maintained, but high-level transaction information is lost and user understanding becomes difficult
Solution Approach 1:
The patent segments EDA operations into discrete transactions with unique identifiers, separating high-level transaction information from low-level operation details. Each transaction is recorded as a distinct unit in the transaction history, allowing users to understand operations at multiple levels of abstraction simultaneously.
Solution Approach 2:
The patent introduces a transaction history data structure as an intermediary between the EDA operations and the user interface. This intermediary layer captures both the high-level transaction context and the detailed operation sequence, providing a bridge that preserves information without increasing apparent complexity.
2Reliability
If detailed operation logs are maintained, then complete operation records are available, but user productivity decreases due to difficulty in tracking transactions
Solution Approach 1:
The patent implements dynamic transaction history management where the system automatically tracks and records transactions as they occur during the EDA process. The transaction history adapts to the user's workflow, maintaining detailed records when needed while allowing rapid navigation through transaction summaries to maintain productivity.
Solution Approach 2:
The patent provides feedback to users through the transaction history interface, allowing them to see the impact of operations in real-time. Users can review transaction details, understand operation sequences, and make informed decisions, which improves both reliability and productivity by reducing errors and rework.
3Ease of repair
If checkpoints are used to track operations, then rollback capability is provided, but checkpoint positions are arbitrary and unrelated to transactions
Solution Approach 1:
The patent performs preliminary action by automatically creating transaction records before EDA operations are executed. Each transaction is pre-configured with metadata and context information, so when rollback is needed, the system can restore to the correct transaction state without losing contextual information about what operations were being performed.
Solution Approach 2:
The patent creates copies of transaction states and operation sequences in the transaction history. These copies preserve the complete context of each transaction, including the state before operations and the sequence of changes made. This allows accurate rollback to any transaction point while maintaining full transaction context for future reference.
Data Source
AI summary
A technique for maintaining a transaction history is described. This transaction history includes a sequence of commands or operations in an electronic-design-automation (EDA) environment. For subsets of one or more operations in the sequence of operations, the transaction history includes an associated transaction name, as well as a state of the of the subset, which is open after an initial EDA operation in the subset has been performed and is closed after a last EDA operation in the subset has been performed. This transaction history can be displayed in a window in a graphical user interface, and facilitates undoing and/or rolling back of changes to the data associated with one or more subsets. For example, if an error is detected, roll back of one or more subsets to a known software state or condition prior to the operations in the one or more subsets may be performed without user instructions using the transaction history.