Digital design flow


Digital design flow

Easics originated in 1991 as a digital design service company. Between then and now we have seen quite a bit change. FPGA’s evolved from so-called glue logic to complex digital systems and naturally we grew along. Even more, applying many aspects of our design methodology developed for ASIC’s, which is based on software techniques and thorough verification in simulation, to the digital design for high-end FPGA’s, brings us leaps ahead of other companies with “glue logic / PCB-roots”.

In what follows we will describe the phases of our digital design service “flow” which are common for both ASIC and FPGA development.

Specification Handoff

At the starting point of the specification phase for your custom SoC design usually several inputs exist:

  • Marketing wish list
  • “What are our competitors doing?”
  • Standards
  • Or it can be a contest (like a call for proposals from ESA, EU, etc.)

The goal however is to derive from all this a set of detailed technical requirements, which are usually contained in a document, but it might as well be a software model in a high-level language such as C++ / SystemC, Matlab, Python, Ruby, etc. Read here how Easics successfully demonstrated this datapath modeling approach in a CMOSIS camera-chip for the new “Leica M” camera.

This is where easics’ proactive requirements engineering comes in very handy. We can perform what we call a “sensitivity analysis” of the requirements, i.e. to challenge and “tune” them, thereby using our experience from related domains. It is our ambition to unveil the unwritten requirements, taking into account the future (scalability / product roadmap).

Various potential dangers are lurking during this phase:

  • Feature creep
  • What, not how!
  • Time to market
  • Budget
  • Competitive analysis
  • Market potential
  • Draft standards
  • “Never final”

System Architecture Advice

Once the “What?” is defined (i.e. the specification phase outcome), we can start to tackle the “How?”. At this stage, easics can bring numerous aspects into play:

  • Reality check
  • Risk analysis
  • Make vs. buy
  • Various trade-offs
  • Block decomposition (aka module partitioning)
  • Clock domains, clock strategy
  • Reset strategy
  • Gate count estimate
  • Memories
  • Serial versus parallel implementation
  • Approximation of mathematical operators – e.g., CORDIC
  • Quantization, fixed point versus floating point
  • Early modeling & simulation
  • Synthesis experiments
  • Technology exploration and choice
  • Profiling using project-specific metrics
  • Scalability
  • Debug strategy
  • DFT strategy

This on-demand process is fitting your specific needs.


At easics we are very enthusiastic about our methodology fundaments. We vastly believe that increasing the abstraction level equals increasing design productivity. Higher abstraction layer code is easier to understand by humans and often more compact. We bring this into practice in two ways:

  1. Writing high-level HDL RTL
    • High-level data types (e.g. VHDL records, integers, enum, arrays)
    • SW like way of coding, let synthesis tool generate netlist
  2. HDL code generation using in-house developed tools
    • Typically, the input for the tool is a very concise description in a “higher” language
    • Another great advantage is change resistance: the tool input will change during the design and easics’ tools are developed with this in mind. All changes automatically ripple through.

At the end of the day, only for the core functionality HDL is written manually.


As already mentioned in the introduction, thorough verification in simulation is simply in our DNA. We even have a mantra for it: “If it is not tested, it doesn’t work.” Analoguously to our implementation strategy, we aim for the higher level. We use SystemC or SystemVerilog to build our testbench and self-checking test cases, both for module and top-level verification. These test suites are managed by our in-house developed automated regression tool, with following advantages:

  • Re-running tests is trivial
    • Everybody is able to run the regression suite
    • Re-run the regression suite on a regular basis allows early detection of new bugs
  • Test suite is run on every code release
    • Code revision number included in test logs
  • Automated reports and documentation
    • Even requirements compliance matrices if applicable

Finally, verification goes beyond the simulator environment. The ability to reuse our high-level verification components reduces the verification effort and efficiency significantly.


Our methodology pays off not only in a fast time to market but also in easy reusability and scalability of the design. If you would like to discover more about our services, please go ahead and read our customer testimonials!