Continue reading Twitter Maps America’s Mood in Real Time

Related posts:

1. Is Twitter Flattening? A Short Answer
2. Twitter and snowflakes
3. How Twitter is changing access to information

Tier Logic had a unique value proposition: you could turn its FPGA into an ASIC in a predictable time and cost. It had a working silicon and a proven production tool, and achieved to do so with spending only $20M.

It is a pity to see that a company with such a good technology and such an attracting business proposition must shut down because of lack of interest from VCs. You have to wonder which strings you have to pull in the investment community to get the attention you deserve.

Although Tier Logic will likely attempt to sell its technology to a Xilinx or an Altera, it is also quite likely that whoever the buyer is will simply buy Tier Logic’s patents to bury them. Too bad.

After Abound Logic‘s shut down 6 weeks ago, another startup showing how hard it is to be successful in FPGA.

Related posts:

1. Can Tabula and Tier Logic be successful?
2. RIP Abound Logic
3. Why FPGA startups keep failing

When developing in C++, an impeccable API is a must have: it has to be as simple as possible, abstract, generic, and extensible. One important generic concept that STL made C++ developers familiar with is the concept of iterator.

An iterator is used to visit the elements of a container without exposing how the container is implemented (e.g., a vector, a list, a red-black tree, a hash set, a queue, etc). Iterators are central to generic programming because they are an interface between containers and applications. Applications need access to the elements of containers, but they usually do not need to know how elements are stored in containers. Iterators make possible to write generic algorithms that operate on different kinds of containers.

For example, the following code snippet exposes the nature of the container –a vector.

     void process(const std::vector<E>& v)
     {
         for (unsigned i = 0; i < v.size(); ++i) {
             process(v[i]);
         }
     }

If we want to have the same function operating on a list, we have to write a separate function. Or if we later decide that a list or a hash set is more appropriate as a container, we need to rewrite the code everywhere we access the vector. This may require a lot of changes in many files. Contrast this container-specific visitation scheme to the following:

     template <typename Container>
     void process(const Container& c)
     {
         typename Container::const_iterator itr = c.begin();
         typename Container::const_iterator end = c.end();
         for (; itr != end; ++itr) {
             process(*itr);
         }
     }

Using the notion of iterator, we have a generic processing of a container ‘c’, whether it is a vector, a list, a hash set, or any data structure that provides iterators in its API. Even better, we can write a generic process function that only takes an iterator range, without assuming that the container has a begin() and end() method:

     template <typename Iterator>
     void process(Iterator begin, Iterator end)
     {
         for (; itr != end; ++itr) {
             process(*itr);
         }
     }

An STL iterator is a commodity that behaves as a scalar type:

• It can be allocated on the heap
• It can be copied
• It can be passed by value
• It can be assigned to

The essence of an iterator is captured by the following API.

     template <typename T>
     class Itr {
     public:
         Itr();
         ~Itr();
         Itr(const Itr& o);                   // Copy constructor
         Itr& operator=(const Itr& o);        // Assignment operator
         Itr& operator++();                   // Next element
         T&   operator*();                    // Dereference
         bool operator==(const Itr& o) const; // Comparison
         bool operator!=(const Itr& o) const { return !(*this == o); }
     }

Usually the container will provide a begin() and end() method, which build the iterators that denote the container’s range. Writing these begin/end methods is an easy task if the container is derived from a STL container, if the container has a data member that is an STL container, or if the iterator is a scalar type, like a pointer or an index.

It is more complicated if we want iterators that dereference to the same type of object, but that must visit several containers, possibly of different types, or iterators that visit containers in different manners. For instance let us assume that we have objects with some property (say, a color) stored in several containers, some of them of different types. We would like to visit all the objects, independently of the number of containers and their type, or we would like to visit objects of a given color, or we would like to visit objects that satisfy some predicate:

     class E;

     Itr<E> begin(); // This give the range to visit
     Itr<E> end();   // all the elements of type E      

     Itr<E> begin(const Color& color); // Same as above but only for the
     Itr<E> end(const Coir& color);    // elements of the given color      

     class Predicate {
     public:
         bool operator()(const E& e);
     };      

     Itr<E> begin(Predicate& p); // Same as above but only for the
     Itr<E> end(Predicate& p);   // elements that satisfy the predicate

In this case the iterator is more complex than a scalar type like a pointer or an index: it needs to keep track of which container it is currently visiting, or which color or predicate it needs to check. In general, the iterator may have data members so that it can fulfill its task. Also we want to factorize the code and reuse general purpose iterators’ methods when writing more targeted iterators –e.g., visiting elements of a specific color should make use of the next-element method Itr<E>::operator++(). This can be done by having Itr<E> be a virtual class, and having derived classes to implement the different iterators. For example:

     class E {
     public:
         Color& color() const;
     };      

     template <typename E>
     class ColoredItr<E> : public Itr<E> {
     private:
         typedef Itr<E> _Super;
     public:
         ColoredItr<E>(const Color& color) : Itr<E>(), color_(color) {}
         virtual ~ColoredItr<E>;
         virtual ColoredItr<E>& Operator++() {
            for (; _Super::operator*().color() != color_; _Super::operator++());
            return *this;
         }
     private:
         Color color_;
    };

We would like a generic iterator that meets all the requirements described above:

• It can be allocated on the heap
• It can be copied
• It can be passed by value
• It can be assigned to
• It dereferences to the same type
• It can visit several containers
• It can visit containers of different types
• It can visit containers in arbitrary manners

This can be implemented as follows.

     template<typename E>
     class ItrBase {
     public:
         ItrBase() {}
         virtual ~ItrBase() {}
         virtual void  operator++() {}
         virtual E&    operator*() const { return E(); }
         virtual ItrBase* clone() const { return new ItrBase(*this); }
         // The == operator is non-virtual. It checks that the
         // derived objects have compatible types, then calls the
         // virtual comparison function equal.
         bool operator==(const ItrBase& o) const {
             return typeid(*this) == typeid(o) && equal(o);
         }
     protected:
         virtual bool equal(const ItrBase& o) const { return true; }
     };      

     template<typename E>
     class Itr {
     public:
         Itr() : itr_(0) {}
         ~Itr() { delete itr_; }
         Itr(const Itr& o) : itr_(o.itr_->clone()) {}
         Itr& operator=(const Itr& o) {
             if (itr_ != o.itr_) { delete itr_; itr_ = o.itr_->clone(); }
             return *this;
         }
         Itr&  operator++() { ++(*itr_); return *this; }
         E&    operator*() const { return *(*itr_); }
         bool  operator==(const Itr& o) const {
             return (itr_ == o.itr_) || (*itr_ == *o.itr_);
         }
         bool  operator!=(const Itr& o) const { return !(*this == o); }      

     protected:
         ItrBase<E>* itr_;
     };

The ItrBase class is the top class of the hierarchy. Itr is simply a wrapper on a pointer to an ItrBase, so that it can be allocated on the heap –the actual implementation of the class deriving from ItrBase can have an arbitrary size. Note how the Itr copy and assignment operators are implemented via the ItrBase::clone() method, so that Itr behaves as a scalar type. Last but not least, the (non-virtual) ItrBase::operator== equality operator first checks for type equality before calling the (virtual) equality method equal on the virtual subclass. The reason ItrBase is not a pure virtual is that it can conveniently be used to denote an empty range, i.e., the range (ItrBase(), ItrBase()) is empty.

Iterators on containers of elements of type E just need to derive from ItrBase<E>, and a factory providing the begin() and end() methods for any specialized iterator returns object of type Itr<E>.

For example, let us assume that we have a container c of E’s, and that we want an iterator to visit (1) all the elements of c, possibly with repetition; (2) all the elements of c without repetition. This can be done as follows.

    class E;

    class ItrAll : public ItrBase<E> {
    private:
        typedef ItrAll     _Self;
        typedef ItrBase<E> _Super;
    public:
        ItrAll(Container& c) : _Super(), c_(c) {}
        virtual ~ItrAll() {}
        virtual void  operator++() { ++itr_; }
        virtual E&    operator*() const { return *itr_; }
        virtual ItrBase<E>* clone() const { return new _Self(*this); }
    protected:
        virtual bool equal(const ItrBase<E>& o) const {
            // Casting is safe since types have been checked by _Super::operator==
            const _Self& o2 = static_cast<const _Self&>(o);
            return &c_ == &o2.c_ && itr_ == o2.itr_;
        }
    protected:
        Container&          c_;
        Container::iterator itr_;
    };     

    class ItrNoRepeat : public ItrAll {
    private:
        typedef ItrNoRepeat _Self;
        typedef ItrAll      _Super;
    public:
        ItrNoRepeat (Container& c) : _Super(c) {}
        virtual ~ItrNoRepeat () {}
        virtual void  operator++() {
            _Super::operator++(); // Go to the next element then
            // look for an element that has not been visited yet.
            for (; itr_ != c_.end(); _Super::operator++()) {
                E& e = _Super::operator*();
                if (visited_.find(e) == visited_.end()) {
                    visited_.insert(e);
                    return;
                }
            }
        }
        virtual E&    operator*() const { return _Super::operator*(); }
        virtual ItrBase<E>* clone() const { return new _Self(*this); }
    protected:
        virtual bool equal(const ItrBase<E>& o) const { return _Super::equal(o); }
    protected:
        set<E> visited_;
    };     

    // Build the container’s range w/ and w/o repetition
    Itr<E> begin(Container& c, bool noRepeat = false)
    {
        Itr<E> o;
        if (noRepeat) {
            o.itr_ = new ItrNoRepeat(c);
        } else {
            o.itr_ = new ItrAll(c);
        }
        o.itr_->itr_ = c.begin();
        return o;
    }     

    Itr<E> end(Container& c, bool noRepeat = false)
    {
        Itr<E> o;
        if (noRepeat) {
            o.itr_ = new ItrNoRepeat(c);
        } else {
            o.itr_ = new ItrAll(c);
        }
        o.itr_->itr_ = c.end();
        return o;
    }

Related posts:

1. API design 101

Continue reading Why Facebook wants you to believe that “email is dead”

Related posts:

1. So will Buzz and Facebook finally bury Twitter?
2. Is Twitter Flattening? A Short Answer

Instead, I have chosen to share my absolutely non-exhaustive, completely biased view of DAC. I will then publish a couple of posts focused on specific themes in the next few days.

Attendance

The 47^th DAC was held June 13-18 at the Anaheim Convention Center in California. The preliminary attendance numbers are reported as follow:

• Total full conference: 1554
• Total exhibit attendees: 3444 (24% international)
• Exhibitors, visitors, and guests: 2557
• Total attendees: 6001

The final attendance numbers are usually a few percent higher.

For a fair comparison, I pulled out the preliminary attendance numbers of the past conferences. I was first fooled by the way the numbers were labeled this year –see the comments below, and a big thanks to Sean to bring me the correct interpretation. The table below shows the correct data, excluding booth staff. It shows a sharp decline (33%) of the total attendance compared to last year in San Francisco. Not having DAC in San Francisco means higher cost for most of the attendees –many of them are from the Silicon Valley–, which is clearly reflected in the attendance numbers.  But if we compare this year’s numbers with the 2008 DAC venue held at the same location, we see the same sharp decline (28%). Note the drop in exhibits-only attendees (-41% w.r.t. 2009, -21% w.r.t. 2008), not a good sign as this number captures most of the customer audience.

DAC preliminary attendance numbers (not including booth staff)

This year’s DAC comes after one of the worst recession, but looking forward to a very strong semiconductor growth in 2010 and 2011, which should eventually translate into a mildly better business for EDA. The exhibition was well attended on Monday, with a sharp decline on Wednesday –lots of people left by that time.

The buzz

With Cadence’s EDA360 campaign in the background, and the fresh acquisitions of Denali by Cadence and Virage Logic by Synopsys, it felt that IP was the buzzword of the day. IP design here, IP verification there, verification IP everywhere, the overall SoC design looked like an IP integration problem that EDA was gearing up to take on. Embedded software and ESL were also showcased by Cadence and Mentor Graphics as part of their SoC focus.

Verification

There was a booth dedicated to UVM/OVM (Universal Verification Methodology/Open Verification Methodology). These methodologies offer open and interoperable verification solutions. They both support multiple languages and simulators, and enable verification IP, so critical to SoC design. The message was well received and had a strong attendance.

Still on the verification side, new products and startups are trying to repeat the success of Certess (acquired by SpringSoft last year). Advanced formal verification tools (e.g., property checkers) are slow to find acceptance by the design community. Instead these new products and startups leverage the existing test bench and simulation methodology in place to produce better coverage or faster simulation. Notably missing in this space was NuSym, a no-show at this year’s DAC, confirming the rumors that the startup that demonstrated “intelligent” simulation two years ago is actively looking for a buyer.

The whole simulation and emulation space was strong. Mentor’s Veloce is showing impressive numbers, and is ready to take on Cadence’s Palladium. Eve will likely take notice, and this may bring it closer to Synopsys.

Magma’s Tekton offers sign-off quality multi-mode/multi-corner static timing analysis for multi-million gate circuits. The tool has been designed from the ground up, and tailored for multi-threading and distributed systems. It is a clear competitor to Synopsys’ PrimeTime, even though running PrimeTime *is* the signoff for most customers.

Design and implementation

On the P&R and backend side, nothing really stood out. Synopsys clearly gained in QoR, Mentor’s momentum with Sierra’s Olympus is still strong, and Magma keeps lagging behind, especially in runtime. Atoptech and Azuro, although showing pretty good numbers (verified at customers’), are still considered more like add-ons that comprehensive solutions. This segment looks more and more commoditized, and only the high-end (20nm and below) and 3D seem to offer new growth opportunities in that space.

Oasys, the darling of last year’s DAC, did not make as much as a splash this time, despite its recent announcement with Juniper Networks and Xilinx. Nobody question the speed and capacity of their tool, as well as the clock cycle it can achieve. But some raised concerns regarding the area of their netlists for ASIC.

On the fringe

This is the “stuff I liked that may be too small to be noticed”, even more so since two of these three companies didn’t have a booth at DAC…

Low power is still under-represented, even though power gets worse with smaller geometries, and power management remains mostly a very manual process. In that space I liked Docea Power, which can simulate system-level models to analyze power consumptions and thermal behaviors. System-level analysis can bring the biggest power savings. It also has a significant impact on the packaging, which is still a domain where conservative approaches are preferred to more cost-efficient, but riskier, choices.

A comprehensive system-level design framework is really an IDE (Integrated Development Environment) for SoC, where hardware and software can be designed together, written and simulated together, and where the HW/SW tradeoffs can easily be explored. IDEs have been used in software for a long time, but are a novelty to hardware designers. Sigasi proposes an IDE for VHDL –what Microsoft’s Visual Studio is to C++. Although this is still light-years away from a SoC IDE, this is a hint into the future of writing RTL.

We heard several claims that cloud computing is coming to EDA (or the converse?). Xuropa best illustrates that (slow) move. They provide turn-key online community solutions for the electronic design industry. Their main customers, Cadence and Synopsys, are using the services for CRM and virtual demo only. But Xuropa could become a platform that enables collaborative design in the cloud, providing secured access to a multi-vendor flows. More on this in a future post.

Last words

I felt that there was a lot of system-centric messages (best captured by EDA360), and attempts at rising the abstraction level for higher productivity. EDA vendors are forced to see the big picture –full system design, software and hardware together. But as pointed out by Steve Jones (TI) at Cadence’s Silicon Realization Luncheon, EDA is still missing out on two important parts of the SoC design. One is that customers want a first-silicon that is functionally operational, and Steve singled out the need for useable verification IP –UVM/OVM is a step in the right direction. The other is analog –mixed-signal design is the rule, and there is no good integration there.

Related posts:

1. Did you feel the tremor? The 2010 challenges for EDA
2. The formal verification market is still untapped
3. Has formal verification technology stalled?

Oasys’ product, RealTime Designer, is claimed to be 10x-60x faster than the competition. Among other things, it uses AIG-based optimization. This technology is best illustrated by UC Berkeley’s ABC synthesis: several FPGA startups reported that ABC boosted significantly the speed, capacity, and quality of their synthesis engines. No question that Oasys’ synthesis is competitive, at least in the FPGA world.

Xilinx is an investor into Oasys, and it has been toying with their synthesis technology for at least a year, so it’s not like they just discover each other. Xilinx has to close a software technological gap with respect to its closest competitor, Altera, and a fast, high capacity synthesis will certainly help.

Synthesis speed is key here. Until recently FPGA design was mostly an iterative process: synthesize, simulate, and debug (i.e., change in the RTL) until the performances and functionality of the design were satisfactory. That trial-and-error approach becomes impractical as the size of FPGA devices is increasing to the point that one single iteration takes hours, if not a day. Having a 10x speedup in synthesis means you can restore that familiar design iteration for a few more years.

Verification has become a bottleneck in FPGA. Simulating is used and will still be used in the future. But FPGA’s complexity requires a more complete verification methodology, like formal verification. However formal verification has trouble addressing optimization techniques heavily used in FPGA synthesis, like retiming and state re-encoding. An ABC-like optimization engine comes with a built-in formal verifier that can check independently the correctness of every incremental optimization steps performed during the optimization run. The correctness of the resulting netlist comes with a very high degree of confidence, and only the RTL description needs to be simulated.

Xilinx’ customers will benefit from that technology, and catch up with Altera’s synthesis. As for the EDA vendors selling their own FPGA synthesis, they all use or will use some flavor of AIG-based optimization. Differentiation will be done on the smartness of the high-level optimization –datapath, IPs–, the user experience (GUI), the integrated verification environment (still to be demonstrated), and of course the bottom-line: QoR –clock cycle, area, and power. The race is on.

Related posts:

1. Is FPGA a sustainable market for EDA?
2. How can Xilinx improve its bottom line
3. What to read in Xilinx’ and Altera’s third quarter results

Abound logic, previously known as M2000, was founded by three EDA veterans who had previously started Meta Systems. Meta Systems developed the industry’s first emulation system based on custom FPGAs, which was to become the basis for the Abound Logic device after Meta Systems was acquired by Mentor Graphics in May 1996.

Abound logic’s device, the Raptor FPGA, offered in 65nm technology the capacity of 774k CLBs, each containing a 4-input LUT. This made the Raptor the largest FPGA on the market at a time.

Abound logic was in discussions to close another financing round, estimated around $20M, but one of the main tentatively new investor pulled out, which put to rest the last investment opportunities.

Related posts:

1. RIP Tier Logic
2. Can Tabula and Tier Logic be successful?
3. Why FPGA startups keep failing

EDA360, John Bruggeman’s brainchild, is a manifesto that promotes a vision for the future of EDA. In a nutshell, it states the following:

• So far EDA has been providing the tools to IC creators: design, implement, and verify ICs.
• With the development cost of 32nm SoC reaching $100M, only a handful of semiconductor companies will still create ICs in the next future.
• With modern consumer electronics fueled by apps-based model, electronic design is moving from a hardware-first to a software-centric industry.
• Future SoC will be designed top-down, with software and apps requirements driving the integrations of IPs, DSPs, GPUs, CPUs and cores (ARM, MIPS, x86, etc).
• EDA needs to provide the environment for integrating and optimizing software and hardware resources.

One can disagree with some figures of EDA360’s white paper (e.g., today’s cost of SoC software, placed at 50% of the total SoC development cost, which looks overstated). One can argue that this document states the obvious –that consumer electronics are differentiating with the end applications, which is more and more software dependent, which means EDA needs to focus more on the software aspect if it wants to stay relevant.

But that would not give justice to this document. EDA360 is a detailed, well articulated, and viable vision of what EDA should be. It is a call for action that can revitalize an industry that has been looking for new areas of growth.

EDA’s main value proposition must follow its customers’ evolution. Semiconductor companies are moving from silicon to system companies, which provide application-ready hardware/software platforms, targeted for a precise market within a narrow time-to-market window.

The best example is the evolution of mobile phones. It started with heterogeneous HW/OS/SW devices, all proprietary and hardware centric. Then the iPhone came in 2007, providing a HW+OS environment with a SDK (Software Development Kit) for developers in 2008, together with the App Store and its 70/30 seller/store profit sharing model. As for May 2010, the App Store offers 200,000+ apps and received over 4B downloads, and it produced a Q1’10 revenue for Apple estimated at $150-225M. The next step was Google that released Android OS for mobile devices as open source in 2008. As for May 2010, there are 17 manufacturers proposing mobile phones built on the Android platform, and 12 offerings for tablets and e-readers. The semiconductor companies providing the hardware are really delivering complete Android-enabled, apps-ready, HW/SW systems.

So where does that leave EDA? EDA already started to address some of the issues. HW/SW simulation, virtual prototyping, IP reuse, verification IP, and ESL/C-flavor synthesis have received significant investments by Cadence, Mentor, and Synopsys. Synopsys acquisition of Vast (virtual prototyping) and CoWare (ESL) was not as noticeable as Cadence’s acquisition of Denali, but it participates of the same logic. Cadence’s Open Integration Platform was announced early May, and intends to grow an ecosystem that will help realizing EDA360.

Still, we are far from an integrated development environment (IDE) for SoC, which would meet EDA360’s vision. For instance, IP reuse is still elusive –the cost of IP integration is often comparable to the cost of developing a new IP.

I don’t know whether EDA will meet the challenge of an environment where the software application drives the cores selection and power management, where IPs are selected according to some cost/performance tradeoffs, where the different hardware components are integrated seamlessly, and where the verification of the software together with the hardware is done incrementally. I don’t know whether this will result in moving from a $5B to a $25B industry. But I applaud a strong vision that gives a new roadmap for the future of EDA. It will certainly impact the industry. Already we see some EDA vendors espousing EDA360’s message, like Duolog, and Cadence’s acquisition of Denali shows it is serious about fulfilling the vision. Also if the SoC’s silicon results mostly from integrating IPs and cores, RTL synthesis and place & route will be commoditized. Only vendors able to provide HW/SW integration and verification will emerge as the next leaders.

No related posts.

In a world where FPGA software design is expected to be free (or very cheap, compared to it ASIC counterpart), is there still a market for EDA companies to sell their FPGA solutions? Synplicity stopped growing after it built its success on FPGA synthesis. Is that the fate of EDA for FPGA?

There are several forces at play here: device complexity, software complexity, and know-how.

The complexity of FPGA starts to rival that of ASIC’s. The largest FPGA devices contain 100,000’s of LUTs and registers, 1000’s of DSP components, and are equivalent to 1+ million gate designs. The increasing device size requires faster synthesis and larger capacity. It also strains verification because simulation costs are augmenting accordingly. The days were a designer could complete her FPGA project with a simple write-RTL/synthesize/simulate/fix iterative flow are gone.

FPGA companies differentiate with their devices’ speed, capacity, and power consumption. But beyond the raw hardware features, software to design FPGA has become a key for success. Altera learnt the lesson the hard way 10 years ago when it released software that was not ready: Altera quickly lost its top customers to Xilinx, while it could have become the undisputed #1 FPGA vendor. Some FPGA startups in the past could not get off the ground because they fail to deliver good synthesis for their device. Closer to us, we have heard about Tabula’s chronic problems to bring up its synthesis before it finally announced its device earlier this year. And Abound Logic’s huge netlist has stretched the capacity of today’s FPGA synthesis.

Altera has now a software powerhouse, and is meticulous about its software design and testing. Xilinx is currently going through a major overhaul of its software to catch up with its main competitor. There is no question that software is taken very seriously by the two vendors –they both have a couple hundreds engineers dedicated to provide customers with a full design tool suite.

So does EDA has any future in FPGA synthesis? There will always be FPGA startups looking for an OEM with Synopsys and Mentor, but this is not enough. The EDA industry must showcase a comprehensive FPGA development environment that will cover design, synthesis, and verification:

• Verification is becoming ever more costly for FPGAs, as it already is for ASICs. Formal verification for FPGA is still embryonic –FPGA synthesis uses retiming and FSM re-encoding that makes formal verification quite difficult.
• Synthesis of complex systems with a large IP spectrum is an area of expertise that EDA must leverage. Also EDA could provide a much-needed improvement in power management.
• As for design, EDA must seize on the FPGA community’s ability to adopt new methodologies much faster than the ASIC community. ESL, SystemC, and C/C++ as hardware description languages are the right direction.

If EDA wants to compete with the few hundred software engineers of Xilinx and Altera, it needs to deliver a best-in-class and innovative FPGA design environment. Else it will end up as a no-growth by-product of ASIC synthesis.

Related posts:

1. Why FPGA startups keep failing
2. The formal verification market is still untapped
3. Who should worry about Xilinx and Oasys partnership?

The dominant factor in classical FPGA architecture is the interconnect: most of the die area is taken by the wires and the interconnect switches and muxes. If you can somehow reduce the area dedicated to interconnect, you can augment the logic density and lessen the cost of the device. Tabula and Tier Logic pitch a 3D architecture to address the interconnect bottleneck, albeit in very different flavors.

Tabula innovative design is based on its ability to reconfigure itself, up to 8 times with a clock running at 1.6GHz. At each cycle a cell can change its functionality, its latch configuration, and its interconnect. The time-multiplexing increases the amount of logic that can be fit on the same area. It is like having 8 layers (or “folds”) of cells stacked on top of each other along a time axis, with very short connection between cells at the same (x,y) coordinate but in two adjacent folds. At each cycle one jumps to the next fold and feeds the new configured logic with the results of the previous fold. Tabula claims they increase the logic density by 2.5x compared to classical FPGA architectures.

Tier Logic’s design idea is to place the SRAM cells that configure the interconnect muxes on top of the routing layers, instead of having them distributed throughout the logic die area. Doing so leaves more room for logic cells, increasing the cell density by about 50% according to the company. The design flow will not throw anybody off: it uses Mentor’s Precision for synthesis, and is followed by Tier Logic’s mapping and P&R.

A big plus touted by Tier Logic is the ability of moving painlessly from their device to an ASIC. Simply replace the interconnect configuration SRAM cells at the top with metal, and voila, you obtain an ASIC with no change in timing. This is a simple, predictable process: it takes about 4 weeks to go from the SRAM configuration to a top-layer mask, and you do not need to go through a timing closure flow again, which means a non-recurring engineering cost of about $50k. This is a real bargain when you consider that moving from FPGA to ASIC usually requires a redesign that can take as long as 9 months.

So who of Tabula and Tier Logic is best positioned to challenge the duopoly Xilinx/Altera?

Tabula made it clear that they are aiming at the high-end of the FPGA market. There are a number of FPGA startups that targeted the same niche, and none survived. One reason is that it is easy for Xilinx and Altera to increase the size of their device, by simply moving to the next technology node. Tabula’s design is innovative and pushes the limits, but how far is too far? It is unclear whether the company can deliver the design tools to match their device’s challenges –they went through a complete reset a few years ago, replacing the whole software team. Verifying a device that can reconfigure itself 8 times in a loop may be another challenging problem. Increased density is obtained by continuous reconfiguration, which means extra power consumption: is it still an acceptable tradeoff? Last but not least, with 100+ people in the US, it is a well-known fact in the Silicon Valley that Tabula burns cash fast, and their funding of $106 millions so far is about to come short.

Tier Logic’s FPGA can reduce the cost of the device for the same density. But their compelling value proposition is really their FPGA to ASIC translation. This is what Altera’s HardCopy was supposed to be, a seamless and risk-free migration from FPGA to ASIC. For anybody that wants to design an application and then migrate to a low/medium volume ASIC production, this could be the most cost efficient solution. I do not know the inside story regarding the financial aspect, but their business proposal looks more solid.

So who do you think has a chance here? Let’s meet again in 3-4 quarters and see how the two companies are doing.

Related posts:

1. RIP Tier Logic
2. Why FPGA startups keep failing
3. RIP Abound Logic