Author Topic: OpenROAD project  (Read 2257 times)

0 Members and 1 Guest are viewing this topic.

Offline donotdespisethesnakeTopic starter

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
OpenROAD project
« on: December 31, 2019, 10:52:51 am »
The guys and gals over at https://theopenroadproject.org/ wish to "develop open-source tools that achieve autonomous, 24-hour layout implementation."

Quote
About OpenROAD

Problem: Hardware design requires too much effort, cost and time.

Challenge: $$$ costs and “expertise gap” block system designers’ access to advanced technology.

Objective: We want to enable no-humans, 24-hour design and catalyze open source EDA.

I'm not entirely convinced of the initial problem statement, it may be more a case of "DARPA and others are handing out money, so we'll take it. However, I'm very skeptical that they could get anywhere near their goals. One example quoted is:

Quote
We are working on a (for now) standalone placer, router, DRC checker (for advanced constraints), and a decompactor. The idea is to be able to autoplace and autoroute a BeagleBone Black type design ... This means 6+ layers, BGA microprocessor, DDR3L memory, USB, HDMI, eMMC, and so on.

Is that anywhere near possible in the next year or two? Is it really just a way of spending research dollars?
Bob
"All you said is just a bunch of opinions."
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 9758
  • Country: gb
Re: OpenROAD project
« Reply #1 on: December 31, 2019, 11:34:15 am »
The problem statement seems reasonable. The goals seem ambitious, but reasonable. However, staffing these things with PhD students is generally a route to failure. The moment someone tells them they have been awarded their PhD they tend to run away without effectively handing over their work for someone else to continue it effectively.
 
The following users thanked this post: Ysjoelfir

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4702
  • Country: au
  • Question Everything... Except This Statement
Re: OpenROAD project
« Reply #2 on: December 31, 2019, 11:52:51 am »
It is possible, however I suspect it would take a the average desktop weeks of computing time, (so they are likely hoping to throw a server farm at the problem), 200 computers generate the next iteration, best one is chosen, repeat,

Travelling salesman problems have been mostly solved, this issue is that layout has other freedoms and constaints that make it more computationally expensive,

Placing is often the harder part of layout,
 

Offline awallin

  • Frequent Contributor
  • **
  • Posts: 694
Re: OpenROAD project
« Reply #3 on: December 31, 2019, 12:40:31 pm »
some work with kicad auto-placement/routing apparently underway: https://forum.kicad.info/t/advanced-constraints-syntax-for-kicad-and-openroad/20468
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11806
  • Country: us
    • Personal site
Re: OpenROAD project
« Reply #4 on: December 31, 2019, 06:21:31 pm »
A typical issue that comes up with auto-placers is that specifying all the constants takes more time than placing thing by hand, even if you need a couple attempts. There needs to be a flexible constraint system where a human places parts approximately and the placer is forced to maintain relative layout, but is free to jiggle things around.

Specifying decoupling capacitors is another huge issue. They are easily the most numerous part on modern designs and require intelligent placement.

I'm not sure this is doable in this short of a time. And I'm also not convinced that this is really necessary. It is a cool research problem, but I'm not convinced that this is a real industry problem.

Better auto-routers would be more useful.
Alex
 
The following users thanked this post: nctnico, Jacon

Offline donotdespisethesnakeTopic starter

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: OpenROAD project
« Reply #5 on: January 01, 2020, 10:18:48 am »
It reminds me of the software product that claimed to be "the last program ever written" because it would generate code for you from requirements spec. That was 30 years ago... turned out real world was not so easy.

In this case, there is still a lot of skill required to create a netlist, and set up the constraints. Then you really need to check the layout before making boards. At our place, the design or manufacturing engineer can go to the layout team and discuss layout issues. For the AI to be useful, it needs to explain its decisions.

I can sort of see a use case where you might want to customise a fairly standard Linux module for different configurations. You still need all the design, qualification and software implementation though.
Bob
"All you said is just a bunch of opinions."
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4702
  • Country: au
  • Question Everything... Except This Statement
Re: OpenROAD project
« Reply #6 on: January 01, 2020, 10:58:40 am »
What I imagine would be a nice midway step, a practical and usable stating point would be a DDR memory autorouter, a person places the chips initial position, taking consideration of length matching, and impedance autoroute that in under an hour

From there, look at the trace length mismatches and see if skewing the chip 0.1mm up down left or right would reduce the complexity of the length matching, do minor edits and compare, and iterate from there,

It is not as audacious as what they are promising, but its a generally very well defined problem that allows for a large amount of pin swapping to simplify the challenge,
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 28253
  • Country: nl
    • NCT Developments
Re: OpenROAD project
« Reply #7 on: January 01, 2020, 06:37:43 pm »
What I imagine would be a nice midway step, a practical and usable stating point would be a DDR memory autorouter, a person places the chips initial position, taking consideration of length matching, and impedance autoroute that in under an hour

From there, look at the trace length mismatches and see if skewing the chip 0.1mm up down left or right would reduce the complexity of the length matching, do minor edits and compare, and iterate from there,

It is not as audacious as what they are promising, but its a generally very well defined problem that allows for a large amount of pin swapping to simplify the challenge,
I would imagine a modern autorouter should be able to do that. It is actually something I want to try with Orcad's Allegro and see if it can do better than me. The layer setup for DDR routing is pretty much fixed anyway so it is a nicely constrained problem.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15593
  • Country: fr
Re: OpenROAD project
« Reply #8 on: January 01, 2020, 06:43:25 pm »
In other words, tools should remain tools. Useful helpers, not fully-automated stuff that will keep eluding us for a long time.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4702
  • Country: au
  • Question Everything... Except This Statement
Re: OpenROAD project
« Reply #9 on: January 02, 2020, 12:44:47 am »
More of a minimum time implementation, the more to be autorouted, and the more complex it has to be specified the more time is wasted with revision, so by making well understood time consuming parts automated, it should reduce the total time by the largest amount.
 

Offline excitedbox

  • Regular Contributor
  • *
  • Posts: 104
  • Country: de
Re: OpenROAD project
« Reply #10 on: January 11, 2020, 11:35:14 pm »
Look at Jitx. They are doing the same thing and their demo does pretty well on simple stuff. They were going to publish their software but now it seems it will be offered as a pcb design service.
https://www.jitx.com/


I am working on something similar as a programing exercise and quickly realized how hard the problem really is. After reading a lot of research papers and discussing with people on the forum I came to a solution that could simplify the process a lot but will still need a lot of processing power.

You take a users input and convert it to a net list. Then using pattern recognition the Ai needs to compare to netlists of training circuits that serve as examples. For instance a switch mode power supply. When the Ai says this matches a SMPS to 80% it decides ok that must be what is being built here. Then the AI tries to figure out what is needed to make the user input look more like the netlist of the examples it has while maintaining the same current levels, voltage levels, etc. of the parts that the user has placed or are defined by some set of rules.


Pattern matching -> Subtracting the match from the input to see what is missing -> Convolution Network to find the right components to match the design rules.

This requires a lot of computational power though but I found a research Paper about Evolution Algorithms where from each round of tries they keep the best matches and throw out the worst. Their Result was almost as good as an expert architect at designing an opamp chip and reduced the number of tries from over 77k run throughs to 435.

https://bair.berkeley.edu/blog/2019/09/26/circuits/



So far I am still at the very basic concept stage since I only started 2 weeks ago. I made my own little input language and a parts db system for the Ai to get the component specs from. The next step is converting user input to a netlist. Then I will start writing the AI part using some framework to do the pattern matching. On the kicad forum there as a project to parse component datasheets to generate a parts library which I want to use to fill the parts database.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf