Presentation
Elevating BFM Capabilities:
DescriptionBus Functional Models (BFMs) are commonly used in digital design and verification processes. They serve as abstract representations of the behavior of buses or communication interfaces within a system. People use BFMs for several reasons, such as early system-level simulation, verification of communication protocols, speed up verification, modular verification, test bench development, and debugging.
Companies may choose to use proprietary Bus Functional Models (BFMs) instead of standard-defined BFMs for various reasons such as, Customization for Specific Requirements, Competitive Advantage, Protection of Intellectual Property, Optimized Performance, Integration with In-House Tools, and Industry-Specific Standards. for example Ethernet proprietary BFMs caters the Automotive, IoT, Security, Networking and cloud-based application SOCs.
While going forward with proprietary BFM for their IP companies also face some functional verification challenges, such as they can't directly connect Third-party Verification IPs (discrepancy in Connections and frame fields) and need to define their own Protocol checks and Packet scoreboard In case they choose to go for third party verification IP then Verification IPs Requires Flexible topologies, and it requires support for extra proprietary fields.
This paper will focus on understanding the problem and the solution of proprietary BFM verification using the use case of Ethernet frame BFM carrying the Upper layer proprietary frames. We will try to explain the problem and solution using topology diagrams and all the required pointers.
Companies may choose to use proprietary Bus Functional Models (BFMs) instead of standard-defined BFMs for various reasons such as, Customization for Specific Requirements, Competitive Advantage, Protection of Intellectual Property, Optimized Performance, Integration with In-House Tools, and Industry-Specific Standards. for example Ethernet proprietary BFMs caters the Automotive, IoT, Security, Networking and cloud-based application SOCs.
While going forward with proprietary BFM for their IP companies also face some functional verification challenges, such as they can't directly connect Third-party Verification IPs (discrepancy in Connections and frame fields) and need to define their own Protocol checks and Packet scoreboard In case they choose to go for third party verification IP then Verification IPs Requires Flexible topologies, and it requires support for extra proprietary fields.
This paper will focus on understanding the problem and the solution of proprietary BFM verification using the use case of Ethernet frame BFM carrying the Upper layer proprietary frames. We will try to explain the problem and solution using topology diagrams and all the required pointers.
Event Type
Engineering Track Poster
TimeTuesday, June 255:42pm - 5:43pm PDT
LocationLevel 2 Exhibit Hall
Back-End Design
Embedded Systems
Front-End Design
IP