Difference between revisions of "Need for a free alternative to OpenAccess (by Matthias)"

From F-Si wiki
Jump to navigation Jump to search
(Created page with "== Why An Open Access Alternative (personal view) == NOTE: my view is mainly based on the OpenAccess packaged with Virtuoso. I'm not Si2 member, so I cannot see their sources...")
 
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Why An Open Access Alternative (personal view) ==
== Why an alternative to the [https://en.wikipedia.org/wiki/OpenAccess#OpenAccess_software OpenAccess] (OA) database is needed (personal view) ==


NOTE: my view is mainly based on the OpenAccess packaged with
For a background about OpenAccess, see [https://en.wikipedia.org/wiki/OpenAccess#OpenAccess_software Wikipedia].
Virtuoso. I'm not Si2 member, so I cannot see their sources.
 
NOTE: my view is mainly based on the OpenAccess packaged with Virtuoso. I'm not Si2 member, so I cannot see their sources.


* OA is mainly a data container, not an algorithmic database
* OA is mainly a data container, not an algorithmic database
* OA is not Open, you need to be Si2 member to get
* OA is not Open, you need to be Si2 member to get access to the sources. I have some doubt that legally it's correct to publish source code as GPL when it can only be built using headers from non-permissive licenses. Apart from violating the basic idea that open source should be available to everyone.
access to the sources. I have some doubt that legally it's correct
* OA is Cadence dominated and I don't see that OpenAccess fosters tool interoperability. OA is like a cage that is set up by Cadence. For example, I don't see a real netlist API - the one OpenAccess offers is for schematic, not netlist. I think this is the reason why the modified OA - once it got a threat to their product lines, they crippled it.
to publish source code as GPL when it can only be built using headers
* Limited flexibility: you cannot plug in your algorithms or own data structures. But IMHO that's a basic requirement for a modern flow (see first point). And text views are a very weak way to deal with this.
from non-permissive licenses. Apart from violating the basic idea that
* Configuration management through git or svn is virtually impossible, as files and folders are created and removed dynamically on the fly. The only chance is to integrate configuration management through their API.
open source should be available to everyone.
* OA is Cadence dominated and I don't see that OpenAccess fosters tool
interoperability. OA is like a cage that is set up by Cadence. For
example, I don't see a real netlist API - the one OpenAccess offers is
for schematic, not netlist. I think this is the reason why the modified
OA - once it got a threat to their product lines, they crippled it.
* Limited flexibility: you cannot plug in your algorithms or own data
structures. But IMHO that's a basic requirement for a modern flow (see
first point). And text views are a very weak way to deal with this.
* Configuration management through git or svn is virtually impossible,
as files and folders are created and removed dynamically on the fly. The
only chance is to integrate configuration management through their API.
Good for vendors, but bad for open source.
Good for vendors, but bad for open source.
* The library management drives me crazy. You really need a very
* The library management drives me crazy. You really need a very disciplined team and tight configuration control via cds.lib to avoid utter chaos. And it's hard to believe that in a modern system data is soft-linked. In my case, the project was very complex, because it is a technology development tapeout with pre-release versions of PCell libraries and cross-technology links and more than ten contributing teams ... maintaining control under such conditions is a nightmare. Our only chance to freeze a layout is to stream out. But this will make you loose the PCell information. I wish that libraries need to be pulled actively into a project rather than instantly becoming active .. with the effect of getting PCell evaluation errors when they changed their PCell code in an incompatible way. And no way back.
disciplined team and tight configuration control via cds.lib to avoid
* There are some more technical nuissances, like instance magnification, which got dropped from OA layout views. PCells are no longer available in public OA (?)
utter chaos. And it's hard to believe that in a modern system data is
soft-linked. In my case, the project was very complex, because it is a
technology development tapeout with pre-release versions of PCell
libraries and cross-technology links and more than ten contributing
teams ... maintaining control under such conditions is a nightmare. Our
only chance to freeze a layout is to stream out. But this will make you
loose the PCell information. I wish that libraries need to be pulled
actively into a project rather than instantly becoming active .. with
the effect of getting PCell evaluation errors when they changed their
PCell code in an incompatible way. And no way back.
* There are some more technical nuissances, like instance magnification,
which got dropped from OA layout views. PCells are no longer available
in public OA (?)


== Cornerstones of an OA alternative (suggestion) ==
== Cornerstones of an OA alternative (suggestion) ==
Line 42: Line 18:
Keywords: reproducibility, extensibility, sustainability
Keywords: reproducibility, extensibility, sustainability


* Library concept reviewed: "package management" rather than "soft links" (i.e. pull in a library  
* Library concept reviewed: "package management" rather than "soft links" (i.e. pull in a library by "package update" rather than changing the source and instantly get a new version)
  by "package update" rather than changing the source and instantly get
* Enhanced support for configuration management  
  a new version)
** Merge support
* Enhanced support for configuration management
** Diff support
  * Merge support
** Should be possible simply using git or svn (i.e. no "vanishing" or "appearing" files)
  * Diff support
  * Should be possible simply using git or svn (i.e. no "vanishing" or "appearing" files)
* Extensible
* Extensible
  * New views can be plugged in and are not part of the "one and only" specification
** New views can be plugged in and are not part of the "one and only" specification
  * Each view type comes with meta information and an API ("model driven" approach)
** Each view type comes with meta information and an API ("model driven" approach)
  * Glue/application language shall not be confined to scripting as high-performance
** Glue/application language shall not be confined to scripting as high-performance alternatives emerge (Go, Rust, ...) -> Q: is there a generic, binary-level infrastructure similar to COM on Linux?
    alternatives emerge (Go, Rust, ...) -> Q: is there a generic, binary-level infrastructure similar to COM on Linux?
** View specs need to be versioned, migration between versions shall be supported automatically
  * View specs need to be versioned, migration between versions shall be supported automatically
* Flow as a chain of "view transformations" or "view creation steps":
* Flow as a chain of "view transformations" or "view creation steps":
  * Each tool consumes input views and generates output views.  
** Each tool consumes input views and generates output views.  
  * Editors: only generate/update views, Consumers: only take views
** Editors: only generate/update views, Consumers: only take views
  * Views keep a timestamp or generation ID (-> "make like" flows can be built)
** Views keep a timestamp or generation ID (-> "make like" flows can be built)
  * The flow controller shall be an integral part of the framework (-> EDA tools have to register in the system)
** The flow controller shall be an integral part of the framework (-> EDA tools have to register in the system)
  * The flow step configuration data (run specific scripts etc.) shall be part of the file set.
** The flow step configuration data (run specific scripts etc.) shall be part of the file set.

Latest revision as of 21:23, 14 February 2020

Why an alternative to the OpenAccess (OA) database is needed (personal view)

For a background about OpenAccess, see Wikipedia.

NOTE: my view is mainly based on the OpenAccess packaged with Virtuoso. I'm not Si2 member, so I cannot see their sources.

  • OA is mainly a data container, not an algorithmic database
  • OA is not Open, you need to be Si2 member to get access to the sources. I have some doubt that legally it's correct to publish source code as GPL when it can only be built using headers from non-permissive licenses. Apart from violating the basic idea that open source should be available to everyone.
  • OA is Cadence dominated and I don't see that OpenAccess fosters tool interoperability. OA is like a cage that is set up by Cadence. For example, I don't see a real netlist API - the one OpenAccess offers is for schematic, not netlist. I think this is the reason why the modified OA - once it got a threat to their product lines, they crippled it.
  • Limited flexibility: you cannot plug in your algorithms or own data structures. But IMHO that's a basic requirement for a modern flow (see first point). And text views are a very weak way to deal with this.
  • Configuration management through git or svn is virtually impossible, as files and folders are created and removed dynamically on the fly. The only chance is to integrate configuration management through their API.

Good for vendors, but bad for open source.

  • The library management drives me crazy. You really need a very disciplined team and tight configuration control via cds.lib to avoid utter chaos. And it's hard to believe that in a modern system data is soft-linked. In my case, the project was very complex, because it is a technology development tapeout with pre-release versions of PCell libraries and cross-technology links and more than ten contributing teams ... maintaining control under such conditions is a nightmare. Our only chance to freeze a layout is to stream out. But this will make you loose the PCell information. I wish that libraries need to be pulled actively into a project rather than instantly becoming active .. with the effect of getting PCell evaluation errors when they changed their PCell code in an incompatible way. And no way back.
  • There are some more technical nuissances, like instance magnification, which got dropped from OA layout views. PCells are no longer available in public OA (?)

Cornerstones of an OA alternative (suggestion)

Keywords: reproducibility, extensibility, sustainability

  • Library concept reviewed: "package management" rather than "soft links" (i.e. pull in a library by "package update" rather than changing the source and instantly get a new version)
  • Enhanced support for configuration management
    • Merge support
    • Diff support
    • Should be possible simply using git or svn (i.e. no "vanishing" or "appearing" files)
  • Extensible
    • New views can be plugged in and are not part of the "one and only" specification
    • Each view type comes with meta information and an API ("model driven" approach)
    • Glue/application language shall not be confined to scripting as high-performance alternatives emerge (Go, Rust, ...) -> Q: is there a generic, binary-level infrastructure similar to COM on Linux?
    • View specs need to be versioned, migration between versions shall be supported automatically
  • Flow as a chain of "view transformations" or "view creation steps":
    • Each tool consumes input views and generates output views.
    • Editors: only generate/update views, Consumers: only take views
    • Views keep a timestamp or generation ID (-> "make like" flows can be built)
    • The flow controller shall be an integral part of the framework (-> EDA tools have to register in the system)
    • The flow step configuration data (run specific scripts etc.) shall be part of the file set.