Kenneth Chang Blog

Register for Cadence's Front End Design User Summit -- December 6, 2012 in San Jose

Kenneth Chang — Tue, 27 Nov 2012 17:45:00 GMT

Cadence is hosting a Front End Design Summit on Thursday, December 6, 2012 9:30am – 5:00pm at Cadence San Jose headquarters, 2655 Seely Avenue, Building 10. Logic designers will hear from customers including Cisco, Chelsio, PMC, Spansion, and Via Technologies about strategies they employed to overcome challenges in synthesis, verification, and test deployment. Attendees will also learn about product updates and roadmaps from Cadence R&D experts from the Encounter RTL Compiler, Encounter Test, and Conformal product teams. The day will end with a networking reception.

Space is limited and registration is now open. Click here to register. Hope to see you at the event!

Kenneth Chang

Going 'Digital End-to-End' ... and Riding Your ECOs to the Finish Line

Kenneth Chang — Mon, 07 Feb 2011 18:00:00 GMT

Thinking of your next ASIC ECOs? It could be for today, or maybe you are considering your next ASIC ECO methodology. You are probably not alone ... most designs will go through ECOs, whether they are related to bug fixes (those 'oh oh' moments of silence), or intended functional changes (which are not out of the ordinary -- maybe your marketing department has requested the design team to add a new feature to the ASIC because of competitive pressures). Thus, planning for ECOs is a necessity for any solid ASIC flow.

Let's take a step back. If you are unaware of what the term "ECO" means, in the ASIC world, it is defined as the "Engineering Change Order". In simple terms, it is a change to your design, whether it be functional, timing, or electrically related. In our case we are going to focus on functional logic design changes, since it is historically a big challenge to make them predictable, according to customer experiences. By the way, ECO is an acronym widely known and used because it is that common (and painful). ECOs hurt by reducing overall team productivity if not planned for carefully.

Being prepared to perform ECO functions is a necessity today because:

(1) Designers can make mistakes, and verification people can also make mistakes (missing design errors). We are all human, so we need plan for that.

(2) People make mistakes for all kinds of reasons, one reason being that designs are becoming more complex so verification coverage becomes more challenging (i.e. possibilities for missed coverage increases).

(3) Competitive pressures can correlate to higher occurrences of ECOs for a given design. In other words, design teams are being pushed to the limits with less time to verify due to tighter schedules, especially for ASIC products where time-to-market is critical.

(4) In additional, as mentioned above, competitive pressures can also lead to design specification changes, occurring dynamically during the implementation of the ASIC. Thus project scheduling may no longer be static and predictable, and must dynamically adjust to ever-changing design needs to produce the end ASIC product on time.

Now comes the question: "Can we plan for success under these conditions?"

The answer is a solid "Yes"- and Cadence technologies can help deliver solutions to meet these challenges.

In an exciting announcement January 31, Cadence released a flow to provide a digital end-to-end solution, with ECO automation as part of the flow. (You can read a nice summary in Wei Lii Tan's recent blog post). This work was a result of listening to customers and understanding what they needed to meet their ever growing challenges. Specifically, Cadence Conformal ECO Designer is leveraged in the digital end-to-end flow to help translate the designer's intent, abstract the issue at a level that the designer can understand and manage, and help implement and converge on a solution to meet the digital ASIC's requirements. What is exciting about Conformal ECO Designer is that it provides superior automation capabilities that can greatly reduce turnaround time for ECOs, thus increasing designer productivity, and in parallel play a role in increasing schedule predictability.

What we have seen with some customers is changed behavior when it comes to planning for ECOs. They actually embrace and budget for an increased number of ECOs that can be allocated in a shorter time, because of the confidence they have in Cadence's ECO technologies.

One week ago, while visiting a customer, one designer made this comment:

"With the option of leveraging Conformal ECO Designer automation capabilities, our management expects us to do more ECOs -- faster."

Wow -- that's a bold statement, and it could only be made because of the high confidence our customers have. In the context of a the full blown digital end-to-end solution, Conformal ECO Designer works in conjunction with a number of Cadence leading edge technologies.

These include:

(1) Conformal Logic Equivalency Checking (a.k. a. LEC), in order to set the foundation for analyzing the ECO changes. Conformal LEC has been the standard for logic equivalency checking for a long time.

(2) RTL Compiler, including the option to leverage physically-aware synthesis, in order to get the best optimizations for the ECO logic.

(3) Encounter Digital Implementation System (EDI), to merge the ECO changes into the design in the physical world, as Cadence's leading edge back-end design tool.

With all these strong technologies working hand-in-hand, I am excited and look forward to hear many customer successes in the near future.

If you have any comments based on your experiences with ECOs in the past and present, or have any questions regarding ECOs, I would appreciate hearing from you.

Good luck with your meeting your digital end-to-end needs with the best ECO methodology and underlying technologies. See you at the finish line!

Kenneth Chang, Product Manager

Wrapping Up 2009 With Some Reflections

Kenneth Chang — Wed, 23 Dec 2009 14:00:00 GMT

As many of my customers mentioned and no surprise, 2009 was a tough year. Regardless though, designs continued to get pumped out the door by aggressive design teams, putting products in eager customer hands. I constantly get mesmerized by the number of people who are buying iPhones, including co-workers.

Here are just a few highlights from the digitial perspective for 2009 (in no particular order):

ECOs continue to be a priority. For all of 2009, Conformal ECO was being used almost everywhere. ECO automation has become a necessary option for the ASIC flow.
Low Power design and verification - getting more mainstream, seems like everyone is at least learning (even if they aren't using it immediately). No one wants to be left behind for LP.
Front End Digital Design Community Forum -- We held this special R&D event again in November. Lots of good customer feedback, I look forward to this customer event in 2010.
Early Chip Planning - starting the decision making pre-RTL - automation in this area gathered quite a large interest, according to my worldwide travels to different customers.
C-to-Silicon technology (new higher level abstract stuff) continues its momentum. I had a chat with one of my big customers who said C was going to be a big part of their strategy soon.
Synthesis continues to evolve, with more intelligence put into the flow up front with respect to physical implications.

And that's it in a nutshell for 2009 from my view as an engineer working day-to-day with many customers

Best wishes to you all and have a great happy New Year!

Kenneth Chang
Engineering Manager, CPS Division

I Need ASIC IP. Where Can I Find Information?

Kenneth Chang — Fri, 07 Aug 2009 13:05:00 GMT

By Kenneth Chang.

The world's best IP ecosystem is ChipEstimate.com. That's what we're hearing every day from our customers.

Second to none as a solution, ChipEstimate.com took DAC by storm, with its incredible line up of IP Talks! sessions with guest speakers from all sorts of world famous companies who are part of this huge ecosystem which helps customers every day make smarter decisions earlier in the design flow.

ARM, Cadence, Chartered, Denali, PLDA, Synopsys, TCI, TSMC, Uniquify, Virage Logic ... just to name a few IP companies, presented their solutions to large interested crowds.

Click here to download the PDF presentations from each IP Talks! guest speaker (click on the company you're interested it, it's linked to the PDF) - thanks to all the partners who made their presentations available for everyone (lots of people asked too, for example, looking for the latest technology info on USB, PCIe, ARM, etc ...).

For 4 days straight, every half hour, at our DAC ChipEstimate.com booth we held live interactive sessions between the speakers and the audience. For 4 days straight, ChipEstimate was one busy booth giving demos as well with the tool that leverages the IP. If you came by, you might have seen quite a bit of activity, lots of buzz. According to much feedback, it was one of the busiest and exciting booths at DAC.

The thing that makes ChipEstimate.com so unique and attractive to our customers is that the ecosystem is made up of two complimentary parts: (1) the IP portal database, ChipEstimate.com, and (2) the automation tool, the Chip Estimator (we call the systems by CICE or CCPS), which leverages the IP information for intelligent and accelerated early chip estimation.

If you're interested, you can download a free version of the InCyte tool to test drive to see how it can help you with early chip estimation, and also register for a free account so you can view a wealth of IP data from tons of IP providers to help with IP selections for your next projects.

If you're an IP company interested in being a partner, please contact us for more information, our ecosystem is open to everyone.

SDC Best Practices: What to do With "-through" Constraints?

Kenneth Chang — Tue, 28 Apr 2009 13:01:00 GMT

One of my customer's last week asked a good question that has come up many times before when I was a designer too.

Customer: When is using "-through" in my SDC timing constraints a bad thing? Any guidelines?

Here was my response for those curious:

One reason '-through' for exception path SDCs may not be recommended for synthesis and P&R tools is because they may restrict optimization. So in general, by default, definitely keep them to a minimum where possible.

For one ASIC vendor in the past, they restricted all set_false_path and set_multicycle_paths with a maximum of N '-through' per SDC statement due to known QOR issues with at least one of their backend tools. I thought this was a good practice of the vendor - be proactive to make the ASIC flow smoother.

One popular reason why '-through' constraints may come into the picture is when using internal IP or external IPs that come with their own set of SDCs. We didn't want the constraints on the submodule hierarchical pins because it was not a good practice (explanation below). In some cases, you may not be able to translate these 'through' SDCs easily to the fan-in or fan-out cones, especially if large - so you may choose to live with it. The problem is that even if you do translate them to get rid of the '-through' points on hierarchical module pins in this case, you need to verify your SDC again after the changes, which may not be trivial. In the past, for example, while integrating a popular 3rd party PCI/PCIX core which had many SDC exception paths on the I/O of the IP, we tried to do this translation. It looked easy on first glance, but after we started doing the work, it took months to do a full multi-mode verification (on and off work for our startup team, since realistically this was only one of many tasks/challenges we had in our tight schedule) that we were satisfied with and could sign-off on for these particular SDC changes because of the complexity of the paths (large cones) and much longer run times we saw from STA (our chip was a large SOCE to begin with, ~10M gates).

In general, if you do declare '-through' points, a good methodology is to place them on at least cell instances rather than sub-module hierarchical pins. For example, I've heard that in P&R, due to hierarchical pins that can be cloned, it can complicate the SDC constraints that reference the hierarchical pins with '-through'. Why take a chance with your flow when you can use any given tool which may treat these situations differently? Better to be safe and keep the flow at tight as possible by proactively pushing these SDCs upstream or downstream instead. Even better, push them right to the sequential elements or a siimlar if possible, since those are the best anchors for the SDCs.

Also, aside from the above question, another question came up on understanding the status of SDCs at each step of the process. Pretty much for any tool that gobbles an SDC, it will give some kind of status (very brief, or more detailed).

In general, whenever you read in your SDCs, you should have an accounting for what pass/failed at each step if you don't do that already. Make it a formal process in your ASIC flow and understand what you're tools are checking (because it may not be complete). I've seen too many times in the past when people only look at their SDCs when the tool gives an error and stops, or when results from a tool looks weird, and debugging the SDC then comes into the picture.

If you're looking for dedicated SDC constraints verification (and generation), such as my customer, you can check out Cadence's Conformal Constraint Designer, well worth it's checks for sign-off.

If you have other opinions, it would be great to hear them!

Kenneth Chang

My Twitter Experiment - Just Follow Me

Kenneth Chang — Tue, 24 Mar 2009 13:30:00 GMT

"I didn't know that Conformal ECO-physical was released. When did that happen? Which version of LEC?", said one of my customers said recently.

I have a lot of customers who ask about the latest product information once in a while. I see my peeps at seminars, customer visits, workshops, etc ... I was wondering, how do I update them in a fun and efficient way, and timely too. While taking a Web 2.0 class at Stanford this winter, it dawned on me. This one application called Twitter seemed like a perfect fit.

'Twitter', like 'Google', has become a verb! "I've twittered" will soon be a common phrase. Even basketball players use it (at half-time), how cool is that!

Twitter is: concise (max of 140 characters - that's just a dozen or so words), and timely.

To keep this short, I'm beginning a little experiment on Twitter for all my customers. Everyone is welcomed to join. Just updates latest info, only the frequently asked stuff my customers like.

I'm going to keep it to these frontend products: Conformal (including ECO), RC, and InCyte/CCPS

Click here to add me to Kenneth's Twitter!

Here's the birth image of my Twitter page:

Hope to see you at Twitter!

Making the Right Decisions Before You Start Your Project

Kenneth Chang — Mon, 23 Mar 2009 10:30:00 GMT

Seems logical, but unfortunately, I run into customers today that grumble about their past experiences such as:

"Gosh, I wish our chip wasn't so big. How did that happen?", says one ...

"Our memory requirements grew and grew, out of control, almost couldn't fit it", says another ...

"If I knew where we'd be today (which is not where I want to be), I wouldn't have bought that IP to begin with, it just doesn't make sense!", a manager says...

and just as bad ...

"I would have never approved this chip project if I knew this (this = exceeding our constraints) was going to happen! What a waste of money, now we're in trouble ... ", one very unhappy camper.

In the past, many of the above thoughts also often entered my teams' minds as we designed numerous chips. After initial planning, coding, implementation, we would just hack away at it, and at times, eventually be forced to make sacrifices in our design (hardware and/or software = our 'system') in order to minimize the effects of an earlier decision(s) but still meet the market needs. So, how did this all start? ...

Usually, it begins with a RFQ, hopefully the most orderly formal documentation that you hand your vendors (or, if you're in a COT flow, you may have something similar but for internal processes). For background, RFQ = Request for Quote, meaning you want to see how much you're going to pay for your chip development (and your return on investment) given your set of input needs. (for example, you *think* your design will be 5 million gates, have ~5M bits of memory, 500 I/Os, you'll need a USB PHY and controller, etc ...) It's basically a rough specification of your design, enough information to build your chip. From the RFQ, you'll eventually usually get a bid (or bids if multiple vendors, or a quote, if internal source), then you haggle on the price until you settle on it. In the mean time, in parallel, depending on your design, there could be a ton of information in email, spreadsheets, documents that's all over the place that needs to be processed and summarized to feedback into the RFQ bid. From past experience, this can be a big pain, since data can change very fast, thus requiring recalculation. Even worse, the data is all over the place, in numerous people's hands depending on who owns what relationship. No consolidated central location of information to collaborate on. This is where the process can break down. Eventually, if things spin out of control, you're left with having to decide on a approving a project based on information that you believe is accurate. In any case, you sign up for the project, then, eventually, get bitten due to some inaccuracy in the earlier assumptions when the decision to approve the project was made.

This is where a collaborative system can help - help give solid input when it's needed - before you commit and spend the dollars on the resources including IPs. What is needed is a 'place' that consolidates all the information into one central location that everyone understands - a database and language that everyone understands easily. With this database, all key decision-makers should be able to use it easily. Ideally, this would be the best solution, and fortunately, Cadence acquired a company called ChipEstimate(.com) in 2008 which provides this solution today.

If interested, you can check out two of their products: InCyte and Chip Planning Solution.

In a nutshell, these software tools have helped many teams collaborate on early chip estimations as well as post-implementation analysis when more information is available. Cadence's ChipEstimate solutions provide a holistic view of the chip estimation process, leveraging a powerful IP database, helps drive better RFQ analysis and ROI, and will give soon-to-be released low power estimation capabilities (which we'll explore in upcoming blogs). The benefits are good enough that vendors that you may be working with may be using ChipEstimate's tools for their RFQ responses.

So ... make those right decisions with the right tools, before you start your project!

Build ASICs With a Strong Ecosystem: A New Paradigm

Kenneth Chang — Thu, 05 Feb 2009 16:00:00 GMT

Building ASICs is a pretty much standard process - you may define your specification based on whatever constraints you have, pick your IPs if any, do a guess-timate of your entire chip so you can figure out the budget, then commit - plunk down the cash and commit resources so you can really do the work to get silicon out the door.

What hasn't been standard is the way people have approached doing something like the above. Specifically, beginning with the specification, every company project group may have their own way of manually, semi-automating, or almost-fully-automating the above process so that things can get done faster and more accurately in order to meet their schedule needs and utlimately the market window for their product.

A key recipe ingredient that many companies have shared with me is the importance of ensuring the IP portion of the ASIC ecosystem is strong. This includes:

Availability
Accessibility
Flexibility

A wise man (Camille from IDT) once told me - IPs and the strategy around them are integral to building successful ASICs. Lots of companies now base their designs on some IP. In fact, he even wrote a paper related to this IP stuff that was published late last year to back up his passion which he shared with me.

So comes the next question: how do I create such an infrastructure to create this beautiful ecosystem / playground where I can build and prototype ASICs earlier with higher ease?

One answer is to in part turn to tool automation. Check out ChipEstimate.com for more details. This large ecosystem of IP as well as their tool leverages the 200+ IP vendors and foundry relationships, providing thousands of popular IPs, probably at least some you are already using. The tool cockpit also allows you to define your own internal IPs easily, pretty cool stuff.

ChipEstimate.com in fact has been so well received by customers in the last year that it just won 2009 DesignVision Award from the International Engineering Consortium (IEC).

Here's a short clip of the ChipEstimate guys collecting their award and Adam's (aka as 'the young boss') speech:

If you're looking to improve your ASIC decision-making process up front, definite check out this stuff to at least get ideas for your next project since it is very useful and practical.

Levels of Logic Analysis - A Thing of the Past? What's the Trend?

Kenneth Chang — Wed, 07 Jan 2009 22:32:00 GMT

For years as a designer, levels of logic analysis was a staple in the ASIC flows I worked on. Especially the last company (before I joined Cadence), the ASIC vendor we worked with forced us to abide by their Levels of Logic analysis metric before moving onto the next milestone. It seemed to work, to help identify a good number of paths that would give us bigger headaches in the backend if we didn't address them early on.

Our ASIC Vendor said: " No Levels of Logic 'PASS', no check mark." As simple as that.

How about today?

One question that's been bouncing around in my mind lately is: "Levels of Logic", is that a thing of the past? Does it matter any more? Does anyone care and measure it today?

I honestly thought it was dead, until a few customers contacted me recently.

Customer 1: A few months ago, a designer from a big company said that they were looking into it as a metric to help drive RTL designers. This request was coming from a group that believed that they needed to be more proactive in giving feedback to the RTL designers., and this was one solution.

Customer 2: Today, another customer from another large company was saying something similar. "I don't want to only see my timing challenged paths, they aren't typically the only ones I need to worry about, I want to see the longest paths too. Why? Because those are the ones that historically have given me timing closure issues."

So, if you have an opinion, please post a short one to share. :)

(of course this doesn't describe what method would be used to generate the Levels of Logic report, but that's another topic for later ...)

Flash: Qi Wang - Cadence Low Power Architect Presenting @ VLSI Conference in India

Kenneth Chang — Tue, 06 Jan 2009 17:36:00 GMT

Just a short note for those who will be attending the exciting 22nd International conference on VLSI design in India.

Don't miss Dr. Qi Wang of Cadence, Senior Architect, who co-authored a paper and is co-presenting at this event @ 9am !

Location: New Delhi, India

Date: January 8, 2009

Session: Power Reduction Techniques and Flows at RTL and System Level

Qi has been a key contributor in defining low power standards for the ASIC design community worldwide. He is part of Si2's Low Power Coalition Steering Committee.

This tutorial is a great opportunity to listen to one of the best sources for ASIC Low Power vision and the intricate details, as well as ask questions directly.

Hope to see you at the event!