Imera has shut down its operations, leaving behind a number of customers (Broadcom, TSMC, Qualcomm, Sandisk, Infineon, Synopsys, Cadence, Mentor, etc).

Usually a customer requiring support means that some design data need to be sent over to a vendor for debugging. This is obviously a concern for most customers, who are unwilling to send sensitive data to any 3^rd party. Thus debugging needs to happen on-site, which means the EDA vendor has to bring up its code source at the customer’s location. This is time consuming, and vendors are reluctant to move their source code outside of their premises for the same reason their customers want to keep their design data within their walls.

Imera’s solution enabled a secured end-to-end channel allowing an authorized 3^rd party to access the customer’s data. Practically, the secured channel (aka “Virtual Fabric”) was obtained by installing two physical gateways, one at the customer site, and the other at the vendor’s. Once setup, a virtual private network is established, and data can be exchanged between these two endpoints only.

Of course, people liked having an actual piece of hardware: anchoring the security message into a physical medium made it more real.

However this solution was limited to very simple transactions, which may explain the company’s restricted outlook that led to its demise.

With more collaborative efforts between customers, vendors, and third party infrastructures (e.g., cloud providers), the need for secured data exchange is only becoming greater. Imera had pioneered a solution, however limited, in the EDA field. More will come, and will hopefully be more flexible.

Related posts:

1. EDA in the cloud: shall we be scared?

Besides the quality of services, which most agree AWS is the leader of among the top cloud computing offerings, cost is a most important variable. Lower cost of entry is one reason driving people to the cloud. However many argue that if you were to commit to long-term hardware resources, you may be better off buying your own hardware. That may be true for a 3 years, static, investment. But for burst computing and flexible architectures, this is questionable.

One reason AWS is making computing resources look more and more like a commodity is it’s reserved and spot instances.

Usually, the act of provisioning an instance results in running a virtual machine in some data center, and you are then billed by the hour. Besides on-demand instances, AWS proposed two other kinds of instances: reserved instances, and spot instances.

Buying a reserved instance gives you the option to provision an instance at a 20 to 70% discount price during a 1 or 3 years period.

For instance, a medium Linux instance in the US East region costs $0.16/h. Assuming a 50% utilization rate for 1 year (meaning the instance is stopped half of the time, during which you are not billed), it comes to a cost of $700.80 (in reality it is slightly higher, as resuming a stopped instance will be billed for a full hour, even if it’s stopped before the end of the hour). A reserved instance of the same kind for 1 year is $0.078/h, with an upfront fee of $138, which comes to a cost of $479.64, a saving of 32%. Reserving for a 3-year period ($0.063/h plus a $212.50 fee) increases the saving to 51%.

A reserved instance also gives you the confidence that it will launch when needed. Indeed it is not rare to see on-demand instances failing to launch. For large and/or fast buildup of set of instances, I have experienced failure rates of up to 20%, meaning that up to 20% of my instances failed to reach their operational state.

Spot instances enable you to bid for unused Amazon EC2 capacity, and to run those instances for as long as your bid exceeds the current spot price. The spot price changes periodically based on supply and demand. If your bid exceeds the spot price, you gain access to the available spot instances, and you are charged at the spot price (not your bidding price). However if the spot price increases and overtakes your bidding price, your spot instance is terminated.

Spot instances are a great way to acquire instances at a low price. However given that they can be terminated whenever the spot price exceeds the bidding price, spot instances can only be used by applications that are truly fault tolerant. Batch computing is one obvious application –assuming that every job is small enough that restarting then when needed does not impair performances.

On-demand instance is a common good in cloud computing, but reserved and spot instance make AWS a true marketplace for computing power. A good strategy that balances these three kinds of resources to optimize cost and availability will become a significant factor for the many companies that choose to use a public cloud like AWS for their IT needs.

“Every day Amazon Web Services adds enough new capacity to support all of Amazon.com’s global infrastructure through the company’s first 5 years”

Between 5 to 10% of the computing resources in the world is in the cloud, and its share grows fast, driven by features-hungry mobile applications. Maybe will come a time where one can buy and trade computing power.

Related posts:

1. Cloud computing is not grid computing
2. Cloud computing: an opportunity for EDA
3. Amazon’s outage, a step back for EDA in the cloud?

The “why” first. For Synopsys, I can think of a few good reasons:

1. Magma’s Talus Vortex is still a disruption for many P&R Synopsys deals.
2. Magma’s FineSim started to make a significant dent into Synopsys’ SPICE market share.
3. Magma’s Titan is a viable solution against Cadence’s solution for analog and mixed signal design, unlike Synopsys’ in-house tool.
4. Magma’s Tekton showed how Synopsys’ PrimeTime has been lacking innovations to bring distributed timing signoff to the customers.

For Magma, a good answer to “why “is a 30% premium on its stock price, which Rajeev Madhavan, the CEO of Magma, has been working very hard to push up. Also maybe Rajeev realized that Magma would never realize one of his ambitions, beating Synopsys at his own game, RTL synthesis. Or maybe he finally acknowledged that you cannot grow if you keep discounting your own products, and keep trimming talents for cost reasons. Regardless of the motivations, I am sure that Rajeev leaves with a good deal in his hands.

What about Magma’s employees? For them, the premium on the stock price is good news. But what will happen to their jobs is more of a mixed bag. In such acquisition, sales and marketing are the first to go. Synopsys will certainly retain the R&D talents they care about –FineSim, Titan, Tekton, and possibly a handful of people in the backend. I hear a lot of people in Magma India that wonder what will happen of them. Not to worry. I think it would be foolish for Synopsys not to leverage Magma’s R&D facilities in India. Both Noida and Bangalore’s Magma offices are made of strong, committed, talented people. They can easily be reassigned to other projects.

What about the users? Their reaction is likely to be negative. The reason: Magma out means less competition, thus less innovation and possibly higher prices. Also many users are reluctant to deal with Synopsys sales people that are often perceived as arrogant.

However Magma has been cutting down the price of its tools to a point that it has been hurting the EDA industry as a whole. Being aggressive on price to gain market share is good, but cutting down the price to stay in business is bad. Investing in new tools is good, but dispersing scares resources on too many projects results in unfocused strategies that fail to deliver. My take is that for the longer term, the disappearance of Magma will benefit the user as well.

What about the EDA industry? This is clearly good news. This consolidation is an opportunity for Synopsys to be ambitious. Also Magma’s acquisition will free talents, and will make some startups look like a decent alternative for the customers that want to balance Synopsys’ hold on the industry. Change is good. Thank you Magma for shaking the industry, and welcome to the future movers.

Related posts:

1. Synopsys is getting into the cloud

With a compute farm, you have a fixed amount of computing resources. You rely on an engine like LSF (Load Sharing Facility) or SGE (Sun Grid Engine) to schedule and prioritize jobs to best use these fixed computing resources. The rule of the game is to keep the queue as short as possible, or better, to keep the relative processing time increase as small as possible.

Clearly having access to hundreds of compute nodes (or instances, to use the cloud terminology) on demand changes the game of parallel computing entirely. In the word of cloud computing, using 100 instances for 1 hour costs the same as using 1 instance for 100 hours (a bit more than 4 days). Assuming you can borrow as much as you want and that you can keep all the instances busy, there is no point in limiting the computing resources: the cost will be the same, but the wall time will be reduced.

Of course, this is more complicated in practice. You are billed by the hour. Thus starting a new instance to process jobs is wasteful if that instance is not fully utilized during a whole hour. Also starting or shutting down an instance takes a few minutes, during which that instance is unavailable. Thus you must be able to anticipate the upcoming job distribution and have a clear pictures of the instances’ load and how long they have before their hour expire to decide whether you should:

• Start a new instance to process jobs;
• Shut down an instance before being charged another hour;
• Queue a job.

You also want to account for hardware failures, which is more likely to happen if you have many instances for a long time. Also inter-instance communication, if needed, can become a major bottleneck in scaling up –unless there is a 10Gb network available.

The cloud has an appealing message –borrow when you need it. It is a paradigm shift for parallel computing. This means moving from “managing resources” in a compute farm to “managing cost” in the cloud. As explained above, managing cost in the cloud is substantially more complicated that scheduling jobs on a compute farm. Yet cloud computing gives the flexibility to design strategies that reduces wall time and keeps costs low. It will only benefit customers: borrow more for less time, pay the same, and get the result faster.

Related posts:

1. Cloud computing: an opportunity for EDA
2. How Amazon is building a new computing resource marketplace
3. Synopsys is getting into the cloud

But this is a hard step. There are many obstructions to viable cloud-backed EDA solutions:

• Both customers and providers of EDA are conservative communities. They are usually slow to adopt new technologies. The semiconductor industry is reluctant to invest in new design frameworks, as its wants to preserve its investment in working flows.
• Security remains a hot issue. EDA vendors want to control the usage of their tools, and they are uncomfortable making them available in a public cloud. And the EDA customers are paranoid about their designs slipping out in the wild.
• Massive parallelism is great, but data transfer via Internet is slow. Because some tasks require moving huge amount of data to and from applications, it is better to host the design data in the cloud for the whole design lifetime. This requires a drastic different mindset for project managers.
• The current TBL (Time-Based License) model makes no sense with massive parallelism. We need new business models based on actual usage (per hour, day, or week) to unlock the flexibility and scalability offered by cloud computing.

The big EDA companies have been slowly espousing the idea of making their tools available in the cloud. Cadence set up a (private) cloud offering a while back, but it has never been successful. Synopsys announced in March that it would provide a cloud computing solution for VCS simulation with AWS (Amazon Web Services). We will see how it unfolds.

Meanwhile, startups have been testing the water. Xuropa hosts demos and a CRM platform in the cloud, and counts Cadence and Synopsys as customers. Plunify proposes FPGA synthesis with multiple runs in the cloud. Nimbic (formerly known as Physware) uses the cloud to develop and deploy its tool. Same for Tabula (although in a private cloud). Xuropa, Plunify, and Nimbic are now making claims about moving other EDA applications in the cloud. And more stealth startups are working on their own solutions.

This is good news. Big EDA companies encounter many internal resistances to moving to the cloud: “this requires costly technical expertise”; “we cannot secure the usage of our tools”; “this is not our core competency”; “we will cannibalize our traditional TBL business and loose money”; “no customer is willing to put his data in the cloud”; etc.

These concerns are legitimate. Transitioning a +20 year old business to a pay-as-you-go model is a daunting, if not scary, proposition for well-established players. Also using cloud technology is much more than high-octane IT. This makes startups the best apt to answer the challenge, evangelize the solutions, and educate the customers. Parting from the TBL business model will take at least that much.

Related posts:

1. Synopsys is getting into the cloud
2. EDA in the cloud: shall we be scared?
3. Cloud computing: an opportunity for EDA

Not such big claim here. This post is simply about a recent experience that decided me to put in practice what I have been praising.

For the past decade I always had several computers at home –two to five Windows PCs, a Mac, and another couple of Linux machines. Very early I was interested in having a storage unit I could share on my LAN between all my computers. Having one central unit to archive, backup, and serve medias (pictures, music, video) is pretty handy.

Back in 2004 I bought a 250Gb Ximeta Netdisk. Technically it is not a NAS (Network Attached Storage), as you have to install a small program on every computer you want to access the disk from. But the device worked just fine, and it still does. Later in 2007 I upgraded to a real NAS (i.e., using TCP/IP for all communications with the devices on the LAN) for my storage needs with a 500Gb LaCie Ethernet Disk mini.

Soon I placed all my data on my Lacie drive: email, business related documents, publications, presentations, C/C++ and Java code, tech articles, books, tax declarations, music, photos, etc. A few days ago, after 4 years of good service, the drive quit on me: it just ceased to power up. Since I had 260Gb of data on that disk, you can imagine my reaction. “Do not panic. The disk itself is fine. It’s only the drive mechanism or the controller that is fried”.

Here is the email exchange I had with Jon L. from Lacie’s support:

Jon: “[…] according to the serial information, the drive appears to be past the two-year warranty. […] Although the drive is no longer serviceable by our repair department, we strive to provide all of our customers with a positive experience with our service and products. LaCie would like to offer you a discount on a replacement product.”

Me: “Nice thought. But what about my data?”

Jon: “[…] a qualified technician may be able to replace the failed internal drive and reconfigure the unit to accept the new drive.  […] We can not assist with this third party repair process.”

Me: “The most important part for me is to retrieve the data stored on the drive. It looks to me that the disk itself is fine –the electronic and control part just stopped to function. Do you provide data recovery service?”

Jon: “Pricing is simple:

• Single drive recovery, no clean room = $399
• Single drive recovery, requires clean room = $1299”

Me: “Ouch!”

So retrieving my data via this service would cost about twice as much as what I paid originally for the disk four years ago. Come on, for $399 I can buy a brand new 4Tb RAID-1 Gigabit Ethernet NAS from Lacie!

The lesson: having a NAS at home is nice to share pictures and music. But if you want to use it as a central repository and backup, you need to think about what happens if that unit fails. Sure, you can use another disk to mirror the backup. Or use a RAID-1 disk, which adds redundancy for higher reliability. But it became clear to me that I was ready to put in practice what I have been advocating for the industry: use the cloud.

Don’t get a backup for the backup, just put the data in the cloud. Then you can always access it –instead of carrying around an external hard drive, as I used to do. Use a service that guarantees replication and redundancy to preserve the integrity of the data, even in case of catastrophic event (e.g., the recent hurricane on the east coast that flooded a few hosting data centers). Encrypt the data at the source, so that nobody but you can read the data.

Eventually I recovered my data for $99 (a fourth of the price Lacie quoted to me) at a computer repair shop in Mountain View. Since then I have been hunting for some cloud data service. I will share my findings and my experiences in a couple of weeks.

Related posts:

1. EDA in the cloud: shall we be scared?

Calypto has been into low power (using notably sequential optimization techniques) and sequential verification for a while. And the company has always been very close to Mentor Graphics: it had integrated its verification tool with Catapult-C as early as 2005.

But the move came somewhat as a surprise, at least for me. Mentor has been touting itself has the leader in ESL, with some good reasons. Mentor had a strong offering in that space, including Catapult-C, and a consistent strategy.

Until now.

The decision of letting Catapult-C go has been sugar-coated, to say the least. Dixit Brian Derrick, VP marketing at Mentor Graphics: “We remain deeply committed to ESL. We view this transaction as an innovative way to accelerate adoption of ESL methodologies, to strengthen our partnership with Calypto, and as one that complements our continued investment in ESL virtual prototyping environments led by our Vista product”. Huhu.

It is hard to not interpret Mentor’s decision as a change of strategy, and a disengagement from ESL. The truth is, despite all the promises, ESL has been very slow to gain acceptance. After more than seven years, ESL’s market is still dwarfed by conventional synthesis, and even more by the cash cows that are simulation and physical verification. So from Mentor’s perspective, it may make sense to focus on better business opportunities.

Some will see in that transfer of ownership the proof that yet again, pushing EDA innovation to success is essentially left to startups. Wait, isn’t that the very purpose of startups?

Calypto, with the acquisition of Catapult-C, got a sweet deal. They have the opportunity to have a single environment for ESL synthesis and verification. Problem is, unless they provide a path for 3^rd party verification tool (read: Cadence and Synopsys) to independently check their synthesis, it will be difficult to substantially increase the number of their adopters. Best of luck to them though.

Related posts:

1. Is FPGA a sustainable market for EDA?
2. Automated low-power design flow is up for grabs (Part II)
3. Automated low-power design flow is up for grabs (Part I)

Serializing a primitive type like a bool, int, or float, is trivial: just write the data as it is (assuming that no compression is used). Serializing a pointer is different: the object it points to must be serialized first. That way deserializing the pointer simply consists of setting its value to the memory address at which the object has been reconstructed.

We can distinguish three levels of complexity in serialization, depending on how complex the pointer (and reference) graph is:

1. The pointer graph is a forest (i.e., a set of trees). Data can simply be serialized bottom up with a depth first traversal of the trees.
2. The pointer graph is a directed acyclic graph (DAG), i.e., a graph without loop. We can still serialize the data bottom up, making sure we write and restore shared data only once.
3. The pointer graph is a general graph, i.e., it may have loops. We need to write and restore data with forward references so that loops are handled properly.

It is always an option to serialize objects using your own customized code. However serialization is much more complex than a simple pretty-print method. One would like serialization to support the following features:

1. Serialization should be able to handle any pointer graph (i.e., with loops).
2. Serializing a pointer or a reference should automatically trigger the serialization of the referred object.
3. Serializing an entire data model can require a lot of code –from simple scalar fields (bool, int, float), to containers (vector, list, hash table, etc), to intricate data structures (graph, quad-tree, sparse matrices, etc). One would like templates that carry most of the burden.
4. The save and load functions must always be in sync: if the ‘save’ function is modified, the ‘load’ function must be changed appropriately. One would like that process to be automated as much as possible.
5. One should have a way of serializing objects without changing their .hpp files –this is known as non-intrusive serialization. The reason is that in many case one does not want (or one cannot) change the source files of existing libraries.
6. Serialization needs to support versioning. As objects evolve, data members are added or removed, and it is desirable to be back compatible –meaning, one can still deserialize archives from older versions into the most recent data model.
7. Serialization should be cross-platform compatible (32 and 64 bits machines, Windows, Linux, Solaris, etc).

The boost library provides a serialization that meets all the requirements above, and more:

• It is extremely efficient, it supports versioning, and it automatically serializes STL containers.
• Serialization (the save function) and deserialization (the load function) are expressed with one single template, which reduces the size of the code, and resolves the synchronization problem.
• With a little bit of help, boost serialization is also 32 and 64 bit compatible, which means that a database serialized on a 32 bit machine can be read on a 64 bit machine and conversely.
• Also boost serialization (respectively deserialization) takes an output (respectively input) argument that is very similar to a std::ostream (respectively std::istream), meaning that it can be a file on a disk, a buffer, or a socket. You can literally serialize your data over a network.

The best way to understand how to serialize with boost is to walk through increasingly complex serialization scenarios.

Basic serialization

The code for serialization, as well as an example that saves and restores simple objects, is given below.

#pragma once
// File obj.hpp

// Forward declaration of class boost::serialization::access
namespace boost {
namespace serialization {
class access;
}
}

class Obj {
public:
  // Serialization expects the object to have a default constructor
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_;
  }
private:
  int  d1_;
  bool d2_;

  // Allow serialization to access non-public data members.
  friend class boost::serialization::access;

  template<typename Archive>
  void serialize(Archive& ar, const unsigned version) {
    ar & d1_ & d2_;  // Simply serialize the data members of Obj
  }
};

The template ‘serialize’ defines both the save and load. This is achieved because the operator ‘&’ will be defined as ‘<<’ (respectively ‘>>’) for an output (respectively input) archive. Note the friend declaration to allow the save/load template to access the private data members of the objects. Also note that serialization expects the object to have a default constructor (which can be private).

#include "obj.hpp"
#include <assert.h>
#include <fstream>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

int main() {
  const char* fileName = "saved.txt";

  // Create some objects
  const Obj o1(-2, false);
  const Obj o2;
  const Obj o3(21, true);
  const Obj* const p1 = &o1;

  // Save data
  {
    // Create an output archive
    std::ofstream ofs(fileName);
    boost::archive::text_oarchive ar(ofs);

    // Write data
    ar & o1 & o2 & o3 & p1;
  }

  // Restore data
  Obj restored_o1;
  Obj restored_o2;
  Obj restored_o3;
  Obj* restored_p1;
  {
    // Create and input archive
    std::ifstream ifs(fileName);
    boost::archive::text_iarchive ar(ifs);

    // Load data
    ar & restored_o1 & restored_o2 & restored_o3 & restored_p1;
  }

  // Make sure we restored the data exactly as it was saved
  assert(restored_o1 == o1);
  assert(restored_o2 == o2);
  assert(restored_o3 == o3);
  assert(restored_p1 != p1);
  assert(restored_p1 == &restored_o1);

  return 0;
}

In main.cpp, we first include the files declaring the input and output text archives, where objects will be loaded from and saved to, respectively. We create an output archive (here, a file on a disk), and write three instances of class Obj, as well as a pointer to one of the instances. We then read them back and make sure we restore the data as they were. Note how the restored pointer restored_p1 points to the restored object restored_o1.

More on pointer serialization

Whenever we call serialization on a pointer (or reference), this triggers the serialization of the object it points to (or refers to) whenever necessary. So we do not need to explicitly serialize pointed objects as boost serialization will make sure the appropriate objects reached in the pointers graph are serialized.

For instance, the code below shows that serializing the pointer p1 triggers the serialization of o1, the object it point to. When restoring the pointer restored_p1, we automatically create a clone of the object o1.

#include "obj.hpp"
#include <assert.h>
#include <fstream>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

int main()
{
  const char* fileName = "saved.txt";

  // Create one object o1.
  const Obj o1(-2, false);
  const Obj* const p1 = &o1;

  // Save data
  {
    // Create an output archive
    std::ofstream ofs(fileName);
    boost::archive::text_oarchive ar(ofs);
    // Save only the pointer. This will trigger serialization
    // of the object it points too, i.e., o1.
    ar & p1;
  }

  // Restore data
  Obj* restored_p1;
  {
    // Create and input archive
    std::ifstream ifs(fileName);
    boost::archive::text_iarchive ar(ifs);
    // Load
    ar & restored_p1;
  }

  // Make sure we read exactly what we saved.
  assert(restored_p1 != p1);
  assert(*restored_p1 == o1);

  return 0;
}

When deserializing a pointer, the object it points to will be automatically deserialized if this object has not been deserialized yet. This means that one should not attempt to deserialize an object after a pointer to this object has been deserialized. The reason is that once the pointer deserialization has forced the object deserialization, one cannot rebuild this object at a different address.

#include "obj.hpp"
#include <fstream>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

int main()
{
  const char* fileName = "saved.txt";
  std::ofstream ofs(fileName);

  // Create one object o1 and a pointer p1 to that object.
  const Obj o1(-2, false);
  const Obj* const p1 = &o1;

  // Serialize object, then pointer.
  // This works fine: after the object is deserialized, we can
  // deserialize the pointer by assigning it to the object’s address.
  {
    boost::archive::text_oarchive ar(ofs);
    ar & o1 & p1;
  }

  // Serialize pointer, then object.
  // This does not work: once p1 has been serialized, the object
  // has already been deserialized and its address cannot change.
  // This will throw an instance of 'boost::archive::archive_exception'
  // at runtime.
  {
    boost::archive::text_oarchive ar(ofs);
    ar & p1 & o1;
  }

  return 0;
}

In the example above, the second serialization will result in a runtime error:

ocoudert@MyMacBookPro $ a.out
terminate called after throwing an instance of 'boost::archive::archive_exception'
    what():  pointer conflict
Abort trap
coudert@MyMacBookPro $

This means that when pointers need to be serialized, we should never explicitly serialize the objects they point to.

Explicit save and load function definitions

We need an explicit definition of the save and load functions whenever they are not fully symmetric. This is typical when versioning is involved. Note the use of the macro BOOST_SERIALIZATION_SPLIT_MEMBER(), which is responsible for calling save/load when using an output/input archive.

#pragma once

#include <boost/serialization/split_member.hpp>

class Obj {
public:
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_;
  }

private:
  int  d1_;
  bool d2_;

  friend class boost::serialization::access;

  template<class Archive>
  void save(Archive & ar, const unsigned int version) const {
    ar & d1_ & d2_;
  }

  template<class Archive>
  void load(Archive & ar, const unsigned int version) {
    ar & d1_ & d2_;
  }

  BOOST_SERIALIZATION_SPLIT_MEMBER()
};

Serialization of C-strings

A C-string cannot be directly serialized because it assumes a specific interpretation of a char*, namely an array of char terminated by a null character (‘\0’). Thus we need to explicitly serialized C-string. The class below is a simple helper to serialize C-strings (note that this can be optimized by avoiding the construction of the sdt::string).

#pragma once
// File SerializeCStringHelper.hpp

#include <string>
#include <boost/serialization/string.hpp>
#include <boost/serialization/split_member.hpp>

class SerializeCStringHelper {
public:
  SerializeCStringHelper(char*& s) : s_(s) {}
  SerializeCStringHelper(const char*& s) : s_(const_cast<char*&>(s)) {}

private:

  friend class boost::serialization::access;

  template<class Archive>
  void save(Archive& ar, const unsigned version) const {
    bool isNull = (s_ == 0);
    ar & isNull;
    if (!isNull) {
      std::string s(s_);
      ar & s;
    }
  }

  template<class Archive>
  void load(Archive& ar, const unsigned version) {
    bool isNull;
    ar & isNull;
    if (!isNull) {
      std::string s;
      ar & s;
      s_ = strdup(s.c_str());
    } else {
      s_ = 0;
    }
  }

  BOOST_SERIALIZATION_SPLIT_MEMBER();

private:
  char*& s_;
};

A simple example of its usage is as follows.

#include "SerializeCStringHelper.hpp"
#include <assert.h>
#include <fstream>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

int main()
{
  const char* fileName = "saved.txt";
  const char* str = "This is an example a C-string";

  // Save data
  {
    // Create an output archive
    std::ofstream ofs(fileName);

    boost::archive::text_oarchive ar(ofs);
    // Save
    SerializeCStringHelper helper(str);
    ar & helper;
  }

  // Restore data
  char* restored_str;
  {
    // Create and input archive
    std::ifstream ifs(fileName);
    boost::archive::text_iarchive ar(ifs);

    // Load
    SerializeCStringHelper helper(restored_str);
    ar & helper;
  }

  // Make sure we read exactly what we saved
  assert(restored_str!= str);
  assert(strcmp(restored_str, str) == 0);

  return 0;
}

Non-intrusive serialization

So far the serialization code is added in the class definition. A non-intrusive serialization, outside of the class, might be preferable. For instance we would like to serialize a class from a library without altering the library’s hpp file. This is easy when the data members are public:

#pragma once

class Obj {
public:
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_;
  }

public:
  int  d1_;
  bool d2_;
};

namespace boost {
namespace serialization {

template<typename Archive>
void serialize(Archive& ar, Obj& o, const unsigned int version) {
  ar & o.d1_ & o.d2_;
}

} // namespace serialization
} // namespace boost

If we want to protect the data members, the code is a bit more complicated because the serialization template needs to be declared as a friend. This requires a forward declaration of the template.

#pragma once

//// Declaration of the template
class Obj;

namespace boost {
namespace serialization {

template<typename Archive>
void serialize(Archive& ar, Obj& o, const unsigned int version);

} // namespace serialization
} // namespace boost

//// Definition of the class
class Obj {
public
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_;
}

private:
  int  d1_;
  bool d2_;

  // Allow serialization to access data members.
  template<typename Archive> friend
  void boost::serialization::serialize(Archive& ar, Obj& o, const unsigned int version);
};

//// Definition of the template
namespace boost {
namespace serialization {

template<typename Archive>
void serialize(Archive& ar, Obj& o, const unsigned int version) {
ar & o.d1_ & o.d2_;
}

} // namespace serialization
} // namespace boost

Non-intrusive explicit save and load function definitions

This combines the two previous serialization styles, except that the include file and macro are different. For the sake of simplicity, we give the version for public data members.

#pragma once

#include <boost/serialization/split_free.hpp>

class Obj {
public:
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_;
  }

public:
  int  d1_;
  bool d2_;
};

namespace boost {
namespace serialization {

template<class Archive>
void save(Archive & ar, const Obj& o, const unsigned int version) {
  ar & o.d1_ & o.d2_;
}

template<class Archive>
void load(Archive & ar, Obj& o, const unsigned int version) {
  ar & o.d1_ & o.d2_;
}

} // namespace serialization
} // namespace boost

BOOST_SERIALIZATION_SPLIT_FREE(Obj)

Serialization of STL containers

The boost library comes with templates to automatically serialize STL containers, as well as some STL objects (e.g., std::string). Instead of saving/loading a vector with the following code:

template<typename Archive>
void save(Archive& ar, const std::vector<Obj>& objs, const unsigned version) {
  ar << objs.size();
  for (size_t i = 0; i < objs.size(); ++i) {
    ar << objs[i];
  }
}

template<typename Archive>
void load(Archive& ar, std::vector<Obj>& objs, const unsigned version) {
  size_t size;
  ar >> size;
  objs.resize(size);
  for (size_t i = 0; i < size; ++i) {
    ar >> objs[i];
  }
}

One simply writes:

#include <boost/serialization/vector.hpp>

template<typename Archive>
void serialize(Archive& ar, std::vector<Obj>& objs, const unsigned version) {
  ar & objs;
}

All the STL containers are supported using the appropriate include files:

#include <boost/serialization/array.hpp>
#include <boost/serialization/vector.hpp>
#include <boost/serialization/hash_map.hpp>
#include <boost/serialization/hash_set.hpp>
#include <boost/serialization/list.hpp>
#include <boost/serialization/slist.hpp>
#include <boost/serialization/map.hpp>
#include <boost/serialization/set.hpp>
#include <boost/serialization/bitset.hpp>
#include <boost/serialization/string.hpp>

Serialization of base class

When a class inherits from another, the base class needs to be serialized as well.

#include <boost/serialization/base_object.hpp>

class Base {
public:
  Base() : c_('\0') {}
  Base(char c) : c_(c) {}
  bool operator==(const Base& o) const { return c_ == o.c_; }

private:
  char c_;

  friend class boost::serialization::access;

  template <typename Archive>
  void serialize(Archive& ar, const unsigned version) {
    ar & c_;
  }
};

class Obj : public Base {
private:
  typedef Base _Super;
public:
  Obj() : _Super(), d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : _Super('a'), d1_(d1), d2_(d2) {}
  bool operator==(const Obj& o) const {
    return _Super::operator==(o) && d1_ == o.d1_ && d2_ == o.d2_;
  }

private:
  int  d1_;
  bool d2_;

  friend class boost::serialization::access;

  template <typename Archive>
  void serialize(Archive& ar, const unsigned version) {
    ar & boost::serialization::base_object<_Super>(*this);
    ar & d1_ & d2_;
  }
};

Versioning

We want maintain back-compatibility when the class Obj evolves. For instance, if a new data member ‘ID_’ is added, we want to read an old archive and build new Obj, with the missing data member taking the default value.

#pragma once

#include <boost/serialization/split_member.hpp>
#include <boost/serialization/version.hpp>

class Obj {
public:
  Obj() : d1_(-1), d2_(false), ID_(0) {}
  Obj(int d1, bool d2, unsigned ID id) : d1_(d1), d2_(d2), ID_(id) {}
  bool operator==(const Obj& o) const {
    return d1_ == o.d1_ && d2_ == o.d2_ && ID_ == o.ID_;
  }

private:
  int  d1_;
  bool d2_;
  unsigned ID_;

  friend class boost::serialization::access;

  template<class Archive>
  void save(Archive & ar, const unsigned int version) const {
    ar & d1_ & d2_ & ID_;
  }

  template<class Archive>
  void load(Archive & ar, const unsigned int version) {
    ar & d1_ & d2_;
    // If archive’s version is 0 (i.e., is old), ID_ keeps
    // its default value from the new data model,
    // else we read ID_’s value from the archive.
    if (version > 0) {
      ar & ID_;
    }
  }

  BOOST_SERIALIZATION_SPLIT_MEMBER()

};

Serialization of const data or objects

Attempting to serialize a const data or object triggers a long trail of error messages, which includes something that looks like:

[snip]

/opt/local/include/boost/archive/detail/check.hpp:162: error:
  invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>‘

[snip]

/opt/local/include/boost/archive/basic_text_iprimitive.hpp:88: error:
  ambiguous overload for ‘operator>>‘ in
  ‘((boost::archive::basic_text_iprimitive<std::basic_istream<char,
       std::char_traits<char> > >*)this)->boost::archive::basic_text_iprimitive<std::basic_istream<char,
         std::char_traits<char> > >::is >> t’

This means that the input archive expects the recipient of the data to be non-const. Thus const data members must be const_cast<>()’ed to be serialized. For example:

#pragma once

#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

class Obj {
public:
  Obj() : d1_(-1), d2_(false) {}
  Obj(int d1, bool d2) : d1_(d1), d2_(d2) {}

private:
  const int d1_;
  bool d2_;

  // Allow serialization to access data members.
  friend class boost::serialization::access;

  template<typename A>
  void serialize(A& ar, const unsigned version) {
    ar & const_cast<int&>(d1_) & d2_;
  }
};

Text, XML, and binary archives

The text archive is an ASCII file that is somewhat human readable. There are other archive types available in boost/archive/*.hpp, e.g.:

// Text archive that defines boost::archive::text_oarchive
// and boost::archive::text_iarchive
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

// XML archive that defines boost::archive::xml_oarchive
// and boost::archive::xml_iarchive
#include <boost/archive/xml_oarchive.hpp>
#include <boost/archive/xml_iarchive.hpp>

// XML archive which uses wide characters (use for UTF-8 output ),
// defines boost::archive::xml_woarchive
// and boost::archive::xml_wiarchive
#include <boost/archive/xml_woarchive.hpp>
#include <boost/archive/xml_wiarchive.hpp>

// Binary archive that defines boost::archive::binary_oarchive
// and boost::archive::binary_iarchive
#include <boost/archive/binary_oarchive.hpp>
#include <boost/archive/binary_iarchive.hpp>

The text and XML archives are portable across 32 and 64 bits platforms.

Having a binary archive that is portable between 32 and 64 bits is not trivial, because C++ does not specify exactly the size of primitive types. For instance a long is usually 4 bytes on a 32 bits machine, and 8 bytes on a 64 bits machine. In practice though it is pretty portable –there is a non-official version for a portable binary archive.

Related posts:

1. How to write abstract iterators in C++
2. How to make software deterministic

Refining this definition, we should consider whether a program produces the same result on any platform (32 and 64 bits machines, running Windows, Mac OS, Linux, Solaris, etc). Or whether the program is insensitive to the form of its inputs. For example, the problem of generating the shortest route to visit all the capitals of Europe should not depend on how the map of Europe is entered, nor it should depend on which language is used to name the capitals.

Determinism is obviously very desirable. For the user, a non-deterministic program can be confusing and frustrating. For the developer, a non-deterministic program is extremely hard to test and debug, since bugs and specific configuration cannot be easily reproduced.

Repeatability looks like a given for most applications. For instance, if we add two numbers in a spreadsheet, we expect the same result no matter how many times we perform this operation and regardless of the platform we run on (PC, Mac, etc). Or if we run a spell checker several times, we expect it to flag the very same errors.

But it is not that obvious for more complex applications. This is especially true when there are multiple solutions to a problem, or when heuristics are used to produce a result –because an exact solution is too computationally expensive. For example, it is not uncommon to see slightly different outcomes when running the same EDA synthesis or P&R tool on the same input several times.

Even more, a user would like to see the same result when only minor changes are applied to the input. For instances, running a P&R tool on two netlists that differ only by the names of their cells should produce exactly the same result –a P&R tools should produce a result that only depend on the netlist structure. But experience shows that industrial synthesis and P&R tool does not meet that requirement. Closest to software, it is not uncommon to generate slightly different object codes with gcc by changing the names of a few variables.

Among the causes of non-deterministic response, we can distinguish the following types:

1. A random number generator
2. Reading an uninitialized data
3. A race condition on concurrent threads
4. An unordered iteration that is assumed ordered
5. A total order that depends on memory address
6. A total order that depends on time stamps
7. A total order that depends on a non-canonical labeling

1. Random number generator

There are a lot of applications that use stochastic processes (e.g., simulated annealing, genetic algorithms, Monte-Carlo simulations), but that we would like to be repeatable. Using a pseudorandom number generator with a known seed makes possible to reproduce the same long sequence of seemingly random numbers over and over again.

Note that some applications (e.g., gaming, cryptography, statistical sampling) require a non-deterministic behavior. In that case the seed of the random number generator must be an always-changing value, for example the host’s current time.

There are more deliberate efforts to produce true random values by relying on natural, chaotic events. For instance Lavarand produces random numbers by hashing the frames of a video stream of lava lamps. HotBits generates random bits by timing successive pairs of radioactive decays detected by a Geiger-Müller tube interfaced to a computer. Random.org uses variations in the amplitude of atmospheric noise recorded with a normal radio.

2. Uninitialized or random data read

Initialized data may not exist in languages that have systematic default values and no memory management control, as opposed to high performance languages like C/C++.

Finding and fixing this kind of issues is relatively simple. For instance, tools like Purify and Valgrind can report when a C/C++ code reads arbitrary values in memory. To use Purify’s terminology, such errors are UMR (Uninitialized Memory Read), ABR (Array Bound Read, i.e., dereferencing an array outside of its bounds), and FMR (Free Memory Read). These defects all consist in reading some random value in memory.  The code below illustrates some of these errors.

#include
#include 

int main() {
  bool large;
  int size = 100;

  if (large) {                    // UMR
    size *= 10;
  }

  char* const str    = new char(size);
  char* const middle = str + size/2;
  // Set the end-of-string.
  str[size - 1] = '\0';
  // The loop intends to fill up the string str with 'a'.
  // But this loop is faulty, because *++c is used instead of *c++.
  char* c = str;
  for (int i = 1; i < size; ++i, *++c = 'a');

  printf("%c\n", str[0]);         // UMR
  printf("%c\n", str[1]);         // Ok, will print 'a'.
  printf("%c\n", str[2]);         // Ok, will print 'a'.
  printf("%c\n", str[size - 1]);  // Ok, but will print 'a'
                                  // instead of the expected '\0'.
  printf("%c\n", str[size]);      // ABR
  printf("%lu\n", strlen(str));   // UMR, because we overwrote
                                  // the final '\0' in the loop.
  delete [] str;
  printf("%c\n", *middle);        // FMR

  return 0;
}

Note that an ABW (Array Bound Write, i.e., writing outside of an array’s bounds), FMW (Free Memory Write), FNH (Freeing Non-Heap memory) and FUM (Freeing Unallocated Memory), although severe bugs also reported by dynamic analysis tools, are not an original source of non-determinism: they consistently reproduce the same bug.

3. Thread races

Thread races are difficult to detect, and fixing them can be very costly. A typical example is when one thread writes a value at some address, and another thread reads the value at that address. Depending on which thread access the address first, the outcome of the program will be different. Two threads performing a non-atomic write at the same address simultaneously results in some unpredictable value.

One can use a mutex to prevent conflicting read/write for non-atomic operations. But racing threads (e.g., who reads/writes first) must be resolved with synchronization, which can be quite complicated. Moreover it can hurt performances.

4. Iteration on unordered data

Iterating data with some random order can make a program non repeatable. This pattern is often encountered, and is easy to fix.

For example an algorithm produces a result via a visitor that assumes a total order. The developer uses an incorrect visitor, which enumerates data in a random order, usually depending on the memory allocation of the data container. E.g., instead of using a std::set as a container, the developer uses a std::hash_set (or a tr1::unordered_set instead of a tr1::ordered_set). Forcing a total order on the data fixes the problem.

Note that the fix may be incomplete if it simply transforms a type (4) non-determinism into a type (5) or (6) non-determinism, which we discuss below.

5. Ordering by pointer value

This type of non-determinism is extremely common. For instance, a developer uses a tr1::ordered_set as a container of pointers, and feels that the visitor is deterministic. It is indeed deterministic, but only w.r.t. the memory addresses allocated to the data, which depend on factors out of the application’s control.

One way of addressing the problem is to force a specific memory addressing scheme, but that requires a very fine control of the memory allocator and is therefore complicated.  A more common way consists in assigning a unique ID to an object at the time of its creation. The ID can be a 32 bit unsigned integer that is incremented for every new object. A total ordering, independent from the objects’ actual memory addresses, is then obtained from the IDs. It is a simple solution, as long as one can afford the extra 4 bytes for every object. ID-based sorting with no memory penalty can be obtained using custom memory allocators.

6. Ordering by time stamps

Note though that the total ID-based ordering described above is exactly the order of creation of the objects. It is no different from an order that depends on time stamps. Therefore two equal sets of inputs that only differ in the order will be visited in a different order, which can lead to different results. This leads us to the type (7) of non-determinism.

7. Ordering induced by a non-canonical labeling

Type (7) non-determinism often goes unrecognized, or is simply ignored. The idea is that as long as the same input is given to a program (but possibly in a different order or form), the output should be the same. If the input can somehow be normalized to a form that captures the notion of “same input”, then the program can be made insensitive to the format of the input. That is of course assuming that the normalization process run time penalty is not too high.

This normalization process is better defined as canonization. Formally, let O be a set of objects, and let EQ be an equivalence relation that captures the notion of “same” on these objects. A function Canon maps an object onto its canonical form, and is such that for any two objects o1 and o2, o1 and o2 are the same (i.e., o1 EQ o2) if and only if Canon(o1) = Canon(o2).

For instance, a set of integers can be represented by a number of containers (a list, an array, a hash set, a binary tree, etc). A canonical form can simply consist in sorting the integers. Two sets that are equal because they contain the very same integers, but that are initially given in different orders and forms, will end up in the same canonical form. Since sorting is an O(n log n) algorithm, this is an efficient canonization.

Canonization can be much more costly. A Boolean function can be represented in many ways, e.g., with a truth table, a Conjunctive Normal Form (CNF), a Disjunctive normal form (DNF), a decision diagram, etc (see below). Boolean function canonization is at least NP-hard, since it solves the satisfiability problem (SAT). In practice this means that Boolean function canonization algorithms have an exponential complexity.

Canonization can also be elusive. Let us consider the problem of drawing a graph in some aesthetic way (e.g., such that the nodes are evenly distributed and such that there is a minimum number of crossing edges). One would like the graph to be drawn the very same way, regardless of its representation (adjacency list or adjacency matrix), and regardless of the order the adjacency information is given. For instances the three graphs below, although looking different, are exactly the same, and can be drawn without any edge crossing as shown on the right side.

Graph canonization is also known as graph labeling. It is at least as hard as graph isomorphism, one of these rare problems that are in NP but that are not known to be NP-complete or in P. Although all existing graph canonization algorithm have an exponential worst-case complexity, it is believed that graph canonization can be done in polynomial time.

Conclusion

The most common  cause for non-determinism is related to some unreliable data order. The ultimate solution to make a program insensitive to the form of its input is to canonize its input as a pre-processing step. This proves to be a challenging and costly task in some cases. Whenever possible, canonization (or some imperfect normalization) goes a long way to make the application consistently repeatable.

Related posts:

1. What is software quality?
2. Test-driven design, a methodology for low-defect software
3. How to write abstract iterators in C++

Amazon released a full description of what happened. In a nutshell, Amazon shifted traffic in one of its zones from one network to another in order to upgrade a network. The traffic was mistakenly shifted to a lower capacity network, which was unable to handle the traffic. This caused Amazon EBS volumes (Elastic Block Store, a persistent storage unit for database and file system) in one US East Region zone to become unable to perform read/write operations.

Besides the many websites taken down during the outage, it turned out that 0.07% of the data stored in the EBS volumes in one zone have also been lost. Chartbeat reports losing 11 hours of historical data to their customers saying it is ‘irrecoverable’.

Since then a lot has been written about the dangers of the cloud. It looks like Amazon’s outage brought weight to those opposing security concerns against EDA’s cloud aspirations. What to think of Synopsys’ recent announcement that they will provide SaaS in Amazon Web Services?

But many companies that are entirely relying on Amazon’s cloud services were not significantly affected by the outage. Twilio did not shut down. And more notably, Netflix, which runs its massive infrastructure entirely in Amazon’s cloud, did not shut down.

Why were some websites taken down while others were unaffected? Because some systems are designed to be resilient to all sort of failures. Taken from Netflix’ experience when moving its infrastructure to AWS:

“One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.”

In short, being in the cloud does not mean you are inherently safer or more exposed. It means that you have to design your system so that it can recover from defects –any defect. From G. Reese in O’Reilly:

“If your systems failed in the Amazon cloud this week, it wasn’t Amazon’s fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon’s cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.”

And I’ll stand by this too.

Related posts:

1. Cloud computing: an opportunity for EDA
2. Synopsys is getting into the cloud
3. Plunify, a glimpse at EDA in the cloud