IC Mask SemiWiki Webinar Banner
WP_Term Object
(
    [term_id] => 106
    [name] => FPGA
    [slug] => fpga
    [term_group] => 0
    [term_taxonomy_id] => 106
    [taxonomy] => category
    [description] => 
    [parent] => 0
    [count] => 339
    [filter] => raw
    [cat_ID] => 106
    [category_count] => 339
    [category_description] => 
    [cat_name] => FPGA
    [category_nicename] => fpga
    [category_parent] => 0
)

When Invaluable Kills Business

When Invaluable Kills Business
by Frederic Leens on 12-11-2017 at 7:00 am

Productivity is notoriously hard to sell. I recently visited a company where the engineering team wanted to evaluate one of our FPGA debug and analysis products on an existing board. This board had an FPGA that we supported and had all the required connectivity – it could just be used ‘out of the box’. Our tool – Exostiv – involves the insertion of a debug IP in the FPGA. We offered to set up the tool with the engineering team and within 60 minutes, the board was instrumented and ready to use. As I did it by myself, there was no initial setup cost nor learning curve cost in this example.

Well, a good demonstration as it seemed… After 2 hours of discussion and having shown the product’s main features, I left the engineering team a unit with a license until the next day.

The next day, the engineering team told me that the tool was easy to use for those used to JTAG-based logic analyzers such as Chipscope / Xilinx logic analyzer. Basically, the flow was identical. Specific items like transceivers configuration required some additional understanding of the parameters, but overall, they said the setup and trial had run pretty smoothly.

20802-exostiv-ultrascale.jpg

Then, they told me that our tool had allowed them to find and correct a bug in an Ethernet IP that they were unaware of. With our tool, they had been able to cover a specific test scenario that had not been explored until then. They were about to send the board and the firmware to production and said that this new result was‘invaluable’.

As for me, I was absolutely delighted. This trial had totally exceeded my expectations. I expected to receive a purchase order the same day.

I was wrong.

Actually, they were puzzled. They somehow went to the conclusion that our tool was priced too high because our model involves subscribing for our software for a minimum of 12 month – and here they had resolved the bug so quickly… (I am still perplexed by this reasoning).

Anyway, they decided to wait until they had a new bug or alert that could *justify* buying the tool. Practically, this means waiting until ‘someone’ (a customer?) complains after the system is released.

They had discovered an issue that they were not aware of – and before it had become painful to anyone…

And what about the management? He was almost not aware of it. Practically, nothing harmful had happened at all – so nobody was even considering a purchase…

This – real – case is a little extreme, I agree – and I certainly do not know all the details of the decision process in this company.

However, we are seeing a real trend this days of engineering ‘waiting for pain’ and then look for a remedy for it.

The problem with this approach can be a severe loss of money.

Going to production with unknown bugs has a cost that generally reduces to how much market (share) you’ll loose by arriving late on the market with a working product. In this case, it seemed that the product was already reasonably stable: the engineering team was perfectly qualified and had not seen anything wrong (somehow someone had second thoughts or doubts, since they showed some interest in testing our solution). This cost can be estimated at the value of the market that is left to the competitor because you are delaying your product launch – or fixing the product.

Even if this cost is very large (loosing a few % of market share should be a lot of money – or you do not address a market that is large enough), it can have no impact on a decision to invest in a new hardware or software EDA tool to debug and analyse electronic systems in the late stages.

My opinion is that it is usually too complicated for many companies to put a number on it. The value cannot be estimated accurately and its consequences are usually unpredictable and too distant. We are constantly working at gathering such numbers… But who really believes the salesman who tries to frighten the customer to get a sale…? As a professional, I am personally inclined to calling to the intelligence of my prospects, not their fear…

In my opinion, as an electronic engineer, we should all ask ourselves the following questions:

– Will there be bugs in your design?Absolutely. FPGA are such complex beasts that this cannot be avoided. No wonder why 40% of the total design time is spent on debug and verification.
– When do those bugs cost the most? When they ‘escape’ to production: the cost of having to stop the production and get back to design is gigantic.
– Who is responsible to avoid this?The engineering team.
– Why would you reserve a budget for any tool?Because it pays back.

It pays back first from the saved engineering hours. It pays MUCH MORE back if the tools help avoid bugs escaping to production, even on FPGAs.

Thank you for reading.
– Frederic

Share this post via:

Comments

6 Replies to “When Invaluable Kills Business”

You must register or log in to view/post comments.