EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => Altium Designer => Topic started by: mingming on May 26, 2017, 02:01:31 pm
-
:)
-
We've made it faster.
We've also completely changed the UI so you'll need ten times as long to get things done.
-
i've seen it. i've played with it. it's good. no more endlessly dragging inspectors around between screens.
-
7 hours to produce gerbers? I would have though the the program just crashed after about 20 minutes. Then again, I never made a 26 layer board with 9000 parts.
-
26 layers and 9k+ parts? Christ, who even does that in Altium? I'm amazed it even loaded in the PCB editor.
That kind of a board is solidly in the Cadence Allegro/Mentor Xpedition territory. The cost of a prototyping revision or two for something like that is going to cost at least the price of a seat of Cadence or Mentor, and those are expensive packages.
-
You see some things on this forum occasionally that opens your eyes and sticks in your mind. :o
26 layers and 9k+ parts? Christ, who even does that in Altium? I'm amazed it even loaded in the PCB editor.
This:
i regularly work in collaborative mode. where two or three designers work on the same design. each is allocated specific rooms to work with. we play tag. meaning there is a day shift and a nightshift to keep layout rolling 24/7.
now we have to manually merge files at the end of every day. this involves a lot of copy and paste. especially with complex layer stackups ( blind and buried, stacked via's (laser) split planes etc this is VERY TEDIOUS to re assemble a board every single day.
Last design i did in collaborative was a 22 layer with 6000+ components and 27000+ nets ... 3 mil track and gap. 6 laser layers 8 powerplanes , 8 internal routing layers (buried via). all impedance control and fully length-tuned. DDR5 , gigabit ethernet , HDMI, USB3.0, multiphase regulators for the 0.9 volts CPU core eating 50 ampere... the whole shebang.
Anything that can make my life easier and shave weeks off the design is welcome ...
-
I wonder what the release date will be?
-
26 layers and 9k+ parts? Christ, who even does that in Altium? I'm amazed it even loaded in the PCB editor.
you called ?
perfectly possible. no need for torMentor Siemens (they borged Mentor a few weeks ago) or Crapdance....
-
26 layers and 9k+ parts? Christ, who even does that in Altium? I'm amazed it even loaded in the PCB editor.
you called ?
perfectly possible. no need for torMentor Siemens (they borged Mentor a few weeks ago) or Crapdance....
Possible maybe. But vastly easier in Mentor. I have spent many years spent driving both.
On modest FPGA designs Altium grinds to a halt with on line DRC enabled - in 2005 (!) Mentor did not!
-
Is this a Designer update or Atina? Any hints at new features in the analysis area of SI/PDN?
-
Damn it, it sounds nice. And my subscription is ending. And management told me to f off, they dont want to spend x EUR on stuff which is not really necessary.
-
They gone black????
No!!!! No !!!! No-o--o---o !!!!!!! :rant:
-
They gone black????
No!!!! No !!!! No-o--o---o !!!!!!! :rant:
Relax, its probably like Solidworks or Skype, or hundreds of other apps that now offer a dark theme.
Its a good thing.
Be sure to sign up for EEVBlog Black©, coming soon.
-
For those of us who use large format monitors,. Dark theme is a must...
-
Damn it, it sounds nice. And my subscription is ending. And management told me to f off, they dont want to spend x EUR on stuff which is not really necessary.
...yet they continue to cost the company money for their own mostly unnecessary positions.... :-)
-
I wonder what the release date will be?
It is scheduled for October:
https://www.evaluationengineering.com/altium-presents-2020-pcb-design-roadmap (https://www.evaluationengineering.com/altium-presents-2020-pcb-design-roadmap)
-
Dave, can you add a black or dark gray or dark blue UI theme please? It looks awesome!
If you aren't already aware, can try these:
https://chrome.google.com/webstore/detail/dark-reader/eimadpbcbfnmbkopoojfekhnkhdbieeh?hl=en (https://chrome.google.com/webstore/detail/dark-reader/eimadpbcbfnmbkopoojfekhnkhdbieeh?hl=en)
http://userstyles.org/styles/681 (http://userstyles.org/styles/681)
Many options out there.
-
The other new rumored feature is git support...
I am looking forward to the multi-board support. You can design at the system level and do electrical checks through all of your board/connector/cable interfaces.
-
How does a multiboard project handle boards that will mate together directly? Can you check mechanical clearances between their components? Enforce alignment of mating connectors?
-
Git support would be "yuge"
-
Git support would be "yuge"
Careful, you'll scare off the luddites.
-
They should fix basics...
Like add through hole part batch generation to IPC-wizard and allow you to redefine how mouse navigation works.
I want to pan with middle click and zoom with scroll wheel like in 95% of other software.
But no... ;(
-
They should fix basics...
I want to pan with middle click and zoom with scroll wheel like in 95% of other software.
But no... ;(
The scroll wheel has complete configuration options:
http://www.altium.com/documentation/17.0/display/ADES/WorkspaceManager_Dlg-SysPrefsForm_MouseWheel((System+-+Mouse+Wheel+Configuration))_AD (http://www.altium.com/documentation/17.0/display/ADES/WorkspaceManager_Dlg-SysPrefsForm_MouseWheel((System+-+Mouse+Wheel+Configuration))_AD)
Middle click vs right click for panning is a little more complicated but should still be possible to remap also.
-
finally multi board design :-+
-
It makes it sound like they finally dumped Delphi - I figured this would be impossible by now, so expect an enormous number of bugs.
-
complete rewrite in c#
mulit board design even checks connectivity accross the connectors. highlight a trace on one board and it highlights on the connected boards ....
-
complete rewrite in c#
mulit board design even checks connectivity accross the connectors. highlight a trace on one board and it highlights on the connected boards ....
I'm simultaneously really excited and really horrified how this will turn out 8)
-
complete rewrite in c#
Eagerly awaiting the release of 18.1 :-\
-
complete rewrite in c#
mulit board design even checks connectivity accross the connectors. highlight a trace on one board and it highlights on the connected boards ....
Wow...I hope they have a back up plan...usually a rewrite takes a few iterations....
-
I am going to hold off for minimum a year before even thinking to renew my subscription.
-
I am exceptionally excited about this.
I just really hope that licensing and installation allows for 17.x to work side-by-side with 18.x just in case some odd issues come up.
I'm really pumped about the potential Git support. I hope it's easy to integrate it in with some off-site repo providers.
-
I am a fairly happy SVN user.
Why is GIT a big deal for Altium users? I mean, what are the headline feature improvements?
Is it the local commits when away from the main GIT server?
-
[...]main GIT server?
Which main git server? ;)
-
The intranet one. Unless of course you wanna do the cloud thing.
-
Ah, or are you hinting that there is no central server in GIT. That's out of my comfort zone. :scared:
-
I am a fairly happy SVN user.
Why is GIT a big deal for Altium users? I mean, what are the headline feature improvements?
Is it the local commits when away from the main GIT server?
I use Git with altium projects already, it's so much nicer than SVN for me, and because I also use it for firmware, python, and all sorts of other things it means I need just one repo tool to understand and maintain and use.... though a lot of the advantages are lost on not exactly text files like altium schematics and PCB files...
I am happy to see AD will support GIT from inside the program, but to be honest I've been using it for so long from the commandline and windows shell integration tools, I don't need it in Altium.
And yeah... I think everyone is going to be running 17 alongside 18 for quite a while... unless altium pulls something amazing out of their hat and somehow AD18 is more or less feature complete, and bug-free... that would be an even better uprise than AD18! Even then we'll need them side by side as we get our heads around where all the commands and hotkeys are for AD18...
-
I am a fairly happy SVN user.
Why is GIT a big deal for Altium users? I mean, what are the headline feature improvements?
Is it the local commits when away from the main GIT server?
For me, it's support from third party cloud services. The one I prefer to use doesn't support SVN. A move to GIT should allow me to just plug into the existing service to have an integrated off-site backup of data.
-
I am a fairly happy SVN user.
Why is GIT a big deal for Altium users? I mean, what are the headline feature improvements?
Is it the local commits when away from the main GIT server?
It's more about what your organization uses.
At the end of the day, they both do the same thing. They store your updated files in one location. With git, everything is in the cloud. With SVN, you usually have to go to someone's server and upload or download from there. That being said, there are cloud SVN servers as well.
From using both (and this is just from my experience at different organizations, so your experience may differ), SVN encourages 1 local copy and committing changes when you are done. Git encourages you to make branches. At the end, you could have 5 different branches and you commit to that branch as you please. This works well for software. You can do the same thing in SVN, but it is discouraged (not sure why).
With Git, things do not get committed to the main branch unless you have approval (at least that is how it was done with my stuff). With SVN, you can commit as long as the file is not locked in away, so it requires an admin.
With Altium, you can use it with git, it is just not integrated. I use SVN with Altium, but I do not use what is integrated in Altium itself (does not play well with our SVN server). So in reality, I think the integration is only a big deal if you want to be integrated with Altium Vault as well, but even then, there are probably ways around it.
-
With SVN I only work in trunk for trivial changes otherwise branch.
You say SVN branching is discouraged, I'm not sure about that but maybe in very large projects branching is expensive and discouraged. GIT is likely more efficient in that respect.
IIRC GitHub can be used with SVN clients.
Thanks for your thoughts.
-
Really hoping this doesn't turn into a git vs SVN thread.
Oops, too late... :horse:
-
Wise up. I'm not bashing GIT at all, never used it, just curious what the features are that might make me switch.
-
complete rewrite in c#
mulit board design even checks connectivity accross the connectors. highlight a trace on one board and it highlights on the connected boards ....
May I ask you where the information comes from ? Because this is f* awesome. AD code needs clean-up like hell.
.... I was amazed when seeing DXP20xx and Altium Designer folders in my PC when I installed the Circuit Maker... That code must be a complete mess and my silly assumption drives me OCD crazy.
-
It's more about what your organization uses.
At the end of the day, they both do the same thing. They store your updated files in one location. With git, everything is in the cloud. With SVN, you usually have to go to someone's server and upload or download from there. That being said, there are cloud SVN servers as well.
With GIT you can absolutely host your own "remote" server (local office network, internet, wherever) you don't have to use github and bitbucket for your remote. You can just install a package that goes onto a linux server. (probably windows too? no idea)
Also there are cloud SVN hosts out there. I've used this before... https://www.assembla.com/subversion (https://www.assembla.com/subversion)
The fundamental difference is that GIT always has 2 repository levels. local and remote. While SVN just has 1 repository that everyone in the project uses, and they check out specific versions of files in specific parts of the repo to work on... With GIT, you local repo is the thing you work on (ie commit changes to) and it contains your ENTIRE remote repository. Then you regularly push your local repo up to the the remote repo which gives you your off-computer backup so you're not hanging everything off a single disk drive on your laptop.
This fundamental difference means that if something critical happens to your master GIT repo you will have multiple copies of it in multiple other places to recover from.... SVN gives you one single master repo and people are always needing to connect to that, wherever they are, in order to have configuration management of what they are working on. And if that master repo is destroyed with no backup, you are in very deep very sticky poo.
This also enables all sorts of workflows and arrangements of your repository system..
here's a good writeup of what sorts of workflows you can have when using GIT.
https://www.atlassian.com/git/tutorials/comparing-workflows (https://www.atlassian.com/git/tutorials/comparing-workflows)
I like gitflow and forking workflows for firmware and software, but it depends on how your team is arranged. gitflow still needs everyone to use the same repo all the time, and have some understanding of what everyone else is doing. Forking needs someone to be the master who is responsible for importing and checking all the different changes from everyone else's remote repos when asked.
Apparently the Linux kernel project is run with a massive hierarchical forking workflow. It has chains of people with responsibility for different aspects at different levels, all responsible for merging any changes below them and propagating changes up the chain when their responsibility is taken care of.
From using both (and this is just from my experience at different organizations, so your experience may differ), SVN encourages 1 local copy and committing changes when you are done. Git encourages you to make branches. At the end, you could have 5 different branches and you commit to that branch as you please. This works well for software. You can do the same thing in SVN, but it is discouraged (not sure why).
git branches are completely invisible to the file system. you have your working copy that your software tools see, and that's it... you navigate branches in GIT itself. you pull out the one you want to see, merge with the other one you want to merge with, put that merged branch back, then pull out another branch to work with...
my understanding of SVN branches is it's entirely on the user to make and manage them inside the SVN working folder structure - ie, you make parallel folder structures for branches and operate on whatever folder branch you need.
As a result git branches require a bit of automation to make them manageable... so they work well with things like source code, that are well structured text. Where if there's an edit collision (ie 2 different edits of the same thing in 2 different branches you want to merge) you can visually diff them and make a decision about what the merged version of the branches needs to be to work.
With something like a PCB file (even one in ASCII!) looking at that diff in a text editor will make no sense at all. so you really should be very careful to use branches in GIT for Altium projects - unless you love pain.... (or want to see if altium's built in visual file diff will work well enough to save you)
A limited version of the "feature branch" in the git workflows link above could work.... have a single release branch, then whenever you want to do any work, you start an "under change" branch, where you can go mad and commit changes all day long, push them to the remote whenever you feel like it... Then when you have finished all changes and checked all your release checkboxes, and want to do another release the "under change" branch basically merges in over the top of the (completely untouched since branching happened!) release branch and replaces all the release branch file states with its exact states. no file level merging needed..)
Meanwhile, anyone needing the last release version of a project even while you are actively developing the next version knows just where to get it... clone the remote repo, checkout the master branch. done. (most probably though, if it's a released version of the project they need, they should be looking for RELEASE FILES in a PRODUCTION RELEASE FOLDER, not design files in a design repository but that's another 5 page rant for another time...)
With Altium, you can use it with git, it is just not integrated. I use SVN with Altium, but I do not use what is integrated in Altium itself (does not play well with our SVN server). So in reality, I think the integration is only a big deal if you want to be integrated with Altium Vault as well, but even then, there are probably ways around it.
Yep! I'm keen to see exactly what altium does with GIT and how it's implemented as at a low level the GIT model is fundamentally different to SVN and vaults capabilities. If it works for me, I'll probably use it, but if it's too simplified or is going to clash with how I like to to my repos, I'll just stick with commandline git. Even built for purpose GUI tools like sourcetree can make a big ugly mess in the name of providing abstractions to simplify your git workflow for you.
-
complete rewrite in c#
mulit board design even checks connectivity accross the connectors. highlight a trace on one board and it highlights on the connected boards ....
May I ask you where the information comes from ?
From the altium PCB2020 roadshow. They showed the tool. talked extensively about it and let us play with it.
Code is also optimised for extensive GPU acceleration. The realtime 3d viewer is photorealistic now. And you don't need a quadro (although a 975 or a Pascal is heavily suggested )
-
I can confirm, talked with an Altium sales.
Who will tell you whatever they think you want to hear.