Valentina Toll Villagra and Kyle Dumont with Allspice.io

Welcome to the macro fab engineering podcast. We are guests Valentina, Toby llogara

and Kyle Dumas.

And we're your hosts Parker Dolan

and Steven Craig.

This is episode 210.

Kyle is an experienced electronics designer. Having launched consumer products at large companies and startups for over seven years, he has developed low volume products for government and military applications, and high volume commercial products. Valentina is a project manager exploring the intersection of physical and digital systems at Allspace. Valentina has also worked at Amazon, expanding its national customer fulfillment network and rolling out into internal productivity, collaboration and project management software applications to support the company's growth.

Welcome, and thank you for coming out to the podcast Kyle and Valentina. Yeah, thank you. Pleasure to be here.

Thanks for having us.

So today, we want to talk about all spiced.io, which is something we have actually mentioned a handful of episodes ago, which is get for electronic design and electrical engineers. So you guys want to give us a quick rundown of all spiced.io? And what it is and how you guys are involved in that?

Yeah, absolutely. As you mentioned, we've we found some, I think, similar problems that that you have in the electronic space, especially for managing designs, using Git and, and other tools available. So we started all spies to try to remedy some of those those issues we found, we'll talk a little bit about, about what we're doing and how we met and what we can we can do to hopefully help ease along the

way. So what is all spice.io? Yeah, so we are

currently supporting electrical engineers that are revisioning, their designs using kit in any any repository hosting service, like GitHub, or GitLab, or self hosting. Essentially, we're building a tool that sits in between Git and the EDA tool like your Altium that converts between the file formats and makes it a little more friendly. For instance, our first product that we're releasing is a tool that helps you actually run a diff between different versions, using native Altium design files.

So solving kind of the issue of schematic review and schematic changes and things that has traditionally been a little bit more of a hey, I changed this, can you go and check it kind of problem?

Yeah, definitely. There's kind of two real use cases for the diff tool. One is that you know, you're a designer, you're about to release your latest design, and you want to check to make sure that you did all the things you wanted to do, you didn't make any changes that you didn't want to make. And then the other one is, like you said, that Designer view where you want to kind of package everything up and send it off this to your, your colleagues, and, or maybe a client if you're doing consulting, to try to summarize all the changes that have been made. So those are kind of the two things we we

see. So how does how does all spice differ from let's just say, opening up the old version of a, of the schematic, and then the new version? And another monitor?

Yeah, absolutely. Um, yeah, that's, that's the classic way of doing it. And we've seen everything from like, you know, read lines, you print something out, and actually mark it up and drop it off in someone's desk. I've done that, you know, in my past, too, to, you know, sometimes maybe marking things up in PDFs, or just the side by side comparison. What we're trying to do is just save time, given that, it's, you know, if you've ever done firmware design, as I'm sure a lot of your listeners have. It's, it's such a breeze to do some of these comparisons. And when you hop back to the space, it's, it's kind of frustrating to have to do that. What's the child game that you play? Well, you have to spot the differences between between two images.

All right, you got to find like that the apples there or not? Yeah,

well, yeah. But the difference of with that kind of game is it usually tells you can you spot the six differences? Like it tells you how many there are?

Yeah, so our goal is basically to make that automatic process and something like the comparison in the software world where you just type git dev gives you a list of the changes on this change, and especially for ease something more on the visual space. So can you just do that like automatically rather than having to reload I like remembering what it is that you've changed. Or trying to, again, like Spot the Differences. It's like we hear counsel stories of like, people like accidentally shorting something, or moving a component or deleting something that they didn't need that to happen. And then going ahead ordering your prototype, the board gets back and it doesn't work. And then you spend like a week troubleshooting trying to figure out what it was wrong. And it was just a small accident that could have been like, very easily prevented. So for those scenarios, where we're trying to make it make it an automatic process that we just type git diff, and for schematic drawings, the same way that you know, for code, when something like GitHub for somebody joins with Old Spice, you can just get the diff results back.

So you will get a list similar back, like our five has been changed to 2.4k ohms.

Yeah, it's kind of cool with at least schematic diffs, you have two components. One is the visual piece, and one is just that meditated metadata, delta. So you could say, you have that like add delete list, and we break that out. But you also have the visual diff, which is something we're working on to make it easier just to spot very quickly, this thing moved, this was connected from

so simple, like an overlay image. Some of those color coded if you think of it, putting one or the other word, the only things that pop out are the things that actually changed out or deleted, modified between one revision on the next.

So it's really, really quick to glance at it and see what has changed. Yeah, our

goal is basically that in 30 seconds, you're able to look at your design and first like never have a change that you didn't intend it to happen, make it to the activation, and then also get high level overview of the project. Or barricade go glance and trying to save a lot of time. And like putting these packages together for design reviews. And we also hear stories from engineers where they spend like hours putting out 45, slide google doc presentation together to send it out and they actually forgot half of the things and you're trying to look through your notes and things are all over the place. And like what is actually the has changed. But can we make that like a one step? And then it's interesting, because that there's also like, from the people we talked to, it kind of gets a lot of interest also from managers, right? Especially if you have like multiple projects at the same time, being able to get like a high level snapshot of the status and the progression. When you're having multiple projects to manage at the same time, that's super valuable for them.

I, I'd imagine to be really useful for managers, but for if your product is in production, and you're going to next revision, what do you need to tell your manufacturer, hey, these things are changing. Instead of just being like, here's everything, again, the whole package, you can just go, Hey, here's just the change file.

And that's the whole idea about gate. Right. So the whole concept is to just store the deltas rather than like the whole thing all over again. So we're trying to kind of bring some of those methodologies to the hardware space, because we think it's, it's needed, and we think it will be very valuable.

Yeah, and I can see something that could really work. Well, at my current work, a lot of our schematics have 678 pages of, of work. And, you know, some of the pages are, you know, this is our processor page. This is an input page kind of thing. And, you know, sometimes a revision is one value change in one op amp circuit on one of those pages, it'd be excellent if it could, if we could just see like a zoomed in thing of just that one little circuit and say, This is the only thing out of all of it. So you don't have to hunt for everything.

Oh my god. Yeah, yeah, that's what that's what we're going for. You get a little bit of that with with getting now in that's one thing we are trying to support is the designers that are moving over. Even in the native format, it'll tell if you have a binary file that changed, which is kind of nice, at least to be able to get you to focus on the right file, just going from version to version. But you're right, you're stuck. Once it tells you what what schematic page it's in, it's still up to you to figure out what that change was. And it could be as simple as like, the time update, like when you just hit save. I think it updates the time somewhere in that in then that counts that as like your your file change.

So where did the name all spice come from?

Yeah, that's, that's a great question. So we were playing with a lot of different ways to help the process. So spice of course, is synonymous with circuit simulation. So looking at a lot of the open source simulation tools like ng spice, which is nutmeg spice, right I think there's a few other like spice esque simulation tools, decided to just go all the way in and see us all spices kind of a unifying simulation tool for for IE.

It's kind of a nice inside joke. Because whenever we talk to customers or or people around, like usually, electrical engineers will know exactly what we're talking about. It's kind of a, if they laugh of the name or make a comment, it's a it's a very easy way to know that. They understand what we're doing.

And everyone outside of Electrical Engineers thinks we're selling food.

Yes, we've been asked multiple times what type of food we make.

So how did it all begin? Where did the idea come from? And where it how did you start it?

Yeah, sure. I, so I experienced, you know, some of these issues, I was at iRobot. And, you know, we had a great process. A lot of amazing engineers, too. But still, we had what was probably typical for most mid to large sized companies. As far as like a product lifecycle management PLM tool, that didn't really play nicely with Altium, which is what we used. And felt like there had to be a better system. So when I, I left iRobot, in about 2015, I helped start a 3d printing company called voxel eight. And we were so I was in charge of kind of stepping up the electrical team and getting the hardware design for that printer that we released. And it was there, I kind of had the opportunity to from the ground up, build a build a system, which is an opportunity, I'm assuming lots of your listeners have been through or will go through. And so then it was just a search for what tools I had available to help, you know, help the team and was about three of us on the hardware team, staying synched, and then do these design reviews. So that was it was cool, we use Git, actually, at the end of the day, it was pretty simple, because our software team was using that. So it was pretty easy for us to just spin out a repository, and then get going in that, and it was a huge learning opportunity. But of course, you know, we run into a lot of the same issues you did. So you know, there's no ability, for instance, to branch and merge. So if anyone ever does end up branching or working on two things at the same time, they can collide. You know, versus I was also helping run, especially at times the firmware team. And it was like night and day difference, you know, you open up a pull request, and you can send, you know, tag your teammates in it, people can go through like you said, rev, right arrow, comment right in the middle of the design, you know, call out a line in the firmware and say, hey, you know, did you look at this value. And that was like going through that was really what what I wanted to see for the for hardware as well. So I started in a leaving that company, started actually at this new ms MBA program at Harvard, which is where I actually met Valentina. And we started talking about this space and what we could do, and we both got excited about solving these problems.

So I'm a mechanical engineer. So we kind of started talking about the hardware space in general, and as any other to good nerds mapping out on Fridays, afternoons on the walls, on whiteboards, like what the entire system looks like, and what's broken, and what should we batter and like, what that 200 years ahead of us, like looks at future type of thing. And then we keep coming back to this idea of a lot of what was happening is this pressure on ease to accelerate the designs, and you see the trends and either adjacent spaces to electrical within the hardware space, the world agile gets thrown a lot around and Emmys now have 3d printing and software engineers have great design and test tools. And there's continuous integration and continuous development. And he felt like he didn't have like the comparable version of that. So we kept coming back to that. And that's kind of when we started talking about after our first class together, kind of brainstorming around for another semester in about February of last year is when we started working on all spice more on the business plan and kind of the product and what it will be like starting talking to potential customers during interviews, talks, interview tons and tons of Electrical Engineers just about all the problems and we went into an incubator last summer between first and second year of school. We did that full time for the summer and now we're back in our last year at Harbor in the dual degree program.

You know, one of the things that really stands out right now No, is what you were just saying you interviewed a bunch of E's. And I would love to hear what are the some of the things that you heard from them that they complained about or something that they would like you to fix with this. Everything,

so many things. So some of the things we hear a lot arm

e's are great designers, and they love doing products and innovating in that space like, and those tools are pretty good. Everything else around that it's a mess. And it's just such a pain to like spend three hours doing an amazing circuit, and then spending two hours taking screenshots and doing little red boxes around the changes to submit it for a design review to get approval to actually get it released. And it feels like such a non value add task. And he's like you're spending so much of your time and energy and creativity. And like these things that don't mean too much. It's just because the process is broken is like imagine if you could get those hours back and actually focus on like making your product better and making it more efficient and making it like reducing the cost or like improving the battery life or whatever it is like you're trying to optimize for. So what we're trying to do is basically leave as much time for you to focus on your design as possible.

I'm thinking what else we hear a lot. And the other thing we hear a lot around is

this idea of the majority of the problems that happen in designs are actually not engineering flaws. They're like small mistakes that could have been prevented, again, when an engineer gets back a board is not because the design was wrong. It's because someone accidentally shot at something, or it's because someone forgot to update the name, or whatever, are we because someone deleted this thing by accident, tons of stories about mechanical engineer, slip, that connector, forgot to email the electrical engineer, three weeks later, you're in the factory in China, the board doesn't work. And it's like those small things, it creates such a headache, and it's something that could have been prevented. And it's not necessarily the engineers fault is more because these things are kind of falling through the cracks to their process that and it's filling the schedule and time to market and especially in product like hitting your schedule is critical and accelerating, it's time to market it's critical. So if we can prevent those unnecessary iterations of prototypes that that could mean a lot for those companies.

Yeah, no one tries to usually no one tries to sabotage the design on purpose.

Yeah, but like, you know, yeah, ease want to design. I mean, that's where that's what we all wanted to do just focus on our designs, and you know, inside the lab and also on the computer and all the administrative stuff kind of tends to bite us. Like, that's what we hear a lot. And I think Valentina mentioned there, too, is the collaboration or the communication between different teams, like when you get multiple stakeholders involved, like firmware, and electrical and mechanical. All those communication points become become critical.

I may be jumping the gun here a little bit, but Allspace has some unique tools for doing design review. Right? Yeah, that's,

that's one we're working on. We're actually kind of refocusing on this supporting diff. And next is actually helping engineers build some automated testing. And then we're gonna work on creating more of a holistic, holistic design review process.

So it can be used a bit by, you know, engineering managers as a, as a design tool that plugs in with all the EDA software, right?

Yeah, definitely. I mean, our hope is that we can use, you know, get for hardware in similar ways, is software. So I think that analogy still still works here, in that you really can get a much better snapshot of what's going on. When you're, you're creating that, that next release. So that's really what we're gonna do, we think a lot about, about Travis and Jenkins in some like CI style software tools. So we do want to, to help build this kind of that test platform where we can start to build some very simple, simple tests for the designs that can help give you just that base functionality checklist. And we can do things. For instance, like check that all your components using your design have a specified manufacturer and manufacturer part number, that's one of the ones that we we hear a lot and we're we're pretty excited to add. But then also start to you know, if we're in get we can start to really connect the the pieces between the farmer design and the electronics design and for instance, check like our Pin Mapping. So if you have a pin configured in firmware for something so like You know, TX for your wine, we can check that it's actually mapped to painter and that that actually says something like, You are

the actually that's one thing that would be really useful for a tool like this is the say you, you're the hardware designer, and you already designed the schematic, you pass that off to the firmware guy, or gal, and they start working on the firmware. And then you start doing the routing as the hardware designer, and you go, Oh, if I swapped this entire bus around, and make the routing lot easier, well, back then, you know, you would normally have to pass a note off to the firmware person, that was a thing. But we hear a tool, the firmware person would be notified basically right away.

Yeah, definitely in there's some interesting tools. I don't know if you've all played with cube NX studio is like a ST product. They're starting to play with some of these block diagrams that that autogenerate firmware and playing back and forth. So I think it's interesting because the, the chip manufacturers seem to be playing in this space and wanting to help that process. But that's definitely, definitely interesting for us.

I'm actually in the middle of a project with Cuba max right now, where I did all my schematic design, and I'm in my layout right now. And the way that I'm trying to set this up for my firmware designer is, since I know the best routing scheme for the processor, I got in contact with him and basically said, Hey, what are what pins are best for you for these kinds of applications. And then we fix those. And as I'm routing things, I'm doing the cube MX side of everything, and then I'm just going to pass that off to him, and he has it already done for him when he gets to start. So it worked out really nice that way. You know another thing, though, that this is fairly simple, but it actually ends up being an issue at my work on occasion, and not necessarily an issue just like a minor annoyance, but our entire our system that we store our Bill of Materials in and do all of our inventory has the ability to to suck a bill of materials in from our EDA tools, but it's kind of, I guess it's kind of dumb, the way it does it is it doesn't really double check anything and it doesn't really

it doesn't do it intelligently. So if for instance, I have 100, Pico farad, it's written as 100, capital P, little f, somewhere on my schematic, and then I have lower p capital F, it will think those are two separate line items. And then it'll try to generate, you know, two different line items or like a 10, lowercase k and a 10. Capital case k, what it would be amazing if I could just have some kind of thing that would just identify that for me without having to go through all my schematics and figure that all out. And it sounds like all supplies might be able to do something of that sort.

That actually reminds me of like a linting tool in in firmware software. I'm not sure if you've used anything like that. But essentially, it just tells you you set up some pretty simple, like a framework for how you want to to code and say name your variables and things like that. And then it tells you if you ever go outside of those, it just gives you a little flag and gives you a squiggly red underline it says, Hey, this thing is, you know, for instance, like you said, lowercase p or uppercase P and it should be lowercase p.

It sounds a lot like coding standards. Yeah, yeah, each company's got a coding standard, stuff like that. So yeah, if you if your EDA tool would enforce a coding standard for your naming conventions and stuff, because right now they don't care. I've actually never came across an EDA tool that even looks at that.

So what are your roles at all space?

So I'm mostly focused on strategy and doing the product and also development right now. We've been been building this all in house for the moment. We actually had we had an intern for last summer since we were working on this full time, which was great. But he had unfortunately, or fortunately for him, go back to school, finish his degree. So we are we're actually looking for software developers over the next few months.

And I do mostly run the operations, customer success because my interview is marketing in more of the product, roadmap development, so it's being a good play for us so far, but also that said, we were a small team. So we do a lot of things happen between us.

And the team right now is the two of you, right?

The two of us for now. We graduated may in we plan to continue to work Can this full time after that? So at that point, we will be expanding the team.

Yeah. And we're starting to put together some content to for especially the help. Hardware EES who want to get into using Git for their designs, we're trying to start to put together just some blog content for helping people get started. So one of our near term focuses.

Yeah, I think we've heard a lot of there's like an organic transition from the the newer, more innovative teams that start directly on good from newer companies. And then there's also these more established companies that kind of want to try but don't really know where to start, it seems like the barrier is not doesn't work for us more like how do I set it up? Where do I click? How do I create a report that I have to talk to you what I have to do, so we're trying to make that a little bit easier, and that I least put the knowledge out there so that anyone that wants to try it out? The barriers, not like just like have access? But

then the big questions that that people ask, and it's really tough is should I use Git LFS, like get large file system format is kind of new, I'm not sure if you guys have talked about that at all, or looked at it. But it's, it's somewhat of a new tool in the last couple of years that is supposed to like get handle binary files a little better with the larger ones. Because it's doing that saving the Delta every time the design changes, which works well for code, when it can actually split things up and just save a little hunks. Because the entire binary file just does not handle it, it just basically saves a new revision of that file every single time which compounds on itself. So you end up with what can be a pretty massive git directory that you have to repository that you have to download. So Git LFS is supposed to handle it, it was one of the first things we're gonna try to help out with, you know,

Valentin, you were saying that a lot of, well, some of the, I guess, older engineering teams were questioning, how does it get set up? Why don't you go ahead and answer that, like, how do we set it up? And how do we get it to work?

So one of the beauties about it is that if you're a hardware company with a software team that already has, get are using, the only thing you have to do is basically open a repository for your team and configure kind of the back end of how to set up the Git ignore and like how to read the files properly. And we have a blog posts and like more the mechanics of it, like how to do it. But I guess, at a high level, it's like, it's pretty simple as to opening up a new repository, configuring the Git ignore and then start using, again, if you're familiar with, like software practices, and know how to operate from the command line, shouldn't be that much of a lift.

Yeah, we're gonna try to give a demo version of a Git ignore file that the workflow for hardware ignore, essentially tells git when you're originally saying which files and folders to not care about. So when Altium creates things like the archive folder, which is its own kind of back end revisioning component. That's one of the things you put in that file. And you can tell it, hey, ignore this file. Do revision it and don't show me changes in the diff,

temporary files and stuff like that. Yeah, exactly.

So in terms of the engineer on his day to day tasks, how does that impact an electrical engineer? Is it you know, what did they need to do? And what do they need to care about if they're using all space?

Yeah, so if they're, if they're already using get in swing, we've seen a lot of a lot of younger teams, then, right now, it should be able to plug in pretty seamlessly, at least for the diff component of it. We have, we actually have it set up so that you can install it as a git diff utility. So there's like a config file that we adjust in installer, we add a line to that says, hey, if you see a dot schematic document folder, run our diff tool and don't run the git diff tool because the git diff tool is just gonna come back and tell you it's a binary file. I don't know what to do with this. So that's the first step we have which should be pretty pretty low, low bar for adoption. Once we get to, we're going to try to from here and this are probably a few months out is trying to brought in the people we're trying to talk to more people that don't currently have get don't really know what you It's all about. And that's what we'll need to build on some more UI features to kind of help people say, you know, a walkthrough, this is when you're getting started, this is how to set it up. But we're actually not even sure there because it's possible that, you know, ease really want to learn how to use get in some do some good, so we're still kind of testing that.

Great. How about engineering managers? How does it impact them? Or does it at all?

So one of the things we're trying out, which has been fairly positive feedback is this idea of having the snapshot of of different salts and stuff like that, on a way that you can share a that doesn't require you to have, for example, a full e cat license or a fully CAT software. So rather than the engineers having to take screenshots and putting in a document is handed out to managers, can we output the results of the data directly to a web page or in the link that you can send to people just to keep to give like more visibility directly, and also something that you don't have to remember to update every time so that anytime you look at this, you know that it's always based on the latest revision from your engineer, rather than like, trying to like have like the weekly task of updating whatever document you have to report when?

So right now, it's almost is mainly dedicated to the schematic side of electronic hardware design. Have you guys thought about moving into PCB, the PCB land and finding differences between two revisions of PCBs?

Yeah, it's we're trying to say a little focus right now. But that's definitely one of the things we want to we want to tackle. It's a new set of a new set of challenges, and also different process that that people go through when you know, when you're comparing to, to PCB files. But yes, definitely on our list.

We're still a small team. So we're trying to keep, keep focus. But it's definitely something we also hear a lot, especially when you think about, like longer term implications of running, Design Review, and you want to look at the differences. Obviously, PCB is going to be a big component of what you're reviewing, and just doing schematic alone wouldn't be the full solution. So when we think about it, like longer term, but we have to grow the team first.

I don't I'm sorry, if you already said this, I don't remember how long is the the team been together?

So we started working in February of 2019. On an after school, so we did. Whereas go full time, stay on with the full time, the startup for the summer, and then we'll go back to it full time after we graduated this me.

And right now all space supports Altium. What do you guys have any plans for expanding that?

Yeah, I think so far, our roadmap would first be adding PCB and doing layout, probably, you know, with with Altium. And then we'd love to expand more towards tools. You know, we've, I was like PT icon last year, we'd love to add, you know, chi CAD, I'm sure a lot of your user or listeners use, and some other tools, which would be great to add to our system.

I'm sure that's challenging to migrate everything to a new tool, because it just it's, there's the challenges of what's different between the tools and how to handle each one individually.

Yeah, that's kind of one of the frustrations. So what what we do on the technical side on the back end side is that we do convert to a intermediate file format. So we do most of the computation, like the diff, and things like that, and the analytics will run will do using our own like text ASCII based file format. And so adding new tools for us would be a matter of providing that link between you know, the Chi Chi Chi CAD, file format, and then RS limb start adding one after another, but basically,

the translation layer so to speak.

Exactly, exactly. And that that lightens the load a bit for us. You know, this is it's a challenge too, because there's definitely companies that have tried to do this in the past. I'm in where we're watching closely to see you know what Why maybe those didn't work out? And where were some of the roadblocks will be? And we'd love feedback to like what, you know, what does an ideal schematic file format look like? That is obviously, you know, get friendly in scriptable.

So you're, you're starting to dive into a, a universal format that could go forwards and backwards with many EDA tools, then.

Yeah, I mean, that would be the long term long term goal. But in reality, it's something we kind of need to have to be able to even let get do its thing on a, you know, on the text files. So it's a, it's kind of a necessary component of it, like some formats like eagles, an XML based format, so it is ASCII. XML is not great with doing diffs, it has a ton of extra information that doesn't really show you, you know, if you compare one line to another, whereas other formats like JSON or Yamo, are, are much more I would say, get friendly. file format. So what we're looking to do is really build build up that that ecosystem, yeah.

Having having parsed JSON versus XML, JSON is tends to be a little easier. And generally, the information you get well, depending on how the structure is set up, of course, and what system you're on, is, it's more predictable. What you get back.

Yeah, that's what we're hoping I don't know, maybe, maybe there's some some better methods we can find as well. Definitely, if anybody has, has input on that, we're happy to hear it.

Or you should go to our Slack channel, then. We have over over 450 engineers there that would love to give you feedback.

Yeah, they're, they're parked there every day. And yeah, it's a really quick injection to engineers, thoughts. It's not hard to get an engineers opinion on something.

But yeah, if you ask that slack question, Slack channel question, you'll probably get 900 different answers out of 450 people.

So I see, I see this being a really useful tool. You know, I've been asking a handful of things about managers, but but also for teams of engineers, especially the, you know, say you have groups of people working on different sub circuits or, or portions of projects, for people to have some kind of a repository that they can bounce between each other, and then eventually combine them together and give to a manager, and then the manager can flip that around and create design reviews. It seems like, like this could be a very useful tool if it had a nice user interface, because if it in my opinion, if it just ends up being like command prompts that everyone is having to send to each other, it ends up being a little bit convoluted.

So Steven, you're looking at, like how Git handles conflicts between files. Yeah, there's not really a way at all right now in for hardware for that the handle like if you if I designed a sub circuit, and you design a circuit circuit in the same file, let's say a dip trace file. There's no way to combine those things.

Right, but I guess I'm saying more from just a global project management style of distributing work, and then bringing it together. And then creating design reviews off of that.

One of the beauties of Ghana is that you basically have one when history, right, like everyone contributes their own piece, but you can look through every committed revision and get the full snapshot of the project, regardless of who's been working on what different pieces

for this really cool feature called I get sub modules, which is what we're looking at for combining assemblies. What it is, is it basically is a, you can build a git repository and then link another git repository in that. So you can essentially build like these nested Git repositories, which at least in the hardware space could become these these assemblies. Like if you have some sub module, you want to link now to your PCBA here and your enclosure, potentially, in theory, your firmware and have all that kind of linked together so that you can quickly kind of look through and see, you know, a what version goes with what version but then also see exactly, you know, click through and then see the design history for for the other components. Yeah.

So Kyle and Valentina, what is the future hold for us electrical engineers. It's, it's gonna be great. Kyle just gave me a really weird face.

I was, I know, that's a big loaded question. But yeah, it's like, there's a ton of opportunity. And honestly, our biggest, the thing we're focused on the most is just improving the experience. And just the happiness level. I think the reason like, we get so much feedback, and like if people care passionately about doing hardware design, is because like, there's kind of, there's a bit of a left behind component, I think, to like some of the EDA tools and some of what, especially the PLM tools, don't really consider ease. And if you feel that when you're doing the design, and you're trying to export you're trying to use these systems and integrate. So the thing we're focused on the most just like, making a better, more enjoyable process. So hopefully funner more more enjoyable,

more enjoyable. Yeah, as as, as a contract manufacturer for electronics, I'm really looking like having proper diff, between versions of boards, like version one versus version 1.01. What's that point on one mean? In manufacturing, that's a big deal. Because right now is, the customer will come to you and say, Hey, here's 1.1. And they dumped this, like 20 megabyte zip file on your lap, and you're like, Well, now you need to go through and spend a week figuring out what's going on in here. Whereas they could give me a couple kilobyte text file that says, hey, we change three resistors

Yeah, and oh, by the way, that other thing changed to what's that all about? You know, why do you still want copper, just the one gold plating,

you know, the, the the PCB thing, I did this at macro fab, certainly, and I've done it more recently, but, you know, customers give version two of a PCB and you don't know what's different between them. So you're having to pull up your Gerber viewer of PCB layers and turn layers on and off and like visually see what is flipping on and off. So you can see where things are changing. And sometimes it's just, they move some text on a silkscreen layer, but it's up to you as the contract manufacturer to figure that out, you know,

imagine how great it will be if we could just run all spice and it tells you one line, this is why they changed, or you run the test, like did this change, pass or fail? And then like, automatically, you can set it up once and then just have it run every time.

Yeah, I really feel for the for the CPMs. In that regard. I've definitely done some last minute. Design pushes from like, oh, yeah, we just added a couple more things in and then you throw the zip file over.

Friday, Friday at five o'clock.

And you you get the quote out at 6pm.

A call on Monday. So yeah, what's the status of it?

Sounds like you guys need a mind reader for the engineer. Like, can you read the engineers mind? What what did this mean?

Mind spice?

Spice. That's version 2.0.

Okay, Valentina, Kyle, where can people find out more about you all spice and products that y'all designing? Cool stuff.

We have our website is all spies that IO. And we have a block there with some more information. And you can reach out to us at Valentina or cowl at all spies IO.

And you can download a demo from there.

Yes, we should. We should have it timed well with the release of this podcast. So right now we have Windows done. And when your finishing touches on that Mac bill. So a question that that might be that might be this weekend.

All right. Well, thank you so much for coming on the podcast. We really appreciate it.

Happy to. So pleasure.

Thanks so much for having us. Would you like to sign us out?

That was a microphone engineering podcast. We were your guests Valentina, Toby Lago

and Kyle Dumas. And we're your host, Parker,

Dolman and Steven Gregg.

Let everyone take it easy.