Path: EDN Asia >> Design Centre >> IC/Board/Systems Design >> Grasp interconnect verification in SoC design (Part 1)
IC/Board/Systems Design Share print

Grasp interconnect verification in SoC design (Part 1)

12 Mar 2015  | Ramneek Real, Janak Patel, Bhavin Patel

Share this page with your friends

The implementation of an interconnect scoreboard needs to consider each possible route of the Interconnect fabric in SoC and the address map. Routing and address map configuration is therefore a key feature of a interconnect scoreboard.


Figure 1: Scoreboard Architecture for Interconnect.


Due to different bus interfaces at input & output of interconnect fabric, protocol conversion (PRC) has been done at each VIP monitor connected to interface, based on master and slave configuration. In protocol conversion, transactions are mapped as per slave interface configuration, to reduce the complexity in response path. Because of diverse addresses and data width of each master and slave, transaction realignment between master and slave interfaces needs to be taken care during protocol conversion with splitting of requests and merging of responses.

In SoC, multiple masters can communicate to multiple slaves and socket protocols introduce two-way communication. We have developed separate scoreboards for request and response per slave. The Scoreboard is kind of a data checker, which checks data integrity with all attributes present on slave interface.

Requests and responses, collected from multiple bus master VIP monitors, are routed through transaction router to the scoreboard based on slave address and connectivity table. The transaction router also has an error reporting mechanism, when transactions are not sent to the correct interface or when transactions, generated to an unmapped address, do not get an error response from interconnect fabric. It filters transactions when transactions are sent to protected area, and checks the response of those filtered transactions from interconnect. Transaction filtering is done based on protection register modelling in transaction router. These registers are continuously updated in transaction router whenever write transactions are successfully completed as per the connectivity table. Also, the functional coverage model is implemented for features to be verified and requires information samples from the transaction router.


About the author
Janak Patel & Bhavin Patel are with eInfochips.

Ramneek Real is with Toshiba.


 First Page Previous Page 1 • 2


Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.


Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming


News | Products | Design Features | Regional Roundup | Tech Impact