Unlocking Collaboration: Altium's New PCB CoDesign Tool in AD24

Dive into the future of collaborative PCB design with Altium's latest feature, the PCB CoDesign tool in AD24! In this exciting episode of the Altium OnTrack Podcast, our host, Zach Peterson, sits down with Wojciech Łaś, Product Manager at Altium, to explore the ins and outs of this innovative tool.

Discover how the PCB CoDesign tool allows multiple designers to work on the same PCB layout simultaneously, extending Altium's version control system. Learn about the compare and merge tool, a game-changer for detecting, comparing, and resolving conflicts in PCB layout files. Wojciech shares insights into the challenges of coordinating work among multiple designers and strategies to optimize the collaborative workflow.

Whether you're a seasoned Altium user or exploring the world of collaborative PCB design, this podcast provides valuable insights and a glimpse into the future of electronic design.

Listen to the podcast:

Watch this podcast:

Show highlights:

• PCB CoDesigner Overview
• Unique Features of the PCB CoDesigner Tool
• Strategies for Collaborative Design
• Layer-Stack Locking and Rules System
• Future Developments: Merge Requests and On-Premise Availability

Links and Resources:

• Learn more about PCB CoDesign Coming Soon in Altium Designer 24
• Follow Wojciech on LinkedIn
• Read this article to see the power of Altium's MCAD CoDesigner in action 

Transcription:

Zach Peterson:  Hello, everyone, and welcome to the Altium OnTrack podcast. I'm your host, Zach Peterson. Today, I'm talking with Wojciech Łaś, product manager here at Altium. We're gonna be discussing a new feature that's coming out in AD 24 and I'm very excited about it. I'm hope you will be excited about it as well. Wojciech, thank you so much for being with us today.

Wojciech Łaś: Yeah, hello, it's really nice to be here with you.

Zach Peterson: Yes, periodically, and especially during this time of year where the new version of Altium Designer is coming out, we get some folks from Altium to come onto the podcast to discuss some of the new and interesting features and upgrades that users can expect. So I wanted to give you the opportunity to discuss a new tool that's gonna be in AD 24. So maybe you can tell us about this new tool.

Wojciech Łaś:  Yeah, the new tool is called PCB CoDesign. So basically it allows multiple designers to work on the same PCB layout in parallel. So it extends our current version control system in Altium Designer and A365 platform. And the main part of this is compare and merge tool, which allows to compare changes and merge changes between two PCB layout files.

Zach Peterson: So the compare and merge tool is already one of those, I think, important tools for collaboration and teamwork, especially when you have two people like you say, working on the same design. But what's different with the CoDesign tool? 'Cause normally you might send out the same copy of a file, they have to come back, and then you have to compare them, and try and merge the changes and make sure there's no conflicts. But what's happening with the CoDesign tool specifically?

Wojciech Łaś:  So it is very similar tool to comparing and merging we know from GitHub platforms from, called, like IT World. So in PCB CoDesign what we did is possibility to compare and merge to PCB layout files. So we are comparing all physical changes, like changes in, like for example position and orientation of components, changes in polygons and all copper, but also changes in constraints, rules, changes in layer stack, and so on. So basically we are able to detect, compare, and find conflicts in all data that start with PCB layout.

Zach Peterson: Yeah, and some folks that I have worked with periodically will check out the same design that I'm working on. And you'll sometimes see a notification up in the corner, you know, so-and-so has this file open, and you have to then work on that same file. And sometimes, like you mentioned, there are conflicts that arise. But it sounds like this is more of a visual cue that someone has made a change in the same area that you're working on. And then later you guys can go back and resolve those conflicts.

Wojciech Łaś: Yeah, so this tool still follows our sub-action control system, which is based on Git. So designers work like asynchronously in parallel on their own local copies of designs. And so the workflow usually looks like this, that before they start, they agree what they will do. Like I take this left side of the board, you take the right side of the board, or splitting by some schematic, or splitting by function. And then when one of designers is ready with this work, and if you can upload changes, save changes to the server. So creating new revision on the server. And the other thing is that other designers are getting notification that there is some new work done by other designers. And those other designers can compare those new changes and also compare what those local changes, and find conflict between those changes. So right now in this current state of the tool, it's more like you have possibility to update your local file with your local design with changes made by other designers.

Zach Peterson: I see, so it's not actually happening live, like you would see in some of the other kind of collaborative design tools that are out there. Like where you can literally see somebody else moving something around in the layout.

Wojciech Łaś: Exactly. So it's not realtime. And it's still based on those revisions commits on the server and those changes are detected, and differences conflicts are detected. It's on demand when you want to check them not in realtime.

Zach Peterson:  So since people are working asynchronously on this, what are some strategies for using a tool like this without creating any double work? 'Cause I think when people are live, they really have to stay in their own areas of the board, like you said. And if they start to run into each other, then I think you risk creating double work. Whereas with this, you know, I can do my version of design, someone else can do their version of a design, and then we just have to come back later and figure out if we, you know, merge or take one version over the other. So what are some of the strategies people are using with this kind of tool?

Wojciech Łaś: Yeah, so we're talking a lot with our users starting from mid-size companies, like two designers working together to enterprise users, were like three, four, or five designers working together. And what we learned is that like splitting the work is not a problem. So the flow is quite common also now. And that before starting the work, designers are just talking to each other, and assigning tasks like what areas of board, for example, they will design. With the Altium Designer, we can use comments, also comments and tasks to help with this communication. So I can mark some area where I will work using comments and I can notify and communicate with other designers using comments, or just this communication as done in realtime using communicators, or just talking to other designers of course. And so we are starting by assigning, let's say tasks areas of the board, and so on. And then designers are working their local copies. And what we see what is really useful, especially for larger teams, is to have some like milestones, let's say, or fixed time of the day when they synchronize together, work. So let's say at the end of the day, they stop their work and they synchronize each other work. So they are saving their changes to the server, synchronizing with others changes, and so on. And so that's what we see as a good workflow. But still we are working on it for sure. And then testing with our beta users. And this PCB CoDesign compare and merge tool, we're discovering more and more use cases, and some corner cases, and what are limitations of our current flow and we are thinking how we can improve it.

Zach Peterson: Well what are some of the interesting use cases? I could imagine some use cases in like multiboard design. I could imagine some use cases in maybe large boards, maybe people stick to routing on, you know, one layer versus another layer. I think there are some different ways you could kind of divide up the work in parallel. But what are you seeing?

Wojciech Łaś: The most complicated use cases when we have like more than two designers, like to coordinate the work between them and where we can have conflict not only between two designers, but also three and more designers, also how to synchronize the work of this more designers. So these are the most challenging cases. With multiboard design, it works well as we see so far. So still there is single file per single board layout. So there are no problems with it. And there are some challenges when, for example, designers are starting to modify a layer stack, or they start to modify some rules. And you can imagine that changing layer stack can easily, like delete the whole layer of someone's work, and so on. So those are like not corner cases, let's say, that's some common, but we are also thinking how to figure it out. We are thinking about some logs, or in permission systems like to lock the layer stack from modification, and so on.

Zach Peterson: I mean the layer stack locking makes a lot of sense, because I would hate to be routing, and then somebody else just deletes my layer.

Wojciech Łaś: Yeah, exactly. So this is the one of steps we have on our roadmap to like lock some objects, classes of objects, of nets, of like layers, tag, and roles, and so on. So users will have more control of what those co-designers can do actually, and assign it, easier assign it in particular areas to that.

Zach Peterson: And then with something like rules, you know, I think using the rooms system is probably one way you could set up rules so that they only apply to one designer maybe. I mean, with rules, if I let's say change a rule on a net class, and somebody else is using that net class, suddenly, they see a bunch of DRCs flash, because I changed the design rules on them.

Wojciech Łaś: Yeah, so you are right. It does make one of good ideas how to solve this problem. And so it's of course collaboration of multiple designers. It requires some, say culture of work and common agreement between designers, how they work, and what they can do, what cannot do. So at the beginning, at least, we don't want to limit it by the software. So we want to like give freedom to people, and it's more like monitor, and observe, and learn what they will do and what problems they'll have. And then based on that feedback to create like the software features that will support it.

Zach Peterson: Yeah, so the tool is currently in open beta. And with the tool being in open beta, I'm sure you're gathering a lot of feedback, like you just mentioned. What are companies saying about the tool? Do they like it? Do they wanna see major changes? Are they communicating maybe some of those use case issues that we've mentioned?

Wojciech Łaś: Yeah, exactly. So we are actively testing it through with our users, the features in beta for a few months already, and have a lot of feedback. Mostly the feedback is very positive about this compare and merge tool itself. And basically all customers are admitting that it brings a lot of value and it speeds up design process. So it's easy calculation when you can have two designers working on single layout versus single designer. And that's huge benefit. And also it's saving a lot of time during merging. So a lot of our users in the past, they were just merging two files, like opening two files and doing copy-paste of some parts of design. It was really time consuming, error prone, and so on. So they liked that this feature speeds it up, and we are still working on some issues related more to version control system in general to our say, Git approach, and we are still trying to improve it. So bringing this compare and merge tool, of course, it creates new workflows, so new challenges for us. So we are actively also working on it and planning to continue to deliver what we call the deed for electronics. So we are working on it still and working actively with our dealers.

Zach Peterson:  So you brought up Git-based version control, and I think anyone who has really dug into the guts of all Team 365 knows, you know, what's going on in the background as far as version control and understands the value. I think though that most EEs are not familiar with Git or version control in general, especially if they're a freelancer. Because if they're a freelancer, they just receive the files, they do the work, they give the files back. They don't really know what's happening on the management end, 'cause that's the client's responsibility. But when you're in these companies where you have multiple people working together, and there may be a lot of data, now version control becomes really important. So are EEs familiar with this kind of compare and merge workflow? You know this is something that normally comes from software and I feel like we're trying to, you know, bring that mindset and that workflow over to EEs.

Wojciech Łaś: Yeah what we see, they mostly know more or less what Git is and what are the principles of Git with this version controls, revisions are stored on the server, and so on. And they're okay with some updates committing revisions. And that this is just basic knowledge and we are aware of that. It's also that's why we don't want to copy one to one Git or GitHub, and so on, platforms. So we want to adjust and mostly simplify and the Git to needs of electronics design. So it's starting from and naming, like we are not doing commits, we have safety server common, which is much easier to understand by non-IT guys. Yeah, and so on. So what we see this comparing and merging is quite natural that you compare, you see visually what are modifications, what are changes. We are using very simple color coding, like green objects are added, yellow one are modified, the removed are red ones, and there's cut list with categories of changed objects. So we see it's this level of understanding, it's quite common, and it's enough to use Pacific Code design, but still we are working on it to make it better and to make it more easier to use it to fit and adjust to needs of electronics design.

Zach Peterson: Has there been any challenges that you've seen in maybe getting EEs to become familiar with a Git workflow and not just what Git is?

Wojciech Łaś: Well some challenges, of course, we have some. For example, yeah, understanding the principles especially that Git is distributed version control system. So behind the scenes perhaps still your local repository and explain to EE what is difference between commit and push, pull, comments when we go to this lower level. And it's not so simple for them. And also like, we are working with Git on more on project level. And so the revision as per project where what we see is more expect work on file level, they want to like save to server and update some single files, and so on. So this is also one of challenges we are working on. So sometimes they see some unexpected results, let's say. So that's where beta testing is very useful and a lot of interviews with the users, and also we are working actively with our contractors, with professional engineers to consult as consultants to help us to better understand this flow from EE point of view.

Zach Peterson: Yeah, I like how in 365 everything is very visual, so it's very easy to see what the flow is as far as version control and revision history. And you're not stuck like typing in everything like you would in a console with a software project. 'Cause I think the software people really gravitate towards that whereas, you know, with hardware engineers, very visual.

Wojciech Łaś: Yeah.

Zach Peterson: It's much easier to make

Wojciech Łaś: For sure.

Zach Peterson: a Git-based system.

Wojciech Łaś: This I can promise we'll never force our users to type like Git comments. So that's not the way we want to.

Zach Peterson: Well good.

Wojciech Łaś: For sure. It has to be visual.

Zach Peterson: Yeah, yeah, I agree. I definitely don't wanna have to type all that stuff out. It's really nice to just be able click, save to server, and there it goes.

Wojciech Łaś: Exactly.

Zach Peterson: So are there other platforms that are using, like a collaborative design approach? I mean I think I know of two for sure, and I'm wondering if there are any others. And then really how does Altium's tool compare? We've discussed, you know, the difference in terms of working asynchronously versus seeing things live. But what else is different from some of those other co-design or collaborative design type of tools?

Wojciech Łaś: Yeah, the first thing is that we have already this quite-well established A365 platform. So everything is on the single place on cloud or on-premise, if needed. The biggest difference is what you mentioned, we're discussing internally a lot about which direction to follow, and this difference between like realtime collaboration, asynchronous collaboration to go like, to still continue this, it's a GitHub-style path, or to go in some like Google Docs, let's say, realtime collaboration. We talked a lot with our users. And this is I would say our key differentiator right now. So most of tools on the market, like our competition, and so on. They went into this direction of realtime collaboration when you can see what other designers doing, and he's moving some components, and so on. But we talked with our users also that were using those tools, and the result of this discussions was usually that it's nice to have such features, it's really like nice feature, but it's not really needed in like daily work. So still they split their work by some board areas and they work independently also the time, and this realtime visibility is useful, just maybe a few percent of their time. So we decided that it's, for us, just over engineering of this thing. And we just focused on delivering this proper flow based on Git with asynchronous work where you can compare changes, merge them. And it brings us for example, much better traceability where we exactly know who did, what changed, or we can easier review those changes. So one of the key features we are planning for the future is merge request or pull requests, you know, from IT. And where some like engineering leader can review those changes between, before merging them to server. So like formal design review process. So we are going this direction more, like providing this Git for electronics rather than those realtime.

Zach Peterson: Yeah, I think the realtime tool looks really cool, right? You can see somebody else doing something in the layout, but you brought up, you know, with the compare and merge that you know, it's in version control, which means if I really needed to, I could roll back to someone else's change if for whatever reason my change doesn't work out. And I think that's-

Wojciech Łaś: Yeah, yeah, exactly. So we have better control and better traceability. So you exactly know who did those changes, you can revert to them, and so on. So it's giving you like better formal design flow.

Zach Peterson: Yeah, yeah, I totally agree. So you mentioned I think merge requests as an upcoming feature on the roadmap for CoDesign, is that correct?

Wojciech Łaś: Yeah, so this is one of features we are considering, planning right now. So there are branching on the table and merge requests, and plus better this conflict prevention, say those permissions or change, making some changes, and so on. So, which I was mentioning for example for roles. So those are like three key areas we are planning to focus.

Zach Peterson: So is this going to be something that is included with access to 365 in the newest version of AD?

Wojciech Łaś: Yeah, exactly. So this compare and merge feature, it's included for all A365 and Altium Enterprise server users. So it requires only that the project will be managed using our platform. So A365 in cloud or Altium Enterprise server on-premise, and that, yeah.

Zach Peterson: And you've mentioned a couple times on-premise, I think that's pretty interesting too. I think on-premise, just usually due to IT support and network support is probably somewhere where you might be more likely to see like the realtime design versus with, you know, somebody who's on the other side of the world and might have, not have the greatest internet access. So, but the on-premise, you know, deployment is actually pretty interesting. Are people more interested in implementing this thing in an on-premise environment versus remote?

Wojciech Łaś: Well of course, let's say naturally, we are promoting our cloud platform, and we believe that the cloud is future. But we are aware that there are still a lot of customers who are not allowed to use cloud services yet, or like we don't have Go clouds in all regions, and so on. So still, we have this proposition for on-prem customers who wants to manage their data on like internal servers. And by the way, this approach with merging with this asynchronous collaboration is also much better here. 'Cause we don't need like direct connection between workstations of different people who could be even from different organizations, yeah. Some part of work could be outsourced. So we don't have such limitations here with this asynchronous design where people can just work even offline, and then they just need to sync and they work together.

Zach Peterson: And then I think last question I have is with external people, right? Contractors, right? You can welcome guests into your 365 workspace, same access would apply to co-design. So now the internal people could bring a freelancer or a contractor in, and work on the design with them. Is that correct?

Wojciech Łaś: Exactly. So yeah, that's the part of the idea behind it, and why we are doing it this way. So that was also to outsource just part of the design, part of the layout to some contractors, for example. They don't even have to see those external contractors. They don't have to see all design, for example, if you wanna hide some internal IP. I would say they can just do their work, they're part of design, and then you can merge this part of design trip to your main branch, you know, the A365 platform.

Zach Peterson: Okay. Well thank you so much for being with us. This is really cool, and I'm gonna be eager to see it in action. And I'm sure all of the folks out there listening as well we'll be eager to see it too. So thank you so much for joining us today.

Wojciech Łaś: Yeah, so the feature will be publicly available from AD 24. Yeah, so thanks.

Zach Peterson: Okay. Yes, thank you very much. We've been talking with Wojciech Las, product manager here at Altium. If you're watching on YouTube, make sure to hit the Subscribe button, hit the like button. You'll be able to keep up with all of our tutorials and of course all the new feature announcements as they come out. And last but not least, don't stop learning, stay on track, and we'll see you next time. Thanks, everybody.