Simulation & Verification are fundamental in the process of developing any good quality FPGA-based RTL codification. These are key steps within SoC-e’s designing procedures, and in this article, we are going to provide more insights about them in our Networking IP Core portfolio.
The whole process is divided in the following high-level steps:
- Entity/Block-oriented simulation: Simulation at entity/block-level for the different modules that compose each IP Core, by generating stimulus on each input signal and verifying that the RTL code behaviour is the expected one.
- Global-oriented simulation: Once the different modules have been validated individually, the next step implies simulating the whole IP as a single UUT (Unit Under Test).
- (On) Hardware testing: Even though an extended simulation plan provides a good level of trustiness, there are still many corner situations that can’t be verified on a virtual environment. For those cases, a hardware-based test plan is required, and also the last step towards a high-quality result.
In this article, the first step is described; how the Entity or block level of the IP simulation is done.
Entity or Block oriented simulation
This first step implies validating the right operation of a specific entity or module that has one specific action inside the IP Core. Every IP Core is composed of many Entities or Blocks, and in order to test them, there would be different testbenches for each Entity, exercising a design by observing the outputs of the design when the inputs are stimulated. This would help to check the expected behavior.
Everything is best understood with an example. In this case, we are going to explain the filtering database of our Ethernet Switch IP Core.
The Filtering Database stores MAC addresses and their associated information to take the frame forwarding decision. It is a hash-based memory with some bins per address entry that stores the filtering data. That hash algorithm also generates the index to the memory of the Filtering Database.
The Filtering Database performs three main processes: Learning, Lookup and Aging.
- Learning process is in charge of saving frames when different conditions are met.
- Lookup process is the one that searches in the Filtering Database and obtains the forwarding portmask of the frame.
- Aging process removes old MAC entries depending on a given period of time.
In this specific case of simulation of the MAC table, always try to test all the mechanisms that form the Filtering database functionality. In this sense like the learning different MACs, different queries, also the aging is done in parallel, and finally we clear the MAC table and verify that all the entries have been deleted, etc. It is also very important to study and always be able to test possible corner cases.
To conclude, the second step of Testing & Verifying complex FPGA designs will be described in another post. Once all Entities that form the IP Core are working as expected, the global simulation comes into play.
