Get your money back in 4 weeks

By on June 6, 2017   /   Uncategorized  
Tags: , , , , , , , , , , , , , , ,
Exostiv pays back in 2 weeks

Get your money back in 4 weeks

Debug productivity is notoriously hard to sell.

Engineers who ask budgets for debugging tools are still too often blamed by the Management for creating the bugs in first instance.
(‘Why would I pay more for correcting the bugs that YOU inserted in the design?’).

Putting a value on debugging is a particularly hard task… It is all about reducing the time spent on debugging but how much does it really cost and how can we be sure that a specific tool really brings an improvement?

Saving how much of the engineering time would justify buying EXOSTIV?
A rule of thumb is 4 weeks per year (or even as low as 2 weeks for the lucky ones located in high salary areas).

A good example

I recently visited a company where the engineering team wanted to evaluate EXOSTIV on an existing board. This board was mounted with an FPGA supported by EXOSTIV and featured a single SFP connector. As such, it was usable ‘out of the box’. We offered to set up the project files for EXOSTIV with the engineering and within 30 minutes, we could insert a debug EXOSTIV IP into the target design. As we did it ourselves, there was no initial setup cost nor learning curve cost in this example. After FPGA implementation, EXOSTIV connected right away and we could capture data. A good demonstration as it seemed. After 2 hours, I left the engineering team with a trial unit of EXOSTIV and allowed them to use it for free 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. Configuring transceivers required some additional experience to understand the metrics, clock sources and so on, but this was general knowledge of FPGA structure that any engineer should learn someday.

Then, they told me that the visibility provided by Exostiv had allowed them to find and correct a bug in an Ethernet IP, that they had not been able to see before, because their tools could not reach such debug scenarios. They were about to go to production and said that the result was ‘invaluable’. This result had totally exceeded my expectations.

I was absolutely delighted.
I expected to receive a purchase order the same day.

I was wrong.

When ‘invaluable’ kills business

Actually, they were puzzled. They somehow went to the conclusion that EXOSTIV was priced too high because our model involves subscribing for EXOSTIV software for a minimum of 12 month – and here the bug resolution had been so fast… (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
EXOSTIV had revealed an issue that they were not aware of – and before being painful to anyone.

And what about the management? Practically, nothing harmful had happened at all – so the management was not even considering a purchase…

Missed market opportunity cost

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.

This cost is called ‘(missed) market opportunity cost’ and can be estimated at the value of the market that is left to the competitor because you are delaying your product launch. Even if this cost can be 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 EDA tool to debug FPGA. The value can hardly be estimated accurately and its consequences are usually unpredictable and too distant. Much too complicated…

Bottom line: ask the right 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. And it si your responsibility as an engineer to find them.

– Can EXOSTIV help you find them? You bet. EXOSTIV provides unprecedented visibility.

And finally:

– Why would you reserve a budget for EXOSTIV? Because it pays back if you save 4 weeks of engineering per year. And this can be 4 weeks total for a team that shares one license.

Thank you for reading.
– Frederic

Back to Top

‘My FPGA debug and verification flow should be improved…’

By on September 25, 2015   /   Uncategorized  
Tags: , , , , , , , , , ,
Improve the FPGA debug flow

‘My FPGA debug and verification flow should be improved…’

In my last post, I revealed some of the results of our recent survey on FPGA. These results depicted a ‘flow-conscious’ FPGA engineer, using a reduced mix of methodologies in the flow and very prone to going to the lab for debugging.

In the same survey, we tried to evaluate the level of satisfaction of the FPGA engineer for his/her debug and verification flow. We asked the respondents to select among several propositions the one that the most closely matched their thinking. See the picture below (click on picture to zoom).

Recognition of the need to improve the FPGA debug flow

More than 70% of the respondents recognize the need to improve the FPGA debug and verification flow.

The chart above represents the answers of the respondents active with an FPGA design, and actually using FPGA as a target technology. 72% of them recognize the need to improve the FPGA debug flow and nearly 40% of them are actively looking for a solution for it.

Are these survey results representative of the whole industry? Well, you tell me. Contact me to share your personal experience – and I’ll update this post.

– Oh, and by the way, as I write this, we are about to release our EXOSTIV solution. It improves the visibility on FPGA running at speed by a factor of up to 200.000 ! See below a preview of what we’re about to release. More information will be available soon.

EXOSTIV Dashboard software screenshot preview

Thank you for reading.
– Frederic

Back to Top

What are your ready to mobilize for FPGA debug?

By on March 12, 2015   /   Uncategorized  
Tags: , , , , , ,

What are you ready to waste mobilize?

I believe that there are 3 common misconceptions about debugging FPGA with the real hardware:

Misconception #1:
Debugging happens because the engineers are incompetent.

Misconception #2:
FPGA debugging on hardware ‘wastes’ resources.

Misconception #3:
A single methodology should solve ALL the problems.

Debugging is part of the design process.

Forget about misconception #1. If the word ‘debugging’ hurts your eyes or your ears, call it ‘functional verification’, ‘functional coverage’, ‘corner case testing’ or perhaps ‘specification check’. Engineers can improve the techniques, methodologies and its competences. Engineers can seek ways to automate the verification process. It remains that verifying a design is at the heart of any engineering activity that presents some level of complexity. Electronic system design has become an incredibly complex task.

Even the best engineer does some verification.

Debugging does not happen over the air.

You need to reserve resources for debug.

It can be ‘hardware resources’– e.g.:

– FPGA resources, like I/Os, logic and memory;
– PCB resources, like a connector, some area on the PCB used to collect the data and maintain its integrity.
…

It can be ‘engineering resources’ – typically the time spent by the engineering team to find a bug with the chosen debugging strategy.

In all cases, the project budget is impacted with additional costs:
– the cost for an extra area on the PCB;
– the extra cost of an FPGA with a larger package or a higher speed grade;
– the cost of a new logic analyzer or a scope;
– the engineering hours cost for implementing a specific debugging strategy.
…

Engineers are assigned the task to optimize the cost of a design. Once the system goes to production, the extra money put in the system ‘real estate’ that does not participate to the system’s functionality is considered as wasted margin. Management constantly recalls that any such dollar is worth saving because it quickly multiplies once the system is produced in (large) series.

Hence ‘hardware engineers’ are naturally inclined to:
– save on hardware, and:
– do more ‘engineering’ (after all, we are engineers !)

Actually every stage of the design flow mobilizes resources.
What can be mobilized to do the job is essentially a trade off -or, if you prefer- a question of economics.

You must mobilize some of your ‘real estate’

In my previous post, I came to the conclusion that improving the FPGA debugging process would require providing much more visibility on the FPGA than the existing solutions. Mobilizing more FPGA I/Os or FPGA memory resources would likely not provide this increased visibility. Hence, a potential better solution would need to hit a ‘target position’ shown on the diagram below and now occupied with our EXOSTIV™ solution.
Exploring the FPGA debug solutions space

As one can expect, the above target requires mobilizing other resources than I/O or internal memory.
Yugo System’s EXOSTIV™ mobilizes the following resources:
– An external memory of up to 8GB, thereby providing a total trace capacity 100.000 times bigger than existing embedded instrumentation solution.
– FPGA transceivers, used to send the data to the external memory.
– FPGA logic and FIFO resources used to reach the FPGA internal nodes and temporarily store the data trace. The footprint of this IP on the FPGA memory resources does not grow with the total captured trace.

Part of the talent of the engineer consists in selecting the right techniques to reach a goal more efficiently

Engineers commonly complaint about verification on hardware because it does not offer the same level of visibility as simulation. I believe that the secret to efficient debugging consists in finding the right mix of techniques.

What is the right mix for you? Well, the answer depends on the economics of your project.
But please bear in mind that going early to hardware is absolutely reachable economically when you work on a FPGA-based system.

Performing some of the verification steps with the target hardware has arguably at least 2 benefits:

1) Speed of execution is optimal – as the target system runs… at system speed – and:

2) The target hardware can be placed in its real environment and won’t suffer from incomplete modeling.

Perhaps the point is all about improving the debugging on hardware, not simply discard it because it does not do ‘everything’…

Debugging involves a mix of techniques

At Yugo Systems, we believe that the engineering community is absolutely right when it chooses to use embedded instrumentation with live designs for debugging purposes. This is just a ‘part of the mix’. We also believe that debugging on FPGA hardware can be improved.

This is what we do with EXOSTIV™.

Back to Top