PREPARING FOR AN IOT EDGE PROJECT

JOHN STABENOW, DIRECTOR, MENTOR, A SIEMENS BUSINESS

W H I T E P A P E R

A M S D E S I G N & V E R I F I C A T I O N

w w w . m e n t o r . c o m
Preparing for an IoT Edge Project

The best plan is, as the common proverb has it, to profit by the folly of others.
– Pliny the Elder (A.D. 23 – A.D. 79).

Old Pliny was a “unicorn” - author, naturalist, philosopher, military commander, and thought to be the originator of
the encyclopedia. He was big on planning, but died in the eruption of Mount Vesuvius. You cannot scheme
everything. But, planning before you start your IoT edge project will limit frustration and save you time and money
in the long run, even if it is tempting to dive right into the task. Whether you are a one person enterprise, a
member of a small team, or part of a large organization, it is wise to consider many aspects of your project up front.

This paper covers a wide-variety of preparation considerations. As an experienced designer, you probably know
most of them. But, it is worth capturing overall planning thoughts for new teams and you might see something
that you have not considered in past projects. Some preparation elements are considered after experiencing
problems or failures. Why not capitalize on the folly of others?

CHOOSING A PLANNING PHILOSOPHY

How you plan is up to you, of course. But, there are several things that you should consider:

•• Planning documents
•• Requirement specification, tracking, and analysis
•• Scheduling
PLANNING DOCUMENTS
Even if you are a one person enterprise or a member of a small team you should consider at least creating two
documents that you can share with your teammates, potential customers, or contractors:

•• Functional specification: documents what your system will do. A common method to creating this
document is to specify use cases. From there, you can break down the lower-level pieces of functionality of
your system.
For example, let’s say you are developing a system for tracking pets. One use case would be from the
perspective of the pet. If the pet is in motion, the system boots up and begins to track the location, direction,
and speed. That means that your system might need GPS, gyroscope, and accelerometer blocks. If the system
will provide live updates, you will need a way to broadcast the signal to the internet. The signal will require
software to present the data to the pet owner. You can see how this simple use case breaks down
functionality into blocks. The functional specification elaborates those blocks.

•• Testing plan: documents how you plan on testing the individual blocks and overall system. This plan is
directly derived from the functional specification and serves as a vehicle to ensure that your system is fully
tested. If you have a QA or verification team, they use this document to create tests and testbenches.
For example, for the accelerator in the pet tracking system, you could create a testbench that verifies that the
block correctly interprets speed.

w w w. m e nto r. co m
2
Preparing for an IoT Edge Project

Some teams also create a separate implementation specification that takes the functional specification information
down a level, to cover the actual implementation details for the project. Other teams add this information to the
functional specification.

You should also consider how you store your planning documents. Typically, you want to store them somewhere
where everyone on the team has access at any time and location. Additionally, you should decide how to track
changes to the documents and if only certain team members have editing rights.

REQUIREMENT SPECIFICATION, TRACKING, AND ANALYSIS

You can capture requirements for your system and then associate those requirements to the functional
specification, the testing plan, implementation specification, and any files that you create or generate during the
life of the project. This usually requires that you come up with a tagging scheme. For example, in your functional
specification, part of a section header is a requirement tag like REQ_Function_1. Then, in the testing plan, that tag
is also used for the test associated with that function. Likewise, that same tag is used in a schematic block or in HDL
code, and in the simulation database. Then, tools such as ReqTracer from Mentor, can show your progress on
implementing a requirement.

Figure 1: The graphical view of requirements, documents, implementation, and verification results in ReqTracer.

SCHEDULING
Especially for projects that include teams, a team leader typically is concerned about meeting deadlines. This leader
tracks scheduling by getting initial task duration estimates from team members assigned to various tasks, such as
implementing or testing a particular system block. Scheduling can be tracked using a spreadsheet or a project
management tool. If the team employs a requirements tool, the progress of implementing and verifying a
requirement can be associated to top-level scheduled tasks. That way, everyone on the team knows what has been
completed, what still needs to be done, and if they are on schedule.

w w w. m e nto r. co m
3
Preparing for an IoT Edge Project

AFFECTED BY STANDARDS?
Is your product development governed by safety standards such as ISO 26262 or DO-254? If so, those standards can
impact your planning process. They often require significant documentation and the ability to show traceability
from requirements to tested implementation.

But, there are other standards to consider as well during the planning stage, such as:

•• Corporate standards: documents that you are required to follow for product development. Examples
include: coding style and rules, naming conventions, and file storage standards.
•• File standards: standards for the files that you create or generate with a tool. For example, your project
might require that you use the latest IEEE Verilog standard, the EDIF interchange standard, or a particular SPICE
model. Sometimes, the input/output file standard that you require, dictates what tools you employ in your
design flow.
Some teams put required standard information into the functional specification document, while others document
this in a separate implementation specification.

DEFINING INITIAL INFRASTRUCTURE

Defining how the project files will be stored and managed before you start your project will save you from
headaches as the project progresses. This includes considering:

•• Directory structure and storage

•• Version management
•• Defect tracking
•• Backups and servers
DIRECTORY STRUCTURE AND STORAGE
Your first infrastructure consideration should be defining a common directory structure for all the files in the
project. Your company might already have a directory convention or you might agree to one for the team. A
common practice is to replicate the directory structure for each block (Figure 2). How you organize the directories
is a team choice, but what you are trying to accomplish is consistency and to support the ability of team members
to quickly find the files that they need. In addition, consistent directory structures enables reuse of scripts within
the team and makes reuse easier on another project.

w w w. m e nto r. co m
4
Preparing for an IoT Edge Project

Figure 2: Sample directory structure.

Once your design is in progress, the files that you create and that tools generate are typically housed within the
individual directories for each block. Figure 3 shows sample block files from within a Tanner project.

Figure 3: Directory contents for a block in the overall system.

Regardless of your directory structure choice, always keep in mind portability. You want to be able to grab the
entire design or a leaf block, make a copy of it somewhere else, and ensure that all the references resolve. To
accomplish this, some common techniques are:

•• Only use relative paths. All file references point to relative locations, such as ../../Includes. Most EDA tools
support this option for generated files and directories.
•• Consider environment variables to point to file paths. For example, you could define an environment
variable called $DESIGN_ROOT that points to a particular path to the design files. It could be the path to the
entire design or you can change it to point to a block. You can employ this same technique in any scripts that
you write.
•• Make referenced items local to the project. For example, libraries or common header files are often
referenced but, they might live outside the project directory structure. This is fine if the project files will always
be accessed within the company. But, what if you want to send the design to a customer or outside vendor? A
way to support this portability is to establish a release or archive technique that is automated (covered later in
this paper).
Some teams even establish a file naming convention. For Verilog files, the convention could be <Module_Name>.v,
for example.

w w w. m e nto r. co m
5
Preparing for an IoT Edge Project

The team must also decide how and where the project files get stored. Your choice of version management tool
can influence your storage strategy. To support remote access, teams can set up a central repository on a server or
in the Cloud. Security of the project files is something that you must consider as well.

VERSION MANAGEMENT
Even for small teams, using a version management tool has value:

•• It is easy to release a version of your design

•• You can roll back the design if changed file(s) cause issues
•• You can check in and out blocks of the design (some tools allow branching and merging)
•• You can see and analyze differences between files
•• The team has a complete record of the life and changes of the design
There is an overwhelming array of free and commercial version management tools available in the marketplace.
Some ideas to consider before choosing one:

•• If your software team is already using a version management tool, consider using the same one. But beware,
they might be using a tool that has many complex features that you do not need for hardware design.
•• Decide if your team needs a client-server model tool, where developers share a single repository, or a
distributed model tool, where developers work in a local repository and changes are shared between
repositories.
•• If your needs are simple, try one of the popular open source or free tools.
•• Some teams like to add their version management tool into their design tool(s) as a plug-in for a more
integrated experience. If this appeals to you, find out if the tools in your design flow support plug-ins.
DEFECT TRACKING
Keeping a record of defects and their status goes hand-in-hand with your requirements management and project
management tools. Together, the team can see the work that is required and the impact to the schedule. If you
project is working under a safety standard, you often need to prove how you track and manage defects and be
able to trace defect fixes to actual verified designs. Some companies also expose their defect tracking system to
end customers. Like version management tools, there are free and commercial defect tracking tools available on
the market. And some of these are offered as plug-ins.

BACKUPS AND SERVERS

It goes without saying that your project files represent your one-of-a-kind masterpiece. If you lose them, you could
lose your company. Therefore, a backup strategy for your project is not optional. A good strategy is to automatically
and incrementally back up the project several times during the day to one or more remote and secure servers.

If your design is large, and you have hundreds of tests and testbenches, you might consider setting up a server
farm for simulation. This allows the jobs to be run independently on several machines in order to get simulation
results back faster than if you run on a single machine. Server farms typically run job allocation software that
manages these simulations.

w w w. m e nto r. co m
6
Preparing for an IoT Edge Project

OUTLINING DESIGN COMPOSITION

Sometimes captured in the functional specification or often documented in an implementation specification is the
design composition. What are the functional elements of the overall system? The design composition outline is
derived from the use cases and descriptions within the functional specification. In it, you can document:

•• The block diagram of the system (Figure 4): a high-level conceptual view of the system, partitioned into
functional blocks.
•• Block creation: will you create the block functionality, download open-source blocks, or purchase IP for the
block? Or, will you reuse a block from another project? Do satisfactory models exist?
•• IP analysis: identifies where the IP source comes from, methods to assess quality, how to fit the block into
the overall design, and cost.
•• IC architecture: is this a single or multi-die IC or a multi-chip project? What packaging technology is
required?
•• Testbench architecture: identifies new or existing block-level testbenches and tests, how to reuse these
testbenches at the top level, and what technology/methodology should be used to implement them.
•• Software architecture: identifies hardware memory and register elements, the processor, software tools to
use, stacks, and languages. Also identifies what software is created, reused, or purchased.
•• PCB architecture: will you need a unique board shape, multiple boards, and how many layers? Will the
overall product be housed in a unique enclosure? If so, is there any impact on the overall design?

Figure 4: Sample block diagram.

SELECTING IC TECHNOLOGY
Your requirements, such as power and performance, drive the IC technology and foundry that you choose. For
example, you might decide that you need to create your MEMS sensor on one die and your AMS design on another
die. This might mean working hand-in-hand with a MEMS foundry and also using a process design kit (PDK) from
another foundry for the AMS design. The technology for the MEMS die can be different than the AMS die.

A PDK consists of a set of data files that model transistors for a specific process technology at a particular foundry.
These files include the schematic symbol library, parameterized layout cells (P-cells), SPICE models, and technology

w w w. m e nto r. co m
7
Preparing for an IoT Edge Project

files for the design flow, such as design rule checks (DRCs) and layout-versus-schematic (LVS) command files. P-cells
automate device generation and are a key element of the PDK. Some vendors support the Interoperable PDKs
(iPDK) which attempts to standardize PDKs (Figure 5).

Figure 5: The interoperable PDK (iPDK) elements.

Tanner EDA works with foundries to offer PDKs for the Tanner design flow and also provides PDK development
services for your specific needs. For more information about PDKs, read this whitepaper.

ESTABLISHING THE TOOL FLOW

After you have decided on your tool flow, and Mentor believes that the Tanner AMS IC design flow is perfect for all
your IoT edge device design needs, there are some aspects to consider:

•• Licensing: will each designer have an individual set of licenses (node-locked) or do you set up a central
licensing (floating) server? There are tradeoffs for each strategy, usually centered on cost and accessibility.
•• Operating systems: while the Tanner design flow supports Windows®, if you opt for Tanner Calibre® One,
that suite only runs on Linux. This means that you need to set up a Linux® virtual machine or separate
environment, and you might need to adjust your licensing scheme. Also, you need to check that the software
that you deploy runs on the operating systems (and versions) that your team is using.
•• Downloading software: you can download all the Tanner tools on Mentor Graphics SupportNet, after
setting up an account.
•• Software installation: all tools come with an installer. Some teams prefer to have a copy of the design flow
tools on their own machines, while others place the software in a central location and team members point to
it. Again, there are tradeoffs for each strategy. A local copy allows each designer to work offline (if using node-
locked licenses), while a central copy allows teams to quickly deploy new tool versions and patches, ensuring
everyone is using the same software. This also means that plug-in deployment is only done once.

w w w. m e nto r. co m
8
Preparing for an IoT Edge Project

•• Plug-ins: if you have decided to deploy a more seamless design environment by adding plug-ins to the flow
(such as version management, requirements, and defect tracking tools), follow the vendor instructions on
installing them into your tools of choice.
•• Tool integration: while the Tanner design flow is a complete IC design and verification environment, your
team might have 3rd-party tools to integrate into the overall flow. It is wise to look into this before a project
starts, to determine what “hooks” these tools provide for integration and to ensure that any data formats that
you use are accepted by the tools. Some larger teams even develop a custom environment that presents a
single interface for invoking all the tools in the flow.
AUTOMATING THE FLOW
Based on your prior project experience, you probably have found that repetitive actions call for automation in order
to make your design flow efficient. In your project planning, some automation items to consider are:

•• Building the design: teams often put into place a method to build and compile a block, testbench,
software, or the entire system, typically for simulation. Often, a makefile-driven process is implemented that
allows the team to store all the commands necessary for the build. The team can tie this methodology into
their version management system.
•• Scripting: if you find yourself executing a set of commands at the shell level or in an actual tool several times
a day, it might be time to create some scripts that can be shared with the team. For example, instead of
remembering the associated commands and their options, you can create a script that checks out the code
from the version management system, sets up for simulation, selects certain simulation options, runs the
simulation, and outputs reports. Scripting is also employed by other team members, such as QA and
documentation.
•• Reporting: can often be automated such that the team has access to status and results at any time. These
reports can be integrated in the version management system or a requirements tool. For example, Tanner
Designer allows you to create a spreadsheet template that gets populated with simulation results and it can
generate documentation, such as a datasheet.
RELEASING AND ARCHIVING THE PROJECT
Eventually, the team needs to release the design to another team, customer, contractor, or a foundry. If you planned
your directory structure and employ a version management system, this should be fairly straight-forward. The trick
is to test the released design on an independent machine (and often not connected to the network) to make sure
that no referenced items are missing (or links to them fail). Typically, failures occur when referencing files outside of
the project, like libraries.

After a project is complete, the team needs to be able to resurrect it when making a new configuration, performing
a redesign, or reusing the design in a new, bigger project. The ideal solution is to plan out an archiving strategy and
a method to automate it. Some teams focus on just the project files, others archive everything, including the tools
(of course licenses and operating system support could expire over time), and some actually archive everything,
including the computer. Just like releasing a design, the key is to test that the archived project and design flow
work independently on a standalone machine.

GETTING SUPPORT
For your Mentor software that is under maintenance, you can interact with Mentor Graphics Award-winning
customer support. Access information online at Mentor Graphics SupportNet, by simply setting up an account.
SupportNet offers a wide-range of information, including:

•• Service requests to interact with a product expert

w w w. m e nto r. co m
9
Preparing for an IoT Edge Project

•• Online troubleshooting
•• Software downloads
•• Access to tool documentation, tutorials, and training
•• Access to communities of users
•• Requests for remote and online services
CONCLUSION
Pliny the Elder is long gone, but his words of wisdom still resonate today. Some up front planning for your IoT edge
project will certainly increase your success rate. Did this paper cover everything there is to know about planning?
Of course not. But, hopefully it got you thinking about fresh aspects of project planning to consider before your
next project.

To learn about the Mentor IoT edge solution, read this whitepaper. Or, if you are ready to get started, check out
how to make a zero cost proof-of-concept SoC by reading this whitepaper.

w w w. m e nto r. co m
10
Preparing for an IoT Edge Project

IOT EDGE PROJECT PREPARATION CHECKLIST

w w w. m e nto r. co m
11
Preparing for an IoT Edge Project

w w w. m e nto r. co m
12
Preparing for an IoT Edge Project

For the latest product information, call us or visit: w w w . m e n t o r . c o m

©2017 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

TFD 12-17 TECH16740-w