DEV Community: Pratik Parvati

Optimizing Verification Workflow with Portable Test and Stimulus Standard (PSS): Best Practices

Pratik Parvati — Fri, 11 Oct 2024 15:49:26 +0000

The semiconductor industry now faces challenges like delivering reliable, high-performance designs with the reduced time-to-market. Verification is an important step that ensures a design meets up to its required functional and performance specifications. Traditional methods of verification are unable to cope with the complexities of semiconductor designs and, hence, are creating inevitable bottlenecks in the development process.

The PSS has become the game-changing methodology since it offers an efficient approach to generating reusable test scenarios across different platforms. PSS therefore accelerates verification by providing higher levels of automation, reuse, and portability. Still, like any other tool or methodology, its power is unleashed only when applied correctly.

Within this blog we will cover how you can optimize your verification flow using PSS. We will dedicate some best practices so PSS can be adopted efficiently and scalably, thus helping to streamline your verification efforts, improve functional coverage, and hence get your design to market faster.

I. Understanding the PSS Workflow

To fully optimize your verification workflow using PSS, one needs to understand what the key stages involve. PSS is an upgrade to a traditional verification flow that allows it to be portable and reusable during test case generation, model creation, and execution across platforms. Let's walk through each stage of a typical verification workflow in PSS.

A. Test Case Generation

Any verification activity starts by generating different and robust test cases. Generating test cases the traditional way is a time-consuming process with a high likelihood of errors, primarily if a user begins to create scenarios for various platforms or use cases manually.

In PSS, test cases are automatically generated from high-level models. These models define a wide set of functional and performance behaviors. It is thus easy to generate tests for various scenarios, corner cases, and conditions. The key benefit here again is the portability of the approach - once a model is defined, the same test cases can be reused with various platforms, such as simulation, emulation, and post-silicon environments.

B. Model Creation

PSS models describe the system under test and encapsulate the components, actions, and constraints in a test. They are written at a level of abstraction that makes it easy to reuse them across projects and adapt them to different platforms.

In model development, engineers typically identify:

Components: These comprise the hardware or software entities to be tested.
Actions: These are operations performed by, or on, components.
Constraints: The conditions under which some actions can be performed.

These are models reusable across scenarios and configurations, making sure not to duplicate work and that testing remains consistent. Engineers could scale their verification efforts from this.

C. Stimulus and Scenario Development

After the model is created, it is followed by stimulus and scenario configurations that describe how tests are to be actually executed. PSS makes available a well-structured approach to define what stimuli must be used so that all the possible use cases and their respective edge conditions are also considered.

PSS offers the ability to randomize and, for constraint-based stimulus generation, to exercise a broad range of scenarios without having to write each and every test by hand. It thus ensures the coverage of even unlikely or infrequent conditions and thereby improves test coverage decisively.

D. Execution and Results Analysis

As soon as the test scenarios are produced, execute them and then analyze the output. PSS lets tests be executed very smoothly on various verification platforms like simulators, emulators, and real hardware without writing down test cases for every environment.

Actually, this is where the portability of PSS really shines - engineers can create test cases in simulation and reuse the same tests in post-silicon environments. Maintaining consistency across platforms reduces duplication of effort and minimizes the risk of discrepancies between different stages of verification.

II. Best Practices for Maximizing PSS Workflow

Optimization of the workflow using PSS unlocks huge efficiencies in semiconductor verification that then translate into faster time to market as well as stronger designs. Below are best practices that ensure you get the most out of PSS.

A. Early Integration of PSS in the Design Flow

Indeed, early use of PSS in the design and verification cycle improves the overall flow of it. This is because test models and test scenarios can be defined from the start, problems are tackled proactively in the design, and hardware and software verification gets initiated at the same time, day one.

Advantages: Early integration will begin to catch problems at the right time before it becomes expensive to fix. In addition, by setting up reusable test scenarios early, teams can be assured that the design will pick both functional and non-functional aspects that had been appropriately tested at all stages through the development cycle.

B. Modular and Reusable PSS Models

One of the major strengths of PSS is in modular, reusable components. The modular aspect of PSS models allows teams to encapsulate complex systems into smaller, reusable pieces that might then be combined or extended to generate a wide variety of test scenarios across multiple projects and platforms.

Utility: Modular PSS models save time and efforts by not requiring people to rewrite the test code based on various configurations that would be required if they didn't need to. Moreover, it makes the process absolutely scalable because teams can simply recycle verified modules in new designs without much change. In addition, this approach simplifies collaboration since different teams can contribute reusable components to a common repository.

C. Automation of Test Scenarios

PSS excels in the field of automatically generating test scenarios. PSS can automatically produce many test cases that utilize constraint-driven randomization which goes beyond even the most elongated conditions and corner cases which are practically possible by developing tests by hand.

Benefits: Automation reduces the use of manual interventions to near zero, which means that test cycle time goes down and test coverage increases simultaneously. It is quicker to find an edge case, hence having a stronger verification. This way, through rapid iteration over generations of test scenarios, teams get more time for analysis of results rather than writing new tests.

D. Cross-platform Consistency

In fact, one of the very important advantages of PSS is its portability across verification environments whether it is simulation, emulation or post-silicon testing. In fact, cross-platform consistency is of paramount importance for a smooth and efficient verification process.

Consistency: PSS tests are created once and can then be applied to multiple environments without needing any adjustments. This means that the same test cases will run at maximum consistency hence having no discrepancies of different iterations since the test is being rewritten for a different environment. This helps with fast transition from one developmental stage to another, and verification is now efficient.

E. Correct Debugging and Maintenance

If the designs become big and the system intricate, maintenance and debugging PSS models will be too complex. This is one reason model readability has to be made easier and debugging more straightforward as part of workflow simplification.

a. Maintenance Tips:

Read-able Models: PSS models must be in plain and modular forms by appropriate uses of meaningful names of the components and actions. Thus, a team can quickly understand and maintain the model over time.
Version Control: A version control system is coupled with documentation such that any changes into PSS models are well-documented and traceable back in the event of any problems.
Debugging: Make use of PSS tools that offer high power debug functionality and include visualization of generation flows for tests and coverage of scenarios. This makes the problem identification of failures and correction of faults more manageable.

Using these best practices, teams can then leverage the benefits of PSS, including higher productivity, higher test coverage, and faster execution times. But much more than this, it is an approach that not only optimizes verification but positions your team better to face the growing semantic complexity of semiconductor design.

III. Overcoming Common Challenges in PSS Workflow Optimization

Although PSS has much promise for verification, it is indeed very difficult to bring it into real-world usage. Let's learn how a semiconductor team had to grapple with their woes in optimizing the verification process with the usage of PSS in this real-life experience.

A. Challenge 1: Complexity in Initial Model Creation

One of the first major challenges was how to deal with complexity in building correct and reusable models after the team adopted PSS. It takes quite a good amount of time to build models from scratch for such large and very complex SoCs that would require deep expertise.

a. How to Overcome It:

The team can ease this challenge by breaking up the task of modeling into a phased approach. Instead of starting with the attempt to model the whole system in one shot, the team would start with smaller, critical parts, such as processor and memory controllers. These were the high-priority areas that had the greatest impact on functionality. Breaking the SoC down into manageable modules in this way will help to work up modular models over time that can then be mixed and matched accordingly.

This phased development approach would allow the workload to be divided in such a way that verification engineers were building confidence in their understanding of PSS before embarking on the more challenging sections. Additionally, the team could assure themselves that every model was heavily documented and modular, making easy updation or repurposing whenever the design evolved.

B. Challenge 2: PSS and Integrating with Legacy Systems So Far

Semiconductor companies had already invested heavily in legacy verification systems and environments, and one of their major concerns was going to be integrating PSS into an existing workflow. They needed to ensure that PSS-based tests worked properly side by side with their established methods without disruption and a delay.

a. How To Overcome It:

To address this, the team can follow a hybrid approach wherein PSS can be applied parallel to the existing testbenches. Here, instead of replacing everything at once, the team can use PSS to generate some portion of the test cases while continuing to run legacy tests in other parts of the system. This would let the team gradually move to PSS without risking either verification coverage or productivity.

With time, as the confidence in PSS models increases, the team will start phasing out their legacy tests and begin to fully adopt to PSS for their verification efforts. This hybrid approach not only minimizes disruption but also gives the team a chance to compare the effectiveness of tests generated by PSS with traditional methods, ultimately proving that PSS is superior in terms of coverage and efficiency.

C. Challenge 3: Debugging PSS Models Across Platforms

Yet another key challenge is debugging of PSS models in case of failures observed against different verification platforms like simulation and post-silicon validation. Indeed, PSS provided excellent test portability, but close cooperation is necessary for diagnosing an issue that manifested only in a given environment-for instance, in hardware but not simulation.

a. How To Overcome It:

To address this issue, the PSS models must use platform-specific logging and monitoring. These tools can easily identify the conditions under which failures occur with a good degree of granularity and can be very useful when trying to correlate issues on different platforms. For example, if a test passes in simulation but fails in hardware, logs help identify particular constraints or scenarios causing the failure.

Also, modular debugging must be used. Break the tests into pieces of smaller, isolated parts so that only the exact parts of a test run on each platform. This really helps with the localizing process as it not only helps narrow down where the problem is but also what location it is at. The other aspect is continuous collaboration between the hardware and verification teams. The data of both parties will yield combined insights into speeding up the root cause analysis and a more efficient resolution of cross-platform failures.

D. Challenge: Skill Gap and Team Adaptation

Although PSS can bring along so many benefits, adopting PSS would definitely mean a rather steep learning curve for engineers who are relatively accustomed to verification methodologies and toolsets. Rapid updating skills of the team would be necessary to draw all the benefits of PSS.

a.How to Overcome It:

Have structured PSS training programs-including workshops and hands-on, across all junior engineers right up to the senior verification lead-and have everybody skilled in this new methodology. Have a culture of knowledge sharing: The best engineers who embrace PSS early on are then coaches, sharing best practices for creating models, generating scenarios, and debugging.

Develop standardized and internal libraries of PSS components that the engineers can leverage as template as well as reference for any new model. Pre-loads of such built assets save huge onboarding time and provide engineers with real references that are more amenable to use and come up with PSS quick on productivity.

E. Challenge: Achieving Cross-Platform Consistency

Since PSS is targeted to be portable, however, it is really challenging to get consistent verification results on a simulation, emulation, or hardware platform. In many cases, these variations in test behavior are the outcome of some kind of platform-specific constraints or limitation.

a. How to Overcome It:

To address this, validation logic needs to be included in the PSS models which will ensure that any test scenario of PSS obeys explicit conditions for each platform. For example, a test requiring more control over timing and synchronizations would need to be taken into account as additional constraints in PSS models.

By adapting the tests for what is possible with each platform, you keep uniformity in executing tests different environments and also ensure the consistency and dependability of the results.

IV. Future-Proofing Verification Processes with PSS

To achieve long-term success, as the complexity of semiconductor designs continues to increase and technology advances rapidly, verification processes must adapt in similar ways. It is in this context that one's verification workflow can be future-proofed with the Portable Stimulus Standard (PSS)-with flexible, scalable models created that take into account the evolution of the industry and emerging methodologies.

A. Adapting to New Technology Developments

The continuous advancement of semiconductor technology through newer architectures, protocols, and fabrication techniques demands verification teams to ensure that the PSS models are designed to embrace new technologies without necessarily demanding a total overhaul. Modular design approaches have made this possible because they allow component swapping and replacement as need be, ensuring verification processes can keep up with changes in technologies.

For instance, in case of new communication protocols or new memory architectures, modular PSS models allow teams to introduce such innovations into their test scenario without forcing them to redo the entire verification flow. Flexibility thus reduces downtime and brings verification processes abreast with the current industrial standards.

B. Preparation for changing industry standards

Verification standards are continually increasing with the time and need to accommodate ever-rising complexity of semiconductor systems. Companies that will be working with flexible PSS models allows it to react better to updated standards. The newly defined verification standards, such as those defined by organizations like Accellera, force teams to review their process constantly in order to adhere to the new standards. With PSS, one develops models not only compliant with current standards but also flexible and able to react to the changing standards in time.

For example, if new safety or security features are introduced for particular devices during the evolution of verification standards, flexible PSS models allow teams to easily add such requirements without reverting to clean sheet design. It is this flexibility that provides the cornerstones of maintaining compliance in an increasingly dynamic regulatory environment.

C. Leveraging Automation to Handle Increased Complexity

Trends of Future Semiconductor Projects - Semiconductor projects can only continue and continually be more complex designs, more subsystems, multiple cores, integrated hardware-software components, and so on. Automation becomes key in the management of complexity through the power of PSS. Generation and execution of test scenarios help teams deal with larger and more intricate designs without overstretching resources.

As the integration of these ML and AI technologies into the verification workflows rises, PSS models have to be adaptable enough to absorb these advancements. Organizations with a base for verifying processes built around automated and adaptive PSS models can quickly integrate these technologies to make the testing even more optimal, increase coverage, and improve analysis.

D. Building Scalable and Reusable PSS Models

Scalability is also one of the critical aspects in future-proofing verification flow. Verification environments need to scale from small designs to much larger, more complex SoCs with minimal rework. Thus, scalable verification environments for various projects can be developed by teams by concentrating on reusable PSS models so that adequate switching to verification flows can be done when the scale or complexity of the design increases.

For instance, reusable models that can be initially created for small components, be thereafter adapted and further elaborated in bigger SoC designs, saving time and effort. In addition, the teams would use these models for other projects, resulting in an efficient workflow, growing with time naturally with the needs of the organizations.

To be competitive in this fast-changing industry of semiconductors, organizations need verification workflows that are prepared for change. PSS provides a framework through which teams can design flexible, scalable models that not only align with current industry standards but also can incorporate some of the new trends and technologies emerging in the future. First, it allows teams to future-proof themselves in this environment with verification processes via investing in automation, modular design, and reuse of models, thus not having to continuously experience large-scale overhauls due to innovation from the industry for long-term success.

V. Conclusion

Indeed, the PSS has revolutionized the world of verification. It makes workflows more efficient, increases test coverage, and maintains cross-platform consistency. When applied early in the design cycle, using modular reusable models, manual effort and verification cycles can be greatly reduced.

With PSS, it addresses all the issues currently but also guards the verification flow from all the accelerations of technology changes and flux in industry standards. Since complexity levels are constantly being pushed upwards by semiconductor companies, embracing PSS will actually give the way to agile delivery, quick time to market, and high-quality products.

In simple words, optimising verification with PSS is the need of the hour to be competitive and look ahead to the dynamic semiconductor industry tomorrow.

Bridging the Gap: Integrating PSS with Hardware-Software Co-Verification

Pratik Parvati — Sat, 31 Aug 2024 15:16:54 +0000

In today's fast changing technological landscape, the line between hardware and software gets increasingly blurred. Today's systems, including smartphones, self-driving cars, Internet of Things devices, and industrial automation, rely largely on software-hardware interactions. Co-verification has become an integral component of the design process as hardware and software become more interdependent. Co-verification ensures that every part of a product functions properly in the real world by combining testing features from both hardware and software.

Hardware and software are traditionally verified on separate tracks, with their own methodologies based around discrete tools. Unfortunately, this method proves insufficient when the systems become too complicated and as a result do not identify some subtle - yet very important bugs based on interactions between hardware and software. Some of these bugs may cause system crashes, security holes or other unwanted effects. Hence, it is clear that a more Unified Verification Strategy was needed.

The Portable Stimulus Standard (PSS) is useful in this situation. The PSS standard, developed by Accellera, is a potent tool that may be used to create automated, reusable, and portable test scenarios for both software and hardware, thereby addressing the issues associated with contemporary verification. Verification engineers may ensure that all interactions are adequately tested and confirmed by bridging the gap between hardware and software with PSS.

In this blog, we will take a look at how PSS may be effectively integrated into hardware-software co-verification. We will explore PSS's role in software-driven verification, discuss practical examples of PSS-powered hardware-software co-verification, and talk about the difficulties and solutions that arise in mixed hardware-software environments.

I. Understanding the Need for Hardware-Software Co-Verification

Modern electronic systems have now become much more complex, embedding high-performance hardware capabilities with sophisticated software. Unlike the older, simpler devices, today's systems integrate many hardware components, including processors, memory units, and peripherals, with complex software layers comprising operating systems, drivers, and applications. This level of integration requires seamless interaction between hardware and software for the system to operate correctly and meet design specifications.

A. Critical Applications That Need Precise Hardware-Software Synchronisation Include the Following:

Automotive systems: Automotive Systems can be considered classic examples of embedded systems, starting with engine control units and advanced driver assistance in modern cars. These involve precise interaction among hardware components including sensors and actuators with software algorithms for real-time braking, adaptive cruise control, and collision avoidance, among others. Any mismatch in hardware-software pairing can trigger a flaw in either safety or system malfunction.
Aerospace Systems: Any aerospace application, such as aircraft avionics systems, needs both high reliability and accuracy. Software has been entrusted to take over critical hardware operations like navigation, communication, and flight control systems. Ensuring the correct interaction of software with hardware in all possible operation scenarios is crucial for guaranteeing safety and performance of the aircraft.
Medical Devices: Medical devices involve everything from very simple pacemakers to highly sophisticated diagnostic imaging systems; hardware, including stimulators and sensors, and software, including signal processing and diagnostics. Poor synchronisation in this interaction can result in hazardous medical consequences and failures in diagnosis.
Industrial Automation: Synchronous use of hardware components like motors, sensors, along with control software, by industrial control systems and robots for activities such as manufacturing, quality control, and material handling. Only through effective integration between the hardware and software can good efficiency and error-free functioning result.

B. Traditional Verification Approaches

In the past, various methods relevant to each area have been used to verify hardware and software:

Hardware Verification: Emulation, simulation, and formal verification are examples of traditional techniques for hardware verification. These methods evaluate the performance and functionality of hardware components either individually or in controlled environments.
Software Verification: Software verification typically involves techniques such as unit testing, integration testing, and system testing. These techniques, which typically make use of virtual environments or mock hardware, evaluate the correctness and functionality of software components.

Even while these conventional methods work well in the domains they cover, they are unable to handle problems that result from the interaction of hardware and software. For instance, testing hardware alone might not reveal software bugs related to timing or synchronization, and software testing without considering hardware contexts might miss critical integration problems.

C. Limitations of Traditional Methods

Insufficient Integration Testing: Most traditional testing methods focus on separate, individual testing of hardware and software. This may allow for the missing of big issues based on how these elements actually work with each other in real situations-a reason for incomplete test coverage.
Manage Complexity: With systems getting increasingly complex, it is difficult to keep supporting various verification methodologies for software and hardware. The complexity of systems today demands a unified approach for assurance that verification is thorough and effective.
Late Issue Detection: Issues related to the interaction of hardware and software can be detected much later, depending on the stage of the development cycle. Fixes due to such delayed discovery are costly and time-consuming, impinging on the budgets and schedules of projects.
Difficulty in Simulating Real-World conditions: This is because conventional methods can hardly model the wide variation in changing circumstances occurring during real-world operation. Limitation in the simulation makes it difficult to find problems which show up under particular real-world conditions.

Understanding such limitations underlines the importance of co-verification between hardware and software. The inclusion of PSS in verification provides a complete bridge between hardware and software interaction, thus ensuring all interactions are properly tested and validated to achieve more reliable and robust system design.

II. PSS Integration with Software-Driven Verification

Software-driven verification is a test methodology that tries to validate how the software interacts with the real hardware. Other traditional verification methodologies will validate the hardware and software components individually, whereas software-driven verification tries to integrate both and perform a test together. This approach makes sure that the software really controls, commands, and talks to the hardware components, which are vital in today's complex systems.

A. Importance of Software-Driven Verification in Validating Software-Hardware Interactions

In most embedded systems, software controls critical hardware components. In automotive systems, for example, software operates sensors, actuators, and other ECUs to safely handle the vehicle. Such interactions are very important to validate because any discrepancy between the software request and the hardware response always results in system failures, safety issues, or bad performance. Software-driven verification emphasizes such vulnerabilities under realistic operational scenarios where software-to-hardware interaction plays an important role.

B. Utilizing PSS for Software-Driven Test Scenarios

The Portable Stimulus Standard PSS describes and automates complex test scenarios involved in both hardware and software. PSS enables the test engineers to create abstract models of the test scenarios that are aware of both hardware and software. This further can be automatically transformed into an executable set of test cases controlling both the software and hardware under test.

Definition of Scenarios: PSS allows the engineer to define test scenarios at a high level, focusing on what of test instead of how to execute. A scenario in this regard may include initializing hardware components, loading drivers, and running specified software commands in order to test the system's response.
Scenario Execution: Once the PSS model has been specified, tools generate executable tests that can be run either on real hardware or in simulation environments. In fact, this kind of automatic execution will guarantee that the defined scenarios are thoroughly checked with no human intervention

1. A Practical Example

Scenario: Verifying the Boot Sequence of an Embedded System

Let's now look at a practical use of PSS applied successfully in software-driven verification. As an example, it could be used to check the boot sequence of an embedded system. The boot sequence is a necessary step in the operating process of the system, which then loads all the required drivers, initializes hardware, and gets the operating system ready to start. As such, this would need to be pretty well tested in order to catch any unexpected behavior or failures to initialize as early as possible.

a. Step 1: Define the PSS Model

To kick-start the work in PSS, a model needs to be defined that can really embody the fundamental elements of the boot process. Based upon this PSS model, for this example,

Hardware components include the following:

Processor (CPU): the primary processing unit that starts the boot process.
Memory: Random Access Memory (RAM) and other initialized memory components.
Peripherals: Hardware components that are required by the system to detect and configure during its boot-up, such as network interfaces, sensors, or display units.
Storage: The operating system and bootloader are kept in non-volatile storage.

Software constitute the following:

Bootloader: This is the software part responsible for loading the operating system and configuring the needed hardware to kick-start the boot cycle.
Operating system (OS): The primary software that runs on the hardware and serves as an application platform.

Test Scenarios include the following:

Normal Boot Sequence: This is the process by which the system turns on, initializes the hardware, loads the bootloader, and then gives the operating system control.
Power Failure Scenario: This refers to a situation in which the system loses power while booting up. This scenario evaluates the system's ability to recover from an unexpected power outage.
Peripheral Initialization Failure: A peripheral device that fails to initialize is referred to as a peripheral initialization failure. This scenario tests the system's resilience to hardware malfunctions and allows it to boot with reduced functionality.

b. Step 2: Creating Test Scenarios Using PSS

We can create several test scenarios using the PSS model to confirm various elements of the boot stage. Here are a few sample scenarios:

i. Normal Boot Sequence

Description: This scenario assesses the system's capacity to carry out a successful boot sequence in its entirety under normal circumstances.
Steps:
- Turn on the system.
- Bootloader loaded from non-volatile storage and CPU initialized.
- The bootloader loads the operating system, sets up peripherals, and initializes memory.
- The operating system assumes command, finishes startup, and launches application services.
Anticipated Result: The system boots up successfully, with accurate initialization of all hardware and software components.

ii. Power Failure Scenario

Description: This scenario evaluates how resilient the system is to an unexpected power outage during the boot process.
Steps:
- Turn on the system and start the boot process.
- During initialization, simulate a random power outage (e.g., while loading the bootloader).
- Turn the power back on and watch how the system starts up again.
Anticipated Result: Upon power restoration, the system ought to identify the power outage, respond appropriately, and carry out the boot sequence successfully once again.

iii. Peripheral Initialization Failure

Description: This scenario examines how the system responds to peripheral initialization errors that occur during boot.
Steps:
- Turn on the system and initiate the boot process.
- Create the illusion of a peripheral (such a network interface card) not being initialized.
- Verify whether the machine logs the problem, keeps booting, and functions with reduced functionality (like no network connection).
Anticipated Result: The peripheral initialization failure should be recorded by the system, informing the user (if relevant) and allowing the boot process to continue without the malfunctioning device.

c. Step 3: Executing the PSS Scenarios

The next stage is to put the scenarios into action after they have been defined using PSS. This includes:

Automatic Test Case Generation: The model and the derived scenarios will be guiding the creation of test cases by PSS tools automatically. Such generation ensures uniformity and reduces the need to create test scripts manually.
Testing Real Hardware and Simulation Environments: It is possible to run the test cases generated on real hardware and also on simulation environments. Testing on real hardware helps ensure that all real-world conditions come into consideration, whereas running on simulators enables the detection of problems early in the design cycle.
Log and Monitor: The action that the system takes is tracked and recorded while the system operates. Anything out of the expected sequence of events is flagged to take an in-depth look at it, hence making identification of just the exact action easier

d. Step 4: Analyzing Results and Iterating

The execution results of the scenarios are analyzed by the engineers:

Pass/Fail Analysis: Identify whether the boot sequence succeeded or if there was an error and identify the causes of failure and conditions when failures happened.
Bug Identification and Reporting: Since testing based on PSS is automated, these abnormalities are reported as bugs with comprehensive logs and steps to reproduce them.
Improvement of the Model: Adding new scenarios or refactoring existing ones to the PSS model, in an iterative cycle, reaches completeness and enriches the test strategy at each cycle.

III. Problems and Solutions in Mixed Hardware-Software Environments

A. Problem 1: Hardware-Software Synchronization

The most common problem that occurs in any type of mixed hardware-software environment is the synchronization issue that occurs between continuous operations of hardware and segmented software. Different parts of hardware work on different clock cycles and, hence, possess different timing constraints than those of software processes. The presence of this difference becomes highly critical if the application comes under the domain of real time because any delay or loss of synchronization will result in performance problems or complete system crashes.

Solutions:

PSS for the Definition of Synchronization Points and Timing Constraints: PSS basically enables a designer to specify synchronization points that provide real-time assurance related to hardware-software co-operability. A designer can thus come up with timing constraints and place synchronization markers within PSS models to subsequently simulate and check whether the interactions happen at the right time and within the pre-specified timing constraints at both the hardware and software levels.

B. Problem 2: Scalability and Complexity Management

Verification management becomes challenging and cumbersome as the systems grow larger and complex. The interaction between various hardware and software components can multiply, which again leads to scalability and complexity challenges. Thus, comprehensive test scenarios that cover every interaction are sometimes difficult to create.

Solutions:

Modular PSS Design: A modular approach will help decompose such complex systems into smaller, manageable modules that can be independently verified and integrated with the rest of the system. This modularity in the design of PSS eases complexity, thereby making scaling in verification easier.

Abstraction of Scenarios and Reusability of Models: PSS enables abstractions; thus, designers can create high-level scenarios that can be shared across tests. Reusing models and scenarios saves time and redundancy, and consistency during verification.

C. Problem 3: Debugging Co-Verification Scenarios

Most of the debugging issues are especially complex in mixed hardware-software interaction. If there is a problem, one has to trace through both hardware and software layers for the root cause. The interaction is so much intertwined that one cannot say if the problem emanates from hardware, software, or the interface of hardware and software.

Solutions:

Advanced debugging tools supporting the PSS model: Advanced debugging tools that can be supported by PSS can detect the bugs in a more precise manner. These trace the operation flows and show runtime status of hardware and software components. It is quite easy for engineers to locate the problems using such type of tool and analyze them, thus simplifying debugging in complicated scenarios.

Specific integration with existing debugging frameworks takes advantage of the strengths of available debugging frameworks and augments them with functionality specific to the PSS domain. That way, engineers can remain in their familiar tool environments while benefiting from the strength of PSS models in inspecting the hardware-software interactions.

Problem 4: Integration with Existing Verification Environments

PSS adoption in existing verification environments, especially legacy ones, faces integration challenges. Sometimes interoperability conflicts with the integration of PSS into the existing workflow and toolchains.

Solutions include the following:

PSS Adapters and Wrappers: Writing adapters and wrappers that bridge the gap between PSS and existing verification environments will facilitate integration. These adapters translate the PSS models to formats that are compatible with legacy tools, thus allowing seamless interaction.

Ensuring Backward Compatibility: To make migration to PSS smooth, backward compatibility with the existing methodologies for verification should be maintained. Thus, it would be easy to integrate PSS with the flow at various teams without disrupting verification processes that are already in progress and provide a frictionless on-ramp to its adoption.

By resolving these challenges with concrete solutions, engineers can successfully leverage PSS in mixed hardware-software environments, leading to better quality verification and enabling robust, reliable system design.

IV. Best Practices of Integrating PSS in Hardware-Software Co-Verification

A. Start Small:

This is really important to keep models simple in PSS integration into hardware-software co-verification. Take the very simple scenarios which model the basic interactions between hardware and software components; this provides that simplicity necessary for the teams to get acquainted with the PSS concepts and process without major complexity. Starting small allows early wins, showing how PSS caught issues that could have easily been missed using traditional verification methods.

B. Incremental Development:

One of the important practices to handle such a complex model is incremental building and testing of PSS scenarios. The decomposition of the system into smaller, tractable parts takes place instead of trying to develop comprehensive models in one go. First, the development of PSS scenarios for individual components or subsystems takes place, which is then gradually integrated to provide more complex interactions. This kind of step-by-step approach helps in isolating problems and ensures that each component is thoroughly verified before going for more complex integrations.

C. Collaboration between Teams:

PSS integration can only be effective through collaboration between hardware and software teams. Both bring very valuable insights into the verification process. Hardware engineers can comment on the capabilities and inefficiencies of the hardware, while software engineers are in a place to provide much-needed insight into what behavior and requirements the software has. If both teams work together and define comprehensive PSS scenarios, then hardware/ software interaction can be modeled and tested accurately. Regular communication and joint review sessions will help both teams be on the same page.

D. Continuous Testing and Refinement:

Emphasize on continuous verification approach based on PSS through the development life cycle. Update continuously and refine PSS models as updated representative model of the system at each new addition or modification of features. This enables one to catch issues early, reducing the possibility of finding critical problems late in the development cycle. With continuous testing, teams can also make sure that the system retains integrity and reliability through its change and evolution process. That means that all hardware-software interactions keep up with each other, working correctly.

Considering these practices, PSS can be effectively integrated into the processes of hardware-software co-verification. Therefore, verification coverage will go up, collaboration over groups improves, and so forth, leading to robust and reliable system designs.

V. Future of Hardware-Software Co-Verification with PSS

Emerging Trends in Verification:

Technology, as it improves, does the modes and tools. Emerging trends like AI-driven verification and machine learning will go a long way in boosting the capabilities of PSS. The AI algorithms can analyze enormous data for verification data and pick up the patterns and consider predicting possible failure points. These predictions can form part of PSS scenarios. Machine learning will play a significant role in optimizing test coverage through automatic scenario generation, targeting the most critical parts of the interaction between hardware and software. These technologies can be employed to prioritize test cases, predict issues that may arise, and adapt to new use cases with much speed and comprehensiveness.

PSS Evolution:

Portable Stimulus Standard will have to evolve to handle this increasing system complexity. With growing system complexity, the PSSs should be able to provide support for more detailed and sophisticated modeling. Examples of such evolutions are complex modeling of timing requirements, more heterogeneous hardware architecture support, and integrating real-time constraints. Improvements in the PSS may also be related to heterogeneous systems support, where a variety of processors and components interact. Its further evolution in the future will be geared toward making PSS more usable, scalable, and integrated with other verification tools to reach a bigger circle of engineers and projects.

Industry Adoption:

Adoption of PSS in the industry will play an important role for shaping the future of hardware-software co-verification. With more companies realizing the value of a single verification strategy spanning hardware and software, the PSS adoption is bound to grow. Industry standards will further evolve; the tendency could be that PSS might become essential in the verification process. In addition, higher complexities of products in segments such as automotive, aerospace, and IoT are likely to drive demand for more robust verification methodologies. With the PSS gaining acceptance in the industry, we can indeed look forward to institutionalization of best practices, further integration of the PSS with the existing verification frameworks, and community involvement in its continuous improvement.

A bright future lies ahead for hardware-software co-verification with PSS. Emerging technologies such as AI and machine learning, coupled with continuous evolution in the capabilities of PSS and greater industry-wide adoption, will be the great facilitators toward a comprehensive and efficient verification strategy that will ensure such complex systems run reliably and safely to meet modern technology's exploding demands.

VI. Conclusion

In this blog, we have seen how PSS fills the gap between hardware-software verification through a single methodology that advances reliability and efficiency for both. PSS allows a team to specify extensive test scenarios covering the entire spectrum of hardware-software interaction-starting from boot sequences down to peripheral driver interactions, including RTOS task management. With PSS integrated into the verification process, teams are able to bridge the gaps that traditional methodologies in verification have left by solving synchronization issues and handling complexity to increase test coverage. That is what makes PSS an extremely efficient tool to handle demands put by modern complex systems.

Since electronic systems are growing increasingly complex, the demand for an effective co-verification strategy becomes even more salient. We encourage you to try including PSS in your verification workflows and to explore its capabilities for being more comprehensive and intensive in performing tests. Be it automotive systems, aerospace applications, or any other domain where hardware and software interact, PSS is ready to help make your systems reliable and safe. Begin by availing yourself of existing resources; take professional training in PSS or consult with an expert about the best way to use PSS on your projects.

Exploring Advanced Techniques in Portable Stimulus Standard (PSS) for Semiconductor Verification

Pratik Parvati — Sun, 12 May 2024 10:48:11 +0000

Exploring Advanced Techniques in Portable Stimulus Standard (PSS) for Semiconductor Verification

In our previous blog, we delved into the fundamental components that constitute Portable Stimulus Standard (PSS) models, providing a comprehensive understanding of the building blocks essential for specifying verification intent. We explored the intricate interplay between scenarios, actions, constraints, and data objects, explaining how these core components work together to capture complex verification scenarios with precision and clarity.

I. Introduction to Advanced PSS Techniques

The relentless march of Moore's Law has pushed the boundaries of semiconductor design complexity. Verifying these intricate designs requires robust and efficient methodologies. Enter the Portable Stimulus Standard (PSS), a game-changer in the realm of verification. PSS offers a standardized approach to creating reusable testbenches and test descriptions, streamlining the verification process across various design stages.

However, as designs grow more sophisticated, the need for advanced PSS techniques becomes paramount. These techniques extend the capabilities of the standard, enabling engineers to achieve higher verification coverage, improve test case diversity, and accelerate the overall verification flow.

This blog delves into the exciting world of advanced PSS techniques. We'll explore how these methods enhance verification efficiency and effectiveness, ultimately leading to faster time-to-market for your cutting-edge semiconductor designs.

A. Importance of Advanced Techniques in PSS

The core PSS standard offers significant advantages for verification, but as designs become more intricate, its capabilities can be further enhanced by leveraging advanced techniques. Here's why mastering these techniques is crucial:

Increased Verification Efficiency: Traditional verification approaches often involve writing a multitude of test cases, leading to a time-consuming and resource-intensive process. Advanced techniques, like constraint randomization and coverage-driven verification, automate test case generation and guide your verification efforts towards achieving specific coverage goals. This significantly reduces verification time and effort, allowing you to focus on other critical tasks.
Enhanced Test Case Diversity: Basic test cases might not adequately explore the full range of design behavior, potentially leaving corner-case bugs undetected. Advanced techniques like constraint randomization introduce variability into test cases, ensuring a wider range of scenarios are exercised. This helps uncover hidden issues that might have slipped through traditional verification methods.
Improved Verification Coverage: Without a clear understanding of what needs to be verified, achieving complete coverage can be challenging. Coverage-driven verification, a key advanced technique, establishes measurable goals for verification. By utilizing these metrics and employing techniques like scenario modeling, you can systematically verify all critical aspects of your design, leading to higher confidence in its functionality.
Faster Time-to-Market: By streamlining verification and achieving comprehensive coverage rapidly, advanced PSS techniques accelerate the overall design cycle. This translates to faster time-to-market for your semiconductor product, allowing you to capitalize on market opportunities and secure a competitive edge.
Management of Complex Designs: Modern semiconductor designs are intricate beasts. Advanced PSS techniques provide a structured framework to manage this complexity. Techniques such as scenario modeling allow you to capture intricate system interactions, while advanced testbench architectures enable the development of scalable and reusable verification environments, ensuring efficient verification of even the most challenging designs.

II. Constraint Randomization

Constraint randomization is a methodology used to introduce variability and diversity into verification scenarios by applying constraints to random stimulus generation. In PSS, constraints are defined using the rand construct, which allows verification engineers to specify the range and distribution of values for input variables and parameters.

action A {
    rand bit[3:0]   f;
};

action B {

    // Define variables
    A a1, a2, a3, a4;

    // Apply constraints
    constraint c1 { a1.f in [8..15]; };
    constraint c2 { a1.f == a4.f; };

    activity {
        a1;
        a2 with {
            f in [8..15]; // same effect as constraint c1 has on a1
        };
        a3 with {
            f == a4.f; 
        };
        a4; 
    }
};

In this example, we define a scenario called B, which includes four variables. We apply constraints to these variables using the constraint keyword, specifying the allowable ranges for a1, a2. The rand construct ensures that values are randomized within the specified constraints during scenario execution.

A. Benefits of Constraint Randomization:

Constraint randomization offers several benefits for semiconductor verification:

Diverse Scenario Exploration: By leveraging randomness, constraint randomization enables verification teams to explore a wide range of possible scenarios, including rare edge cases and corner conditions.
Enhanced Coverage: By systematically varying input parameters and stimuli, constraint randomization facilitates the exploration of different verification paths, leading to higher levels of coverage across diverse scenarios.
Bug Discovery: Constraint randomization has a knack for uncovering subtle bugs and corner cases that may lurk within the design, helping verification teams identify and rectify potential issues early in the development cycle.
Scalability and Reusability: As designs grow in complexity, constraint randomization offers a scalable and reusable approach to verification, enabling verification engineers to iterate more rapidly and efficiently across different design configurations and scenarios.
Reduced Test Case Development Time: Constraint randomization automates the generation of diverse test cases, freeing up valuable engineering resources for other critical tasks.

B. Best Practices for Constraint Randomization:

To maximize the effectiveness of constraint randomization, it's essential to follow best practices:

Define Comprehensive Constraints: Invest time upfront to define comprehensive constraints that capture the range of possible values and behaviors for input parameters and stimuli.
Balance Coverage and Efficiency: Strike a balance between coverage and efficiency by prioritizing critical scenarios and focusing randomization efforts where they are most likely to uncover bugs and corner cases.
Monitor and Analyze Results: Continuously monitor and analyze verification results to assess coverage and identify areas for improvement, adjusting constraints and randomization strategies as needed.
Iterate and Refine: Verification is an iterative process, and constraint randomization is no exception. Continuously iterate and refine your randomization strategies based on feedback from verification results and insights gained from debugging and analysis.

By effectively utilizing constraint randomization within your PSS models, you can significantly enhance the quality and efficiency of your semiconductor design verification process.

III. Coverage-driven Verification

Coverage-driven verification methodologies within PSS offer a holistic approach to measuring and achieving verification coverage. Unlike traditional verification approaches, which rely on ad-hoc testing and directed testing, coverage-driven verification methodologies focus on systematically measuring the completeness of verification efforts across different aspects of the design.

A. Overview of Coverage Metrics:

Coverage metrics can be derived from various verification methodologies, including UVM (Universal Verification Methodology). UVM is a widely used methodology for verification in the semiconductor industry, and it provides built-in support for defining and collecting coverage metrics.

While UVM provides support for defining and collecting coverage metrics, it's important to note that coverage-driven verification is a methodology that can be applied independently of any specific verification framework. Whether you're using UVM, PSS, or another verification methodology, the principles of coverage-driven verification remain the same.

Functional Coverage: Measures the completeness of functional scenarios exercised during verification.
Code Coverage: Measures the percentage of code lines, branches, or paths exercised during verification.

Each coverage metric provides valuable insights into the completeness and quality of verification, helping verification teams identify areas of the design that require additional testing and refinement.

B. Strategies for Achieving Comprehensive Coverage:

Achieving comprehensive coverage requires a systematic and disciplined approach. In PSS, several strategies can be employed to enhance coverage and maximize verification effectiveness:

Define Coverage Goals: Begin by defining clear and specific coverage goals that align with the verification objectives and requirements of the design.
Select Appropriate Coverage Metrics: Choose coverage metrics that are relevant to the design and verification goals, ensuring that they provide meaningful insights into verification completeness and quality.
Monitor Coverage Progress: Continuously monitor coverage progress throughout the verification cycle, using automated tools and techniques to track coverage metrics and identify areas of low coverage.
Iterate and Refine: Verification is an iterative process, and coverage-driven verification is no exception. Continuously iterate and refine verification scenarios and constraints based on coverage feedback, striving to achieve higher levels of coverage with each iteration.

By embracing coverage-driven verification within the Portable Stimulus Standard (PSS) framework, verification teams can unlock new levels of verification effectiveness and efficiency.

IV. Scenario Modeling

Scenario modeling is a methodology used to describe and simulate sequences of events and interactions within a verification environment. In PSS, scenarios serve as the building blocks of verification models, encapsulating specific verification behaviors and stimuli that exercise different aspects of the design. By modeling scenarios at a high level of abstraction, verification engineers can achieve greater reusability and efficiency across different verification platforms and methodologies.

A. Significance of Scenario Modeling in PSS:

Scenario modeling plays a crucial role in semiconductor verification for several reasons:

Abstraction and Reusability: By abstracting verification behaviors into scenarios, verification engineers can achieve greater reusability across different design configurations and scenarios. This abstraction enables verification models to be more modular and scalable, facilitating the development of comprehensive and efficient verification environments.
Complexity Management: Modern chip designs are characterized by their complexity and interconnectivity. Scenario modeling provides a systematic approach to managing this complexity by breaking down verification tasks into smaller, more manageable components. By modeling scenarios at a higher level of abstraction, verification engineers can focus on verifying specific functionalities and interactions without getting bogged down in implementation details.
Behavioral Analysis: Scenario modeling enables verification engineers to analyze and simulate the behavior of the design under various conditions and scenarios. By capturing different sequences of events and interactions, verification models can uncover potential issues and corner cases that may arise during real-world operation, helping to identify and rectify design flaws early in the development cycle.

B. Application of Scenario Modeling in Real-world Verification Projects:

Scenario modeling has wide-ranging applications in real-world verification projects, spanning a diverse range of industries and applications:

Networking and Communication: In networking and communication systems, scenario modeling is used to simulate message passing, routing protocols, and network congestion scenarios to ensure the robustness and reliability of the system.
Automotive and Aerospace: In automotive and aerospace applications, scenario modeling is used to simulate sensor inputs, control logic, and fault tolerance mechanisms to verify the safety and reliability of embedded systems.
Consumer Electronics: In consumer electronics products, scenario modeling is used to simulate user interactions, power management scenarios, and system-level behaviors to verify the functionality and performance of the device.

In each of these industries and applications, scenario modeling serves as a cornerstone technique for achieving comprehensive verification coverage and ensuring the functional correctness and reliability of semiconductor designs.

V. Integrating PSS with Formal Verification Techniques

The integration between PSS models and formal verification techniques revolves around leveraging the rich modeling capabilities of PSS to specify verification intent and generating formal properties automatically from these models. PSS provides a high-level abstraction for describing verification scenarios and behaviors, which can then be translated into formal properties for analysis by formal verification tools. This integration allows verification engineers to leverage the expressive power of PSS while harnessing the exhaustive analysis capabilities of formal verification.

A. Benefits of Combining PSS with Formal Verification:

The marriage between PSS and formal verification offers several compelling benefits for semiconductor verification:

Exhaustive Analysis: Formal verification techniques enable exhaustive analysis of design properties and behaviors, uncovering potential issues and corner cases that may go undetected by simulation-based techniques alone. By combining PSS with formal verification, verification teams can achieve higher levels of verification completeness and confidence.
Bug Hunting: Formal verification is particularly adept at uncovering subtle bugs and corner cases that may lurk within the design. By automatically generating formal properties from PSS models, verification engineers can perform comprehensive bug hunting and validation, helping to identify and rectify potential issues early in the development cycle.
Efficiency and Automation: The integration between PSS and formal verification streamlines the verification process and promotes automation. PSS models serve as a natural starting point for generating formal properties, reducing the manual effort involved in specifying properties and enabling faster turnaround times for verification tasks.

B. Challenges and Considerations for Integration:

While the integration between PSS and formal verification holds tremendous promise, it also presents several challenges and considerations:

Complexity: Formal verification techniques can be complex and require a deep understanding of formal methods and algorithms. Integrating PSS with formal verification may require specialized expertise and training to ensure successful adoption and implementation.
Coverage and Completeness: Formal verification techniques are inherently exhaustive, but they can also suffer from scalability limitations. Achieving comprehensive coverage and completeness with formal verification may require careful selection and prioritization of verification objectives and properties.
Tool Support: The availability and maturity of tools that support the integration between PSS and formal verification may vary. Verification teams may need to evaluate and select tools that best fit their verification requirements and infrastructure.

The integration between PSS and formal verification represents a powerful synergy that holds the potential to elevate semiconductor verification to new heights of excellence.

VI. Conclusion

As we conclude our exploration of advanced techniques in Portable Stimulus Standard (PSS) for semiconductor verification, let's take a moment to recap the key insights shared in this blog.

Throughout our journey, we've delved into a range of methodologies and strategies empowered by PSS, from constraint randomization to coverage-driven verification, scenario modeling and integration with formal verification. Each technique offers unique benefits and capabilities, all aimed at enhancing verification efficiency and effectiveness in semiconductor projects.

It's clear that the adoption of advanced PSS techniques is crucial for semiconductor verification teams striving to meet the demands of modern chip designs. These techniques provide a standardized framework for specifying verification intent, capturing complex system behaviors, and accelerating verification cycles. By embracing advanced PSS techniques, verification teams can overcome verification challenges more effectively and ensure the functional correctness of semiconductor products.

As we conclude, I encourage readers to explore and experiment with these advanced PSS techniques in their verification projects. There is immense value in leveraging the power of PSS to drive innovation and excellence in verification practices.

Let's seize the opportunity to leverage the power of PSS and propel semiconductor verification into a new era of efficiency and effectiveness. The possibilities are boundless, and the future is ours to shape.

Happy verifying!

Understanding the Core Components of Portable Stimulus Standard (PSS) Models

Pratik Parvati — Sun, 01 Oct 2023 11:16:44 +0000

In the previous blog of our exploration into Portable Stimulus and Test Standard (PSS), we embarked on a journey to demystify this groundbreaking approach to semiconductor verification. We covered the basics, from understanding traditional verification methods to uncovering the advantages that PSS brings to the table. We also discussed the widespread adoption and enthusiastic industry support that PSS has garnered, as well as its promising future outlook. If you have followed along so far, thank you for joining us on this path of discovery.

In this blog we are going to take a deeper dive into the core components that make up PSS models. Whether you are new to PSS or looking to enhance your understanding, this blog will equip you with the knowledge necessary to comprehend and utilize this powerful verification methodology effectively. Throughout this blog, we will explore the elements, behavior abstraction mechanisms, modeling of data flow and system resources, and much more. By the end of this journey, you will have a solid grasp of the fundamental concepts that underpin PSS models, setting the stage for more advanced discussions in our upcoming blogs.

I. Purpose of the PSS Model Components

To understand the purpose of PSS model components, we must first recognize that a PSS model is not a monolithic entity but a well-organized collection of elements designed to address various aspects of semiconductor verification. These components serve specific roles in defining and executing verification scenarios.

Think of these components as the building blocks of our verification strategy. Their primary purpose is to make our lives as verification engineers more manageable. Let's explore why we use these components:

A. Modularity and Reusability

These components are like LEGO bricks for verification engineers. They allow us to take complex verification tasks and divide them into smaller, reusable parts. This modularity is like having a toolkit of specialized instruments that we can use across different projects and teams.

B. Abstracting Behavior

Imagine you are an artist. Instead of painting every single detail, you use broad strokes to capture the essence of your subject. Similarly, these components help us abstract the behavior we want to verify. We don't need to get bogged down in the nitty-gritty technical details; we focus on the big picture.

C. Scenario Creation

Just like in a movie, we have different scenes that tell a story. These components help us create various verification scenarios. Each scenario is like a different plotline, exploring different aspects of the device we are testing.

D. Defining Relationships

Think of these components as the scriptwriters of our verification story. They define how different parts of the verification environment interact with each other. It's like choreographing a dance – everything needs to be in sync.

E. Reusable Libraries

Imagine having a library of common phrases you can use in various languages. Similarly, these components help us create libraries of verification intent. We can share these libraries across teams and projects, ensuring consistency and saving time.

F. Hierarchical Organization

We can organize these components in a tree-like structure. It's like breaking a big task into smaller sub-tasks. This hierarchical approach keeps things organized and makes it easier to manage complex verification scenarios.

II. Elements of a PSS Model

when we dive into the world of Portable Stimulus Standard (PSS) models, we encounter a structured framework designed to bring order to the often complex task of semiconductor verification. These models consist of several essential elements, each serving a unique purpose. Let's explore these elements and their roles:

A. Actions as Primary Behavior Abstractions

Atomic Actions: Think of these as the fundamental actions that our verification environment can perform. They represent the basic building blocks of behavior, much like individual steps in a dance routine. Atomic actions are precise, well-defined, and map directly to operations performed by the device under test (DUT) or test environment.
Compound Actions: These are like choreographed sequences of atomic actions. They encapsulate complex behaviors by defining relationships between specific actions. Compound actions specify the critical intent to be verified by specifying how various atomic actions interact.

// Define Atomic Actions
action AtomicAction1 {
    // Specify the behavior of Atomic Action 1
    // This could involve sending a specific command to the DUT
}

action AtomicAction2 {
    // Specify the behavior of Atomic Action 2
    // This could involve reading a register value from the DUT
}

action AtomicAction3 {
    // Specify the behavior of Atomic Action 3
    // This could involve checking a signal value on the DUT
}

// Define a Compound Action
action CompoundAction {
    // Specify the behavior of the Compound Action
    // This involves sequencing Atomic Actions to perform a higher-level operation
    // For example, initializing the DUT
    AtomicAction1;
    AtomicAction2;
    AtomicAction3;
}

B. Scenarios and Their Role

Scenarios are like the scripts of our verification story. They define a set of possible situations or sequences of actions to be applied to the DUT. Each scenario represents a specific verification intent.
Scenarios are composed of behaviors executed by components that make up the DUT or verification components that define the test environment. They specify how these behaviors interact and communicate with each other.

// Define actions
action AtomicAction1 {
    // Define behavior for AtomicAction1
}

action AtomicAction2 {
    // Define behavior for AtomicAction2
}

action AtomicAction3 {
    // Define behavior for AtomicAction3
}

// Define components
component Component1 {
    action actionA {
        // Define behavior for actionA
    }

    action actionC {
        // Define behavior for actionC
    }
}

component Component2 {
    action actionB {
        // Define behavior for actionB
    }
}

component Component3 {
    action actionD {
        // Define behavior for actionD
    }
}

// Define scenarios using CompoundActions
action Scenario1 {
    activity {
        AtomicAction1;
        AtomicAction2;
        Component1::actionA;
        Component2::actionB;
    }
}

action Scenario2 {
    activity {
        AtomicAction3;
        Component1::actionC;
        Component3::actionD;
    }
}

C. Communication Between Actions

Actions don't operate in isolation. They need to communicate and coordinate with each other. It's like actors in a play interacting to tell a story.
PSS models define how actions communicate, exchange data, and share resources. This communication is critical for capturing the dynamic behavior of a semiconductor device accurately.

D. PSS Model Components and Their Relationships

PSS models consist of various components, each with a specific purpose. These components work together to create a coherent verification strategy.
Understanding the relationships between these components is key to effective verification. It's like knowing how different instruments in an orchestra harmonize to produce beautiful music.

In summary, the elements of a PSS model are like the ingredients in a recipe. Atomic actions, compound actions, scenarios, and communication mechanisms are combined to create a verification strategy that accurately captures the behavior of semiconductor devices. These elements provide the flexibility and precision needed to tackle the complexities of modern verification challenges.

III. Behavior Abstraction Mechanisms

Now that we have introduced the core elements of Portable Stimulus Standard (PSS) models, let's dive deeper into the behavior abstraction mechanisms that power these models.

A. Actions and Their Significance

Actions are the heart and soul of PSS models. They represent specific behaviors or sets of behaviors that our verification environment needs to enact.
Think of actions as the verbs in our verification story. They encompass everything from reading and writing data to controlling the flow of operations.
Actions are like the instructions given to actors in a play—they dictate what needs to happen at each moment in the verification process.

B. Atomic Actions and Their Implementation

Atomic actions are like the simplest, indivisible steps in our verification dance. They correspond directly to operations performed by the device under test (DUT) or the test environment.
What makes atomic actions powerful is their explicit mapping of behavior to an implementation on the target platform. It's like having a detailed choreography that tells each dancer exactly how to move.
These atomic actions come in several supported forms, ensuring compatibility with various verification platforms and technologies.

C. Compound Actions and Their Role in Specifying Intent

While atomic actions are the basic steps, compound actions are more like intricate dance routines. They encapsulate flows of other actions and define the critical intent to be verified.
Compound actions provide the high-level structure for verification scenarios. They specify how different atomic actions interact, creating a coherent narrative for verification.
It's similar to a director's vision for a play—how different scenes, dialogues, and actions come together to convey a compelling story.

IV. PSS Model Rules and Processing Tools

In the world of Portable Stimulus Standard (PSS) models, there are certain rules and processing tools that play a crucial role in shaping the verification process. Let's delve into this aspect.

A. Rules Governing PSS Model Creation

Creating PSS models isn't a free-for-all creative process; there are rules in place to ensure consistency and effectiveness.
These rules define how elements within a PSS model should be structured, connected, and configured. They act as the guiding principles that maintain the integrity of the verification strategy.
Think of these rules as the grammar and syntax of the verification language. They ensure that your verification story is well-structured and coherent.

B. Addressing Incomplete Specification of Intent

In the real world, specifications might not always be complete. There might be gaps or uncertainties in the verification intent.
This is where PSS processing tools come to the rescue. They have the intelligence to infer the execution of additional actions and model elements to make a partial specification complete and valid.
It's akin to a skilled editor who fills in the missing pieces of a story, ensuring that the narrative flows seamlessly.

C. Role of PSS Processing Tools in Scenario Generation

PSS processing tools are like the directors and choreographers of our verification play. They take the script (PSS model) and turn it into live scenarios.
These tools analyze the model, evaluate the hierarchy of activities, and infer actions and data flow objects as needed.
The goal is to generate scenarios that implement the critical verification intent while adhering to data flow, scheduling, and resource constraints of the target device under test (DUT) and its associated test environment.

V. Modeling Data Flow in PSS

Understanding how data flows within a Portable Stimulus Standard (PSS) model is fundamental to creating effective and robust verification strategies. Let's explore the intricacies of modeling data flow in PSS.

A. Types of Data Flow Objects

Data flow objects are the channel through which information travels within the PSS model. There are several types of data flow objects, each with its unique characteristics.
Buffers: Buffers represent persistent data that can be written by one action and read by one or more other actions. This establishes a strict scheduling dependency between the producer and the consumer. The producer must complete its execution before the consumer can begin reading the buffer.
Streams: Stream flow objects are used for transient data exchange between actions. The key feature of stream objects is that the producer and consumer actions execute in parallel. There's a one-to-one connection between them, ensuring synchronized data transfer.
States: State flow objects represent the state of some element in the device under test (DUT) or test environment. Multiple actions may read or write the state object, but only one write action can execute at a time. Read actions can occur in parallel, but reads and writes are sequential.

// Define data flow objects
buffer Buffer1 {
    // Define properties and behavior for Buffer1
}

stream Stream1 {
    // Define properties and behavior for Stream1
}

state State1 {
    // Define properties and behavior for State1
}

// Define actions that use data flow objects
action ProducerAction {
    output Buffer1 bufferOutput; // Producer writes to Buffer1
    output Stream1 streamOutput; // Producer writes to Stream1
    output State1 stateOutput;   // Producer writes to State1

    // Define behavior for the producer action
}

action ConsumerAction {
    input Buffer1 bufferInput; // Consumer reads from Buffer1
    input Stream1 streamInput; // Consumer reads from Stream1
    input State1 stateInput;   // Consumer reads from State1

    // Define behavior for the consumer action
}

B. Scheduling Dependencies and Constraints

The choice of data flow object type influences the scheduling semantics within the PSS model.
For buffers, the producer-consumer relationship enforces a strict scheduling constraint, ensuring that the producer completes before the consumer starts.
Streams allow parallel execution of producer and consumer actions, fostering concurrency and efficiency.
State objects maintain sequential access to maintain the integrity of the state.

C. Data Flow Object Pools

To manage data flow objects efficiently, they are grouped into pools.
In buffer and stream types, the pool contains the number of objects needed to support communication between actions sharing the pool.
For state objects, the pool contains only one object at any given time. All actions sharing a state object via a pool see the same value for the state object.

// Define a structure for mem_segment
struct mem_segment_s {
    // Define structure members here if needed
}

// Define a buffer for data
buffer data_buff_s {
    rand mem_segment_s seg; // Randomly generated mem_segment_s object
}
// Define a sub-component dma_sub_c
component dma_sub_c {
    // Define properties and behavior for dma_sub_c
    // ...
}

// Define the main dma_c component
component dma_c {
    dma_sub_c dmas1, dmas2; // Sub-components of dma_c

    // Define a pool for data buffers
    pool data_buff_s buff_p;

    // Bind all instances of data_buff_s to the pool
    bind buff_p {*};

    // Define an action mem2mem_a
    action mem2mem_a {
        input data_buff_s in_data;   // Input data buffer
        output data_buff_s out_data; // Output data buffer

        // Define behavior for the mem2mem_a action
        // ...
    }
}

Understanding data flow in PSS models enables verification engineers to design scenarios that reflect real-world data interactions in semiconductor devices. It allows for precise modeling of how information is shared, transferred, and processed, ultimately leading to comprehensive and effective verification strategies.

VI. Modeling System Resources

In a Portable Stimulus Standard (PSS) model, the representation of system resources plays a pivotal role in ensuring the accurate and efficient verification of semiconductor devices. Let's delve into the key aspects of modeling system resources in PSS.

A. Resource Objects and Their Purpose

Within PSS models, we encounter something known as "resource objects." These aren't mysterious entities; think of them as fundamental building blocks that represent different aspects of your verification environment.
Resource objects are user-defined data objects within the PSS model that represent system resources required for verification.
These resources can encompass a wide range of elements, including hardware components, software packages, or testbench agents.
Resource objects are essential for defining the functionality and availability of various system resources that actions within the model may require.

B. Resource Pools and Their Role

Now, imagine a resource object as a piece of a puzzle. To assemble the full picture, we group resource objects into "resource pools." These pools act as orchestrators, determining how resources are managed and accessed.
The size of each resource pool corresponds to the number of available resource instances in your device under test (DUT) or test environment. It's akin to having a specific number of seats at the verification table.

C. Locking Resources for Exclusive Access

Sometimes, during the verification process, certain actions require undivided attention from a particular resource. To ensure this exclusive focus, actions can "lock" a resource.
Think of it as reserving a room for a private meeting. While the room is locked, no one else can enter until the meeting concludes. Similarly, a locked resource is exclusively dedicated to the locking action until it completes its task.

D. Sharing Resources for Non-Exclusive Access

On the flip side, not all actions demand exclusive access to resources. Some can work collaboratively, sharing the same resource without conflict.
Picture a communal workspace. Multiple people can utilize it simultaneously, as long as there's room. In the world of PSS, actions can similarly share resources, provided they don't exceed the resource pool's capacity.

Effectively modeling system resources in PSS empowers verification engineers to define how various components and agents interact with critical resources during the verification process. This level of control ensures that resources are allocated efficiently, minimizing contention and maximizing the effectiveness of verification scenarios. PSS provides a versatile framework for resource management, enabling engineers to mirror real-world resource interactions within semiconductor devices.

// Define a resource object for DMA channels
resource DMA_channel_s {
    rand bit[3:0] priority;
}

// Define a resource object for CPU cores
resource CPU_core_s {
    string core_name;
    int core_id;
}

// Define an action that performs a two-channel transfer
action two_chan_transfer {
    // Acquire locks on two DMA channels
    lock DMA_channel_s channel_A;
    lock DMA_channel_s channel_B;

    // Share a CPU core for control
    share CPU_core_s control_core;

    // Other actions or properties specific to the transfer
    // ...
}

VII. Basic Building Blocks

Now that we have explored the realm of resource management in PSS models, let's delve into another crucial aspect: the basic building blocks that form the foundation of these models. If you are new to PSS, fear not - we will start from the ground up

A. Components and Their Structural Role

Think of a "component" as a fundamental structural element within a PSS model. In simpler terms, it's like a building block in your model's architecture.
These components are often associated with specific parts of your verification environment or the device under test (DUT). They encapsulate various behaviors and functionalities related to these components.
Each component declaration defines a unique type that can be instantiated within other components, creating a hierarchical structure.

B. Hierarchical Component Instantiation

PSS models embrace a hierarchical approach to modeling. This means that components can be instantiated within other components, forming a tree-like structure.
This hierarchy allows you to manage and organize the complexity of your verification environment. You can break down intricate systems into more manageable subcomponents.
It's akin to assembling a puzzle, where each piece (component) fits into the larger picture, contributing to the overall verification strategy.

// Define a basic component representing a building block
component basic_component {
    // Properties and behaviors related to this component
    bit[32] component_id;
    string description;

    // Action specific to this component
    action component_action {
        // Action implementation specific to this component
        // ...
    }
}

// Define a higher-level component that can contain other components
component higher_level_component {
    // Properties and behaviors specific to this higher-level component
    string component_name;

    // Hierarchical instantiation of basic components within this component
    basic_component sub_component1; // Instantiate a basic component
    basic_component sub_component2; // Instantiate another basic component

    // Action specific to this higher-level component
    action higher_level_action {
        // Action implementation specific to this higher-level component
        // ...
    }
}

VIII. Evaluation and Inference

Now that we've covered the basic building blocks of a Portable Stimulus Standard (PSS) model, let's explore how these models are evaluated and how inference is used to create verification scenarios.

A. Starting the PSS Model Evaluation

The journey of a PSS model begins with its evaluation. This evaluation process typically starts with the top-level action, often referred to as the "root action." The root action serves as the entry point to the model. It's important to specify this action because it defines the context in which the entire model operates.
Imagine it as the starting point of a road trip; you need to know where you are beginning your journey. In PSS modeling, you specify the root action to determine where your verification scenario begins.

// Define a basic component representing a building block
component basic_component {
    // Properties and behaviors related to this component
    bit[32] component_id;
    string description;

    // Action specific to this component
    action component_action {
        // Action implementation specific to this component
        // ...
    }
}

// Define a higher-level component that can contain other components
component higher_level_component {
    // Properties and behaviors specific to this higher-level component
    string component_name;

    // Hierarchical instantiation of basic components within this component
    basic_component sub_component1; // Instantiate a basic component
    basic_component sub_component2; // Instantiate another basic component

    // Action specific to this higher-level component
    action higher_level_action {
        // Action implementation specific to this higher-level component
        // ...
    }
}

component top_component {
    higher_level_component high_component1;
    // Define the top-level action, which serves as the root action for model evaluation
    action top_level_action {
        // This is the starting point of the PSS model evaluation
        // Specify the context and behavior for the entire model
        // ...
        higher_level_component::higher_level_action;
    }
}

B. Hierarchical Activity Tree

Once the root action is defined, the PSS model forms a hierarchical activity tree. This tree encompasses all the activities present in the model, including those within subcomponents. Think of this tree as the roadmap that guides the flow of actions and behaviors within your verification scenario.
The hierarchical structure of the activity tree allows for a systematic and organized representation of the verification intent. It's similar to breaking down a complex task into smaller, manageable sub-tasks. Each component and action in the tree has its place and role in achieving the verification goal.

C. Inferring Actions and Objects to Support the Model

Inference is a fundamental concept in PSS modeling. It refers to the process of automatically generating additional actions, data flow objects, and resources to support the specified verification intent. In other words, inference ensures that your model is complete and valid by filling in the missing pieces.
For instance, if an action requires a specific data flow object as input, the inference mechanism will automatically generate actions to provide that input. This helps in satisfying the data flow, scheduling, and resource constraints of the verification scenario.
Inference is a powerful feature that simplifies the creation of complex scenarios. It eliminates the need to manually specify every detail, making PSS modeling more efficient and less error-prone.

As you explore PSS further, you will gain a deeper understanding of how the evaluation process and inference mechanism work together to generate comprehensive verification scenarios.

IX. Constraints and Inference

In the context of PSS, "Constraints and Inference" are fundamental aspects of creating robust verification scenarios. These components help shape how actions and objects behave within the verification model, ensuring that the scenarios generated are meaningful, realistic, and fulfill the intended verification goals.

A. Constraint Expressions on Data Flow and Resource Objects

Understanding Constraint Expressions : In PSS, constraint expressions are like the rules that govern how actions and data flow objects interact. They define the conditions and limitations that ensure the scenarios remain consistent with real-world behaviors.
Ensuring Realism : Constraints ensure that verification scenarios accurately mimic real-world situations. They allow you to specify limitations on data flow, resources, and behaviors, creating a testing environment that resembles the actual use of the product.

B. Combining Constraints for Valid Scenarios

Harmonizing Constraints : PSS often involves numerous constraints from different sources, such as action behaviors, data flow requirements, and resource limitations. Combining these constraints is akin to harmonizing a complex piece of music—each component must align to create a coherent composition.
Achieving Balance : Balancing constraints is crucial. Too many constraints can make scenarios overly restrictive, while too few can result in unrealistic or unattainable scenarios. The goal is to find a sweet spot that ensures both feasibility and relevance.

C. Ensuring Valid Solutions

Resolving Constraint Puzzles : Valid solutions in PSS involve resolving constraint puzzles. It's about finding configurations and values for actions and objects that satisfy all defined constraints. This process is akin to solving a puzzle with many interlocking pieces.
Addressing Conflict : Sometimes, constraints can conflict with each other, creating a puzzle with pieces that don't fit. Engineers must identify and address these conflicts to ensure that the verification process proceeds smoothly.

// Define a PSS component for my_ip_c
component my_ip_c {
    struct my_struct {
        rand int a;
    };

    action my_op {
        rand my_struct s;
    }
}

// Define a PSS component for pss_top
component pss_top {
    my_ip_c my_ip;

    // Define a struct your_struct
    struct your_struct {
        rand int a;
    };

    // Test action
    action test {
        rand your_struct s;

        // Constraint for your_struct literal
        constraint s == {.a == 2};

        // Instantiate my_ip_c::my_op as 'op'
        my_ip_c::my_op op;

        // Constraint for my_ip_c::my_struct literal
        constraint op.s == {.a == 3};

        activity {
            // Execute the my_ip_c::my_op action
            op;
        }
    }
}

Now, let's explore each subtopic in more detail with concise points

X. Summary of PSS Model Concepts

PSS Components: In this blog, we explored the key components that make up a Portable Stimulus Standard (PSS) model. These components define a set of scenarios used to verify semiconductor designs. They include actions, scenarios, and the communication between them.
Behavior Abstraction: We delved into the central role of actions in PSS models. Actions are the primary abstraction mechanism for defining behaviors. We discussed atomic actions, which directly correspond to operations performed by the Design Under Test (DUT) or test environment, and compound actions, which encapsulate flows of other actions, specifying critical intent and relationships between actions.
Model Rules and Processing Tools: Understanding the rules governing PSS model creation is vital. We explored how PSS processing tools use these rules to generate scenarios that implement the verification intent while considering data flow, scheduling, and resource constraints. We also discussed how tools handle partial intent specifications.
Modeling Data Flow in PSS: Data flow is a fundamental aspect of PSS models. We introduced data flow objects, including buffers, streams, and states. Buffers represent persistent data with strict scheduling dependencies. Streams denote transient data exchanged in parallel, while states represent the state of elements in the DUT or test environment at a given time.
Modeling System Resources: System resources play a critical role in PSS models. We discussed resource objects and their purpose, as well as resource pools, which define the set of actions with access to these resources. Locking and sharing resources for exclusive or non-exclusive access were also explained.
Basic Building Blocks: PSS models are built using components that encapsulate elements of verification intent. We explained how components are hierarchically structured and how they can contain functions and class instances, serving as a foundation for reusable models.
Evaluation and Inference: To comprehend how PSS models work, we covered the process of evaluating a model, starting with the top-level root action. Hierarchical activity trees are used to manage activities and infer actions and objects to support the model.
Constraints and Inference: Constraint expressions on data flow and resource objects were introduced. We explored how these constraints are combined to ensure valid scenarios, with at least one valid solution required for a model to be considered valid.
Multiple Scenarios: A single PSS model can yield multiple scenarios, each with its set of inferred actions, objects, and resources. These scenarios all implement the critical verification intent but may include additional behaviors.
Test Implementation: We emphasized that PSS models are not just abstract representations; they translate into practical test implementations for the target semiconductor platform.
Importance: Highlighting the significance of PSS models, we discussed how they enhance verification efficiency and coverage in the semiconductor industry.
Future Topics: As a closing note, we pointed out that this blog provides a foundation for exploring advanced PSS concepts and applications. Readers are encouraged to dive deeper into the world of Portable Stimulus Standards.
Further Learning: To expand their knowledge, readers are encouraged to explore additional resources and engage in discussions about PSS models, as this field continues to evolve.

XI. Conclusion

In the realm of semiconductor verification, Portable Stimulus Standard (PSS) models offer a revolutionary approach. These models simplify complex verification challenges, enhancing productivity and test coverage.

As we have explored PSS components, from actions to scenarios, remember that PSS is your gateway to efficient verification. It's a dynamic field, so keep exploring, learning, and innovating.

PSS models are more than a standard; they are a catalyst for innovation in semiconductor verification. Embrace the opportunities and stay tuned for further discoveries.

Thank you for joining us on this enlightening journey.

Demystifying the Portable Stimulus and Test Standard (PSS): Revolutionizing Semiconductor Verification

Pratik Parvati — Sat, 23 Sep 2023 11:31:48 +0000

The world runs on semiconductors. From the moment we wake up to our smartphone's alarm, to our daily commute in smart vehicles, and even during our leisure time with the latest gaming consoles, semiconductors silently power our lives. These tiny chips, etched with precision, coordinate the complex performance of today's technology.

As technology continues to surge forward, the complexity of these systems grows exponentially. The tried-and-true verification methods that served us well in the past are increasingly strained. They demand more time, more resources, and more effort. This is where the Portable Stimulus Test and Standard (PSS) emerges as a game-changer, a beacon of innovation in semiconductor verification. PSS represents a paradigm shift, offering a standardized approach to verification that promises to revolutionize how we ensure the reliability of these vital semiconductor systems

In the following sections of this article, we will journey through the world of semiconductor verification, exploring the challenges of traditional methods and unveiling the power of Portable Stimulus.

Traditional Verification Methods

Before the emergence of the PSS, semiconductor verification heavily relied on traditional methods that had long been the cornerstone of the industry. These methods, while effective in their time, are facing increasing challenges in the modern landscape of semiconductor design and verification.

1. Manual Test Case Development

Traditional verification often involves the manual development of test cases. Engineers meticulously design and implement each test case, step by step. This manual approach is not only time-consuming but also prone to human error. As systems have grown in complexity, the sheer number of test cases required has become overwhelming.

2. Lack of Reusability

Another limitation of traditional methods is the lack of reusability. Test cases created for one specific platform or tool are often not portable to other environments. This lack of reusability results in engineers repeatedly recreating similar test cases for different projects, leading to significant redundancy in efforts.

3. Complexity Challenges

As electronic systems have evolved, their complexity has grown exponentially. Traditional verification methods, which were effective for simpler systems, struggle to keep up. It's akin to trying to solve a Rubik's Cube blindfolded – the challenges become increasingly daunting as the complexity of the system grows.

What is Portable Stimulus?

Portable Stimulus, often abbreviated as PSS, represents a revolutionary approach to semiconductor verification. At its core, PSS is a technology that enables the creation of abstract models of verification tests, which can be reused across different platforms and tools. It introduces a fundamental shift in how verification tests are conceptualized. Instead of focusing on the minute implementation details, PSS emphasizes capturing the "what" of a test rather than the "how." This abstraction allows for the creation of test scenarios in a more intuitive and versatile manner.

Moreover, PSS is designed with reusability in mind. Test scenarios created using PSS are designed to be reusable across different platforms, tools, and environments. This reusability significantly reduces the effort required to adapt and apply tests to various verification challenges.

The Need for Portable Stimulus:

Semiconductor verification is a vital step in the development of electronic systems, ensuring that they operate flawlessly in a world that demands increasingly complex functionalities. However, the traditional methods that have long served as the backbone of verification processes are facing significant challenges in today's landscape. Here's why there's an urgent need for a paradigm shift, and why PSS has emerged as the solution with regards to traditional verification methods.

1. Manual Test Case Development

In the traditional verification methods, engineers carefully create every test scenarios, outlining all the fine details of the tests. PSS automates and abstracts this process and it frees engineers from the tiresome work of manual test case development, enabling them to focus on the critical aspects of verification.

2. Redundancy and Duplication

In the traditional approach, engineers frequently find themselves recreating similar test cases for different projects. PSS is a game-changer in this regard. It promotes test scenario reusability, eliminating the need for repetitive work. Engineers can now create abstract test models that can be applied across various projects, ensuring consistency and reducing duplication.

3. Portability

Traditional test cases are often tightly bound to specific platforms, tools, or environments, limiting their adaptability and reusability. PSS offers a solution by providing a standardized framework for creating abstract tests. These tests are platform-agnostic and can be seamlessly applied across different verification environments, promoting flexibility and efficiency.

4. Growing Complexity

In traditional verification methods, engineers are tasked with verifying intricate designs that involve countless interconnected components. PSS addresses this challenge head-on by introducing abstraction and automation. Test scenarios created using PSS can efficiently verify complex systems, ensuring that no critical functionality is overlooked.

5. Comprehensive Coverage and Constraints

PSS introduces comprehensive coverage metrics and constraints as an integral part of the verification process. This ensures that verification is comprehensive, and engineers can define specific conditions that must be met during testing. Traditional methods often struggle to provide this level of coverage.

6. Standardization

PSS is standardized, providing a common framework and vocabulary for semiconductor verification. This standardization ensures consistency and reliability, making it accessible and beneficial to all stakeholders in the industry.

Advantages of Portable Stimulus:

The Portable Stimulus Standard (PSS) offers a various advantages in the field of semiconductor verification, fundamentally changing how engineers verify their systems. Its transformative power stems from its capacity to address long-standing challenges and simplify the verification process. Below are the primary benefits of PSS, each presenting a distinct value proposition.

1. Early-Stage Validation

PSS grants the ability to perform thorough system-level validation at an early stage, allowing engineers to identify and address issues during the design phase instead of encountering them in later development phases. By detecting potential obstacles in their early stages, semiconductor companies can avoid costly design revisions and optimize their development processes

2. Efficiency and Cost Reduction

PSS greatly simplifies the process of developing test cases, reducing the time and resources typically needed. Engineers no longer need to create complex, platform-specific tests from scratch. This increased efficiency directly leads to cost savings, enabling companies to allocate resources more wisely and accelerate product launches.

3. Interoperability Across Platforms

PSS stands out for its exceptional cross-platform compatibility. Test scenarios developed using PSS can seamlessly run on various verification platforms, encompassing simulation, emulation, FPGA-based prototyping and Silicon. This adaptability guarantees that verification efforts remain consistent and flexible throughout different phases of the design process

4. Improved Verification Scope

PSS enhances verification coverage by simplifying test scenarios at a more abstract level. This simplification empowers engineers to create thorough verification plans that methodically examine the design. Consequently, semiconductor experts can have complete confidence in the durability and reliability of their products

5. Increased Automation

Automation is deeply integrated into PSS. The abstract nature of test scenarios enables more extensive automation in both generating and executing test cases. This automation not only speeds up the verification process but also reduces the chances of human errors, enhancing the overall trustworthiness of the verification endeavors.

6. Adaptability to Complex Systems

PSS shines when it comes to verifying complex electronic systems. It effortlessly handles intricate designs with a complex network of interconnected components and multifaceted functions. Semiconductor experts can confidently tackle the complexities of modern systems using PSS as their verification solution

Adoption and Industry Support

The Portable Stimulus Standard (PSS) isn't just a theoretical idea; it's a practical solution that's gaining substantial momentum in the semiconductor sector. The broad acceptance of PSS is backed by key organizations, industry pioneers, and collaborative efforts.

1. Accellera Systems Initiative

Accellera Systems Initiative, a big industry group, is really important for making and spreading PSS. They are the ones working hard to make PSS a standard everyone can use. Accellera's commitment to open standards has helped PSS become widely accepted and encouraged people in the industry to work together.

2. EDA Tool Vendors

Electronic Design Automation (EDA) tool vendors have been proactive in incorporating PSS capabilities into their toolsets. They recognize the demand for tools that support this standardized approach to verification. This support ensures that engineers have the necessary tools and infrastructure to effectively implement PSS in their verification workflows.

3. Leading Semiconductor Companies

Big players in the semiconductor industry are taking the lead in adopting PSS. These industry leaders understand the significant benefits that PSS brings in terms of improving the efficiency and dependability of verification. Their support and use of PSS are propelling it towards becoming a widely accepted and recommended approach in semiconductor verification.

4. Acknowledgment Across the Industry

PSS is widely recognized as a transformative factor in semiconductor verification. Industry leaders, engineers, and verification experts have all recognized its potential to bring about significant changes in the verification methods.

5. Educational Programs

Educational programs and training courses focused on PSS have emerged to equip engineers with the knowledge and skills needed to leverage this technology effectively. This investment in education further supports PSS adoption.

Challenges and Limitations:

While Portable Stimulus Standard (PSS) holds immense promise in the field of semiconductor verification, it is essential to recognize that its adoption and implementation are not without challenges and limitations. Here's an overview of some of the key considerations.

1. Tool Compatibility

Having access to tools that are compatible with PSS can sometimes pose a difficulty. Not all Electronic Design Automation (EDA) toolkits may come equipped with PSS features, which can restrict its use.
Organizations should evaluate their toolkits and consider investing in new tools or updates to make the most of PSS.

2. Standardization and Interoperability

While PSS is a standardized framework, ensuring complete interoperability across different tools and platforms can be a challenge. Variations in tool implementations can lead to compatibility issues.
Ongoing efforts within industry standards bodies are aimed at addressing these challenges and improving interoperability.

3. Over-Abstraction

Over-abstracting verification scenarios can lead to a lack of detail, potentially missing important corner cases or nuances of the design. Engineers must strike a balance between abstraction and granularity to ensure effective verification.

4. Learning Curve

Transitioning from traditional verification methods to PSS may require a learning curve for engineers and verification teams. PSS introduces a paradigm shift, emphasizing abstraction and reusability over traditional detailed test case development. Organizations need to invest in training and resources to ensure their teams are proficient in using PSS effectively.

5. Adoption Hesitancy

Encountering resistance to change is a common obstacle when introducing new approaches like PSS. Engineers and teams might feel at ease with traditional verification methods and be hesitant to adopt something new. To surmount this challenge, it's vital to implement effective change management and communication strategies.

6. Complex Integration

Adding PSS to how things are already done can be complicated. Companies need to plan carefully and make sure it fits in without causing problems for ongoing projects. They might need to check how well it works with the tools and ways they already use and make adjustments if needed.

7. Cultural Shift

Changing from a culture where detailed test cases are the norm to one that values abstraction and reusability can be a challenge in terms of culture. Engineers and teams might require some time to fully accept the PSS approach.

8. Standardization Overhead

While standardization is a strength of PSS, it can also introduce some level of overhead. Organizations may need to invest time and resources in complying with and adhering to the standard. Balancing the benefits of standardization with the potential overhead is a consideration for PSS adopters.

Understanding and addressing these challenges and limitations is essential for organizations looking to harness the full potential of Portable Stimulus Standard (PSS). While these hurdles exist, they are not insurmountable, and the benefits of PSS in terms of efficiency, reliability, and adaptability make it a compelling option for semiconductor verification.

Future Outlook:

The upcoming developments in the Portable Stimulus Standard (PSS) promise exciting changes in the world of semiconductor verification. As PSS gains more traction and more people start using it, we can anticipate several significant trends and advancements that will influence its future.

1. Broader Industry Adoption

PSS is no longer limited to just the semiconductor industry. Different sectors like automotive, aerospace, and IoT are realizing the advantages of using standardized and abstract verification methods.
As PSS demonstrates its versatility across various fields, we can expect more industries to embrace and incorporate it.

2. Maturation of PSS Standards

PSS standards will keep progressing and becoming more refined. Groups of companies and organizations responsible for standards are actively refining the specifications, resolving uncertainties, and improving how PSS works across different systems. This ongoing improvement process guarantees that PSS stays a strong and dependable tool for verifying semiconductors.

3. Improved Tools and Ecosystem

Anticipate ongoing progress in PSS tools and support systems. Companies that make Electronic Design Automation (EDA) tools are likely to make PSS integration even better, making it easier and more user-friendly. These improvements will allow design and verification teams to use PSS to its full potential with more convenience and efficiency.

4. Standardization Beyond Verification

The principles of standardization that PSS follows might go beyond just verification. Ideas like abstraction, reusability, and portability could have an impact on other parts of the design process, such as figuring out the system's structure and developing software. This wider standardization could result in a more unified and connected method for designing systems.

5. System-Level Verification

PSS is poised to play a larger role in validating entire systems at the system level. With the growing importance of verifying complex electronic systems, PSS offers a way to thoroughly test complete systems. Its abstract and adaptable characteristics make PSS a valuable resource for tackling the difficulties of system-level validation

Conclusion:

The Portable Stimulus Standard (PSS) is transforming the way semiconductor verification works, overcoming the limitations of older methods. Its standardized, abstract, and adaptable approach improves test coverage, reduces time and expenses, and gains widespread acceptance across the industry. Although challenges remain, the remarkable potential of PSS and its continuous integration with new technologies hold the promise of shaping the future of semiconductor verification

Design Pattern - Factory

Pratik Parvati — Sat, 08 Jul 2023 13:34:58 +0000

Design Pattern - Factory

The factory method design pattern is one of the well-known GoF design patterns. It is a creational design pattern that uses factory methods to deal with creating instances without specifying the exact class of the object that will be created.

Factory Method is a creational design pattern that defines an interface or abstract class for creating an object, but allows subclasses to decide the type of objects that will be instantiated.

This pattern is named as a factory as it is responsible for manufacturing an Object. Factory design pattern is predicated upon an object-oriented encapsulation idea. In general, Object creation code is written on client side of the program, but with the factory design, we encapsulate object creation code inside the factory method. Therefore, the factory may return an object of one of the various classes mentioned within a program, based on the data supplied to it.

Motivation

Let's look at a scenario where there is a need to create different types of objects with varying configurations, but the exact type of object needed may not be known until runtime.

In the case of a computer game, the game may need to create different types of characters with varying abilities and characteristics. However, the exact type of character needed may not be known until runtime, as it may depend on factors such as the player's progress in the game or the level they are currently playing.

If we were to directly create objects using concrete classes for each character type, we would end up with code duplication and tightly coupled code. As the number of character types increases, managing the creation logic becomes cumbersome and error-prone. Additionally, modifying or adding new character types would require modifying existing client code, violating the principle of Open-Closed principle.

To address these challenges, we can apply the Factory Design Pattern. The Factory Design Pattern provides a structured approach to object creation, encapsulating the creation process within a factory class and promoting loose coupling between the client code and the concrete classes.

!Factory Design Pattern

Let's look at the below C++ example that doesn't use factory design pattern and analyze the potential problems.

#include <iostream>
#include <string>

// Character base class
class Character
{
public:
    virtual void displayInfo() const = 0;
    virtual void attack() const = 0;
    virtual void defend() const = 0;
    virtual ~Character() {}
};

// Concrete character classes
class Warrior : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Warrior: A strong melee fighter with high stamina." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Warrior attacks with a mighty swing!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Warrior raises a sturdy shield to block incoming attacks!" << std::endl;
    }
};

class Mage : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Mage: A magical spellcaster with powerful elemental abilities." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Mage casts a powerful fireball!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Mage conjures a protective barrier to deflect enemy spells!" << std::endl;
    }
};

class Archer : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Archer: A skilled marksman with exceptional ranged attacks." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Archer fires a precise arrow at the target!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Archer swiftly evades incoming attacks with precise movements!" << std::endl;
    }
};

// Client code
int main()
{
    Character *warrior = new Warrior();
    Character *mage = new Mage();
    Character *archer = new Archer();

    warrior->displayInfo();
    warrior->attack();
    warrior->defend();

    mage->displayInfo();
    mage->attack();
    mage->defend();

    archer->displayInfo();
    archer->attack();
    archer->defend();

    delete warrior;
    delete mage;
    delete archer;

    return 0;
}

In this example, characters are created directly in the client code without using the Factory Design Pattern. Each character type (Ex, Warrior, Mage, Archer) is instantiated using the concrete class constructors. The member functions simulate the specific actions that each character type can perform during the game.

Problems in the example

The potential problems include:

Code Duplication: Without the Factory Design Pattern, we end up duplicating the code for creating characters in multiple places throughout the client code. This can lead to inconsistencies and makes it harder to manage and modify the codebase.
Lack of Abstraction: There is no clear abstraction or separation between the client code and the creation of character objects. This can make the code harder to understand, maintain, and extend, especially as the number of character types grows.
Tight Coupling: The client code is tightly coupled to the concrete character classes. It directly creates objects using their constructors, making it harder to introduce new character types or modify the creation process without modifying the client code.
Limited Flexibility and Extensibility: Adding new character types or modifying the creation process requires modifying the client code. This violates the Open-Closed Principle, which states that code should be open for extension but closed for modification.

By using the Factory Design Pattern, we can address these problems by encapsulating the creation logic within a factory class, promoting loose coupling, providing an abstraction layer, and facilitating extensibility without modifying the client code.

The Solution

The Factory Method pattern suggests substituting direct object construction calls (made with the new operator) with invocations of a dedicated factory method. This provides a level of indirection between the client code and the actual creation of objects.

#include <iostream>
#include <string>

// Character base class
class Character
{
public:
    virtual void displayInfo() const = 0;
    virtual void attack() const = 0;
    virtual void defend() const = 0;
    virtual ~Character() {}
};

// Concrete character classes
class Warrior : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Warrior: A strong melee fighter with high stamina." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Warrior attacks with a mighty swing!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Warrior raises a sturdy shield to block incoming attacks!" << std::endl;
    }
};

class Mage : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Mage: A magical spellcaster with powerful elemental abilities." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Mage casts a powerful fireball!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Mage conjures a protective barrier to deflect enemy spells!" << std::endl;
    }
};

class Archer : public Character
{
public:
    void displayInfo() const override
    {
        std::cout << "Archer: A skilled marksman with exceptional ranged attacks." << std::endl;
    }

    void attack() const override
    {
        std::cout << "Archer fires a precise arrow at the target!" << std::endl;
    }

    void defend() const override
    {
        std::cout << "Archer swiftly evades incoming attacks with precise movements!" << std::endl;
    }
};

// CharacterFactory class
class CharacterFactory
{
public:
    static Character *createCharacter(const std::string &characterType)
    {
        if (characterType == "Warrior")
        {
            return new Warrior();
        }
        else if (characterType == "Mage")
        {
            return new Mage();
        }
        else if (characterType == "Archer")
        {
            return new Archer();
        }
        else
        {
            std::cout << "Invalid character type. Creating a default character." << std::endl;
            return new Warrior(); // Default to a Warrior character
        }
    }
};

// Client code
int main()
{
    // Create a Warrior character
    Character *warrior = CharacterFactory::createCharacter("Warrior");
    warrior->displayInfo();
    warrior->attack();
    warrior->defend();

    // Create a Mage character
    Character *mage = CharacterFactory::createCharacter("Mage");
    mage->displayInfo();
    mage->attack();
    mage->defend();

    // Create an Archer character
    Character *archer = CharacterFactory::createCharacter("Archer");
    archer->displayInfo();
    archer->attack();
    archer->defend();

    // Clean up the memory
    delete warrior;
    delete mage;
    delete archer;

    return 0;
}

This code demonstrates the use of the Factory Design Pattern to create different types of characters (Warrior, Mage, Archer) based on the character type provided. The CharacterFactory class acts as the factory responsible for creating character objects. The createCharacter static method in the factory takes a character type as input and returns a dynamically allocated instance of the corresponding concrete character class.

In the client code, various character objects are created using the CharacterFactory::createCharacter method and then utilized by calling their respective member functions (displayInfo, attack, defend). Finally, the dynamically allocated character objects are deleted to release the memory.

Here is a UML class diagram representing the example code:

In this UML class diagram:

The Character class is the abstract base class defining the common interface for all character types.
The Warrior, Mage, and Archer classes are concrete classes that inherit from Character and provide specific implementations of the character behaviors.
The CharacterFactory class is responsible for creating character objects. It has a createCharacter method that returns a Character* pointer to the created character object.
The client code asks CharacterFactory to create an object of Warrior, Mage, and Archer.

This approach offers several advantages.

Instead of tightly coupling the client code to specific concrete classes, the client code relies on the factory method to create the objects. This promotes loose coupling and enhances flexibility in the system.
The factory method encapsulates the object creation process, allowing for potential changes or variations in the way objects are instantiated. By centralizing the creation logic within the factory method, it becomes easier to modify or extend the object creation process without impacting the client code.
The factory method serves as a single entry point for creating objects, allowing for centralized control and consistency in the creation process. This can be particularly beneficial in scenarios where additional steps or validations are required during object creation.
The objects created by the factory method are commonly referred to as products. This distinction helps to highlight the fact that the factory method is responsible for creating specific types of objects and provides a clear abstraction for clients to interact with.

How to implement?

Identify the common interface: Determine the common interface that all the product classes will implement. This interface defines the operations that can be performed on the objects created by the factory.
Create an abstract base class: Declare an abstract base class (or interface) representing the common interface identified in the previous step. This class should have pure virtual methods that define the common operations.
Define concrete classes: Create concrete classes that inherit from the abstract base class. Each concrete class represents a specific product that can be created by the factory. Implement the virtual methods of the base class in these concrete classes.
Implement the factory class: Create a factory class that is responsible for creating objects of the concrete classes. The factory class should have a method that takes in parameters (such as a type or configuration) and returns a pointer to the base class (the abstract type). Within this method, use conditional statements or other logic to determine which concrete class to instantiate.
Utilize the factory class: In the client code, use the factory class to create objects by invoking the appropriate factory method. The client code should work with the abstract base class and the objects returned by the factory method, without being aware of the specific concrete classes.
Test and iterate: Test the implementation to ensure that objects are being created correctly and that the factory is functioning as expected. Make any necessary adjustments or enhancements based on the specific requirements of your application.

Conclusion

The Factory Design Pattern provides a way to create objects without specifying their exact types upfront. By using a factory class, you can centralize object creation, enhance code modularity, and facilitate runtime determination of object types. The pattern is valuable for scenarios where object creation involves complex logic, varying dependencies, or the need to conserve system resources. Overall, the Factory Design Pattern improves code flexibility, maintainability, and scalability.

Design Pattern - Builder

Pratik Parvati — Sat, 25 Mar 2023 17:33:50 +0000

The Gang of Four authors, namely Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm, formally documented the Software Design Patterns in 1995 after discovering and describing them. They divided design patterns into three main categories based on their purpose and functionality: Creational, Structural, and Behavioral patterns.

Creational Design Pattern

The Creational Design Pattern deals with object creation mechanisms and trying to create objects in a manner suitable to the situation. It focuses on how the objects are created and utilized in an application. They provide ways to create objects while hiding the creation logic, abstracting it from the client code. The new operator is often considered harmful as it scatters objects all over the application; over time it can become challenging to change an implementation because classes become tightly coupled. Creational Design Patterns address this issue by decoupling the client entirely from the actual initialization process.

We'll go over each of the creational design patterns, which, as we'll see, all deal with a specific implementation task and add a higher degree of abstraction to the code base.

Builder

The intent of the Builder pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations and in turn, provides better control over the construction process. The design pattern includes two key participants: the builder and the director. The builder is tasked with constructing the different components of the intricate object, while the director manages the construction process by utilizing an instance of the builder.

The builder pattern constructs complex objects using step-by-step approach.

The UML diagram above describes an implementation of the builder design pattern. This diagram consists of four classes:

Product: Represents the complex object that is being built.
Builder: This is base class (or interface) for all builders and defines a steps that must be taken in order to correctly create an complex object (product). Generally each step is an abstract method that is overriden by concrete implementation.
ConcreteBuilder: Provides implementation for builder. Builder is an object able to create other complex objects (products).
Director: Represents class that controls algorithm used for creation of complex object.

#include <algorithm>
#include <list>
#include <string>
#include <iostream>

class Product
{
private:
    std::list<std::string> _parts;

public:
    void Add(std::string part)
    {
        _parts.push_back(part);
    }

    void Show()
    {
        std::cout << "Parts: ";
        for (auto p : _parts)
        {
            std::cout << "\t" << p;
        }
    }
};

class Builder
{
public:
    virtual void BuildPartA() = 0;
    virtual void BuildPartB() = 0;
    virtual Product GetResult() = 0;
};

class Director
{
public:
    void Construct(Builder *builder)
    {
        builder->BuildPartA();
        builder->BuildPartB();
    }
};

class ConcreteBuilder1 : public Builder
{
private:
    Product _product;

public:
    void BuildPartA() override
    {
        _product.Add("Part A");
    }

    void BuildPartB() override
    {
        _product.Add("Part B");
    }

    Product GetResult() override
    {
        return _product;
    }
};

int main(void)
{
    Builder *b1 = new ConcreteBuilder1();
    Director *dir = new Director();

    dir->Construct(b1);
    Product p1 = b1->GetResult();
    p1.Show();
}

/* OUTPUT
Parts:  Part A  Part B
*/

Motivation

Imagine a complex object that requires a step-by-step initialization of many fields and nested objects. Such initialization code is usually buried inside a monstrous constructor with lots of parameters.

Suppose you are tasked with designing a software application that allows users to customize and order their own smartphone. The smartphone can be customized with different brands, models, operating systems, RAM, storage, camera, and price. As the number of customization options increases, it becomes increasingly difficult to manage and maintain the code responsible for creating and initializing the smartphone object. This can lead to code that is difficult to read, understand, and modify, as well as bugs and errors that can affect the performance and functionality of the application. Additionally, different users may want to order smartphones with different customizations, so it can be challenging to keep track of all the different possible combinations of customization options.

#include <iostream>
#include <string>

class Smartphone {
public:
    Smartphone(std::string brand, std::string model, std::string os, int ram, int storage, int camera, double price)
        : m_brand(brand), m_model(model), m_os(os), m_ram(ram), m_storage(storage), m_camera(camera), m_price(price) {
    }

    void printDetails() {
        std::cout << "Brand: " << m_brand << std::endl;
        std::cout << "Model: " << m_model << std::endl;
        std::cout << "Operating System: " << m_os << std::endl;
        std::cout << "RAM: " << m_ram << " GB" << std::endl;
        std::cout << "Storage: " << m_storage << " GB" << std::endl;
        std::cout << "Camera: " << m_camera << " MP" << std::endl;
        std::cout << "Price: $" << m_price << std::endl;
    }

private:
    std::string m_brand;
    std::string m_model;
    std::string m_os;
    int m_ram;
    int m_storage;
    int m_camera;
    double m_price;
};

// Client code
int main() {
    Smartphone samsungPhone("Samsung", "Galaxy S21", "Android 11", 8, 128, 64, 799.99);
    samsungPhone.printDetails();

    Smartphone applePhone("Apple", "iPhone 12", "iOS 14", 4, 64, 12, 1099.99);
    applePhone.printDetails();

    // ...

    // More code for handling user input and creating smartphones with customizations
}

As you can see, the constructor of the Smartphone class is becoming increasingly complex as more customization options are added. This can make it difficult to read, understand, and modify the code, as well as track all the different possible combinations of customization options. The problem, therefore, is to design a software application that is flexible and easy to maintain, while still allowing users to customize their smartphones with different options. The Builder design pattern provides a solution to this problem by separating the construction of complex objects from their representation, allowing for more flexibility and ease of maintenance.

How builder design pattern solve this problem?

The Builder pattern suggests that you extract the object construction code out of its own class and move it to separate objects called builders.

The pattern divides the process of creating an object into a number of steps. You carry out a series of these actions on a builder object to create an object. The key fact is that not all of the steps must be called. Only the steps required to create a specific configuration of an object may be called. Some of the construction steps might require different implementation when you need to build various representations of the product. Fo example: Camera of the Smart phone may use Sony IMX700 or Samsung HM2 sensors for converting light into electric signals.

In this case, you can create several different builder classes that implement the same set of building steps, but in a different manner. Then you can use these builders in the construction process (i.e., an ordered set of calls to the building steps) to produce different kinds of objects.

#include <iostream>
#include <string>

// Product class
class Smartphone
{
public:
    void setBrand(const std::string &brand)
    {
        m_brand = brand;
    }

    void setModel(const std::string &model)
    {
        m_model = model;
    }

    void setOS(const std::string &os)
    {
        m_os = os;
    }

    void setRAM(const int &ram)
    {
        m_ram = ram;
    }

    void setStorage(const int &storage)
    {
        m_storage = storage;
    }

    void setCamera(const int &camera)
    {
        m_camera = camera;
    }

    void setPrice(const double &price)
    {
        m_price = price;
    }

    void printDetails()
    {
        std::cout << "Brand: " << m_brand << std::endl;
        std::cout << "Model: " << m_model << std::endl;
        std::cout << "Operating System: " << m_os << std::endl;
        std::cout << "RAM: " << m_ram << " GB" << std::endl;
        std::cout << "Storage: " << m_storage << " GB" << std::endl;
        std::cout << "Camera: " << m_camera << " MP" << std::endl;
        std::cout << "Price: $" << m_price << std::endl;
    }

private:
    std::string m_brand;
    std::string m_model;
    std::string m_os;
    int m_ram;
    int m_storage;
    int m_camera;
    double m_price;
};

// Abstract builder class
class SmartphoneBuilder
{
public:
    virtual void setBrand() = 0;
    virtual void setModel() = 0;
    virtual void setOS() = 0;
    virtual void setRAM() = 0;
    virtual void setStorage() = 0;
    virtual void setCamera() = 0;
    virtual void setPrice() = 0;

    virtual Smartphone *getSmartphone() = 0;
};

// Concrete builder class
class SamsungBuilder : public SmartphoneBuilder
{
public:
    SamsungBuilder()
    {
        m_phone = new Smartphone();
    }

    void setBrand()
    {
        m_phone->setBrand("Samsung");
    }

    void setModel()
    {
        m_phone->setModel("Galaxy S21");
    }

    void setOS()
    {
        m_phone->setOS("Android 11");
    }

    void setRAM()
    {
        m_phone->setRAM(8);
    }

    void setStorage()
    {
        m_phone->setStorage(128);
    }

    void setCamera()
    {
        m_phone->setCamera(64);
    }

    void setPrice()
    {
        m_phone->setPrice(799.99);
    }

    Smartphone *getSmartphone()
    {
        return m_phone;
    }

private:
    Smartphone *m_phone;
};

// Concrete builder class
class IPhoneBuilder : public SmartphoneBuilder
{
public:
    IPhoneBuilder()
    {
        m_phone = new Smartphone();
    }

    void setBrand()
    {
        m_phone->setBrand("Apple");
    }

    void setModel()
    {
        m_phone->setModel("IPhone 12");
    }

    void setOS()
    {
        m_phone->setOS("iOS 14");
    }

    void setRAM()
    {
        m_phone->setRAM(4);
    }

    void setStorage()
    {
        m_phone->setStorage(64);
    }

    void setCamera()
    {
        m_phone->setCamera(12);
    }

    void setPrice()
    {
        m_phone->setPrice(1099.99);
    }

    Smartphone *getSmartphone()
    {
        return m_phone;
    }

private:
    Smartphone *m_phone;
};

// Director class
class PhoneManufacturer
{
public:
    Smartphone *createSmartphone(SmartphoneBuilder *builder)
    {
        builder->setBrand();
        builder->setModel();
        builder->setOS();
        builder->setRAM();
        builder->setStorage();
        builder->setCamera();
        builder->setPrice();
        return builder->getSmartphone();
    }
};

// Client code
int main()
{
    PhoneManufacturer manufacturer;
    SamsungBuilder samsungBuilder;
    Smartphone *samsungPhone = manufacturer.createSmartphone(&samsungBuilder);
    std::cout << "\nSamsung Spec: \n";
    samsungPhone->printDetails();

    IPhoneBuilder iphoneBuilder;
    Smartphone *iphone = manufacturer.createSmartphone(&iphoneBuilder);
    std::cout << "\nIphone Spec: \n";
    iphone->printDetails();
}

/* OUTPUT

Samsung Spec: 
Brand: Samsung
Model: Galaxy S21
Operating System: Android 11
RAM: 8 GB
Storage: 128 GB
Camera: 64 MP
Price: $799.99

Iphone Spec: 
Brand: Apple
Model: IPhone 12
Operating System: iOS 14
RAM: 4 GB
Storage: 64 GB
Camera: 12 MP
Price: $1099.99

*/

When to use Builder Design Pattern

Use the Builder pattern to get rid of a telescoping constructor.
Use Builder pattern when you want your code to be able to create different representations of some product.

How to implement builder design pattern

Define a Builder interface that specifies the methods for constructing the complex object. These methods should return the builder object itself to allow for method chaining.
Create a ConcreteBuilder class that implements the Builder interface. This class will have all the methods needed to construct the complex object and store its attributes.
Define a Director class that uses the builder object to construct the final object. The Director class should not be responsible for constructing the object directly, but should delegate this task to the builder object.
Create a Product class that represents the final object to be constructed. This class should have all the necessary attributes and methods to represent the complex object.
Use the builder object to construct the final object in the Director class, by calling the appropriate methods on the builder object.

Pros and Cons

Pros:

Encapsulates the construction of complex objects and separates it from the object's representation. Provides a clear and readable interface for constructing complex objects with many attributes.
Allows for the creation of different representations of the same object using the same construction process.
Can improve code maintainability and flexibility by reducing the coupling between the client code and the constructed objects.
Can help enforce design principles such as the Single Responsibility Principle (SRP) and the Open/Closed Principle (OCP).

Cons:

Requires the creation of additional classes for the builder and director, which can add complexity to the code.
Can lead to an increase in code size and complexity, especially if the objects being constructed are not very complex.
Can make it more difficult to refactor the code if the construction process changes significantly.
Can add some runtime overhead compared to direct object construction, due to the additional object creation and method calls required by the builder pattern.

Overall, the Builder design pattern can be a useful tool for creating complex objects with many attributes, especially when you need to create different representations of the same object or enforce design principles such as SRP and OCP. However, it may not be the best choice for simpler objects or situations where flexibility and maintainability are not a high priority.

Design Pattern - SOLID Principles

Pratik Parvati — Sun, 19 Mar 2023 08:58:33 +0000

Design Pattern - SOLID Principles

A design pattern in software engineering is a general solution to a frequently occurring problem in software design. It is a description or template for solving an issue that can be used in a several kinds of situations.

NOTE: Design patterns are not finished solution or a code or a class or a library that you can import in your project. They are a generic solution for solving a problem. Each project will have a slightly different way to solve it.

Why learn design pattern?

Here is a definition of software engineering taken from Wikipedia:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software".

At the initial stage of software development, the code looks clean, elegant, and compelling. It has a basic elegance that draws the same interest of designers and implementers. These applications manage to keep their design integrity throughout the development process and into the first release. But then an anomaly unfolds and the program begins to deteriorate. The program becomes a growing mess of code that the developer find increasingly difficult to manage. Even the simplest of the change in application demands a fruitless effort, that developers cry for a new design.

Design patterns can speed up the development process by providing a tested and proven development paradigm. Knowing how to tackle a problem in a new scenario during the software’s development phase can help you design more effective software.

Coupling and Cohesion

Two words describe how easy or difficult it is to change a piece of software.

Coupling in software development refers to the extent to which one component or module depends on another. A high degree of coupling indicates that the components are closely related and that changes in one can have a significant impact on others. A low degree of coupling, on the other hand, means that components are independent of one another and can be changed or reused without significantly affecting other components.

Coupling describes two things changing together – a movement in one induces a movement in another

Cohesion is a measure of the degree to which the elements of the module are functionally
related. It is the degree to which all elements directed towards performing a single task are
contained in the component. Cohesion represents the clarity of the responsibilities of a module. So, cohesion focuses on how single module/class is designed. Higher the cohensiveness of the module/class, better is the OO design.

Cohesion defines the relationships within a module

SOLID Principles

In object-oriented programming, SOLID is an acronym for Five important design principles. These Five principles were introduced by Robert C. Martin, in his 2000 paper Design Principles and Design Patterns. SOLID is a popular set of design principles with the goals to reduce dependencies so that we can change one area of software without impacting others; they are intended to make designs easier to understand, maintain, and extend. Following the guidelines of these principle generally leads to writing longer and more complex code; However, this extra effort makes software easier to maintain, test and extend. To fully realize the benefits of the SOLID principles, the application must be large; the advantages are not very visible in a small application.

Let's identify these principles.

Principle 1: S - Single Responsibility Principle (SRP)

According to the Single Responsibility Principle (SRP), a software entities (like class, modules, functions, etc) should never be changed because of more than one reason; when the code does have to change, it should do so by seperating the responsibility to different entities, it should not be a victim of collateral damage. It helps keep classes and methods small and maintainable. In addition to keeping classes small and focused it also makes them easier to understand.

A class should have one, and only one, reason to change. – Robert C Martin

Let's analyze the example that violates this principle.

class Bill
{
    Menu menu;
    std::vector<std::string> Items;
    unsigned int customer_id;
    unsigned int dateNtime;
    unsigned int total_price;

    Bill(Menu _menu, std::vector<string> items, unsigned int cust_id, unsigned int dNt, std::vector<unsigned int> item_price)
    {
        this->menu = _menu;
        std::copy(items.begin(), items.end(), std::back_iterator(Items));
        this->customer_id = cust_id;
        this->dateNtime = dNt;
        std::for_each(item_price.begin(), item_price.end(), [this](unsigned int item_p)
                      { total_price += item_p; })
    }

    void printBill() {
        // Print the bill
    }

    void saveBill() {
        // Save the Bill in File or DB
    }
};

How does it violate SRP?

SRP states that classes should have one responsibility, here, we can draw out three responsibilities: Bill Management, Printing the Bill and Bill storage management. These three responsibilities are coupled in a single class which voilates SRP.

How will this design cause issues in the future?

If the application changes in a way that it affects database management functions. The classes that make use of Bill management will have to be touched and recompiled to compensate for the new changes. This makes code rigid, like a domino effect, touch one card it affects all the other card in line.

To make this obey SRP, we create two more classes that will handle the sole responsibility of storing the bill to a database and printing the bill.


class Bill
{
    Menu menu;
    std::vector<std::string> Items;
    unsigned int customer_id;
    unsigned int dateNtime;
    unsigned int total_price;

    Bill(Menu _menu, std::vector<string> items, unsigned int cust_id, unsigned int dNt, std::vector<unsigned int> item_price)
    {
        this->menu = _menu;
        std::copy(items.begin(), items.end(), std::back_iterator(Items));
        this->customer_id = cust_id;
        this->dateNtime = dNt;
        std::for_each(item_price.begin(), item_price.end(), [this](unsigned int item_p)
                      { total_price += item_p; })
    }
};

class StoreBill {
    void saveToFile(Bill& bill) {
        // Save bill to file
    }

    void saveToDB(Bill& bill) {
        // Save bill to DB
    }
};

class PrintBill {
    void printMenu(Bill& bill) {
        // Print Menu
    }

    void printBill(Bill& bill) {
        // Print the bill
    }
};

The fact that we split our Bill class into 3 classes doesn't necessarily mean that we should have a separate class for every method that doesn't suit the class's responsibility. No, we should instead have a separate class for every group of methods that change for different reasons. Now, the three classes are decoupled and if any updates take place on any of them, the other classes won’t be affected.

Principle 2: O - Open-Closed Principle (OCP)

OCP says that a class should be open for extension and closed for modification. The "closed" part of the rule states that once a class has been developed and tested, the class code shouldn’t change. The "open" part of the rule states that you should be able to extend existing code in order to introduce new functionality.

Software entities should be open for extension but closed for modification.

When a single change to a program causes a chain of changes to dependent modules (i.e, coupled modules); the program becomes fragile, rigid, unpredictable and unreusable. For these causes, OCP says that you should design
modules that never change. This may sound contradictory, but there are several techniques for achieving the OCP
on a large scale. All of these techniques are based upon abstraction.

Abstraction is the Key

The abstractions are abstract base classes, and all possible derivative classes represent the inﬁnite group of possible behaviors. An abstraction can be manipulated by a module. Since it is based on a fixed abstraction, such a module can be closed for modification. However, the behavior of that module can be extended by creating new abstraction derivatives.

Let's look at the Example

enum BillType
{
    electricity,
    water,
    broadband
};

struct Bill
{
    BillType itsType;
};

struct ElectricityBill
{
    BillType itsType;
    unsigned int units_consumed;
    unsigned int time_period;
};

struct WaterBill
{
    BillType itsType;
    unsigned int units_consumed;
    unsigned int time_period;
};

struct BroadbandBill
{
    BillType itsType;
    unsigned int units_consumed;
    unsigned int time_period;
};

//
// These functions are implemented elsewhere
//
void CalculateElectricityBill(struct ElectricityBill *);
void CalculateWaterBill(struct WaterBill *);
void CalculateBroadbandBill(struct BroadbandBill *);

typedef struct Bill *BillPointer;

void CalculateAllBills(BillPointer list[], int n)
{
    for (int i = 0; i < n; i++)
    {
        struct Bill *s = list[i];
        switch (s->itsType)
        {
        case electricity:
            CalculateElectricityBill((struct ElectricityBill *)s);
            break;
        case water:
            CalculateWaterBill((struct WaterBill *)s);
            break;
        case broadband:
            CalculateBroadbandBill((struct BroadbandBill *)s);
            break;
        }
    }
}

The function CalculateAllBills does not conform to the open-closed principle because it cannot be closed against new kinds of bills. If we want to extend this function to calculate the bill for groceries along with other bills, we are forced to modify the function. If other functions similar to CalculateAllBills exists (for insance, PayAllBills); then switch statement would be repeated over and over again in various functions all over the application.

The below code provides solution to the different bills problem that conforms to the open-closed principle.

class Bill
{
public:
    virtual void CallculateBill() const = 0;
};

class ElectricityBill : public Bill
{
// member variables for the class
public:
    virtual void CallculateBill() const;
};

class WaterBill : public Bill
{
// member variables for the class
public:
    virtual void CallculateBill() const;
};

class BroadbandBill : public Bill
{
// member variables for the class
public:
    virtual void CallculateBill() const;
};

// This is the new extended class to calculate grocery bill without modifying CalculateAllBills
class GroceryBill : public Bill
{
// member variables for the class
public:
    virtual void CallculateBill() const;
};

void CalculateAllBills(std::set<Bill *> &list)
{
    for (Iterator<Bill *> i(list); i; i++)
        (*i)->CallculateBill();
}

Note that if we want to extend the behavior of the CalculateAllBills function to calculate a total for a new kind of bill, all we need to do is add a new derivative of the Bill class. The CalculateAllBills function does not need to change. Thus CalculateAllBills conforms to the open-closed principle. Its behavior can be extended without modifying it.

Principle 3: L - Liskov Substitution Principle (LSP)

Liskov's principle tends to be the most difficult to understand. The principle states that you should be able to replace any instances of a parent/base class with an instance of one of its children/derived without creating any unexpected or incorrect behaviors.

Derived types must be substitutable for their base types - Barbar Liskov

Derived classes may have different functionality, but their behavior must be in line with that of the base class. It should also follow the implied behavior of the base class, in order to be considered a true behavioral derived type. LSP is generally violated if a derived type of a base type does something the base type's client does not expect.

Let's look at an example that violates LSP

class Vehicle {
public:
    void startEngine() {
        // start the engine
    }

    void pressAccelerate() {
        // accelerate
    }

    void pressBreak() {
        // break or slow down
    }
};

class Car: public Vehicle {

};

class MotorCycle: public Vehicle {

};

class Bicycle: public Vehicle {
public:

    // start engine not possible in bicycle
    void startEngine() {
        // throw exception
    }
};


void startEngineAllVehicle(std::vector<Vehicle*> allVehicle)
{
    // iterate through all objects and start the engine
}


int main()
{
    std::vector<Vehicle*> allVehicle;
    allVehicle.push_back(new Car);
    allVehicle.push_back(new MotorCycle);

    // Well - all works as of now.
    startEngineAllVehicle(allVehicle);

    // Now adding new object of Bicycle
    allVehicle.push_back(new Bicycle);

    // Again start engine for all vehicle & Oops it broke the program.
    // Why we got unexpected behavior in client? --- Because LSP is violated in class Bicycle, 
    // as it changed the original behavior of base class Vehicle
    playVideoInAllMediaPlayers(allPlayers);
}

The above example violates the Liskov Substitution principle because the Bicycle class implements the startEngine interface but it throws exception because the Bicycle class doesn't have an engine to start. LSP suggests that the subtype must be substitutable for the base class or base interface.

Conforming to the Liskov Substitution Principle

Let's refactor the code to make "good" design using LSP.

class Vehicle {
public:
    void pressAccelerate() {
        // accelerate
    }

    void pressBreak() {
        // break or slow down
    }
};

class FuelableVehicle: public Vehicle {
public:
    void startEngine() {
        // start the engine
    }
}

class Car: public FuelableVehicle {

};

class MotorCycle: public FuelableVehicle {

};

class Bicycle: public Vehicle {
public:

};

The Bicycle remains a direct subclass of the Vehicle class unless we are able to identify a subgroup of vehicles with specific functionality that the Bicycle class belongs. Now our abstraction hierarchy is logically sound because the Vehicle class only contains functionality that all the concrete vehicles implement. The same is true for FuelableVehicle.

Principle 4: I - Interface Segregation Principle (ISP)

The ISP states that no client should be forced to depend on methods it does not use. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.

Many client specific interfaces are better than one general purpose interface

ISP guide us to creating multiple, smaller, cohesive interfaces when there are non-cohesive interfaces. The implementation of smaller interfaces improves flexibility and reuse ability. By sharing interfaces among fewer classes, the number of changes required to respond to a change in an interface is reduced, resulting in higher robustness.

Let’s look at the below Vehicle interface

class Vehicle {
public:
    void pressAccelerate() {
        // accelerate
    }

    void pressBreak() {
        // break or slow down
    }

    void openDoor() {
        // open the Doors
    }

    void moveSideStand() {
        // move sidestand
    }
};


class Car: public Vehicle {
public:
    void moveSideStand() {
        // can not be implemented
    }
};

class MotorCycle: public Vehicle {
public:
    void openDoor() {
        // can not be implemented
    }
};

As you can see, it does not make sense for a MotorCycle class to implement the openDoor() method as a Motor Cycle does not have any doors! To fix this, ISP proposes that the interfaces be broken down into multiple, small cohesive interfaces so that no class is forced to implement any interface, and therefore methods, that it does not need. Also, ISP states that interfaces should perform only one job (just like the SRP principle) any extra grouping of behavior should be abstracted away to another interface.

Here, our Vehicle interface performs actions that should be handled independently by other interfaces. To make our Vehicle interface conform to the ISP principle, we segregate the actions to different interfaces.

class Vehicle {
public:
    void pressAccelerate() {
        // accelerate
    }

    void pressBreak() {
        // break or slow down
    }
};


class Car: public Vehicle {
public:
    void openDoor() {
        // open the Doors
    }
};

class MotorCycle: public Vehicle {
public:
    void moveSideStand() {
        // move side Stand
    }
};

If any class might need both the openDoor() method and the moveSideStand() method, it will implement both interfaces.

Principle 5: D - Dependency Inversion Principle (DIP)

Robert Martin defines the Dependency Inversion Principle as:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

In traditional software architecture we design lower level components to be used/consumed by higher level components. In other words, higher level components depend on lower level components. This dependency causes tight coupling in the software. we strive to achieve loose coupling to make it easier to develop, maintain and change code in the future.

I know this sounds a bit complex, but if you apply the open-closed and Liskov substitution principles to your application, it will already follow the dependency inversion principle. The goal is not to have a tightly-coupled system where every module directly references lower-level modules. That's why you need to abstract that out to get to a more loosely-coupled system.

Let's look at Bad design that violets DIP

class Light {  // Low-Level
public:
    bool currentState = false; 

    void turnOn() {
        currentState = true;
    }

    void turnOff() {
       currentState = false;
    }

    bool getState() {
        return currentState;
    }

    std::string getStateString() {
        if (currentState) {
            return std::string("On");
        } else {
            return std::string("Off");
        }
    }
};

class SwitchButton { // High-Level
public:
    Light* light;

    SwitchButton(Light* lig) {
        this->light = lig;
    }

    void On() {
        this->light->turnOn();
    }

    void Off() {
        this->light->turnOff();
    }
};

int main() {
    Light* lig = new Light();
    SwitchButton* sw = new SwitchButton(lig);

    std::cout << lig->getStateString() << std::endl; // OFF

    sw->On();
    std::cout << lig->getStateString() << std::endl; // ON
}

At this point, we would want to know which classes are high level, and which are low level? - In general, the class that uses another class is the high level class. So our SwitchButton class is the high level class and the Light class is the low level class.

How Does This Violate DIP?

The SwitchButton class is dependent on the Light class.
We cannot re-use the SwitchButton class without also including the Light class.
Any update, like creating a new class which needs to be turned on or off by our SwitchButton cannot be added without modifying the SwitchButton class itself.

How Do We Conform To The DIP?

To conform with the DIP, we must invert the dependancies of our code.

SwitchButton must not depend on Light, both must depend on abstractions.
We must be able to easily re-use SwitchButton and Light, SwitchButton must not reference Light directly.

class DeviceInterface {
   void turnOn();
   void turnOff();
};

class Light: public DeviceInterface {
public:
    bool currentState = false;

    void turnOn() {
        currentState = true;
    }

    void turnOff() {
        currentState = false;
    }

    bool getState() {
        return currentState;
    }

    std::string getStateString() {
        if(currentState) {
            return std::string("On");
        } else {
            return std::string("Off");
        }
    }
};

class ButtonInterface {
public:
    void On();
    void Off();
};


class SwitchButton: public ButtonInterface {
public:
    DeviceInterface* d_inf;

    SwitchButton(DeviceInterface* dev_inf) {
        this->d_inf = dev_inf;
    }

    void On() {
        this->d_inf->turnOn();
    }

    void Off() {
        this->d_inf->turnOff();
    }
}

int main() {
    Light* lgt = new Light();
    SwitchButton* sw = new SwitchButton(lgt);

    std::cout << lgt->getStateString() << std::endl; // OFF

    sw->On();

    std::cout << lgt->getStateString() << std::endl; // ON
}

Our updated SwitchButton and Light now both depend on abstractions, ButtonInterface and DeviceInterface respectively. The code works for any implementation and we can pass the implementation when creating the object. This gives us lot of flexibility and it will be easy to maintain.

Conclusion

Implementing SOLID design principles during development will result in more maintainable, scalable, testable, and reusable systems. Engineers worldwide use these principles in today's environment. As a result, it's critical to use these principles when writing good code and applying design principles that are competitive while meeting industry standards. All what we need to do is to start thinking about the design a little bit before rushing into coding.

C++ bad habits - How to make mistakes!

Pratik Parvati — Sun, 09 Jan 2022 17:56:28 +0000

C++ bad habits - How to make mistakes!

When you study programming language, learn to make mistake. Learn to program means to understand what you should not do and how you recognize a mistake and how to debug it. Writing a program is the easy part; learning to program means to find a bug if a program seems to be correct but fails from time to time in an arbitrary way. Then you need to understand what mistake leads into this behavior and how to debug this bug. Therefore you should know as much mistakes as possible.

NOTE: You should not avoid mistakes. You should do them all and learn from them.

So the first mistake you should avoid is to avoid mistakes while being a C++ beginner in order to be able to avoid mistakes as an advanced C++ developer.

Do not mix overloading with overriding

In C++, two functions can have the same name if the number and/or type of arguments passed is different. These functions having the same name but different arguments are known as overloaded function. Overriding means same method name and same parameter occur in different class that has inheritance relationship. Before we get to the problem, lets understand scoping rule in C++.

Scoping

The basic to complex scoping rules are explained at cppreference site here. The inner scope declarations hide the declarations in outer scope regardless of the type of language elements(object, type, function etc).

Similarly, a class name can be hidden by an explicit declaration of the same name - as an object, function or enumeration in a nested declarative region or derived class. The class name is hidden whenever the object, function or enumeration name is visible. This process is referred to as name hiding.

For instance:

#include <iostream>
#include <typeinfo>

struct Base
{
  char x;
};

struct Derived: Base
{
  int x;  // char x is hidden as per name hiding rule
};

int main()
{
  Derived d;
  std::cout << typeid(d.x).name() << std::endl; // prints "int"
}

Since the members of class Base are visible in class Derived, a declaration of an object named x in class Derived will hide char x in class Base.

why name hiding was actually designed into C++?

You probably know that in C++ overload resolution works by choosing the best function from the set of candidates; this is done by matching the types of arguments to the types of parameters. Hence, adding new functions to a set of previously existing ones might result in a rather drastic shift in overload resolution results.

For instance:

#include <iostream>
#include <typeinfo>

struct Base
{
  void foo(char f) { std::cout << "Base::foo(char)\n"; }
};

struct Derived : Base
{
  void foo(int f) { std::cout << "Derived::foo(int)\n"; }
  void bar() { foo('c'); }
};

int main()
{
  Derived d;
  d.bar(); // prints "Derived::foo(int)"
}

Although Base::foo(char) is a better match for the call foo('c') name lookup stops after finding Derived::foo(int) and so the program prints Derived::foo(int). If the member functions weren't hidden, that would mean name lookup in class scope behaved differently where the different versions of foo() is carried forward over the scope of inherited functions with the same name. This type of behavior was then considered to be undesirable by the C++ standard writers, so they implemented name hiding, which effectively gives each class a "clean slate" or a new, clean class.

Why not mix overloading with overriding?

Functions in Derived classes with the same name as the functions in the Base classes, but that do not override the Base class function are considered to be bad practice because it can result in errors.

For instance:

#include <iostream>
#include <typeinfo>
#include <string>

struct Base
{
  void foo(std::string f) { std::cout << "Base::foo(std::string)\n"; }
};

struct Derived : Base
{
  void foo(int f) { std::cout << "Derived::foo(int)\n"; }
};

int main()
{
  Derived d;
  d.foo("xyz");
}

/* ERROR

Output of x86-64 gcc 11.2 (Compiler #1)x86-64 gcc 11.2 (C++, Editor #1, Compiler #1)
<source>: In function 'int main()':
<source>:18:9: error: invalid conversion from 'const char*' to 'int' [-fpermissive]
   18 |   d.foo("xyz");
      |         ^~~~~
      |         |
      |         const char*

*/

The error occurs because foo(string) is hidden in Derived class scope. This behaviour makes sense because it prevents ambiguities in the inheritance process. Suppose, we had a function Base::foo(float) and a function Derived::foo(double). If Base::foo(float) was not hidden by default in Derived, we would call the base class function when calling d.foo(0.f), even though a float can be promoted to a double.

The real fun with these ambiguities would start when a 0 is used instead of a nullptr in C++11 — since a function with an integral parameter will always be a better match than a function taking a pointer parameter, this would result in agonizing, hard-to-trace bugs.

Use "override" for overridden functions

In C++, the virtual methods are introduced with the virtual keyword. However, when creating overrides in derived classes, the keyword virtual is optional, which might cause difficulty when working with large classes or hierarchies. To determine whether a function is virtual or not, you may need to traverse through the hierarchy all the way to the base class. On the other hand, sometimes, it is useful to make sure that a virtual function or even a derived class can no longer be overridden or derived further. In this recipe, we will see how to use C++11 special identifiers override and final to declare virtual functions or classes.

Following below two rules would ensure correct declaration of virtual methods both in derived and base classes and also increase readability.

Always use the virtual keyword when declaring virtual functions in derived classes that are supposed to override virtual functions from a base class, and
Always use the override special identifier after the declarator part of a virtual function declaration or definition.

For instance:

#include <iostream>
#include <typeinfo>
#include <string>

struct Base
{
  virtual void foo(double f) {std::cout << "Base::foo(double)\n";};
};

struct Derived : Base
{
  virtual void foo(int f) { std::cout << "Derived::foo(int)\n"; } // intention here is to override Base::foo(double)
};

int main()
{
  Derived d;
  d.foo(10.0); // prints "Derived::foo(int)"
}

Even though the use is intended to call overridden function of Base::foo(double); the function Derived::foo(int) (by impilicit type coversion to int) is called which is actually a overloaded function that hides foo(double) inherited from base class. The compiler, unaware that it is intending to write a previous method, simply adds it to the class as a new method.

Adding override clearly disambiguate this: through this, one is telling the compiler that three things are expecting:

There is a method with the same name in the base class
This method in the base class is declared as virtual (that means, intended to be rewritten)
The method in the base class has the same signature as the method in the derived class (the rewriting method)

If any of these is false, then an error is signaled.

#include <iostream>
#include <typeinfo>
#include <string>

struct Base
{
  virtual void foo(double f) {std::cout << "Base::foo(double)\n";};
};

struct Derived : Base
{
  virtual void foo(int f) override { std::cout << "Derived::foo(int)\n"; }
};

int main()
{
  Derived d;
  d.foo(10.0);
}

/*ERROR
<source>:12:16: error: 'virtual void Derived::foo(int)' marked 'override', but does not override
   12 |   virtual void foo(int f) override { std::cout << "Derived::foo(int)\n"; }
      |                ^~~
ASM generation compiler returned: 1
<source>:12:16: error: 'virtual void Derived::foo(int)' marked 'override', but does not override
   12 |   virtual void foo(int f) override { std::cout << "Derived::foo(int)\n"; }
      |                ^~~
Execution build compiler returned: 1
*/

To ensure that functions cannot be overridden further or classes cannot be derived any more, use the final special identifier:

#include <iostream>
#include <typeinfo>
#include <string>

struct Base
{
  virtual void foo(double f) { std::cout << "Base::foo(double)\n"; };
};

struct Derived final : Base
{
  virtual void foo(double f) override { std::cout << "Derived::foo(int)\n"; }
};

struct Derived1 : Derived
{
};

int main()
{
  Derived d;
  d.foo(10.0);
}

/*ERROR
<source>:15:8: error: cannot derive from 'final' base 'Derived' in derived type 'Derived1'
   15 | struct Derived1: Derived {};
      |        ^~~~~~~~
ASM generation compiler returned: 1
<source>:15:8: error: cannot derive from 'final' base 'Derived' in derived type 'Derived1'
   15 | struct Derived1: Derived {};
      |        ^~~~~~~~
Execution build compiler returned: 1
*/

Don't specify default value on function overrides

Default arguments are mostly syntactic sugar and get determined at compile time. Virtual dispatch, on the other hand, is a run-time feature. i.e, virtual functions are dynamically bound, but default parameter values are statically bound. Therefore, the default parameter is selected by the compiler using the static type of the object a member function is called upon.

For instance:

#include <iostream>
#include <typeinfo>
#include <string>

struct Base
{
  virtual void foo(double f = 10) { std::cout << "Base::foo(double) --> " << f << "\n"; };
};

struct Derived final : Base
{
  virtual void foo(double f = 20) { std::cout << "Derived::foo(double) --> " << f << "\n"; }
};

int main()
{
  Base *b = new Derived{};
  b->foo(30); // prints "Derived::foo(double) --> 30" which is fine
  b->foo(); // prints "Derived::foo(double) --> 10" ??? expect to print 20 instead of 10!!!
}

Virtual functions are dynamically bound, meaning that the particular function called is determined by the dynamic type of the object through which it's invoked:

b->foo(30) calls Derived::foo(30)

However, when you consider virtual functions with default parameter values; you may end up invoking a virtual function defined in a derived class but using default parameter value from a base class.

b->foo() calls Derived::foo(10)!!

In Derived::foo(), the default parameter value is 20. Since the b's static type is Base*, the default parameter value for this function call is taken from the Base class, not the Derived class! The result is a call consisting of a strange and almost certainly unanticipated combination of the declarations for foo() in both the Base and Derived classes.

Never redefine an inherited default parameter value, because default parameter values are statically bound, while virtual functions the only functions you should be overriding are dynamically bound.

NOTE: Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments

Always use inheritance and virtual functions carefully, commit mistakes but learn from them. That's all I have in this blog, I will keep writing similar points and my learnings in my next coming blogs.

C++ STL Iterators

Pratik Parvati — Sat, 28 Aug 2021 15:25:05 +0000

C++ STL Iterators

One of the keys to understanding how to use the containers of C++ Standard Template Library (STL) is understanding how iterators work. Containers such as lists and maps do not behave like arrays, so you can't use a for loop to go through the elements in them. Likewise, because these containers are not accessible randomly, you cannot use a simple integer index. You can use iterators to refer to elements of a container.

The reason that STL containers and algorithms work so well together, is that they know nothing of each other - Alex Stepanov

Iterators are pointer-like objects that allow programs to step through the elements of a container sequentially without exposing the underlying representation. Iterators can be advanced from one element to the next by incrementing and decrementing them. Each container type has a distinct iterator associated with it. For instance, the iterator for list<int> is declared as:

 std::list<int>::iterator

Iterator Category

Iterators falls into categories because different algorithms require different iterators to be used. For example, the std::copy() algorithm needs an iterator that can be advanced by incrementing it, whereas the std::reverse() algorithm needs an iterator that can be decremented as well. In C++ language, the standard defines five different categories.

Input Iterator
- Read-only and can be read only once.
- Example: std::istream_iterator(istream& is)
Output Iterator
- Write-only
- Example: std::ostream_iterator<int> out_it (std::cout,", ");
Forward Iterator
- Gathering input + output iterators
- Example: std::forward_list::iterator, std::unordered_map::iterator
Bidirectional Iterator
- Like Forward Iterator, but also has operator–
- Example: std::list::iterator
Random Access Iterator
- Has overloaded operator[], pointer arithmetic
- Example: std::vector<int>::iterator.

You can get more information about these here

Iterator traits

Iterator traits allows algorithms to access information about a particular iterator in a uniform way to avoid re-implement of all iterators for each specific case, when it needs to traverse different style of containers. For example, Finding elements in std::list is O(n) complexity whereas in std::vector the random access to an element is O(1) complexity (given the index position). It is better for an algorithm to know that the container can be traversed using += operator (Random Access), or only ++ operator (Forward), to choose what is the better choice to reduce the complexity of the algorithm that is computed.

The iterator traits are the following ones:

difference_type:
- the type for representing iterator distances
- The type of iterator difference p2 - p1.
value_type:
- the type of the value that iterator points
pointer:
- the pointer value that iterator points
- usually value_type*
reference:
- the reference value that iterator points
- usually value_type&

iterator category:

Identifies the iterator concept modeled by the iterator.
one of the following ones:

struct input_iterator_tag {};
struct output_iterator_tag {};
struct forward_iterator_tag : input_iterator_tag {};
struct bidirectional_iterator_tag : forward_iterator_tag {};
struct random_access_iterator_tag : bidirectional_iterator_tag {};

The definition of iterator_traits looks like:

// The basic version works for iterators with the member type
template <class Iterator>
struct iterator_traits
{
    typedef typename Iterator::value_type value_type;
    typedef typename Iterator::difference_type difference_type;
    typedef typename Iterator::pointer pointer;
    typedef typename Iterator::reference reference;
    typedef typename Iterator::iterator_category iterator_category;
};

// A partial specialization takes care of pointer types
template <class T>
struct iterator_traits<T *>
{
    typedef T value_type;
    typedef ptrdiff_t difference_type;
    typedef T *pointer;
    typedef T &reference;
    typedef random_access_iterator_tag iterator_category;
};

// pointers to const type
template <class T>
struct iterator_traits<const T *>
{
    typedef T value_type;
    typedef ptrdiff_t difference_type;
    typedef const T *pointer;
    typedef const T &reference;
    typedef random_access_iterator_tag iterator_category;
};

Sometimes a generic algorithm needs to know the value type of its iterator arguments, i.e., the type pointed to by the iterators. For example, to swap the values pointed by two iterators, a temporary variable is needed.

template <class Iterator>
void swap (Iterator a, Iterator b) 
{
  typename Iterator::value_type tmp = *a;
  *a = *b;
  *b = tmp;
}

The traits also improve the efficiency of algorithms by making use of knowledge about basic iterator categories provided by the iterator_category member. An algorithm can use this "tag" to select the most efficient implementation an iterator is capable of handling without compromising the flexibility to deal with a variety of iterator types.

In the below example we aim to have a single advance algorithm that automatically executes the right version based on the iterator category.

template <class InputIterator, class Distance>
void advance(InputIterator &i, Distance n,
             input_iterator_tag)
{
    for (; n > 0; --n)
        ++i;
}

template <class BidirectionalIterator, class Distance>
void advance(BidirectionalIterator &i, Distance n
                                           bidirectional_iterator_tag)
{
    if (n <= 0)
        for (; n > 0; --n)
            ++i;
    else
        for (; n < 0; ++n)
            --i;
}

template <class RandomAccessIterator, class Distance>
void advance(RandomAccessIterator &i, Distance n,
             random_access_iterator_tag)
{
    i += n;
}

// Generic advance algorithm using compile-time dispatching based on function overloading
template <class InputIterator, class Distance>
void advance(InputIterator i, Distance n)
{
    advance(i, n, typename iterator_traits<Iterator>::iterator_category());
}

Writing Custom iterator

Iterator traits will automatically work for any iterator class that defines the appropriate member types. The Custom iterator should support following pointers:

How to retrieve the value at the point
How the point of iteration can be incremented/decremented
How to compare it with other points of iteration

#include <algorithm>
#include <exception>
#include <iostream>
#include <iterator>
#include <typeinfo>
#include <vector>

template <typename ArrType> 
class MyArray {
private:
  ArrType *m_data;
  unsigned int m_size;

public:
  class Iterator {
  public:
    // iterator_trait associated types
    typedef Iterator itr_type;
    typedef ArrType value_type;
    typedef ArrType &reference;
    typedef ArrType *pointer;
    typedef std::bidirectional_iterator_tag iterator_category;
    typedef std::ptrdiff_t difference_type;

    Iterator(pointer ptr) : m_itr_ptr(ptr) {}
    itr_type operator++() {
      itr_type old_itr = *this;
      m_itr_ptr++;
      return old_itr;
    }

    itr_type operator++(int dummy) {
      m_itr_ptr++;
      return *this;
    }

    itr_type operator--() {
      itr_type old_itr = *this;
      m_itr_ptr--;
      return old_itr;
    }

    itr_type operator--(int dummy) {
      m_itr_ptr--;
      return *this;
    }

    reference operator*() const { return *m_itr_ptr; }

    pointer operator->() const { return m_itr_ptr; }

    bool operator==(const itr_type &rhs) { return m_itr_ptr == rhs.m_itr_ptr; }

    bool operator!=(const itr_type &rhs) { return m_itr_ptr != rhs.m_itr_ptr; }

  private:
    pointer m_itr_ptr;
  };

  MyArray(unsigned int size) : m_size(size) { m_data = new ArrType[m_size]; }

  unsigned int size() const { return m_size; }

  ArrType &operator[](unsigned int idx) {
    if (idx >= m_size)
      throw std::runtime_error("Index out of range");
    return m_data[idx];
  }

  Iterator begin() { return Iterator(m_data); }

  Iterator end() { return Iterator(m_data + m_size); }
};

int main()
{
  MyArray<double> arr(3);
  arr[0] = 2.6;
  arr[1] = 5.2;
  arr[2] = 8.9;

  std::cout << "MyArray Contents: ";
  for (MyArray<double>::Iterator it = arr.begin(); it != arr.end(); it++) {
    std::cout << *it << " ";
  }

  std::cout << std::endl;

  std::vector<double> vec;
  std::copy(arr.begin(), arr.end(), std::back_inserter(vec));

  std::cout << "Vector Contents after copy: ";
  for (std::vector<double>::iterator it = vec.begin(); it != vec.end(); it++) {
    std::cout << *it << " ";
  }

  std::cout << std::endl;

  std::cout << typeid(std::iterator_traits<
                          MyArray<double>::Iterator>::iterator_category())
                   .name()
            << std::endl;
  return 0;
}

/*OUTPUT
MyArray Contents: 2.6 5.2 8.9 
Vector Contents after copy: 2.6 5.2 8.9 
FSt26bidirectional_iterator_tagvE
*/

Iterators and the Range for Loop

The range-based for loop (or range-for in short), along with auto, is one of the most significant features added in the C++11 standard.

The syntax template for the range for loop looks like this:

for (range_declaration : range_expression) 
{ 
    // loop body 
}

In C++11/C++14, the above format results in a code similar to the following:

{  
  auto&& range = range_expression ; 
  // beginExpr is range.begin() and endExpr is range.end()
  for (auto b = beginExpr, e = endExpr; b != e; ++b) { 
    range_declaration = *b; 
    // loop body
  } 
}

A typical usages of range-based for loop:

// Iterate over STL container
std::vector<int> v{1, 2, 3, 4};
for (const auto &i : v)
    std::cout << i << "\n";

The way the range for loop works is by creating an iterator that points to the first element of the vector and then accessing each element of the vector in turn until the iterator reaches the last element of the vector and then the loop terminates. This behavior can be observed in cppinsight here.

C++ STL Containers: Choose your containers wisely

Pratik Parvati — Sun, 01 Aug 2021 08:06:56 +0000

C++ STL Containers: Choose your containers wisely

The Standard Template Library (STL) is a collection of C++ container classes and template algorithms that work together to produce a variety of useful functionalities. The STL was designed to combine different data structures with different algorithms while achieving the best performance; this guarantees the interoperability between all built-in and user-built components. To benefit from the powerful framework and great performance of the STL, you must know the concepts and apply them carefully.

Time Complexity and Big-O Notation

There are various solutions to a problem, but not all of them are the best. Generally, we tend to use the most efficient solution. In programming, we can't leave the mechanism of finding the best solution; we need a clear standard to evaluate their efficiency. This is where the notion of time complexity enter the equation.

The Big-O notation describes the runtime of an algorithm and defines the upper bound of any algorithm (i.e, algorithm should not take more than this time). Big-O notation is the most used notation for the time complexity of an algorithm for a given input of size n. For example, if the runtime grows linearly with the number of elements n, then the complexity is O(n) and if the runtime is independent of the input, the complexity is O(1).

There are different types of time complexities used; the below table lists the typical values of complexity and their Big-O notation.

Type	Notation	Description
Constant	`O(1)`	The runtime is independent of the number of elements
Linear	`O(n)`	The runtime grows linearly as the number of elements grows
Logarithmic	`O(log(n))`	The runtime grows logarithmically with respect to the number of elements
n-log-n	`O(n ∗ log(n))`	The runtime grows as a product of linear and logarithmic complexity
Quadratic	`O(n²)`	The runtime grows quadratically with respect to the number of elements

In the graph, the x axis represents the size of n (or algorithm input) and y represents the amount of time it would take to execute that algorithm.

Let’s run through an example to understand better: Finding the sum of the first n numbers.

`O(1)` solution

int findSum(int n) // input "n"
{
    return n * (n+1) / 2; // this will take some constant time c1
}

There is only one statement in the preceding code, and we know that a statement takes a constant amount of time to execute. The basic idea is that if the statement takes constant time, it will take the same amount of time regardless of input size, which we denote as O(1).

`O(n)` solution

In this solution, we will run a loop from 1 to n and we will add these values to a variable named sum.

int findSum(int n) // input "n"
{
    int sum = 0; // -----------------> it takes some constant time "c1"
    for(int i = 1; i <= n; ++i) // --> here the comparison and increment will take place n times(c2*n) 
        sum = sum + i; // -----------> this statement will be executed n times i.e. c3*n
    return sum; // ------------------> it takes some constant time "c4"
}
/*
* Total time taken = time taken by all the statements to execute
*  i.e, total time taken = c2*n + c3*n + c1 + c4, if the expression c2*n + c3*n constitute to c0*n and another expression c1 + c4 constitute to c then
*  total time taken = c0*n + c, which constitute to O(n) complexity
*/

The big O notation of the above code is O(c0*n) + O(c), where c and c0 are constants. So, the overall time complexity can be written as O(n)

`O(n²)` solution

In this solution, we will increment the value of sum variable i times i.e. for i = 1, the sum variable will be incremented once i.e. sum = 1. For i = 2, the sum variable will be incremented twice. So, let's see the solution.

int findSum(int n)  // input "n"
{
    int sum = 0; // ---------------------> constant time c1
    for(int i = 1; i <= n; ++i) 
        for(int j = 1; j <= i; ++j)
            sum++; // -------------------> this will run [(n * (n + 1) / 2)] times
    return sum; // ----------------------> constant time c3
}
/*
* Total time taken = time taken by all the statements to execute
* total time taken = c1 + c2*n² + c2*n + c3
* which constitutes to c2*n² + c2*n + c3
*/

The big O notation of the above algorithm is O(c1*n²) + O(c2*n) + O(c3). Since we take the higher order of growth in big O. So, our expression will be reduced to O(n²).

Containers

A container is an object that stores a collection of elements (i.e. other objects). Each of these containers manages the storage space for their elements and provides access to each element through iterators or member functions. The container library provides standardized interface for member functions; these standardized interface allow containers to be used with STL algorithms.

The C++ containers library categorized as

Sequence containers - ordered collections in which every element has a certain position.
Associative containers - sorted collections in which the position of an element depends on its key due to a certain sorting criterion
Unordered associative containers - unordered collections in which the position of an element doesn’t matter.
Container Adapter - provide a different interface for sequential containers

Sequence Containers

In sequence containers, the position of an element depends on the time and place of the insertion, but it is independent of the value of the element. For example, if you put 5 elements into the a container by appending each element at the end of the actual collection, these elements are in the exact order in which you put them (Hence the name Sequence Containers). The STL contains three predefined sequence container classes: vector, deque, and list.

`std::vector`

The std::vector comes into play when array-like storage is needed, but with varying sizes. It uses memory from the heap to store objects and hence is a dynamic array. It enables random access, which means you can access each element directly with the corresponding index. Sequence containers are usually implemented as arrays or linked lists

Some Important pointers on std::vector

Appending and removing elements at the end of the array is very fast using push_back() and pop_back() respectively (O(1) in complexity notation).
However, inserting an element in the middle or at the beginning of the array takes time because all the following elements have to be moved to make room for it while maintaining the order (O(n) in complexity notation for n vector elements).
Vector reallocation occurs when vector size increases beyond its current storage capacity, it will automatically move all items to a larger chunk of newly allocated memory and delete the old chunk.
In such cases. iterators or references that point at altered portions of the sequence become invalid.

Size and capacity of the container

size is a the number of elements up to the highest-indexed one you have used; whereas capacity is the number of elements the vector can hold before reallocating.

The following example defines a vector for integer values, inserts six elements, and prints the elements of the vector:

#include <iostream>
#include <vector>  // header for vector

int main()
{
    std::vector<int> vec; //vector container for integer elements

    // append elements with values 1 to 6
    for (int i = 1; i <= 6; ++i)
    {
        vec.push_back(i);
    }

    //print all elements followed by a space
    for (const auto &ele : vec)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

NOTE: STL containers provide only those special member functions that in general have good performance, where "good" normally means constant or logarithmic complexity. This prevents a programmer from calling a function that might cause bad performance.

`std::deque`

Deque is an abbreviation for double ended queue. it is a dynamic array that is implemented so that it can grow in both directions.

Some Important pointers on std::deque

Inserting elements at the end and at the beginning is fast (O(1) in complexity notation).
However, inserting elements in the middle takes time because elements must be moved (O(n) in complexity notation for n deque elements).
If an element is inserted into an empty sequence, or if an element is erased to leave an empty sequence, then iterators earlier returned by begin() and end() become invalid.
If an element is inserted at the first position of the deque, then all iterators that designate existing elements become invalid.
If an element is inserted at the end of the deque, then end() and all iterators that designate existing elements become invalid.
Allocating deque contents from the center of the underlying array, and resizing the underlying array when either end is reached leads to frequent resizing and waste more space, particularly when elements are only inserted at one end.

It is important to note that, deque allocator allocates block of memory in a single allocation and hence frequent push_back() or push_front() has less memory allocation overhead compared to vector. In vector the memory is allocated in smaller chunks, hence frequent insertion of elements leads to frequent allocation of memory, slowing down the container.

The following general deque example declares a deque for floating-point values:

#include <iostream>
#include <deque>

int main()
{
    std::deque<float> dq; //deque container for floating-point elements

    for (int i = 1; i <= 6; ++i)
    {
        dq.push_front(i * 2.2); //insert at the front
    }

    //print all elements followed by a space
    for (const auto &ele : dq)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

`std::list`

A list is implemented as a doubly linked list of elements. This means each element in a list has its own segment of memory and refers to its predecessor and its successor.

Some Important pointers on std::list

Unlike vectors and deques, fast random access to list elements is not supported, to access the tenth element, you must navigate the first nine elements by following the chain of their links (O(n) complexity because the average distance is proportional to the number of elements).
list supports bidirectional iterators and allows constant time insert and erase operations anywhere within the sequence, with storage management handled automatically. (O(1) complexity).
If only uni-directional list traversal is needed, std::forward_list may be more performant in both space and maintenance complexity, because it maintains only list item pointers in one direction.

Example:

#include <algorithm>
#include <iostream>
#include <list>

int main()
{
    // Create a list containing integers
    std::list<int> l = {17, 55, 16, 3};

    // Insert an integer before 16 by searching
    auto it = std::find(l.begin(), l.end(), 16);
    if (it != l.end())
    {
        l.insert(it, 77);
    }

    //print all elements followed by a space
    for (const auto &ele : l)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

/*OUTPUT
17 55 77 16 3
*/

Associative containers

Associative container can be considered a special kind of sequence container because sorted collections are ordered according to a sorting criterion. The automatic sorting of elements in associative containers does not mean that those containers are especially designed for sorting elements. The key advantage of automatic sorting is better performance when you search elements. In particular, you can always use a binary search, which results in logarithmic complexity rather than linear complexity.

An associative container is a variable-sized container that supports efficient retrieval of elements (values) based on keys. It supports insertion and removal of elements, but differs from a sequence in that it does not provide a mechanism for inserting an element at a specific position. The STL contains four predefined associative container classes: set, multiset, map, multimap.

`std::set`

A set is a collection in which elements are sorted according to their own values. Each element may occur only once, thus duplicates are not allowed.

Some pointers on std::set

Insert and erase is O(log n) complexity.
Initialize with unsorted sequence is O(n log n) complexity.
Initialize with sorted sequence is O(n) complexity.
lower_bound and upper_bound can be used with set.

NOTE: lower_bound(st.begin(), st.end(), x) will compile but is O(n) for std::set

Example:

#include <iostream>
#include <set>

int main()
{
    std::set<int> st; //set container for int values

    /** insert elements in arbitrary order 
        *  value 1 gets inserted twice 
        */
    st.insert(8);
    st.insert(1);
    st.insert(5);
    st.insert(7);
    st.insert(1);
    st.insert(6);
    st.insert(11);

    // print all elements
    for (const auto &ele : st)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

/*OUTPUT
1 5 6 7 8 11
*/

`std::multiset`

A multiset is the same as a set except that duplicates are allowed. Thus, a multiset may contain multiple elements that have the same value.

The time complexity of count() is additionally linear (O(n)) to the number of elements having the key.

Example:

#include <iostream>
#include <set>

int main()
{
    std::multiset<int> st; //multiset container for int values

    /** insert elements in arbitrary order 
        *  value 1 gets inserted twice 
        */
    st.insert(8);
    st.insert(1);
    st.insert(5);
    st.insert(7);
    st.insert(1);
    st.insert(6);
    st.insert(11);

    // print all elements
    for (const auto &ele : st)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

// A multiset allows duplicates, so it would contain two elements that have value 1

/* OUTPUT
1 1 5 6 7 8 11
*/

`std::map`

A map contains elements that are key/value pairs. Each element has a key that is the basis for the sorting criterion and a value. Each key may occur only once, thus duplicate keys are not allowed. A map can also be used as an associative array, which is an array that has an arbitrary index type.

Some important pointers on std::map

Since multiset count() could be slow, we can use map to store the frequency of a key instead of inserting multiple copies of they same key into a multiset .
Insertion, deletion and lookup has logarithmic complexity O(log n), when n is the number of entries.
If the index operator is called with a non-existing number, it stores this number in the map and uses the default constructor for generating the data. This ensures that the index operator never returns an invalid reference.
In order to prevent above case, find() should be called beforehand.

Example:

#include <iostream>
#include <map>
#include <string>

int main()
{

    std::map<int, std::string> mp; //set container for int/string values

    //insert some elements in arbitrary order
    // a value with key 1 gets inserted twice
    mp.insert(std::make_pair(5, "map")); 

    /** 
     *  The  elements are key/value pairs, so you must create such a pair to insert it into the
     *  collection. The auxiliary function make_pair() is provided for this purpose.
     */
    mp.insert(std::make_pair(2, "is a"));
    mp.insert(std::make_pair(1, "sorted"));
    mp.insert(std::make_pair(4, "associative"));
    mp.insert(std::make_pair(6, "container"));
    mp.insert(std::make_pair(1, "key"));
    mp.insert(std::make_pair(3, "value"));

    // print key value pairs
    for (const auto &ele : mp)
    {
        /**
         * you must access the members of the pair structure, which are called first and second
         */
        std::cout << ele.first << " : " << ele.second << std::endl;  
    }
}

/*OUTPUT
1 : sorted
2 : is a
3 : value
4 : associative
5 : map
6 : container
*/

`std::multimap`

multimap differs from map in the same way as multiset differs from set: multiple entries of elements with identical keys are possible.

Example:

#include <iostream>
#include <map>
#include <string>

int main()
{

    std::multimap<int, std::string> mp; //set container for int/string values

    //insert some elements in arbitrary order
    // a value with key 1 gets inserted twice
    mp.insert(std::make_pair(5, "map"));
    mp.insert(std::make_pair(2, "is a"));
    mp.insert(std::make_pair(1, "sorted"));
    mp.insert(std::make_pair(4, "associative"));
    mp.insert(std::make_pair(6, "container"));
    mp.insert(std::make_pair(1, "key"));
    mp.insert(std::make_pair(3, "value"));

    // print key value pairs
    for (const auto &ele : mp)
    {
        std::cout << ele.first << " : " << ele.second << std::endl;
    }
}

/*OUTPUT
1 : sorted
1 : key
2 : is a
3 : value
4 : associative
5 : map
6 : container
*/

Custom compare for associative containers

Container have a predefined comparison function, Sometimes we may want to supply alternative comparison function. The complete declaration for std::set is

template <class T, class Compare = less<T>, class Alloc = allocator<T> > 
class set;

Where,

T is the type of elements that will be held
Alloc is the memory allocator, with the default being allocator<T>
Compare is the type of the comparison used, with the default being std::less<T>

we can provide our desired comparison function object for the template parameter.

#include <iostream>
#include <set>

template <typename T>
int printContainer(T con)
{
    for (const auto &ele : con)
    {
        std::cout << ele << ' ';
    }
    std::cout << std::endl;
}

int main()
{
    auto comp = [](int a, int b)
    { return a > b; };

    std::initializer_list<int> lst{34, 45, 1, 77, 98, 15};

    std::set<int> st(lst);                        // default std::less<int>
    std::set<int, std::greater<int>> st1(lst);    // changed compare to std::greater<int>
    std::set<int, decltype(comp)> st2(lst, comp); // custom compare same as std::greater<int>

    std::cout << "With default std::less<int>: ";
    printContainer(st);

    std::cout << "With std::greater<int>: ";
    printContainer(st1);

    std::cout << "With custom compare comp: ";
    printContainer(st2);

    return EXIT_SUCCESS;
}

/*OUTPUT
With default std::less<int>: 1 15 34 45 77 98 
With std::greater<int>: 98 77 45 34 15 1 
With custom compare comp: 98 77 45 34 15 1
*/

Unordered associative containers

Binary search tree is not the only way of implementing associative containers. With hash tables, items can be found in O(1) time. The size of the hash table can be manipulated by the user, and the hash function can also be chosen individually, which is important, because the performance versus space consumption characteristics depend on that.

Some important pointers

These containers has Hash table implementation
Since elements are unordered, you cannot perform binary search
Also, begin() does not return the smallest element
In order to use unordered_set/map, classes must have hash function implemented

Example:

struct hasher
{
    size_t operator()(std::pair<int, int> x) const
    {
        return x.first ^ x.second;
    }
};

int main()
{
    std::unordered_set<std::pair<int, int>, hasher> us;

    us.insert({5, 2});
    us.insert({6, 1});
    us.insert({1, 7});
    us.insert({4, 9});
    us.insert({0, 6});

    std::cout << us.bucket_size(6) << std::endl; // prints 2 becz there are 2 containers with hash code 6
    return EXIT_SUCCESS;  
}

Alternatively, you can implement a stronger hash function that produces different, unpredictable hashes for the same number across runs.

Adapter Containers

Container adapters are a special type of container class. They are not full container classes on their own, but wrappers around other container types (such as a vector, deque, or list). These container adapters encapsulate the underlying container type and limit the user interfaces accordingly.

There are three standard container adapters: stacks, queues, and priority queues.
Constructor adapters allow you to pass a specific allocator to their constructors.
Container adapters provide the emplace() feature, which internally creates a new element initialized by the passed arguments

`std::stack`

A stack is a container which allows insertion, retrieving, and deletion only at one end (LIFO data structure). Objects inserted first are removed last. Any one of the sequence container could be used as a stack, if those containers supports the following operation.

Insertion at one end (push, with push_back()).
Deletion from the same end (pop, with pop_back()).
Retrieving the value at that end (top, with back()).
Testing the stack being empty (with empty()).

The std::stack<T> is a stack of T with a default implementation using a deque.

Example:

int main()
{
    std::stack<int> s;
    s.push(10);
    s.push(20);
    s.push(30);
    s.push(40);
    s.push(50);

    std::cout << "Size: " << s.size() << std::endl; 
    std::cout << "Top: " << s.top() << std::endl; 

    std::cout << "Elements of stack: ";

    while(!s.empty())
    {
        std::cout << s.top() << ' ';
        s.pop();
    }
    std::cout << std::endl;

    return EXIT_SUCCESS;   
}

/*OUTPUT
Size: 5
Top: 50
Elements of stack: 50 40 30 20 10
*/

`std::queue`

A queue allows you to insert objects at one end and to remove them from the opposite end (FIFO data structure). The objects at both ends of the queue can be read without being removed.

list and deque are suitable data types for queue implementation.
The std::queue<T> is a queue of T with a default implementation using a list.
push() inserts any number f elements.
pop() removes the elements in the same order in which they are inserted.
front() returns the first element in the queue.
back() returns the last element in the queue.

Example:

int main()
{
    std::queue<int> q;
    q.push(10);
    q.push(20);
    q.push(30);
    q.push(40);
    q.push(50);

    std::cout << "Size: " << q.size() << std::endl; 
    std::cout << "Front: " << q.front() << std::endl; 
    std::cout << "Back: " << q.back() << std::endl; 

    std::cout << "Elements of queue: ";

    while(!q.empty())
    {
        std::cout << q.front() << ' ';
        q.pop();
    }
    std::cout << std::endl;

    return EXIT_SUCCESS;   
}

/*OUTPUT
Size: 5
Front: 10
Back: 50
Elements of queue: 10 20 30 40 50
*/

`std::priority_queue`

A priority queue always returns the element with the highest priority. The priority criterion must be specified when creating the queue. In the simplest case, it is the greatest (or smallest) number in the queue. We can also write our own custom compare to describe the priority of an element in the queue (default compare is std::less<int>).

Example:

int main()
{
    std::priority_queue<int, std::vector<int>, std::greater<int>> pq;
    pq.push(10);
    pq.push(20);
    pq.push(30);
    pq.push(40);
    pq.push(50);

    std::cout << "Size: " << pq.size() << std::endl;
    std::cout << "Top: " << pq.top() << std::endl;

    std::cout << "Elements of queue: ";

    while (!pq.empty())
    {
        std::cout << pq.top() << ' ';
        pq.pop();
    }
    std::cout << std::endl;

    // using lambda to compare elements.
    auto compare = [](int a, int b)
    {
        return a < b;
    };

    std::priority_queue<int, std::vector<int>, decltype(compare)> q(compare);

    for (int n : {1, 8, 5, 6, 3, 4, 0, 9, 7, 2})
        q.push(n);

    std::cout << "Elements of queue for custom compare: ";

    while (!q.empty())
    {
        std::cout << q.top() << ' ';
        q.pop();
    }
    std::cout << std::endl;
    return EXIT_SUCCESS;
}

/*OUTPUT
Size: 5
Top: 10
Elements of queue: 10 20 30 40 50 
Elements of queue for custom compare: 9 8 7 6 5 4 3 2 1 0
*/

Choose your containers wisely.

Do you need to be able to insert a new element at an arbitrary position in the container? - if so, you need a sequence containers.
Do you care how elements are ordered in the container? - if not, hashed containers becomes workable choice, otherwise use ordered containers.
Do you need to avoid movement of existing containers elements when insertions and erasures take place? - Avoid using contiguous containers
Does you code has frequent push_back()? - use deque instead of vector as deque allocates block of data.
If there are strict requirements on memory usage, additional memory overhead for storing hash table cannot be accepted.
If you are to traverse the map use ordered map instead of unordered map.
If the size is immutable choose std::array instead of vector.
If there are frequent insertion and remove of the elements in the middle of the sequence- use std::list instead of vector and deque.

In some use cases the containers in STL are not a great fit, in that case we can write our own containers. With the implementation of some basic core interfaces we can use adaptor interface efficiently.

Advanced Templates in Modern C++

Pratik Parvati — Sun, 11 Jul 2021 18:08:07 +0000

Advanced Templates in Modern C++

We write high-level languages because they make our program more concise and easier to maintain. Most of the low level details are abstracted over by the compiler, and programmers no longer concern himself into these details. But sometimes the programmers need to know more about some particular details than compiler does to write more efficient code.

Templates enforce the C++ compiler to execute algorithms at compilation time, which gives us more flexibility to write generic program to avoid run-time overhead. This article is an extension to my previous article Introduction to C++ templates to give insight on some advanced features added in C++11, C++14 and C++17.

Dependent names

A Dependent Name is any name within a template definition that depends on one or more of the template parameters. When using templates there is a distinction between the point of definition of the template and the point of instantiation (where templates are used). Names that depend on a template don't get bound until the point of instantiation. For instance:

template <typename T>
struct Base
{
    void baseMethod()
    {
        std::cout << "Base<T>::f()\n";
    }
};

template <typename T>
struct Derived : Base<T>
{
    void derivedMethod()
    {
        std::cout << "Derived<T>::g()\n  ";

        /**
         * ERROR: Dependent Name (as there is no baseMethod() in derived class): Call to baseMethod() depends
         * on Base class template hence compiler is not aware of baseMethod().
         */
        baseMethod();
        f(); // Non dependent Name: hence no issues here
    }

    void f()
    {

    }
};

int main()
{
    Derived<int> d{};
    d.derivedMethod();
    return EXIT_SUCCESS;
}

/* ERROR
test.pp.cpp: In member function 'void Derived<T>::derivedMethod()':
test.pp.cpp:21:20: error: there are no arguments to 'baseMethod' that depend on a template parameter, so a declaration of 'baseMethod' must be available [-fpermissive]
         baseMethod();
                    ^
test.pp.cpp:21:20: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
*/

The compiler treats the call to baseMethod() as a non-dependent name, and must be resolved at the point of template's definition. At this point compiler doesn't know Base<T>::baseMethod() as it can be specialized later. A simple fix is to make the compiler understand that the call baseMethod() depends on template parameters. Changing the call to baseMethod() as Base<T>::baseMethod() (or this->baseMethod()) would compile the code without errors as the call to function baseMethod() is resolved at the point of template's instantiation.

Now, what if the dependent name is a type?

template <typename T> 
struct Base 
{
   using value_type = T;
   void baseMethod() 
   {
       std::cout << "Base<T>::f()\n";
   }
};


template <typename T> 
struct Derived : Base<T> 
{
   value_type val = 10; //(1) ERROR: 'value_type' is not declared in the scope
   Base<T>::value_type val = 10; //(2)ERROR: need 'typename' before 'Base<T>::value_type' because  'Base<T>' is a dependent scope
   typename Base<T>value_type val = 10; //(3) Works

   void derivedMethod()
   {
       std::cout << "Derived<T>::g()\n  ";     
       Base<T>::baseMethod();
   }
};

We already know why (1) doesn't work (value_type is non-dependent); when we use typename in(3) we are explicitly telling the compiler that it is a type. This is stated in the C++ standard, section 14.6:

A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename.

Template Template Parameter

Template Template Parameters enable a template to be parameterized by the name of another template.

// Example for template template parameter used with class

template <typename T, template <typename, typename> class Cont > // the keyword class is a must before C++17, otherwise typename can also be used
class MyContainer
{
public:
  explicit MyContainer(std::initializer_list<T> inList): data(inList)
  {  
  }
  int getSize() const
  {
    return data.size();
  }

  void printCont()
  {
      for(const auto& d: data)
      {
          std::cout << d << ' ';
      }
      std::cout << '\n';
  }

private:
  Cont<T, std::allocator<T>> data; // the hidden default allocator in STL should be explicitly defined with the container to work with templates.                                                              

};

int main()
{
  MyContainer<int, std::vector> myIntVec{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; 
  std::cout << "myIntVec.getSize(): " << myIntVec.getSize() << std::endl;
  return EXIT_SUCCESS;
}

/*OUTPUT
myIntVec.getSize(): 10
*/

The first parameter T, is the name of a type. The second parameter Cont, is a template template parameter. It's the name of a class template that has a two typename parameter. Note that we didn't give a name to the typename parameter of Cont, although we could have:

template <typename T, template <typename ElementType, typename Allocator> class Cont>
class MyContainer;

However, such a name (ElementTypeand Allocator above) can serve only as documentation. These names are commonly omitted, but you should feel free to use them where you think they improve readability. For additional convenience, we can employ a default for the template template argument.

template <typename T, template <typename, typename> class Cont = std::queue>
class MyContainer 
{
    //...
};
//...
MyContainer<int> c1; // use default: Cont is std::queue
MyContainer<std::string, std::list> c2; // Cont is std::list

The template template parameter can also be used with Function template

template <typename T, template <typename, typename> class Cont >
void print_container(Cont<T, std::allocator<T> > container) 
{
    for (const T& v : container)
        std::cout << v << ' ';
    std::cout << '\n';
}

int main()
{
    std::vector<char> v{'c','+','+'}; //initilize vector
    std::list<int> lt(5,10); // initializing a list with 5 elements

    std::cout << "Vector elements: ";
    print_container(v);
    std::cout << "List elements: ";
    print_container(lt);
    return EXIT_SUCCESS;
}

/*OUTPUT
Vector elements: c + + 
List elements: 10 10 10 10 10 
/*

Passing Container of Containers as C++ Template Parameter

template <
    template <typename, typename> class Cont1,
    template <typename, typename> class Cont2,
    typename T>
void print_container(Cont1<Cont2<T, std::allocator<int>>, std::allocator<Cont2<T, std::allocator<T>>>> container)
{
    for (const auto &c2 : container)
    {
        for (const auto &v : c2)
        {
            std::cout << v << ' ';
        }
        std::cout << '\n';
    }
    std::cout << '\n';
}

int main()
{
    std::vector<std::vector<int>> vec{{1, 2, 3}, {4, 5, 6}}; //initilize vector

    std::cout << "Vector elements: \n";
    print_container(vec);
    return EXIT_SUCCESS;
}

/*OUTPUT
Vector elements: 
1 2 3 
4 5 6 
*/

/************** Breaking down function argument for better understanding ******************
 * 
 * using T1 = Cont2<T, std::allocator<int> >, then the argument would be
 * 
 * Cont1<T1, std::allocator<T1>> 
 */

The above code is complex and explicit way of passing container of containers.

Forwarding Reference used with Templates

Forwarding Reference allows a template function that accepts a set of arguments to forward these arguments to another function while retaining the lvalue or rvalue nature of the original function arguments. It reduces excessive copying and simplifies code by reducing the need to write overloads to handle lvalues and rvalues separately.

The Problem

Let's look at the below example

template<typename T> 
void outerMethod(T& param)
{ 
    innerMethod(param); 
}

The outerMethod() accepts an lvalue reference, therefore we can only pass lvalues to it.

int x = 10;
outerMethod(x); // Works, lvalue is passed as argument

outerMethod(10) // ERROR: passing rvalue to lvalue reference

We can fix this by making the outerMethod() to accept const lvalue reference, then the innerMethod() would not be allowed to modify the argument. We would have to overload the outerMethod() to handle rvalues

template<typename T>
void outerMethod(T&& param)
{
    innerFunction(param);
}

What if the innerFunction() must accept the rvalue reference as an argument. We know that, even if the outer function accepts an rvalue reference when it comes to passing that argument to the inner function it will be seen by the compiler as lvalue and is therefore not allowed. This is where perfect forwarding or Forwarding reference comes to our rescue.

Reference Collapsing

Reference collapsing is a set of rules in C++11 to determine the value of T of a template function argument.

Taking the reference of an lvalue reference results in an lvalue reference T& & becomes T&
Taking the rvalue reference of an lvalue reference is an lvalue reference T& && becomes T&
Taking the lvalue reference of an rvalue reference is an lvalue reference T&& & becomes T&
Taking the rvalue reference of an rvalue reference is an rvalue reference T&& && becomes T&&

In any situation where an lvalue reference is involved the compiler will always collapse the type to an lvalue reference, if an rvalue references is involved then the type deduced is an rvalue reference.

The solution: Forwarding with `std::forward`

The function std::forward is required for solving the perfect forwarding problem with the functions purpose to resolve that awkward rule in which rvalue references are treated as lvalues.


class MyClass
{
public:
    MyClass(std::string b) : b(b) {} // Copy Constructor
    MyClass(const MyClass &other) : b(b)
    {
        b = other.b;
        std::cout << "Copy Constructor\n";
    }                             
    MyClass(MyClass &&other) // Move Constructor
    {
        b = std::move(other.b);
        std::cout << "Move Constructor\n";
    }

private:
    std::string b;
};
// And a template function
template <typename T>
void OuterFunction(T &&param)
{
    // As per the rule (third and fourth) lvalue evaluates to lvalue and rvalue evaluate to rvalue
    MyClass a(std::forward<T>(param));
}

int main()
{
    // Passing an lvalue
    MyClass a = MyClass("Amar");
    OuterFunction(a); 
    // Passing an rvalue
    OuterFunction(MyClass("Akbar"));
}
/*OUTPUT
Copy Constructor
Move Constructor
*/

Variable Templates

It is possible to define templated variables since C++14. The most important use of Variable Templates is in defining parametrized constants. Let's take an example of a numeric constant, pi i.e,π; which needs to be defined for various numeric types (e.g., int, float, double) to handle different precisions.

template <typename T>
constexpr T pi = T(3.1415926535897932385);

Now we can have pi constant for different numeric types.

std::cout << pi<int> << std::endl;
std::cout << pi<double> << std::endl;

We can use Variable Templates to compute mathematical calculations at compile time. Here is an interesting piece of code.

template<size_t T> struct fact;

template<> // Explicit specialization
struct fact<0>
{
    constexpr static auto value = 1;
};

template<size_t T>
struct fact
{
    constexpr static auto value = T * fact<T - 1>::value;   
};

static_assert(fact<0>::value == 1);
static_assert(fact<1>::value == 1);
static_assert(fact<2>::value == 2);
static_assert(fact<3>::value == 6);
static_assert(fact<4>::value == 24);
static_assert(fact<5>::value == 120);

The above code evaluates the factorial of numbers at compile time reducing run time overhead to improve performance.

NOTE: The static_assert throws error during compile time if the factorial of a number doesn't match.

Template Type Alias

In C++, it is possible to create synonyms that can be used instead of a type name. The syntax for type alias is as follows

using identifier = type-id 

template<template-params-list> identifier = type-id // to alias templates

For example:

template <typename T> 
using vec_t = std::vector<T, custom_allocator<T>>; 

vec_t<int>           vi; // std::vector<int, custom_allocator<int>>
vec_t<std::string>   vs;  // std::vector<std::string, custom_allocator<std::string>>

template<typename T> 
using ptr = T*;
ptr<double> p = new double;   // double* p = new double;

Variadic Templates

C++11 lets us define variadic templates, taking any amount of parameters, of any type, instead of just a specific number of parameters. For example, you can use the following code to call f() for a variable number of arguments of different types:

template<typename T, typename... Tail>
void f(T head, Tail... tail)
{
    g(head);   //do someting to head
    f(tail...);      //try again with tail
}

void f() { }  //do nothing

The key to implementing a variadic template is to note that when you pass a list of arguments to it, you can separate the first argument from the rest. After evaluating the function (g()) for head, the function f() is recursively called with the rest of the arguments (tail).The ellipses ... is used to indicate the rest of a list. when the tail become empty and we need a separate function to deal with that.

When we call f() as f(1.5, 23, "Amar");, the head (1.2) is precessed by g() and later call f(23, "Amar"); with rest parameters, which will recursively call f("Amar");, which will call empty function f().

f(1.5, 23, "Amar") calls --> f(23, "Amar") calls --> f("Amar") calls --> f()

Variadic Function Template

Here is a basic example :

template<typename T>
T multiply(const T& arg)
{
  return arg;
}

template<typename T, typename... ARGS> // Function parameter pack
T multiply(const T& arg, const ARGS&... args)
{
  return arg * multiply(args...); // Unpacking the parameter
}

int main()
{
  std::cout << multiply(1, 5u, 6u, 8L);
}

/*OUTPUT
240
*/

Variadic Class Template

Here is a basic example

template <typename... T_values>
class Base
{
public
    virtual void f(T_values... values) = 0;
};

class Derived1 : public Base<int, short, double>
{
public:
    void f(int a, short b, double c) override;
};

class Derived2 : public Base<std::string, char>
{
public:
    void f(std::string a, char b) override;
};

Parameter Packs

The typename... T_values is called template parameter pack. if you are just templating a function then it's called a function parameter pack.

class MyClass
{
public:
    template <typename... T_values>
    void myMethod(T_values... values);
};

Expanding the Parameter

The T_values... in myMethod() signature is unpacking the parameter pack in function parameter list.

Recursive variadic class template with partial specialization

Let's look at an example of recursive variadic template to print out the parameter types of a parameter pack.

template <typename... Args>
struct PrintType;

template <typename First, typename... Args>
struct PrintType<First, Args...>
{
    static std::string name()
    {
        return std::string(typeid(First).name()) + " " + PrintType<Args...>::name();
    }
};

// Need  partial specialization to end the recursion
template <>  // Partial specialization
struct PrintType<>
{
    static std::string name()
    {
        return "";
    }
};

template <typename... Args>
std::string type_name()
{
    return PrintType<Args...>::name();
}

int main()
{
    std::cout << type_name<bool, char, int , double>() << std::endl;
    return 0;
}

/*OUTPUT
b c i d
*/

Forwarding references used with variadic templates

template <typename... Args>
void outerMethod(Args&&... args) {
    innerMethod(std::forward<Args>(args)...);
}

NOTE: Forwarding references can only be used for template parameters

Varidic template with template template parameter

template< typename T>
struct MyStruct
{
private:
  T* cont;
  size_t size;
public:
  MyStruct(std::initializer_list<T> list): cont(new T[list.size()]), size(list.size())
  {
      int i = 0;
    for(auto &l: list)
    {
      *(cont + i++) = l;
    }
  }

  void printCont()
  {
    for(int i  = 0; i < size; i++)
    {
      std::cout << *(cont + i) << ' ';
    }
    std::cout << '\n';
  }
};

template< template<typename, typename...> class ContainerType, typename Type, typename... Types>
auto build_container(Type first, Types... args)
{
    ContainerType<Type> c{first, args...};
    return c;
}

int main()
{
    using namespace std::string_literals;
    auto v = build_container<MyStruct> ("Amar"s, "Akbar"s, "Anthony"s, "Arjun"s);
    v.printCont();
}

/*OUTPUT
Amar Akbar Anthony Arjun
*/

Keyword `typename` and `class`

typename and class are replaceable in most of the cases. However, in C++, sometimes you must use typename.


struct Entity
{
    using SubType = int;
    //...
};

template <class T>
class MyClass
{
    typename T::SubType type; // keyword typename is used as the identifier before the type.
    // ...
};


// Another example
class ClassA 
{
public:
    class foo 
    {
    };
};

template<typename C>
class ClassB : public C::foo // dependent name, typename keyword is a must
{
};

We should use typename when a dependent type occurs. To Specify Template Template Type we should use class keyword (prior to C++17).

template< template<typename, typename...> class ContainerType, typename Type, typename... Types>
auto build_container(Type first, Types... args)
{
    ContainerType<Type> c{first, args...};
    return c;
}

Understanding advanced C++ templates is crucial if the developer wish to write flexible and robust code. Templates have advantage over code reuse and faster iterative development, which enhances the flexibility of the code. That being said templates has some downsides, it can cause code bloat problems and can also lead to longer compilation time. When error occurs, the error message is very messy and it is not easy to locate the error.