( ESNUG 551 Item 9 ) -------------------------------------------- [09/10/15]
[ EDITOR'S NOTE: This was unusually clever because ClioSoft also let
engineers from EDA companies answer this survey, too. Srinath was
seeking real answers regardless of who was saying it. Wow. - John ]
Subject: Top 12 answers on getting-designers-to-create-and-reuse-IP survey
>
> Have you heard about ClioSoft's 4 week long Christmas bonanza?
> http://www.deepchip.com/look/see141120-02.html
>
From: [ Srinath Anantharaman of Cliosoft ]
Hi John,
A follow up to our Cliosoft Christmas "IP creation" survey -- which we ran
on DeepChip from Nov 20 to Jan 15. Stats for those 8 weeks:
- readers saw ClioSoft banners ~500,000 times on DeepChip
- ~2,600 people clicked our IP reuse contest link
- 97 engineers each wrote a 200 word paragraph to enter
We gave out 29 prizes: a GoPro Hero 3, a Motorola 360 smartwatch, a Bose
Bluetooth speaker, and a Samsung Galaxy tablet -- to the top four -- plus
we did 25 drawings of $25 Amazon gift cards for the rest.
Thanks for running this. It got the word out about Cliosoft IP tools plus
insights into what engineers currently see as IP creation/reuse problems.
Rather than post all 97 letters, we chose a representative 12 that best show
all the different ideas that the engineers had.
- Srinath Anantharaman
Cliosoft, Inc. Fremont, CA
---- ---- ---- ---- ---- ---- ----
SURVEY QUESTION:
In roughly 200 words please answer --
What Do You Think Should Be Done to Make Design Reuse Work?
Despite all the efforts made by companies, IP reuse within a
company is not at the level one would expect. What would
motivate designers to create and share more IP? What are
the key features IP management systems should have to deal
with the requirements of the IP ecosystem needed to develop
the SoCs of tomorrow?
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
TOP 12 READER ANSWERS:
NEED MANAGEMENT BUY-IN
"Motivation - Designers need incentive to do the additional work
required to create IP out of the layout blocks developed during
normal design process. Under demanding development schedules,
designers will not do the extra work unless they are incentivized.
Monetary awards, public recognition, or other methods would help
to encourage engineers to design with IP reuse in mind.
Management Support - If the chip designers are not supported by
their management to create IP, a reuse culture will gain no
traction. Designers must be afforded the extra time required to
build IP infrastructure into their blocks, or it simply will not
happen. Technical management needs to account for additional time
in development schedules to make this a reality.
Staffing - A dedicated individual or department must be created to
facilitate IP creation & reuse. The IP needs to be supported in
multiple technologies over multiple foundry providers. Designers
do not have the bandwidth to manage this. An individual librarian
or team should be staffed to support this.
Software Tools - Design management tools such as Cliosoft SOS and
IP Manage must be leveraged to make IP reuse a reality. Investment
in such software and training on usage is essential."
- Luis Casas of RFMD
---- ---- ---- ---- ---- ---- ----
"Management buy-in: design creation and reuse should be a continuous
activity througout your company. Management should enact measures
to adapt and adopt IP creation.
Kept in an intuitive catalog system: The IP should be able to be used
in a typical cut-and-paste form. The catalog system should entail
versioning and enterprise-wide usage.
Available in all forms: IP should be described in HDL, transistor
logic, analog function, and modeling style."
- Bismark Espinoza of NASA JPL
---- ---- ---- ---- ---- ---- ----
"Design reuse creation within a company can become successful only
when the management is committed to it. Management must believe
that putting in the additional effort upfront in creating a
reusable IP will pay dividends.
Efforts should be made to ensure that documentation detailing the
architecture, data sheets, test suite, open issues if any etc, is
packaged properly with the design data, verification suite and
scripts. When reusing IP, it sometimes becomes necessary to make
changes in the design. Having documentation will aid in making
design changes and verifying it would be useful.
While selecting IP there should an easy way to determine its
suitability and quality. If there are different versions of the
same IP, one should be able to easily compare IPs to determine
the version which is most suitable. Designers should also be
able to quickly run the scripts to determine the IP quality."
- Steve Netto of Cadence
---- ---- ---- ---- ---- ---- ----
ABLE TO DISCUSS
"Design reuse will only happen when users can design, validate,
archive, and share those designs with other users. The end-user will
need access to the entire design content or what-ever pieces of the
IP that can be shared (schematics, simulation setup/configuration files,
model files, simulation results, layout or abstract, parasitic netlists,
timing libraries, textual documents, etc.) so that they can "use" the
IP in their new design project(s).
This data must be saved in a way that the data can be easily accessed
by many people, and be used with many different software applications.
Another aspect necessary for re-use is the ability to discuss ideas
and information about the content so that people can learn more about
how designers have used or are planning to use the IP; and what
issues or questions were already answered regarding the IP. All of
these aspects will help remove time-wasting mistakes when re-using
existing blocks and/or IP."
- Marc Polito of Silvaco
---- ---- ---- ---- ---- ---- ----
VISIBLE LINEAGE
"Quality -- The IP must have been tested and qualified properly for
the specified ports and parameterizations plus test coverage info.
IPs are assumed to have been already validated and not much effort
is spent on revalidating them again during integration. Moreover
it is important to provide a list of open issues against different
versions of the IP
Packaging -- IP should be properly packaged with the design,
constraints (timing, power, physical), scripts, testbenches,
simulation setup/configuration files etc. A behavioral model of
the IP if available should also be packaged. It should also be
accompanied with good documentation, created from a user's view.
Very often the created docs do not provide much insight into how
the IP should be used, the different modes supported, etc.
Support -- There is a window in the design cycle when people look
for available IPs and at that time it is useful to have someone who
can help resolve any concerns one may have about using the IP.
Moreover, when someone runs into any issues with the IP, working
with an engineer knowledgable about the IP helps speed up the work.
Lineage -- lists all the SoCs in which the IP has been used provides
confidence to the user."
- Devendra Tripathi of Broadcom
---- ---- ---- ---- ---- ---- ----
"During IP selection, I should be able to quickly determine the quality
of an IP very easily. To gain better confidence, I should also be able
to check its lineage to see the SoCs which have taped out using the IP.
An insight into the open issues against an IP would be a definite plus."
- Amrita Jayanti, contract engineer
---- ---- ---- ---- ---- ---- ----
TESTBENCHES LIVE FOREVER
"Small IP is OK, big IP is scary -- I have found small/simple/standard
interface IP is in greatest use. People are willing to use USB, DLL,
JTAG controllers, and other simple IP.
It's the complex IP that often requires more investigation and
trust, and it can take more time to develop the trust than to just
design the IP yourself.
Design versus Verification IP -- designers like to design; they like
to create! An engineer will often look for reasons to discard IP
to do the fun design work themselves. On the other hand, these
engineers are usually very willing to use an outside testbench.
I often give the example of two engineers: one assigned to the design
and one assigned to the testbench. Two years from now, nobody will
know that the designer worked at this company because they will have
tossed his original design and started over. Ten years from now,
everyone will be cursing the verification engineer because the
original testbench did not take into account the features of the
next three generations of the product. Designs become obsolete, but
testbenches never die!
For Verification IP (VIP) to be trusted and used, the verification
suite has to be tied to a spec and reference sections and subsections
that are specifically addressed by the verification IP."
- Cliff Cummings of Sunburst Design
---- ---- ---- ---- ---- ---- ----
EASILY TWEAKABLE
"Most designs we reuse have a high probability of small changes. So the
test environment must be easily configurable to modify if needed; and
easy enough to find the appropriate test for a small RTL change. Users
should not have to run a multiple hour test to validate a small change
in RTL. The verification environment must be modular and there should
be some degree of separation between code (bash scripts, tool setup
scripts, standard protocol drivers and monitors).
For integration, all I/O ports of an IP must be standardized, should be
commented, and organized according to functionality.
Reusable IP should also be constantly maintained with bug fixes and
feature updates being planned in advance. Having short paramaterizable
RTL and test bench code ensures easy maintainence."
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
EVERYONE ON SAME VERSION
"One big problem with using different models of an IP is to ensuring
everyone -- software, verification, RTL developers, and the physical
implementation engrs -- are using the same version of the IP.
From an SoC integration standpoint, it would be useful to receive
updates on an IP and based on the issues fixed -- to determine if
the new update of the IP should be incorporated into the SoC design.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
"My problem is the lack of knowledge regarding an internal IP. One
team has fixed/improved an existing IP; while my project is using
an older version. Why? Because I have no automatic system that
tells me an IP has evolved."
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
STARTING POINT
"Better cataloging and searching for what's available (internally and
externally) and making it attractive and easy to add to this catalog.
Often the blocks that are catalog IP are not reused "as is" but used
as starting points. It would be better to have blocks that can be
re-used "as is", especially if they have been already verified as is."
- Dale Donchin of Analog Devices
---- ---- ---- ---- ---- ---- ----
KNOW WHAT'S UNTESTED
"Ability to track past uses. An IP has X features but the last SoC just
exercised Y subset of features. The remaining (X-Y) features are still
not deployed in field; not tested.
Central bug tracking for all features, ability to attribute bug impact
to each product.
Central archiving system and central team to manage it and advise on
specific IP reuse. Someone has to own IP problems."
- Vibhor Mishra of Silabtech Pvt Ltd
---- ---- ---- ---- ---- ---- ----
BEST DESIGNER
"What works is to have the best designer we have harvest from existing
programs or create and manage the reuse library. Yes other people
contribute, but you have to have someone to ensure the quality and
integrity of the designs in the library.
Otherwise if the users have 1 bad experience with a design from the
company reuse library they won't trust it anymore.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
Related Articles
ClioSoft marketing gimmick finds 8% of engineers willing to cheat
ClioSoft has doubts about IC Manage's "virtual file" BRCM claims
Join
Index
Next->Item
|
|
