Development Philosophy

Philosophy

Hammer's design is centred around three major ideas:

  1. Incremental adoption. The main goal of our users is chip implementation, with tool development as a secondary focus. Therefore, our solution should make it easy to leverage existing, re-usable features that accelerate chip implementation while still allowing creation of non-reusable solutions as needed to complete specific tasks.
  2. System evolution. Non-reusable solutions do not directly lead to re-usable features. We therefore prioritize tool developers, who serve a key role in generalizing non-reusable solutions for future users. For them, tool development is the main goal with chip implementation as a secondary focus.
  3. Modularity and abstraction. Realizing the two above goals requires a mechanism and method. Therefore, we leverage the powerful concepts of modularity and abstraction from the software world in order to organize aspects of the EDA flow and enable re-usability.

Feature Planning

Modern CAD tools can be very complex to use and operate, and we want to be especially careful that Hammer maintains the correct modular abstractions to manage this complexity. To ensure generalizability of Hammer flows, we consult the following guidelines/framework. Note that it is mainly advisory as opposed to being strictly enforced. These are still draft guidelines and subject to change as the project evolves.

  • A feature is generalizable in a meaningful/useful way when there are enough common features between them to allow re-usable code. For example, CPF is a generalizable API because the ideas and concepts between different flows are substantially similar. On the other hand, for example, in certain CAD tools, well tap APIs are hard to generalize meaningfully because they consist of random collections of TCL.
  • APIs will likely be more readily implemented if
  • 1) A Hammer core developer has access to a second technology or CAD tool where that API is used
  • 2) A Hammer core developer has a pressing need for using this API in a tapeout; it is a reasonable candidate for generalization; and it can be implemented in a reasonably clean way.
  • What constitutes a reasonable candidate for generalization?
  • 1) If a feature is present in two or more CAD tools and is generalizable in a meaningful/useful way, consider making it a generalizable Hammer API.
  • 2) If a feature is present in multiple technology nodes/PDKs and is generalizable in a meaningful/useful way, consider making it a generalizable Hammer API.
  • 3) If a feature is very useful but it is unclear how to generalize it in a useful way, then that tapeout project should consider using a TCL hook.
  • TCL hooks can belong to Hammer technology libraries or combinations of Hammer tool and technology libraries (e.g. 28nm with FooBar vendor).