231–240 of 268 posts
I just got back from the Design Automation Conference in San Francisco. It is one of the major EDA conferences. Andreas Olofsson gave a talk about the silicon compiler. There was serious discussion about open source EDA. As far as I could tell it is still unclear what the role of academia will be. It seems tricky to align academic incentives with the implementation, and most importantly, maintenance of an open source…
A great blog post here ( https://wp.josh.com/2017/10/23/adventures-in-autorouting/ ) about some different auto-routing software.
Placement and Routing together is generally the domain of the very-expensive EDA tools inferred in the main article.
I just got back from the Design Automation Conference in San Francisco. It is one of the major EDA conferences. Andreas Olofsson gave a talk about the silicon compiler. There was serious discussion about open source EDA. As far as I could tell it is still unclear what the role of academia will be. It seems tricky to align academic incentives with the implementation, and most importantly, maintenance of an open source…
Do you have a link to WOSET? Googling doesn't turn up anything.
Earlier quoted context omitted.
Any tips on getting started with FPGA on custom pcbs?
What exactly do you mean by "getting started with FPGA on custom PCBs?" Have you made custom PCBs with high density BGAs before? Most non-trivial FPGAs (to me that means you can easily fit a decent softcore processor with space left over for your FPGA logic) will be ball grid arrays and almost impossible to DIY without xray inspection equipment and a reflow oven. You can get what you need for a few hundred $ on eBay…
Have you ever considered a DIY youtube channel?
If you, @slededit, others on this thread did something like Louis Rossmann, that'd be fantastic. I've never even seen a dentist's x-ray machine, much less seen it used for DIY design. That'd be amazing to watch.
Louis Rossmann https://www.youtube.com/channel/UCl2mFZoRqjw_ELax4Yisf6w
(But maybe y'all would dial down the rhetoric from an 11 to a 8 or 9.)
Earlier quoted context omitted.
It's really godawful. Software guys have no idea how good they have it. You have layers upon layers of closed source EDA tools and home-brew scripts, all built around horribly abysmal "standards" like SystemVerilog, mostly cobbled together in TCL and Perl. For instance, the following sounds like a horrible joke, but it is real. In a real life, world-class company, port connections between modules are handled using a…
So true. I used to manage a design verification business that made very good money consulting for companies' in-house design groups. Most of what we did was write Tcl and Perl scripts to glue together tools. Our mojo was that we had seen so many examples of design flows that had terrible tool integration and had to be fixed with one-off scripts, and as a result had built up a large library of scripts that could be be…
Working IT (aka DevOps, continuous tech support), it's just cutting & pasting strings. Maybe some data quality stuff.
Gods I miss product development. Actual design & programming.
Earlier quoted context omitted.
There are many NP complete problems where computer do vastly better than humans. But when it comes to EDA, the utterly closed-source culture of the industry has completely prevented what essentially amounts to a horde of smart people to work on the problem: no one - except a very small number insiders - even know what the problems are.
It's really godawful. Software guys have no idea how good they have it. You have layers upon layers of closed source EDA tools and home-brew scripts, all built around horribly abysmal "standards" like SystemVerilog, mostly cobbled together in TCL and Perl. For instance, the following sounds like a horrible joke, but it is real. In a real life, world-class company, port connections between modules are handled using a…
Earlier quoted context omitted.
There are many NP complete problems where computer do vastly better than humans. But when it comes to EDA, the utterly closed-source culture of the industry has completely prevented what essentially amounts to a horde of smart people to work on the problem: no one - except a very small number insiders - even know what the problems are.
It's really godawful. Software guys have no idea how good they have it. You have layers upon layers of closed source EDA tools and home-brew scripts, all built around horribly abysmal "standards" like SystemVerilog, mostly cobbled together in TCL and Perl. For instance, the following sounds like a horrible joke, but it is real. In a real life, world-class company, port connections between modules are handled using a…
You can also look at it from the other perspective: at least you can still make money making hardware tooling. That is not possible for software tooling, as everything is open-source already.
Earlier quoted context omitted.
Thanks very much for the kind words! Perhaps you can ask the professor for who has the copyright on ABEL now? So we can ask the holder if it can be open sourced. Miracles like this do happen - last year Symantec allowed the Symantec C++ compiler to be fully open sourced!
Walter - appears Xilinx are the current copyright holder and ABEL was last supported in the XILINX 10.1 ISE toolset released circa 2008 (Current release is 14.7). Introductory guide can still be found here: https://bit.ly/2NfkLWq
https://www.xilinx.com/support/documentation/sw_manuals/xili...
Earlier quoted context omitted.
Google has that luxury because they make their money on ads. If their primary source of revenue was selling a database product (like say oracle) then there may have been a different decision made there.
Not to mention the "commoditized complement" approach, e.g. https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ That's probably what's lacking here, anyone with anything to gain by opening up all the bemoaned goodies. Is that Darpa's role?
Earlier quoted context omitted.
It's really godawful. Software guys have no idea how good they have it. You have layers upon layers of closed source EDA tools and home-brew scripts, all built around horribly abysmal "standards" like SystemVerilog, mostly cobbled together in TCL and Perl. For instance, the following sounds like a horrible joke, but it is real. In a real life, world-class company, port connections between modules are handled using a…
> It's really godawful. Software guys have no idea how good they have it. You can also look at it from the other perspective: at least you can still make money making hardware tooling. That is not possible for software tooling, as everything is open-source already.
You have a very distorted view of OpenSource. People working on OpenSource related project do make money. And lots of it. They're just not selling what essentially amounts to obfuscated source code, a way of doing business that is apparently a great source of astonishment for HW folks.
The other point is the state of hardware tooling. Tool vendors may be making money, but their customers are getting shafted something fierce.
Every single EDA tool I've used feels like it was written in the 80's: slow, bulky, bloated, opaque, complicated, unpredictable behavior, need band-aids all over the place to get it to do what you actually need (Tcl anyone?)
The typical byproduct of an industry focused on secrets instead of innovation.