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

From F-Si wiki
Jump to: navigation, search
(Why an alternative to the Open Access (OA) database is needed (personal view))
 
Line 1: Line 1:
== Why an alternative to the Open Access (OA) database is needed (personal view) ==
+
== Why an alternative to the [https://en.wikipedia.org/wiki/OpenAccess#OpenAccess_software OpenAccess] (OA) database is needed (personal view) ==
 +
 
 +
For a background about OpenAccess, see [https://en.wikipedia.org/wiki/OpenAccess#OpenAccess_software Wikipedia].
  
 
NOTE: my view is mainly based on the OpenAccess packaged with 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.

Latest revision as of 20: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.