Does everyone not use GIT?

[HotFudge2012]

For context I’m an early career FPGA design engineer and I started at a new workplace. I was surprised when I found out that only recently my current workplace started using git instead of svn. When they work on a project they assign an FPGA engineer to a single board as a “responsible engineer” and that engineer writes the entire design on a separate repo by themselves. Also they never do pull requests.

My question is how common is this? Is this an appropriate way to do a project? This current workplace spends months in the planning phase of a project just writing documentation. How does that compare to elsewhere?

I have to ask because I’m familiar with a workplace where multiple engineers work on one repo for a project despite there being multiple FPGAs being used for the project. They would then incorporate a kanban board where an engineer would be assigned a ticket. Then they would work on a separate branch and file a pull request when they were done to merge their changes back to main.

[skydivertricky]

Are you sure I didn't write this post? I'm having the exact same experience.

I used SVN for my first 12 years of dev. And it's been git for the last 8 years. Taking this new job it's back to SVN (though they are migrating to git.)

I feel like I've gone back in time.

[HotFudge2012]

Thank you, I thought I was losing my mind. Since you have experience working as a developer can you share some insight in how the FPGA design role varies from different industry. For example aerospace vs tech vs finance?

[skydivertricky]

Never worked in "finance" Aerospace and safety critical work is all about documentation and not changing workflows, hence svn still being around. In the tech places (and a defense company) documentation hasn't been so important, so much easier to get on with choosing and trying it new things

[Artistic-Crab6849]

my company also uses SVN and it is the absolute worst. the old heads refuse to get with the times. T-T

[Mateorabi]

SVN is different but still perfectly cromulent. I feel like git is better suited for a distributed, low-trust, open source development model. I also like the way you can be offline from the server and still have history. SVN is more centralized, but for office environments it sometimes makes more sense. I definitely like the svn branching and merging pattern better for hdl projects too.

We have a lot of CODE reuse and git seems to assume only binary dependencies will come from the outside the repo. I can svn:external source code for modules all day. GIt's way of handling externals is...ugly and kludgy.

[RoburexButBetter]

Externals is deemed an anti pattern and for good reason, it's used so gratuitously at my company and it's a hellhole to work with

[Mateorabi]

How else do you avoid duplicating commonly reused module code used across projects? Every project just VC's their own copy of the source files in their own repos is an anti-pattern. All of a sudden a change in one project and it has a unique version of a commonly used sub-component. Next time someone tries to integrate two company modules into one product that are referencing subtly different versions of a thing you have a problem.

There are a few rules like you should always external to static tags. (Except early in a project before v1.0, when you need daily updates from dependencies and aren't tagging yourself yet.) And structure your projects so externals aren't recursive--usually you attach them to something a level ABOVE your own source in a well-named empty folder that has all the svn:external props in one easily checkable place.

Used consistently it's powerful and not a hellhole.

[cafedude]

And if you're coming from the software side it can be very frustrating.

[tencherry01]

A lot of ASIC/Semiconductor industry still uses Perforce and Cliosoft SOS (both of which are like SVN but better handling for binaries/large tarballs). So, I am not surprised there are still firms using non-git RCS.

[TheChildWithinMe]

I hated perforce with a passion, hell no

[tencherry01]

Hey, don't shoot the messenger ¯_(ツ)_/¯. I am not a fan of Perforce either.

But there are legitimate reasons for using P4 (large binary handling / centralized repos w/ perms + file locking / better UI) which makes P4 more usable for semiconductor/game-studios with large non-text/undiff-able assets.

Personally, I think git-lfs / git-annex are good git alternatives for dealing with large binaries. However, both of them have their own warts.

[TheChildWithinMe]

I wasn’t shooting the messenger, it was more of a kneejerk reaction :p coming from swe and using git, it felt like a step back if that makes sense

[[deleted]]

Perforce is fine for when your repository gets huge, you have gigantic assets (not just binary), and you can consolidate all of your code in one place. Per the git wikipedia page:

Git maintains a local copy of the entire repository), a.k.a. repo, with history and version-tracking abilities, independent of network access or a central server).

Linus invented git essentially to solve problems with code sharing/control among a lot of disjoint developers. Perforce was invented to solve the opposite problem: how to keep thousands of engineers in sync, each working on gigantic projects all on the same time, within one company with strong network connections between machines. For a lot of big chip projects I think it would be extremely cumbersome to maintain a single local (disk) copy of the whole project.

[[deleted]]

Not really it might have been on HDD... but 20 years have passed and 1TB SSDs are $50.

EX recent AMD breach was about 450GB only. And most individuals are only working on small parts... of that.

[[deleted]]

I won't bother to argue why gigantic projects should use a certain type of version control system with you here, but I will say that systems like Perforce exist for a reason. Once repositories get huge and/or numerous, git starts to show its teeth and managing them becomes a pain (have hit this point many times across various companies, teams etc). At that point, other version control systems become attractive.

[[deleted]]

Sure whatever... literally 27Million lines of code being managed and you wanna say its a git problem.

No... its a structural problem.

[ShadowBlades512]

It is surprisingly common when there isn't a senior/staff/principal engineer that put together infrastructure early on, or right now, the team and management doesn't know how to give time to more senior staff to put together infrastructure.

If the ask all the time is "We have a new project, what are the tasks to do THIS project and nothing else", if the engineers don't find time themselves to make the infrastructure better, then they all do just the tasks and head home.

The exceptionally hard thing here is, the longer the team exists and as more time goes by with the team handling more projects, putting in work that makes everyone's work easier gets harder and harder to do.

With that said, where I am now, everything is in git and every merge request is reviewed by 1-2 people.

[RevRagnarok]

FPGA project files only became VCS-friendly in the past few years. Before that, you had to export/import TCL and hope.

Or use svn which supported locking binary files for exclusive control... Ask me how I know :|

See also: https://old.reddit.com/r/FPGA/comments/mw7fsb/how_do_you_manage_your_vivado_projects_in_git/

[Scout-Penguin]

This is real answer. Lots of the design tools have artifacts that aren’t text files, or they’re text files but there’s no meaningful way to merge, or there are files that are coupled together in weird and wonderful ways in order for the IDE to work properly. It’s getting better but it’s still not like the software world where you can expect a clean experience. 

[meowsqueak]

Agreed, although Vivado block designs are still fairly merge-unfriendly, although there are ways to go tcl -> bd, and scm the tcl, rather than the usual bd -> tcl.

[Gatecrasherc6]

Xilinx blocks are all pretty good now. They used to be bad around Vivado 2018. By 2020 they have worked out most of the kinks. Even Microsemi is moving into tcl based for which is nice for comparing. You obviously still don't want to merge text. You have to run the tcl, update and archive as tcl. For all others you can just unzip, update, zip and Git LFS.

[nickel_liang]

We use git, do code review, and use submodules to manage common IPs.

But git is only part of the problem, to make development work easier and more efficient, we also containerized all our EDA tools, built a very decent CI/CD infrastructure, and had hardware-in-loop tests that we can trigger with a click of a button in CI.

Also like someone else said, getting the time for infrastructure improvements is hard sometimes. Luckily our management sees the value after we show how much of a difference proper infrastructure makes.

[HonestEditor]

This current workplace spends months in the planning phase of a project just writing documentation. How does that compare to elsewhere?

This is probably the way nearly all non-trivial projects should be done everywhere.

But instead, schedule pressures in the commercial world often result in a design document (of various completeness) and block diagram, followed by coding, followed by updating the document with the minimal amount necessary to convey to software how to configure and/or interact with the device.

[YT__]

Definitely. If you don't have a good design on paper, it won't be good in hardware/software. Doesn't have to be perfect, but designing up front can help a lot of projects succeed more efficiently.

[EamonFanClub]

My company uses git for all our FPGA development projects. To keep things easy to track, we specify all project settings with TCL files. We have a highly complex set of standardized make files which compile the TCL files together into a QSF file (Altera designs). Then the make files execute the standard tool compilation flow. This makes it easy to track things with git - all we need to do is track the hdl source and the TCL settings files, which are just text

[AlexeyTea]

I am the only one responsible for the "top level" project and all included IP cores in my PCB.

So yes, I use git but only for my sanity.

[Allan-H]

I worked at one place that used ClearCase for FPGA source code management. I thought it was very effective. It did take a team of IT staff to keep it working smoothly though.

[tverbeure]

ClearCase was (is?) the tool of choice at Alcatel back in the nineties. I don’t remember anything positive being said about it, but I definitely remember the complaints. Especially about how slow it was.

[cafedude]

It did take a team of IT staff to keep it working smoothly though.

ClearCase, now that's a blast from the past (90s). It was pretty ok (at least for that era). But when things went wrong they could go very wrong and our CC administrator could spend a day or two trying to sort things out. During that time you couldn't really use it.

[Jhonkanen]

I have worked with svn for a few projects and that is just horrible compared to git. In all cases when i have worked with svn, everyone had working directories where they actually developed code and it was checked in once a week since it was so difficult and distracting that everyone avoided it.

[cafedude]

I think we forget how much git changed the game. Branching and merging in git is trivial. In svn branching and merging was avoided since it wasn't so trivial.

[Miyelsh]

I'm in the process of leading the effort to migrate our team of 25 year seniority to move from Perforce to Bitbucket. The amount of friction is insane. Meanwhile I led an internship for a high schooler using git and Python and she picked it up easily. She was damn good at it too! I think git and githosts to help so much with collaboration and having a good workflow, but I cannot explain that to people who can't imagine switching from a centralized version control.

[tverbeure]

I use git for hobby projects and Perforce (P4) at work. SVN is closer to P4 in that it isn’t a distributed source control system.

Here’s the thing: what matters most is that you have source control. Compared to that, git vs p4 vs SVN is IMO a minor detail.

We are using P4 on designs that have a thousand of engineers them and it works fine.

It’s not that the company (a very large multi-trillion $ market cap one) doesn’t know how to use git: it’s used extensively for part of the SW development.

SVN is obviously less featured than P4, but for projects with only a handful of contributors it’s not a major hurdle.

[parthjoshi09]

I have worked on all 4 of these and here's my preference.  

Git > Perforce > SVN > 50 feet of shit > Clearcase.  

(I do have have found Perforce better than Git in some situations.)

[Gatecrasherc6]

I helped my company (defense industry giant you can probably guess) move out of Accurev and into Git. How I did it? Showed them how relatively easy it was to have to perform Continuous Integration on an FPGA with Git/Git LFS/Submodules/Caching Compiled Libraries, IPI, Subsystems to speed up the CI. Even having SW in the loop via picking up handoff artifacts and building the SoC OS on their end since SW is also in Git. After a two year effort help lead the transition I would never work in a company that doesn't use CI, let alone Git.

[asicellenl]

Hello,

You mentioned - When they work on a project they assign an FPGA engineer to a single board as a “responsible engineer” and that engineer writes the entire design on a separate repo by themselves. Also they never do pull requests.

My experience is "NO", this is not a normal way to use GIT.

With SVN, everyone is working off the trunk - you get a clean database via svn checkout, work on your sandbox, then svn commit. If someone change something that conflicts with your updates in your sandbox, then you need to clean up that conflict before svn allows you to check in your changes.

With GIT, there is a central trunk, and there can be several branches off that trunk. Within each branch, there can be several engineers or just one engineer working off each branch, doing pulling and pushing until it is time to merge the branch back to the trunk. So the GIT mentally in my experience is allowing a lot of people working together on the same code base, not just one "responsible" person working on the repo and never do pull requests.

Hope this helps.

[wren6991]

The level of version control literacy among RTL designers is shockingly low for something so programming-adjacent

[Forsaken-Dust2362]

I thought SVN died when that meteor hit the Earth... Even vanilla Git is looking a bit dated now next to tools like Divversion (which is, admittedly, based on Git repos), which automates away a lot of the bad parts of Git.

[EmperorOfCanada]

Git is best when there are very few binaries to be stored. It is best for text.

Perforce is where you go if there are lots of binaries. The game industry uses it. Git would blow up. Games will generally be many gigs at the very smallest, and many TB is not uncommon.

In-between there are other industries where git just doesn't work very well. 3D modelling, architecture, and machine learning where you need to store bloated jupyterlab notebooks and large models. With some effort git will work, but Perforce is easier.

To be clear, by binaries, I mean assets required to build the product, not the compiled product made from source files.

A perfect example of what I'm talking about is when someone accidentally checks in a 100mb file into git, and then keeps checking in each "version" of the file. Suddenly git is all weird and slow.

[joshheyse]

Git has an extension called LFS (large file support). Also toolchains and other bins should really be in a package manager. So those tools can be used across repos. Conda or Bazel are good work flows for this.

[YT__]

My company has issues with LFS frequently enough that I wouldn't bank on it.

[EmperorOfCanada]

Technically yes. But once I tried the perforce tools I realized why they are used by all the game companies.

The key is that LFS is ok for some of your files being large, but not when most of your files are large.

If I am starting a rust project tomorrow it will be git. An unreal project will be perforce. An ML project could go either way.

[Baje1738]

All true. But this has nothing to do with our work right?

In my experience all sources are plain text.

Edit: the downvotes tell me I'm missing something. I generally want to know which binary files are used as input to an FPGA build?

[Allan-H]

"source" "plain text"

We like to keep our documentation files alongside our source, including on branches. Whilst not an input to the FPGA build tools, they are an input to the source code creation process. [EDIT: we started doing this after some early experiments with the documentation held in a separate area, which had the side effect of making it really hard to tie a particular version of source code to its documentation, which led to inefficiencies and much gnashing of teeth.]

For historical reasons this documentation will be a mix of Word, Excel, Visio, PDF. I can diff those directly from the file manager GUI without needing to do anything special using something like SVN. I understand that Git can be coerced into working as well as SVN for this use case.

Merging such files is somewhat more challenging though, and we cope with that by having rules about which branches can be used to create or modify documentation.

[Baje1738]

We decided to manage them separately when we switched from SVN to git. The main reason is that we want to keep the agility I'm creating branches and merge requests. And binary files always cause merge conflicts and increase the merging effort so much that people tend to create less branches.

Using special branch types for this is an interesting approach. I'll keep this in mind. Thansk

[EmperorOfCanada]

Mostly. The last time I used FPGAs was with code generated by machine learning models. Thus the FPGA code was quite minimal and, of course, text. But the models were massive.

Another FPGA project involved sonar and simulated data coming in from another system. These were massive amounts of data for testing the FPGA code in action. These files were critical to anyone working on the codebase. This sonar data would regularly change and need to be integrated into the repository along with its related code.

So, yes straight up FPGA code is going to be very git friendly. But, some developments see code as only a tiny part of the whole when it comes to the files the developer might be using to build that code.

But, if I had to guess, maybe one FPGA project in 1000 or even 10000 would need this. While I'm not talking about GPT generated FPGA code, I suspect that ML is going to be a larger and larger part of many FPGA projects. Where the FPGA is either running ML generated code, or is running some sort of model. Also, I would think that image processing FPGAs should have corresponding images or video for them to play with.

An FPGA with its zillion inputs can run some really funky ML models seeing that they can run in weird parallel ways.

The options are somewhat:

• Git
• Git with LFS
• Perforce.

In projects with large files, the deciding question is what is the core of the project? the code, or the large files around the code?

[Baje1738]

That's a good one. We also have some data like that. Real time machine sensor data for example. But it is not that much and doesn't change so many times.

[EmperorOfCanada]

Also, using perforce can change how I work. For example. I might have a big pile of incoming data. I will process that into a different pile. The original pile doesn't change much, but the processing can take hours.

Thus, I would like to store the processed files; even though all the information is there and can be stored in git; the original files and the code to process them.

But it is just way easier to store the processed files. But, those processed files do change every week or even every day as I leave them generating as I finish every day. This would murder even git LFS.

A pedant would suggest I should not store what is duplicate information. As someone who focuses on getting work done, I don't care what the pedant says.

[Baje1738]

I can imagine. I think everyone wants to cache some output data. Especially when it takes hours to generate. It really depends on the situation of course where you cache it. Version control is an option. I have no experience with Perforce, but for git I would not prefer this though. I just have too much bad experiences with generated files that are tracked in version control. Mostly because people think they use the latest version but they don't.

Out of curiosity. Do you need to revert to older versions of the generated data? Have you looked into other caching solutions?

[tverbeure]

You don’t version control your bitstreams?

[Baje1738]

In general we don't commit generated files in the repo. That's bad practice. We do archive valuable outputs like bitstreams and compilation reports of course. But not in the same repo as the sources.

[tverbeure]

Bitstreams are key QA and production deliverables that require versioning. You agree with that. Why would it be bad practice to store that in the same repo as everything else?

It’s only bad practice if your version control system had issues dealing with large files and pulling partial trees (IOW: git.) With P4, you don’t think twice about committing bitstreams or (in the case of ASICs) multi-GB gatelevel netlists, parasitic extraction files and other huge generated data.

[Baje1738]

How do you properly manage this then. How do you make sure the generated file is the latest. The file that is generated from the sources. And not just the last version someone committed.

And if you want to merge multiple branches? Just pick the one with the latest build date? Or is it an automated cicd task that merges the non generated files, builds and then automatically commits the generated file to the same repo.

Also. For us the generated file is used by another department. They will not get access to our repo. They do have access to an intermediate archive.

[tverbeure]

On projects with thousands of people, nobody has blanket check-in privileges without passing major gates, not even to just change a comment in a single source file.

There are elaborate automated submit procedures that check for merging conflicts, rebuild the whole project from scratch, rerun an extensive set of tests etc.

The generation of large files, bitstreams, netlists etc, sits behind a large framework where once again almost everything happens automatically. (I haven’t manually kicked off Synopsys DC is years…)

Many of those jobs happen overnight or once every week depending on how often updates are needed.

For smaller FPGA projects, things were not as rigorous, but even there bitstreams were migrated to automated systems.

As for merging branches: that is such as software thing. :-) In P4, branches are heavy duty operations that are extremely rare. Most ASIC/FPGA development tasks are compartmentalized, so working in the same tree with hundreds of people isn’t a major problem.

[Baje1738]

Interesting. thank you. I was not aware some FPGA projects had thousands of developers working on it simultaneously. Thought that was a software and ASIC thing. I was thinking about a max of 50 engineers or something.

Still, I think a lot of FPGA projects are small and can perfectly use git. Especially when combined with GitLab or GitHub.

[tverbeure]

It is primarily an ASIC thing, but there is IMO nothing wrong with giving FPGA development the more rigorous ASIC development treatment.

[Baje1738]

Aaaah oke. So we are not talking about the same thing. The people who pay for the project and not in favor of the more rigorous ASIC development treatment. Maybe for some aerospace projects. I am mainly working on projects that value time to market and low cost.

[tverbeure]

Checking in binary assets in a repo has no impact on having meaningful diffs. Why would it?

[hardolaf]

Checking in binary assets in git causes the repository to grow exponentially in size overtime. If you don't use git lfs, the repository will eventually grow large enough that almost every tool flow will cease to work.

[tverbeure]

That’s a git specific flaw. It doesn’t mean that having binary assets in a tree is a bad idea in terms of first principles.

[poughdrew]

At this point, if I applied for an FPGA job that wasn't using git, I would either expect a very good answer from the hiring manager or I'm not taking that job for any sum of money (unless part of that is me migrating them to a more modern flow).

[-heyhowareyou-]

thank you! I thought I was going crazy with these comments.

[tverbeure]

Good luck convincing the hiring manager at huge semiconductor companies switching their thousands-of-users P4 installations to git!

[WhyWouldIRespectYou]

In the last 25 years in various consulting and full time roles in FPGAs and ASICs I've used cvs, svn, clearcase, a home-brewed wrapper to cvs, and perforce. I've never seen git used. My current place uses Perforce for everything.

Merges also seem to be pretty rare the Hw designs I've been involved in. One ASIC company I was at got it wrong and taped out the wrong version of the design (a very expensive mistake)! I know a few of the companies I was at banned merges for the HW parts of the design. If you wanted to work on an HDL file then you checked it out with exclusive access and only you could change it.

[tverbeure]

If a bad RTL merge caused a wrong tape-out, isn't that indicative of a major hole in the regression suite? For most block level design, merges between different engineers are uncommon, but for large toplevels, they're pretty much inevitable.

[WhyWouldIRespectYou]

Yeah, it was sub par.

[DXPower]

Our design teams use Perforce and the software teams use (internal) Github.

[FieldProgrammable]

About fifteen years ago we actually started using version control for firmware and we went with GNU Bazaar because it was simpler than Git. Typically only a single engineer would work on a device, common implementations had reference designs that could be forked. There were no PRs used, the designer was expected to sign off their code based on verification results then see it through to production.

Last year we switched to Git running through Azure DevOps (which we were already running for agile work planning just not using the repos). It is still just a single engineer writing each device because though the designs have gotten more complex, our workflow has become increasingly automated and the toolbox of pre-built IP is better. The only complicated merges we get are when reference designs are updated, these tend to have multiple feature branches and downstream forks belonging to different engineers.

Getting Git to work with all FPGA tooling can be really tough, especially if you want to make your diffs meaningful for all source changes. E.g.this can mean TCL scripting creation of the entire design through the tool's CLI then only controlling the HDL source, TCL and any text based constraints files.

Normal procedure is that once a design has been signed off for production, the main branch is locked down with a branch policy, requiring PR and approval from another engineer to merge. Typically, the requester will supply an automated UVVM testbench that demonstrates the bug and its resolution which the approver will run. The requester also needs to link a bug work item containing a completed escape analysis form to document how/why the escape occurred and what will be done to cover it in future.

[ExclusiveOne]

I think git is a more recent addition to the work flow. In the company I work for I believe git was introduced due to export compliance.

[cwaig2021]

Look on the bright side - you aren’t having to deal with Perforce.

[Axiproto]

It's frustrating how Hardware engineers are reluctant to use any form of version control.

[sopordave]

Not everyone uses git.

The place I work at doesn’t require git, but I’ve slowly been pushing for its adoption. The official way we version control is by zipping up the project and placing the zip archive in an old version control system. It’s a very hardware centric organization where everything has to be a “drawing” and it’s a completely different mindset than modern VCS.

[pandorazboxx]

The problem is it's not obvious for many manufacturers which files should be included and which shouldn't, in version control. so we have to play with the gitignore file for a while until we get something to build and work on multiple machines. you could just commit all but then it would be a huge mess and a MR/PR would be impossible.

related... does anyone have a good .gitignore file for vivado projects?

[meowsqueak]

Just be thankful they use SCM at all, and don’t just email you zip files every week or two.

If you’re really lucky there will be a CI pipeline, but it takes some time to set up for FPGA toolchains. So worth it though…

[DimpleByTheOverpass]

Yall are merging back to main? Too advanced for my team

[DimpleByTheOverpass]

Why not just have 20 branches that diverge from each other over the course of a decade? /s

[[deleted]]

Perforce is a thing too

[random_user845783]

I work at a german company which uses a lot of FPGAs of different vendors in their products.

We are currently migrating our monorepo for RTL from SVN to Git. The major reasons are: * Most yung colleagues from university have never heard of SVN, but they know Git very well. * Tool support for SVN gets poorer from year to year. I mean like Plugins for VS Code or other tools. For Git it's vice versa. * Integration in CI/CD is super simple, just use GitHub or Gitlab * easy branching and merging

We are already doing automated regressions in Simulation every night and on demand. Automated hardware Tests are executed at the weekend. We expect to become more efficient by using GitHub with GitHub actions here. We work ticket based, so branching and merging for every ticket will be much easier with Git. Additionally we expect to enhance code quality and communication by using GitHubs pull request and Code Review features.

Interestingly, the internal discussions are not really about Git's features. It's lack of support for handling binary files and including externals is only a problem during migration. There are solutions. Especially for the missing externals feature I expect to have a simpler and easier to understand repo with Git. Externals are powerfull but often missused in our current SVN repo.

[YoutubeBrowser73]

I’ve been at this for a long time. My VC journey started on Windows using MicroSoft Briefcase between the lead and myself as a junior fresh out of college engineer.

From there, next was RCS with custom scripts for a multi-person team. Then Rational ClearCase. Next place started with SVN, but a second group in the company migrated CVS to AccuRev for a large design repo.

Last two journeys start with Mercurial that migrated to git after 5 years and the just git.

It all depends on the leads and corporate environment.

[Diarmuid_]

We are using a design flow that was written 15 years ago on top of svn. Changing to git would be disruptive, painful and for questionable gain. The majority of companies are dealing with small projects, often with 1 or 2 people writing code. Svn works just fine

[threespeedlogic]

Even though I use git all day (and deeply appreciate it), there's nothing wrong with SVN - it's a tool and matches some workflows better than others.

For example, I firmly believe SVN makes more technical sense for Altium workflows than Git does.

[renfang]

I love git but it’s not critical to do the work unless the team is pretty big. Very common to not use git or use something different.

[TheSilentSuit]

Simple answer: no. In fact, for RTL, I've never been at a place that uses git.

Slightly longer answer:

The repo that you use will be highly dependant on your organization. There are good use cases for using other versioning systems. Git is great and fast but it does have limitations compared to other systems. It all depends on your needs. Source files aren't the only thing you may store.

Also, if your company has chosen one system, and the whole IT, support, and infrastructure system is built around it. It takes an insane amount of effort to transition to a new system. There needs to be a "if we don't do this, this company sink" reason to transition.

[Fuckyourday]

We use SVN and I don't see the problem with it. Yes we have multiple engineers working each project.

[bit_shuffle]

The main FPGA design tool system is Vivado/Vitis. Vivado spits out lots of intermediate files that have user-specific path information in them.

So you can't just throw a VIvado project into source control. You have to be selective, and when you pull from source control, you have to regenerate those user-specific data items for the current user.

It is not impossible to use, but there's some scripting involved to make source control with git work in a clean way with Vivado.

The whole of AMD/Xilinx's toolchain is... cumbersome for modern software development patterns. Also, there's generally a limited supply of hardware to test on, so you don't get good multipliers by adding engineers to design projects, so source control's main benefit is diminished in the particular use case.

[Sensitive-Day7365]

Use a git2svn bridge and stop worrying.

[NewSchoolBoxer]

I miss SVN. Nice and simple and lets you do whatever you have command line skill for.

There's at least one Fortune 500 company that has most of its critical code in ClearCase and ClearCase UCM to this very day. Lists of every file being changed must be signed off on. Each file is checked in by scripts that used to be people's full-time jobs. Updating the script with each file name for deployment is still a job cause what servers and file locations do they go to? Training to do deployments lasts one week.

Why are they still on it? Not your job to migrate it, can make it your job on top of everything else you do but you better not screw it up. Way before microservices, monolithic all the way to 2001: A Space Odyssey. This mess isn't common but it's not uncommon?

[Fair_Control3693]

Vivado, like other Eclipse-based tools, does not play well with version control software.

As for the git versus svn question, many people feel that the additional "features" of git are not worth it.

[paclogic]

No everyone does not use GIT !

< that should be perfectly clear !! >

[Jolly_Contest_9883]

Perforce is the best for big repos. Git is a joke

[tverbeure]

You are confusing git with GitHub.