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

From F-Si wiki
Jump to: navigation, 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...")
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
  
 
* 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
disciplined team and tight configuration control via cds.lib to avoid
+
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.
utter chaos. And it's hard to believe that in a modern system data is
+
* There are some more technical nuissances, like instance magnification, which got dropped from OA layout views. PCells are no longer available in public OA (?)
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 43: Line 19:
  
 
* 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
+
   by "package update" rather than changing the source and instantly get a new version)
  a new version)
+
* Enhanced support for configuration management  
* Enhanced support for configuration management
+
** Merge support
  * Merge support
+
** Diff support
  * Diff support
+
** Should be possible simply using git or svn (i.e. no "vanishing" or "appearing" files)
  * 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.

Revision as of 20:16, 14 February 2020

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.

  • 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.