Yes I have done so several times. 2 layer and 4 layer.
I can't see how it would cost me money to do so, on the other hand if I was to blindly autoroute my designs i'd spend more time troubleshooting and way more money doing several revisions before I got something stable.
What problems would you expect to find when blindly autorouting? I have to admit, I've only used two auto-routers in my life. Both were in Altium CircuitMaker. The first one was flawless, the second one was unusable. So maybe yours is more on the unusable end?
I think an autorouter does come in handy, but not if you use it blindly. How well it does is as you would expect of any other tool that operates without complete information.
It can't trivially tell which areas of your board you have intended for analog signals, or where high speed things are. When you autoroute a 2 layer board (in particular) if you don't drop vias next to ground pins it goes nuts trying to connect ground pins with a ground pour constantly changing. It tries to keep traces as close as possible to edges where a human would really just give it "breathing room". If you want to make a prototype that can be reworked, you need to be super careful (you always do, but it's easier to miss a lack of accessibility if it's automatic). It orients traces in ways that are in accordance with a score metric rather than geometric elegance, legibility, or crosstalk because it doesn't know what signals are where.
None of these are unsolvable, but they are the kinds of problems I expect when I use it. That said, if I have 1000 traces to route I will do 970 of them manually and be grateful for the autorouter doing the last 30 that would take me a half day to figure out a clean path for.
The problem comes when people think an autorouter is a computer program written by people who know about their PCB and that the results will approximate an expert doing an okay job. Then they realize that's not the case and decide the autorouter cannot do a decent job ever. Much later they realize that if they actually learn how the autorouter works they can use it as a tool to do... what the autorouter is programmed to do. But it can't read the designer's mind.
I should probably clarify that I mean to say that the reason I think there is so much disagreement here is that the autorouter is an advanced feature, and using it as a wizard to make your PCB work is very unlikely to work out well.
In the future I certainly hope that the integration of ECAD and Spice works transparently, I think it's closer every year.
I also hope that EMI simulations of PCBs become straightforward as well. I think if Spice worked, that would be a pretty clear second step and it would be a gamechanger.
As soon as the autorouter is aware of all of these constraints and is trying to keep signals that you manually specify to constraints you specify (say, from spice or from you reading the datasheet -- or an language system trying its best I guess, I've had terrible luck extracting data from datasheets).
That would be genuinely game changing. You could tell the autorouter not just "go diagonal or add 4 points" or "a via costs 3 points" or "stay away from this area" but instead "keep EMI spread spectrum and give me a spectrum for the noise as measured in a solid surface one meter away" so that you can actually simulate your FCC test. And make the autorouter minimize the spikes with filters of various kinds. And since Spice might know how fast you are operating different traces, and knows rise-fall times, the autorouter can simulate how much cross talk there is.
None of this puts the designer off the hook, it just changes the nature of the work. For more than a trivial board I think it's unlikely a human could do better than an EMI aware autorouter with Spice level knowledge of what every single net is doing -- and on top of that knows all about the capacitance between planes...
Basically, I see this as a huge opportunity for growth, and dismissing autorouting out of hand is something a senior professional might well do because autorouters have sucked for so long. They may continue to suck, if you don't use them like algorithms and instead pretend they are an expert. But I see a heck of a lot of people trying very hard to create an EMI and Spice aware ECAD system, even KiCAD has Spice integrated (albeit I have no clue how to use it). Eagle does too, so Autodesk will.
I assume Altium has Spice and I sure hope it has EMI since what else is the thousand dollars per year per head for... Okay, no, I know their parts management system is second to none I've ever seen, god I wish I could specify alternate parts and automatically generate BOMs based on alibaba real-time availability in KiCAD. But again... soon.
In any case, kudos to this project either way. I will never, ever use a proprietary PCB tool again in my life, I still struggle to get OrCAD 16.2 running and regret learning Eagle instead of just jumping to KiCAD and recognizing that nothing that can be bought will stay available.
It is too much to ask someone who does professional PCB designs to change tools for reasons that only are about the business that makes the tools. It's just a waste of so much billable productivity... that I don't want to do. KiCAD will hopefully be my last, I've learned my lesson.
That said... I am still trying to understand how this is better for a beginner than KiCAD, which does have an autorouter, has a pile of paired extremely useful tools (calculator, geber viewer, image importer), a pile of excellent add-ins, an excellent footprint library (I've rarely had to manually do it), a shockingly complete symbol library, a 3D viewer that I can use to check footprints against manually downloaded packages, excellent DRC, and for little things it can round traces and make teardrops which is just aesthetically pretty compared to sharp corners.
For a retrocomputing project, you can likely do analog as a separate board. And it's trivial to route power and ground lines by hand (excluding them from the autorouter with a rule). You don't even need power planes at the low speeds used by old computers! But, the hard part is optimally routing 100+ signal lines between chips. You can do it by hand, but it's just drudge work.
I was excited for this because I thought it'd enable me to compile my HDL projects on my MacBook, since I'm targeting the Xilinx XC9500XL series of CPLDs this requires some an EOL design suite.
Anyway, build times are:
4 minutes with Rosetta 2
11 minutes with qemu-user-static
Whereas it only takes 20 seconds on my early 2013 MacBook Pro.
I think it would also be nice if it were possible to use this with other hypervisors. I believe it is limited to virtualization.framework so it cannot be used inside fusion for instance
Rosetta is not limited to virtualization.framework. You can easily extract rosetta binaries and emulate stuff using qemu that Apple emulates if rosetta even checks something. I'm not sure if it would be legal, but technically it should not be a big issue. Apple just made it very easy with virtualization.framework.
Possibly dumb question - while running are you able to inspect the page mappings? If they’re doing runtime codegen (from the Rosetta pov that’s a jit no matter what), alternatively see if it appears heavy on x87.
The former means you lose a lot of the AOT benefits and caching in Rosetta, the latter is due to Rosetta implementing x87 precisely - so a ton of software floating point.
These are the two things that to me would be most likely to cause that degree of penalty.
Lockdown means that it is literally illegal to make that drive to the coastline right now, and it will continue to be for the foreseeable future. The only people who get to enjoy being in "one of the most beautiful places in the world full of sunshine, sea and sand" during lockdown are a few incredibly wealthy folks living in expensive homes in expensive regions of the country. The comment you're replying to is exactly right.
Half an hour drive ≠ 5km lockdown restrictions. Your condescending tone is typical of Australia's managerial class, completely disconnected from the realities most locked down Australians are facing.
Have a moment to ponder the existence of immigrant small business owners facing bankruptcy in Parramatta, the furloughed truckies in Blacktown, the working class kids in overcrowded government housing in Penrith.
At a previous job we used beaker tests as part of our pipeline to test puppet modules & environments before we would merge to prod. One of the things this tests is that the module applies and doesn't try to change anything / error out on subsequent runs.
The documentation sucks though imo, every different guide you find will show a completely different way of doing it
For me it's fun being able to play around/make hardware for a system that is still simple enough for one to understand broadly how the whole thing works.
The schematics are available for them & they're documented really well
People still make software & games for it for presumably the same reason, then there's people who are into it for the nostalgia and the games.
