BLOGS & FORUMS
Breaking The Three Laws
|Breaking The Three Laws|
Archive for the 'Project management' Category
Posted by Michael Posner on 17th April 2015
The WNS I am talking about is Worst Case Negative Slack and not White Nose Syndrome, a disease in North American bats which, as of 2012, was associated with at least 5.7 million to 6.7 million bat deaths. Please help and stop the spread of this nasty disease. Poor little bats have no defense against it. The WNS I’m going to talk about is Worst Case Negative Slack of a prototyping design, reduce WNS and prototype execution performance increases.
A couple of weeks back I blogged on Timing Biased Partitioning and received a number of follow up questions and comments. This blog is to hopefully answer those and provide more information on the Synopsys capabilities to optimize for the highest system performance on your HAPS-based prototype.
The first question, actually statement was from one of the Synopsys engineers who correctly pointed out that my blog title only covers a fraction of what HAPS ProtoCompiler does in the area of prototype performance optimization. In addition to reducing the number of multi-hop paths during the automated partition stage, ProtoCompiler can also reduce the path length and automatically use a lower pin mux ration on multi-hop paths. The combination of these result in the highest performance prototype. In essence timing biased capabilities cross the partition, system route and system generate stages of the prototyping design flow.
Something that I did not mention in the previous blog was the recommendations for pin mux ratios for optimized performance, so here they are.
- All paths are not critical
- Some paths don’t need to be fast
- False paths and asynchronous clock crossing
- Slow clocks and debug paths
- Some paths are just fast, pipeline paths with little logic
- Don’t use one HAPS HSTDM ratio everywhere
- Lower ratios on critical paths
- Higher ratios on non-critical path
- HAPS ProtoCompiler supports ratios up to 128:1
- HAPS Hardware Traces are precious
- High ratios on non-critical paths, frees up traces for critical paths (HAPS flexible interconnect)
- No cost to mixing ratios with HAPS HSTDM
- Source sync clock is shared across ratios
- No overhead of mixing ratios
Much of this is automated in HAPS ProtoCompiler but the 2nd question was why these timing biased capabilities are not default “ON”. The answer is that typically the goal at the start of the project is Time to First Prototype (TTFP), and you sacrifice performance optimization to get a valid solution in the least amount of time. Optimization for performance, while automated, increases the runtime of the tool. The recommendation is that you utilize the HAPS ProtoCompiler TTFP mode to generate a feasible solution and hand this off to your developers. While it might not be performance optimized your developers will thank you as you delivered it very quickly. They can be very productive debugging the initial HW/SW integration, board support software and completing initial OS boot procedures. With your developers busy and happy you have an extra day or so to optimize the platform for performance. Now you turn on timing biased capabilities as you can afford the slightly longer runtime to a feasible solution. This is an iterative process as you play with partition, route and physical interconnect on the HAPS systems.
The results of HAPS ProtoCompiler timing biased capabilities are astonishing and I was able to get my hands on the results of these capabilities from a suite of test designs. This suite of designs consist of real customer designs which we have gather over time (with permission). The goal of this testing was to judge the automated capabilities of the tools.
First the “hop” reduction with multi_hop_path optimization enabled is amazing. It’s hard to see in the picture but all designs yielded multi-hop path reduction with the capability enabled.
Second, the effect to worse case negative slack showed up to 60% reduction. Reduce WNS and performance is improved !!!!
The funny thing is that the effect on runtime is not huge so while above we recommend a TTFP flow first and then a timing optimized flow you can be successful in generating a timing optimized solution right out of the starting gate. Well at least a version where you have enabled the capabilities but spend no time analyzing the output. Remember, to get the most out of the HAPS solution you should tailor the HAPS hardware flexible interconnect to the SoC partition needs.
I’ve not had much time for projects recently and the next couple of months are busy, busy, busy with business stuff but I have been making slow progress on my new gaming console in a briefcase. Below you can see pictures of the custom controllers, I had to make them small to ensure they fit inside a briefcase. The second picture is a mock up of the monitor and controllers in the briefcase. You open the case and the monitor pulls up and can be rotated for vertical and horizontal play. The whole system is powered by two 7 ah 12v sealed batteries which based on the current draw should enable 5 hours of play before needing to be charged. There are 912 games installed, all the old school favorites like pacman, donkey kong, street fighter, 1945 etc…
If you like this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.To SUBSCRIBE use the Subscribe link in the left hand navigation bar.
Another option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”
• Click on “Accept” or “Yes” or whatever the dialogue box says.
Posted in ASIC Verification, Early Software Development, HW/SW Integration, In-System Software Validation, Man Hours Savings, Mick's Projects, Milestones, Performance Optimization, Project management, System Validation, Use Modes | No Comments »
Posted by Michael Posner on 10th April 2015
You read the title correctly, this blog discusses prototyping over 700 Million ASIC gates using the Xilinx Virtex-7 2000T FPGA’s. To get to this capacity you need to utilize sixty four (64) FPGA’s. The picture above was taken in the Synopsys HAPS lab and shows part of our Super Chain testing. As noted previously, HAPS documented seamless deployable capacity is 288 Million ASIC gates, which is six HAPS-70 (four) FPGA systems chained together, a total of twenty four (24) FPGA’s. However we have customers where this is not enough. The HAPS solution is modular and scalable with base building blocks of x1, x2 and x4 FPGA systems and supported with a HAPS-Aware design tool flow.
The HAPS capabilities and software infrastructure enables the solution to scale with ease but Synopsys does not claim support for capabilities until they have been tested and validated. Once the HAPS systems are configured in the Super Chain they act as one unified massive prototyping system. Thanks to our synchronized clocking capabilities the prototyped design still utilizes the HAPS High Speed Time-Domain Pin Multiplexing, HSTDM, which enables the highest system performance. The above picture super chain models sixty four FPGA’s operating synchronously with HSTDM between all FPGA’s ensuring the highest system performance. That’s over 700 Million ASIC gates (12 million ASIC gates per FPGA)…
While HAPS can scale to these huge systems that does not mean that users of just x1, x2, x4 or x8 FPGA’s do not benefit from this testing. Testing of such large systems ensures that the communication, clock synchronization, HSTDM and other capabilities are bullet proof which benefits the smaller system usage ensuring maximum reliability and uptime when used in server farms or on the user’s desk.
Off subject, while visiting Mountain View CA I noticed that one of our creative R&D engineers had come in over the weekend and decorated their Cube space for Easter
Absolutely amazing don’t you think! Anyway I introduced myself to the R&D engineer and congratulated them. Apparently they do this once in a while and shared a couple of pictures of their previous cube creations.
Crazy cool right!!! I also think that this R&D engineer might have just a little too much time on their hands. Or maybe they are just like me and maximizes every second or every day. I personally think there is a business here, cubicle decoration in a box…. Would you buy a box of decorations to jazz up your cube?
Posted in ASIC Verification, Debug, Early Software Development, Humor, HW/SW Integration, In-System Software Validation, Man Hours Savings, Project management, Support | No Comments »
Posted by Michael Posner on 3rd April 2015
It’s been a while since Xilinx shipped the first UltraScale VU440 engineering sample devices to Synopsys so I thought it time to deliver a short update on development progress. It might be hard to see in the above but that is a picture of one of the new development HAPS systems for the UltraScale VU440 devices. I say hard to see not only as the picture quality is low but also because we have the system completely configured with intelligent interconnect as part of our stringent characterization and functional validation process.
Each module is individually tested, see picture below as an example, this is the controller module in standalone test. The controller module hosts the HAPS supervisor which controls the system and manages advanced capabilities such as the Universal Multi-Resource Bus, UMRBus for short. Once all individual modules are signed-off they are assembled and the system is validated.
So far both the Xilinx VU440 devices and the new systems are functioning well. Xilinx has posted an errata on the engineering sample VU440 devices but these issues do not preclude the devices from being useful for system development or actual usage as part of a production prototyping project. All IO’s are operational as well as the transceiver GTH links. We have been filling the devices with high speed toggle designs as part of the performance and power characterization and smaller IP designs for other test purposes so we have not compared the utilization between V7 and UltraScale devices yet. We still predict that the UltraScale VU440 devices will deliver ~26 Million ASIC gate capacity, about 2.2X increase over the V7 2000T devices.
As a teaser for future blogs, the new integrated solution is expected to deliver
- Highest performance w/superior partitioning & new time domain pin-multiplexing schemes
- Always available debug with deep trace storage
- Fastest time-to-first-prototype with HAPS aware prototyping software
- Rapid Turn-around Time from RTL to Bit file with incremental flows
- Native integration for regression farm & remote accessibility
- Both HW and SW tool flow is Modular & scalable to over 24 FPGA’s (Over 600 Million ASIC Gate capacity)
- Hybrid Prototyping ready
Preserves existing HAPS investment
- Interoperable with HAPS-70 & HAPS-DX, (mix and match HAPS V7-based systems with UltraScale systems) same form factor, I/O voltages, HT3 connectors, daughter boards, cables
In the coming months I’ll post more information on these new and unique capabilities.
Posted in Admin and General, ASIC Verification, Bug Hunting, Daughter Boards, Debug, DWC IP Prototyping Kits, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Man Hours Savings, Milestones, Project management, Real Time Prototyping, System Validation, UltraScale, Use Modes | Comments Off
Posted by Michael Posner on 16th March 2015
Possibly inspired my one of my blogs, Troy Scott, wrote a new whitepaper to help dispel the myths of physical FPGA-based prototyping. TTFP = Time To First Prototype
I highly recommend this whitepaper as unlike my blogs, which I write mostly on the fly, this whitepaper obviously had a lot of thought put into it.
That’s it for the blog this week. I was traveling in the UK last week so I am a little jet lagged. While there I picked up a little UK history
It’s a ceramic poppy from the Tower of London remembers exhibit. It’s an amazing piece of history and I feel honored to be able to buy one.
I received another honor, this time from the hotel I stayed at
Yes, I am still known as Mr Bacon. This has a little to do with the fact that I love bacon and more so because I always seem to wear a T-Shirt that says BACON on the front of it.
I also had some fun with the rental car while trying to find parking one day. Below you can see my parking spot halfway up a hillside.
I’m not sure if you can see it or not but the back wheel is floating in the air. Fun, fun, fun.
Posted in FPGA-Based Prototyping, FPMM Methods, Humor, Milestones, Project management, Technical, Tips and Traps | Comments Off
Posted by Michael Posner on 27th February 2015
This week a prototyping engineer challenged me that “his” customized and hand crafted pin multiplexing capability was “better” than the HAPS High Speed Time-Domain Multiplexing, HSTDM. My response, “Faster, maybe, better NO”. This blog explains why the HAPS HSTDM capability will beat out a custom coded multiplexing capability hands down every time.
First let’s list of the positives and negatives of a custom coded pin multiplexing capability
- It’s tailored to the exact design requirements
- It’s tuned for a specific set of FPGA pins and inter-FPGA connections to push performance to the limits
- It’s hand crafted meaning effort to develop
- It has to be manually inserted into the design
- It breaks if the design requirements change
- It’s tuned so will need to be customized to different FPGA pins and inter-FPGA connections
- Might be unreliable leading to mystery ghost bugs to chase down
I am sure the list of negatives is longer but I would bet that you already get the idea. While it’s possible to craft a pin-multiplexing block that eeks out every possible drip of performance the overhead of insertion, modification to different design and hardware requirements and testing makes it inferior to the HAPS HSTDM capability.
HAPS HSTDM was designed to deliver an automated, cycle accurate, highest performance, reliable, modular and scalable pin multiplexing solution for the HAPS systems. Automated insertion through ProtoCompiler ensures that the usage is as unobtrusive as possible. HAPS HSTDM is tested to run on every qualified IO pin across the HAPS-70 system. It will reliably run on any HAPS platform, we can claim this as the HAPS hardware itself is performance tested as part of the production manufacturing tests ensuring that all systems and interconnects meet the minimum required performance for HSTDM operation. It supports multiple ratios meeting the need of many different design requirements. It is very high performance using the latest differential signaling and training techniques with built in error detection. Just looking at this list it’s clear that HAPS HSTDM has many advantages over custom.
But wait, there is more…. I would challenge that using the flexible capabilities of the HAPS hardware interconnect combined with the HAPS HSTDM capabilities that the overall HAPS prototype will run at a higher system performance. I’ve talked about this capabilities a couple of times. The HAPS systems do not have any dedicated PCB traces between FPGA’s. All interconnect is done via intelligent cabling. This method enables the HAPS hardware to be customized to better match the DUT’s interconnect needs. This means you can create more interconnect density where the DUT needs it. More dense interconnect can help reduce the overall pin multiplexing ratio required resulting in higher performance system operation. Remember your prototype is only as fast as the slowest link.
This HAPS flexible interconnect combined with the HAPS HSTDM automated and deployed by ProtoCompiler is a very powerful solution and this is why I claim that it’s “better” than a hand crafted scheme.
Do you agree?
Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, Project management, Support, Use Modes | Comments Off
Posted by Michael Posner on 13th February 2015
How many ASIC Gates does it take to fill an FPGA?
This question almost sounds like a joke doesn’t it. In reality this is a question I am asked to answer all the time and it’s not easy as ASIC designs don’t map the same to FPGA as they do to ASIC process technologies. In the ASIC design flow ASIC gates are represented as two input NAND gate equivalent and this is the base date point which should be used in the calculation as to how the design will map to FPGA.
For multiple generations of HAPS systems Synopsys has used the following tried, true and field proven calculation as to ASIC gate equivalent capacity of the Xilinx FPGA families.
The basis of the calculation is that you can map the equivalent of six two input NAND gates per Look Up Table, LUT per Logic Cell, LC.
1* LUT = 6 Two input NAND Gate equivalent (go try it!)
With this knowledge its easy to calculate the total capacity of the FPGA in ASIC NAND Gate equivalent as you then multiply the LC count per FPGA by 6.
The Xilinx Virtex-5 series biggest capacity device was listed as 330K LC’s, so 330K times 6 = 1,980,000 two input ASIC NAND gate equivalents (~2 million)
So for the other Xilinx large devices used for Prototyping you get the following.
- Xilinx Virtex-6 = 760K LC’s = 4,560,000 two input ASIC NAND gate equivalents, (~4.5 million)
- Xilinx Virtex-7 = 2000K LC’s = 12,000,000 two input ASIC NAND gate equivalents, (~12 million)
- Xilinx UltraScale = 4400K LC’s = 26,400,000 two input ASIC NAND gate equivalents (~26.4 million)
Synopsys has shipped over 5000 HAPS units across 400 customers and with 1000’s of designs being validated using HAPS we are confident with this method to correctly set the expectations as to how many FPGA’s are needed to model the design under test. Of course you can only use this as a guideline as we all know ASIC RTL is typically FPGA hostile so you rarely get optimized mapping. Your ASIC RTL source code contains non-FPGA type resources, mux’s, adders, subtractors which don’t map nicely to FPGA resources and you have designs with intensive datapath and heavy interconnect stressing FPGA routing resources. The Synopsys defined estimation calculation has helped 100’s of customers quickly estimate the number of FPGA’s they need for their projects.
The only true way of more accurately estimating the number of FPGA’s your SoC prototype will need is by executing FPGA area estimation within a prototyping tool such as ProtoCompiler. Even running your design through the FPGA vendor tools will help you get an idea of the number of FPGA’s needed.
Simple right…… If only……. There is no standardization in the FPGA-based prototyping commercial market or across FPGA vendors so the poor prototyper is faced with multiple capacity claims for the same FPGA device!!!! A simple web search will quickly confirm this, other vendors ASIC gate equivalent capacity claims can be very different from the Synopsys calculation. This has led to some quite funny (now that I look back on it) conversations with customer. One such conversation is summarized by the quote
I have to buy two HAPS-70 systems to get the same capacity of the <other vendors> one board
I did actually laugh out loud… The hardware has the same FPGA’s !!!!!! Your SoC design does not magically shrink to fit into less FPGA’s. If your tool run estimations shows that you need four FPGA’s that’s what you need, forget the vendors claimed capacity per FPGA. Don’t be fooled by wild capacity claims, do your own area estimation based on your SoC prototyping project.
It should be noted that the software tool flow used to support your prototyping effort can make a difference in the FPGA utilization. For example ProtoCompiler has a Time to First Prototype, TTFP mode which is designed to get you onto hardware fast and as part of this can be configured to use more available FPGA capacity to reduce synthesis and P&R times. ProtoCompiler also has a performance and area optimization mode where the tool will use unique techniques to pack more logic into each FPGA. This TTFP mode is typically used at the start of a project, optimized mode when you deploy HAPS in volume to software developers.
Of course, prototypers, one way for you to neutralize the vendor capacity claims is just to compare the number of FPGAs, apples to apples.
One final point, the way Xilinx “counts” gates and markets seems to be a much more sophisticated calculation which I *think* includes much more than the raw LUT NAND gate equivalent. I reached out to my Xilinx contacts and asked them to clarify, I’ll post a blog on the results if they give me permission to. (Hey maybe I can twist their arms and get them to guest blog!!!) I think their calc includes memory, hardened IP blocks and other logic but I’m just speculating.
Do you count FPGA capacity in another way? If yes drop me a note or comment and share.
Click the links to the left and below to subscribe and get blog updates as soon as I post them
Posted in Man Hours Savings, Milestones, Project management | 2 Comments »
Posted by Michael Posner on 30th January 2015
I was forwarded this user quote and I thought I would share as it was so heartwarming for me
The design came up on HAPS in less than two weeks and we found a rather serious bug early in testing. This is the bug that would have cost the company dearly if it wasn’t found until later in the development cycle.
It’s short and sweet and communicates the HUGE value that FPGA-Based Prototyping delivers. This note reminded me that a while back I did an internal analysis of the value of HAPS FPGA-based prototyping in respect to the various use modes. The use modes I examined was Functional Verification, HW/SW Integration, Firmware Development, System Validation and Software Development. First I created a baseline score for HAPS in respect to various user requirements. This list stays consistent across all use modes.
- Early Availability
- Initial Design Setup
- Iteration Turnaround Time
- Execution Speed
- Deployment (Ease of/Cost of)
- HW Debug Visibility
- SW Debug Visibility
How the scoring works, 1 = Sub-Optimal, 10 = Excels. To score I created a set of definitions per requirement and using real data which compared the results to other technologies thus to objectively score. The scores are mapped into a radar chart. Here is the scoring baseline for HAPS. I should point out that its subjective but I tried to be as data driven as possible. If anything I might have been a little harsh on HAPS to be fair.
At the same time and using the same list of requirements I scored the NEEDS of the use mode. For example the user needs for software development are pictured here. Note the dotted line.
The baseline needs were mapped for each of the desired use mode. Then it’s a simple case of overlaying the results of the baseline value score of HAPS against the use mode. It’s a multiplication of the value times the need. This way it clearly shows where there is synergy of a need and as strength.
Starting with Functional Verification
Remember the dotted line represents the user needs within the use mode of functional verification and the solid line represents the relative strengths of HAPS. Within a radar chart it’s easy to see the matching requirements and HAPS strengths. It’s clear to see that while HAPS does bring value to functional verification it’s definitely not the best technology for the use case. Hey, we all knew this already. A simulator such as VCS or emulator such as ZeBu is a far better choice for functional verification as they deliver on the key needs of the use case such as early availability, debug visibility, capacity etc. But I also know that HAPS is used in this use mode as the performance enables a huge amount of tests to be run in a short amount of time flushing out those hard to find RTL bugs.
Now lets review the HW/SW Integration use mode
Immediately it’s clear that the value of HAPS FPGA-based prototyping is far better matched to the requirements for HW/SW Integration. HW/SW Integration is typically the point at which FPGA-based prototyping is deployed in development. As more and more RTL blocks are coming together and the volume of software has become significant then the additional performance that HAPS FPGA-based prototyping delivers is needed to execute in a reasonable timeframe.
Now onto Firmware Development
FPGA-based prototyping enables the use of real physical interfaces using the real interface blocks such as DesignWare IP. This means that the hardware aware firmware development is a key use case for HAPS FPGA-Based prototyping and this is represented in how well the values match the use case needs. The real physical IO, actual RTL blocks combined with the high performance operation make HAPS FPGA-based prototypes one of the best firmware development platforms next to the real silicon. Actually I would be bold enough to say better than the real silicon as once you have silicon its too late to fix RTL bugs!
For the same reasons as firmware development it’s clear to see that HAPS FPGA-Based prototyping is the best technology to address the needs of System Validation use mode. In System validation you will be running lots of software against the hardware, doing interoperability and compliance testing against real hardware. No other technology enables you to do this, PRE-SILICON
Finally the software development use mode
This is the traditional and most well know use mode for FPGA-based prototyping. Again the HAPS values map very well against the needs and requirements of Software Development. Really the only area in question is capacity. I thought it would be interesting to add the benefits of Hybrid Prototyping into the scoring for this particular use model.
Hybrid Prototyping, the combination of HAPS FPGA-based and Virtualizer Virtual Prototyping makes for a powerful platform for software development. Hybrid Prototyping combines the accuracy, performance and real world IO of HAPS with the capacity and differentiated debug capabilities of Virtualizer. I can tell you that a number of customers have adopted Hybrid Prototyping to improve their early software development activities. A number of these have been able to accelerate their software development and validation to a point where the software run on the real silicon on day one! Hey bonus, the green radar chart line looks like a fish, do you see it?
Anyway, there you go, the value of HAPS across multiple use modes. Is this consistent with your scoring of FPGA-based prototyping in respect to your project usage?
Posted in ASIC Verification, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Milestones, Project management, Real Time Prototyping, System Validation, Use Modes | 2 Comments »
Posted by Michael Posner on 8th August 2014
A couple of weeks back I posted a humorous list of the quotes I use in my day to day life, one of which is “Hope is not a strategy”
Well as it turns out this caused quite a fluster as apparently hope is a strategy, well sort of. Here is a link to a Harvard Business Review Article – Hope as a Strategy, well sort of.
The premise is that when hope is based on real-world experience, knowledge and tangible and intangible data, it results in trust, which is necessary to implementing any strategy. What do you think about that? Is the word hope being used to explain the standard practice of planning and factoring in the calculated risk assessment? If yes, this is going to totally revolutionize my life.
To ensure we have a little FPGA-based prototyping content this week I highly recommend the new Synopsys white paper on Solving the ASIC Prototype Partition Problem with Synopsys ProtoCompiler
The white paper describes the challenges of ASIC prototyping when the design has to be split up over multiple FPGA’s and how the new ProtoCompiler tool solves these challenges automatically. It’s a highly technical paper with in-depth data on how to rapidly partition an ASIC design ready for high performance prototyping. The ProtoCompiler tool can partition process a design in lass than 5 minutes and highlights bottlenecks which will limit the prototyping performance and pointers on how to resolve to deliver the maximum optimization.
Posted in Humor, Man Hours Savings, Project management, System Validation, Use Modes | 1 Comment »
Posted by Michael Posner on 17th July 2014
By far my favorite aircraft growing up was the Harrier jump jet. Back in those days it was the only jet aircraft with vertical takeoff and landing (VTOL) capabilities. I dreamed of flying one and even owning my one. Actually I still dream of owning one. I like the idea of a helicopter as you can vertically takeoff and land meaning you have a wide range of landing zones. The problem with a helicopter is that it’s very slow in comparison to a plane so it would take you ages to get any real distance. Hence the Harrier was a perfect option for me, vertical takeoff and landing and jet speed in the air, it’s the best of both worlds.
In the land of FPGA-based prototyping there is a lot of horizontal and not much vertical, especially when it comes to daughter boards. Traditional daughter boards are flat or horizontally mounted to the system such as the HAPS DDR3 daughter board pictured below.
There is nothing wrong with a daughter board like this, in fact the above daughter board has exceptional SI characteristics and operates at very high performance. However we found that some customers ran into challenges when it came to building custom daughter boards specifically tailored to their needs. Here is a summary of some of the issues they ran into.
- Customers daughter board was quite big but it only required a couple of IO’s interfacing to the system. Often the daughter board covered up more connectors or blocked airflow and fans just because the daughter board PCB had to be large to accommodate the custom logic
- The daughter board required a big connector, but again only required a couple of IO’s. The size of the connector forced the size of the daughter board PCB to again cover things.
- Once in a while the customer actually wanted to get access to both sides of the daughter board. Sometimes this was to connect to both sides, other times to probe. They would build a long daughter board expanding out of the system to do this. It was typically mechanically unsound.
Enter the Synopsys R&D Boffins! They could have ignored this little gripe with daughter boards, lets face it, the issue is annoying but not the end of the world. But that’s not good enough for the Synopsys! So drum roll please……. for the worldwide announcement of the availability of the VERTICAL HAPS daughter board. Yes, vertical….
The new vertical daughter board addresses the issues laid out above.
- For daughter boards that use relatively few IOs, say up to 50 (HT3 connector IO count) but require more PCB real estate than a typical LAB board, building in a vertical way is excellent. Look at the picture, the board form factor is huge yet it only plugs into and utilizes one HT3 connector. It does not block any other connectors or airflow.
- Same for the problem of the big connector, a vertical board enables a HUGE connector to be used if wanted.
- Oh my, you can even access both sides of the daughter board, perfect for additional PCB access and probing.
The HAPS HT3 spec is being updated to define the new HT3 vertical daughter board and will be available to all existing HAPS-70 customers. Synopsys validated the form factor and usage and now shares it with any HAPS-70 customer that wants it.
So now we can all go vertical. Ease of use, functionally with performance, it’s like the Harrier jump jet of FPGA-based prototyping daughter boards. Someone once made fun of the upper frame on the HAPS-70 systems, now who’s laughing……
Posted in Daughter Boards, Project management | 1 Comment »
Posted by Michael Posner on 16th May 2014
Achieving first pass silicon success is always the goal of the project. While a company may plan for a second chip spin they really want first pass silicon success enabling reduced cost and earlier time to market. I ran across this video featuring Peraso and Eric from the DesignWare USB team, http://youtu.be/DyNyZP8Ysj4 . Now while Peraso do not claim first pass success bringing up a chip in the lab in 24 hours is amazing. Peraso used HAPS FPGA-based prototypes for system validation enabling them to test their software with their RTL implementation before they taped out. As you can tell from the video, Peraso were very, very happy with the fact that they had the silicon up and running in such a short period.
While we are on the subject of videos, here is another featuring the DesignWare HDMI IP and the HAPS-60 series systems. http://youtu.be/Ao-JeWz9g0A
These examples show the power of HAPS for reducing project risk, achieving first pass silicon success and exhibit high performance enabling the validation of very high speed real world interface.
Honestly I’m a little tired this week so I’m going to keep this blog short. A couple of weeks ago I did get the chance to take out one of the best off-road vehicles on the market. While I am used to far more horse power, this one horse power proved sufficient for the activity and we climbed some terrain that not many other modes of transport could reach. Unlike my other hobbies this trek was very relaxing. In addition I did not burn any fossil fuels in the process.
Do you want to meet me in person? Are you going to DAC? If the answer is yes to both drop me a comment and let me know and I’ll be happy to meet.
Posted in ASIC Verification, Early Software Development, HW/SW Integration, In-System Software Validation, IP Validation, Mick's Projects, Milestones, Project management, Real Time Prototyping, System Validation | Comments Off
| © 2015 Synopsys, Inc. All Rights Reserved.