While roaming the halls of Synopsys corporate offices I found myself in one of the smaller demonstration labs and spotted this:
Hey, it’s not too late to attend SNUG Silicon Valley: http://www.synopsys.com/Community/SNUG/Silicon%20Valley/pages/default.aspx
Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, DWC IP Prototyping Kits, Early Software Development, FPGA-Based Prototyping, FPMM Methods, Getting Started, HAPS-80, HW/SW Integration, In-System Software Validation, IP Validation, Man Hours Savings, Performance Optimization, Project management, Real Time Prototyping, Support, System Validation, Technical, Tips and Traps, UltraScale, Use Modes
Posted in ASIC Verification, Bug Hunting, Debug, Early Software Development, HAPS-80, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Man Hours Savings, Performance Optimization, Real Time Prototyping, System Validation, UltraScale, Use Modes
Design defects (bugs) can be introduced at multiple levels in the design process from RTL defects, SW defects and Integration defects. The key to rapidly locating these bugs is to tailor the debug strategy to the type of bugs you are looking for. Depending on where you are in the design cycle usually dictates which type of bug is more prevalent. Physical Prototyping exercises the RTL, SW and the fully integrated design so is a key technology for design verification. Having the right debug tool set if critical to accelerate the verification task.
Great article by Tom De Schutter on using Physical Prototyping for software development. The article goes into other use cases and explores the age old make vs. buy decision making process.
Posted in ASIC Verification, Bug Hunting, Debug, Early Software Development, HAPS-80, HW/SW Integration, In-System Software Validation, IP Validation, Man Hours Savings, Performance Optimization, Project management, Real Time Prototyping, System Validation, Use Modes
In a continuation of last week’s blog titled “Validating USB Type-C using Physical Prototyping” one of the key USB folks here at Synopsys, Morten Christiansen, made a short 30 second video of the DesignWare USB Type-C physical prototype in action. (Click the picture to take you to the video)
This week Synopsys Introduced the DesignWare USB 3.1 Type-C IP with DisplayPort 1.3 and HDCP 2.2 for High-Bandwidth Data Transfer with Content Protection. USB has been continually evolving and USB Type-C is the one cable to connect them all. The USB Type-C is already gaining widespread acceptance and is becoming the most rapidly adopted USB standard in history. The need to rapidly adopt a new standard comes with challenges for the design engineers, verification team and the software developers.
Posted in ASIC Verification, Bug Hunting, Daughter Boards, DWC IP Prototyping Kits, Early Software Development, HW/SW Integration, IP Validation, Man Hours Savings, Project management, System Validation, Use Modes
While traveling this week I found myself explaining the value of Hybrid Prototyping when used with DesignWare IP or your own IP blocks and RTL code. Simply put, using Hybrid Prototyping you can immerse the IP in the context of the SoC without needing to have RTL for the whole SoC. Hybrid Prototyping enables a Pre-RTL SoC representation to be rapidly created (using off the shelf Virtualizer Development kits as a starting point) and incorporating the block(s) under test modeled in HAPS Physical Prototype. This Hybrid Prototype is used for early software development in the case of the DesignWare IP and can be used in the same way for your own blocks in addition to increasing the verification of the design(s) under test.
A long time ago in a blog since forgotten I talked about the importance of 1:1 mapping between the Xilinx FPGA Super Logic Region, SLR, to IO Bank to Connector. The result of which can be as much as 2X system performance thanks to efficient mapping of the design to the FPGA.
Back in 2011 I had a vision, a vision for how users of both IP and FPGA-Based Prototypes could be more productive. The problems these users faced was not to do with bugs or lack of capabilities in the products but from the fact that the usage crossed between the two products. IP users traditionally are not experienced prototypers and prototypers lacked IP specific knowledge. Of course this was not helped by the fact that the IP did not document it’s prototyping specific needs. For example, the IP is optimized for ASIC deployment and when you prototype it the clocking, reset and rams sometimes need to be modified to fit into a FPGA environment. Another issue is that as it’s ASIC IP not all configurations can be physically supported in FPGA. For example while the IP might support up to 16 IO ports on the prototype you might only be physically implement up to 4.