Good afternoon, so what I’m going to talk about is some of the thought and learning process we have gone through as we are replacing our design management (DM) system. Since today’s theme is multi-site design, I’m going to talk about a few things about multi-site design, with respect to the legacy DM system we use to have, and the new DM system we are moving to.
Legacy Design Management System – CVS
Our legacy DM system, CVS, was based on some very old technology. It is 20 years old; our company is at least 15 years old, and we had used it from day one.
Basically CVS wasn’t design for silicon development; it basically is a software version control system. So we went with our own script, to try to make it work for our silicon design. And, obviously it doesn’t have any support for geographically distributed teams, no mirroring, cache, or proxy support.
Its performance was pretty poor, even for the main site – and even worse for the remote site.
Even though Juniper is a multi-site team, we actually operate as one design team. It may be a little different than other companies. So the definition of one design team is that we are actually using a centralized source and a single design flow, which is distributed the same across the company.
Because of that, it is hard to set up multiple design management systems (DMs) per site, so we have to work on the same site, with the same version on two systems.
But the problem is, with such poor performance, especially with a remote site, people try to work around the system by not updating their workspace to the proper tree. They avoiding updating for weeks or even months; sometimes they cherry pick changes to update.
At the end of the day, what they have is an inconsistent tree. When you have an inconsistent tree, you have a lot of instability, because people make changes that are not consistent with the top of the tree. So when they check in, it may break the tree.
Those are observations we have, in terms of performance and of behavior.
So we started looking into a better replacement to fit our needs with our multi-site design challenge.
After we did a study, we decided to go with IC Manage.
IC Manage Design Management System
The performance improved quite a lot because of the proxy support. Now our remote sites see the same performance as our main sites. So our users do not have an excuse to not update their tree, so they can basically keep their trees up-to-date with the target tree.
There are certain features, in addition to performance, where IC Manage works pretty well.
- IC Manage has global file status, so before you update or modify a file, it will tell you who is actually working on the same file.
So if you are concerned about someone else modifying the same thing, you can contact them in advance about what they are going to change. So everyone is on the same page, the system actually guarantees that.
- Because it’s DM is for silicon development, IC Manage has support for the release process – we don’t have to develop our own script to do release support.
- The other thing I like is there is a feature called shelve and unshelve. We basically can store a set of files, and before we actually commit to the DM, we can actually store them in the centralized system, and you can share them with multiple users.
So you can use that feature to test the release change. You can put it in the central system, and ask people to unshelve the change.
- It is much better than asking people to copy some of the files from the workspace, because sometimes those files are all over the place, and it’s hard to ask people to copy from your own workspace to another workspace.
DM System Migration Process
So now I will move on to the migration process.
- I think the first challenge we had for migrating a DM system is the team resistance to change. Humans don’t like change sometimes, especially when the tool has been used for ages – decades. Not everyone sees the performance problems, because some people work only work on a small part of the design, they don’t see that penalty. So forcing people to change is a challenge.
Instead we need to take time to explain to them the benefit of the new DM system, and to convince them by making them comfortable with our reasons behind the changes.
- If you remember, we have a single design flow. So it’s hard to find the time to switch over. It’s not like someone the company has a different group, and maintains the DM per group. Even though we have overlapping projects, we all work on the same design flow and the same set of IPs.
We share IPs across projects. So we needed to find a window of time that was a non-crunch time for all the projects. This is hard, so we have really switched over yet. But we are prepared.
- You also want to take advantage of the DM system strength. You don’t want to just blindly move the file from one DM system to another system. You want to study how to organize the files in the best way to take advantage of the DM system.
- Different DM systems have different philosophies. For example CVS does merging at update time, but IC Manage does the merging as explicit resolve steps. People may not be familiar with the differences, and you need to tell your users upfront about the differences.
Basically we set up a Wiki to document the differences between the prior commands they used to use and the commands are for the new system. And we will provide training by the time we do the formal switch over.
DM Migration Process Tips
I also want to share some tips on the migration process. I mention that we spent time understanding the strength of the DM system. One conscious decision we made is that there are two views of the files.
One view is for the user when the file gets checked out into the user’s workspace – they see a certain organization of the file. You want to avoid changing that because it may make it hard for people to find their files.
But in the version control system of the DM system, you may not have to have the same file structure. IC manage allow you to be very flexible as to how you map the file. Let’s say we map all our IP into an ICM project so we can take advantage of their “variance” feature. We also speed up some the file libraries of some of the PD files into a different library.
We allow people to check out trees to feed their functions, so we don’t have to just generate huge workspace for different functions, because not all files are used by all people.
We can streamline the process, not only for performance, but also for the disk space usage problem – we can actually reduce that. We took advantage of the remap feature for the path.
The last thing I also recommend when you go to this migration process is to automate the process. Basically we scripted the entire thing. After we scripted it, we timed it, and it took just about half a day do the migrations. We also need to do some check-ins, and that probably will take another half a day. After you do that you know that time, you can decide when you are going to switch over.
So because this can be done in one day, you can find a weekend and then switch over. So by the time people come back from the weekend, they can just use the system.
Also you have to try the migration process multiple times. We want to make sure the process is proven. We need to dry run with the migrated database – you need to try all the scripts to make sure there are no surprises. We found some problems during the dry runs, and streamlined and fixed the problems.
The last thing is you need to develop a tool to verify the import data. One catch: because of the difference in the DM systems, the import data might be slightly different. One example is that a lot of version control tool have a “$Id$” that will be different for different DMs.
So you need to make sure that your script is smart enough when you verify the input data that it can filter that information.