cloud design flow

[alb]

Hi there,

I was wondering if there's any one out there working with a cloud design
flow which is tool agnostic.

The reason for asking is that I'm trying to evaluate if there's a way to
integrate the benefits of a cloud service (with more hardware resources
than our inhouse ones) into our design flow.

We clearly noticed that several times our simulations would take too much
time and we prefer to go directly to the bench in order to verify a
specific function. This approach forces us to rely on the bench
availability (which is not always granted) and may not always be efficient
(we need to set up special configurations which gives us greater
observability/controllability on the bench).

Another main advantage is the design space exploration: having much more
power available would result in the possibility to throw more cpus at a
specific problem, hence addressing the issue faster.

Last but not least, regression testing and automated testing can be a
great advantage of moving to the cloud. Any new module/component which is
ready to be integrated in the overall design can be automatically included
in the regression suite which is regularly running and can spot early
integration issues.

So far I've heard/read about 'Plunify', which supports the Quartus
software in the cloud, but we are working with Microsemi (former Actel)
devices and there's nothing available out of the box.

Should we set up the environment the hard way, i.e. a set of scripts to
handle the flow remotely? This might require a great initial effort but it
has the benefit that we know what we are doing and we can fix it anytime
an issue arises (provided that the share of time devoted to fixing
problems doesn't eat designing time!). Or maybe there are tools out there,
or services, which are already providing such environments?

Ideas/comments/suggestions are more than welcome.
Cheers,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[alb]

alb <al.basili@gmail.com> wrote:

I was wondering if there's any one out there working with a cloud design
flow which is tool agnostic.
[]

uhm, considering the amount of replies to this thread I have only two
possibilities to choose from:

1. nobody is using such paradigm in this community
2. nobody using this paradigm is willing to share it with this community

In both cases I'm out of luck and guess that if I ever want to go down
this path I'll be doing it on my own.

 

[HT-Lab]

On 13/03/2014 09:00, alb wrote:

alb <al.basili@gmail.com> wrote:
I was wondering if there's any one out there working with a cloud design
flow which is tool agnostic.
[]

uhm, considering the amount of replies to this thread I have only two
possibilities to choose from:

1. nobody is using such paradigm in this community
2. nobody using this paradigm is willing to share it with this community

In both cases I'm out of luck and guess that if I ever want to go down
this path I'll be doing it on my own.

Hi Al,

It is not a paradigm, it is simply not a viable business model for most
EDA companies. If you look at Plunify for example you will see they only
managed to signed up 2 companies since 2011(?) and neither of them is
any of the big 3.

In addition most companies prefer to keep their regression testing
in-house. Splashing their crown jewels onto some cloud server in a
foreign country is simply too risky. Also, you nearly always have to
tweak your regression suite and doing it in the cloud might add an extra
layer of hassle.

Regards,
Hans
www.ht-lab.com

 

[alb]

HT-Lab <hans64@htminuslab.com> wrote:

On 13/03/2014 09:00, alb wrote:
alb <al.basili@gmail.com> wrote:
I was wondering if there's any one out there working with a cloud design
flow which is tool agnostic.
[]

It is not a paradigm, it is simply not a viable business model for most
EDA companies. If you look at Plunify for example you will see they only
managed to signed up 2 companies since 2011(?) and neither of them is
any of the big 3.

This is quite interesting indeed, but surprising as well. When it comes
to high computation demand it seems so obvious to move to a cloud
service. Actually before the buzzword 'cloud' jumped in it was called
'grid', where several farms/computer centers were connected together in
order to increase throughput.

In addition most companies prefer to keep their regression testing
in-house. Splashing their crown jewels onto some cloud server in a
foreign country is simply too risky.

I honestly find this quite insane, the same companies are exchanging
confidential information via much less secure means like emails, faxes
or phone lines, without anyone bothering about encryption.

A two keys encryption mechanism would be safe enough to prevent any
intrusion. But if you really want to get paranoid there are other
technologies available like quantum criptography.

Also, you nearly always have to
tweak your regression suite and doing it in the cloud might add an extra
layer of hassle.

this I may take as an argument. Nevertheless I find it quite strange that each
one should build its own computer farm to handle big regression suites with all
the maintenance cost it goes with it.

Not only that, how many in-house solutions we have to develop and debug
constantly? On top of that in-house solutions are rarely scalable unless
a big effort is put in it from the very beginning, again requiring a
large investment in the IT department, ending up with more network
specialists than FPGA designers.

 

[Sean Durkin]

alb wrote:

In addition most companies prefer to keep their regression testing
in-house. Splashing their crown jewels onto some cloud server in a
foreign country is simply too risky.

I honestly find this quite insane, the same companies are exchanging
confidential information via much less secure means like emails, faxes
or phone lines, without anyone bothering about encryption.

A two keys encryption mechanism would be safe enough to prevent any
intrusion. But if you really want to get paranoid there are other
technologies available like quantum criptography.

The problem is not so much getting the data to the cloud service
securely. The problem is trusting the cloud company to protect the data
once it is on their servers.

Since Snowden it is known that all the major companies that provide
cloud services are constantly subjected to court orders forcing them to
give the authorities access to pretty much anything that is stored on
their servers or otherwise handled there, and to the information as to
who is doing what with their services.

And since Snowden it is know that this is not only done if there are
suscpicions of crime or terrorism, but also as a tool of corporate
espionage (see http://tinyurl.com/o5cuneg).

So for any European company it is more or less out of the question to
use cloud services for anything important anymore these days. Especially
not cloud services that are offered by companies that are US-based. Not
because they are evil, but because they are subject to US laws that
force them to grant access and disclose pretty much anything.

So, cloud storage? Maybe, but only if data is encrypted properly BEFORE
it is put there. Cloud computing for my simulations and synthesis? No
way am I uploading my project data anywhere I don't have complete
control over.

This may sound like paranoia, but it is not. It seems that nowadays
every week there's a new revelation proving reality is even worse than
what paranoid luncatics have had nightmares about for decades...

Fortunately, my designs are not big enough to require server farms, so
for me personally cloud services are of no interest anyway.

 

Hi,

My name is Harnhua; I'm one of Plunify's founders and I just wanted to chime in on a much-loved topic.

@alb:

Naturally we agree wholeheartedly with what you said. If you are willing and interested, let's have a chat and maybe we can propose a trial project with the vendor to implement the system you envisioned?

@Hans:

I respectfully disagree with your comments - we are proving that it is a viable business model.

Do you wonder why the big 3 aren't moving to the cloud? They have tried, and are still trying, but their current sales organizations are simply too deeply entrenched in their lucrative all-you-can-eat models to ever want to change. That's a big obstacle they have to overcome. Only the smaller EDA companies see the benefits and are more agile -- we are working with a few who wish to remain anonymous for now.

No less than Joe Costello, former CEO of Cadence, has commented that in the end, only customers can lead the change, not the big 3. And people wonder why the EDA and chip design industry are perceived as "sunset industries" nowadays, steadily losing all the innovation we once had. It is because of the fear of change.

Plunify is our effort to try to affect a change, but it is not change for the sake of changing. More and more customers are seeing the benefits of offloading compute-intensive tasks to pay-by-the-hour datacenters. We've been inspired by seeing cases where an engineering team accomplished in 3 days tasks that would have taken them a whole month to do!

If you don't mind, may I understand more of your concerns with using a cloud service? That will help educate us on how we can improve.

@Sean:

I understand what you said about not having designs that are big enough to require a server farm, and agree that it is mostly trust, not (merely) technology that is the issue with entrusting a 3rd-party in another country with your confidential data.

The point I'd like to make is, why judge us before you even get to know us? One of our first suggestions to customers is to NOT share their latest and greatest designs if they don't feel good doing so, and just offload their tedious tasks on stable designs, whatever they are comfortable with. For the record, we do encrypt your data before it is stored, if you want to store it. We are Singapore-based, and you can choose European servers if you are concerned about your data falling under US jurisdiction. And we're regular engineers and software developers. Do let's have a chat if you're interested in finding out more.

We spend all our time making sure that our platform is secure and that supported design flows function smoothly at scale. This is what's putting bread on the table so you can be sure that we will move heaven and earth to make our stuff work as customers'd expect it to. As cheesy as it might sound, the belief that Plunify can contribute to our industry as a whole also keeps our team motivated.

Cheers,
Harnhua

 

[alb]

Hi Harnhua,
harnhua@plunify.com wrote:

My name is Harnhua; I'm one of Plunify's founders and I just wanted to
chime in on a much-loved topic.

good that you guys are following this group. I wish more people from EDA
industry /lurked around/ here instead of trenching themselves behind
their user-forums.

@Hans:
[]
Do you wonder why the big 3 aren't moving to the cloud? They have
tried, and are still trying, but their current sales organizations are
simply too deeply entrenched in their lucrative all-you-can-eat models
to ever want to change. That's a big obstacle they have to overcome.

maybe they do not see their share in the business model you are
presenting and therefore are simply not interested. What you present as
a win-win solution might not be regarded as such by them.

What in your opinion is their advantage in letting you get in this
business as a gateaway to their tools? EDA industry has always worked on
the principle to /federate/ users [1] with their tools to provide them what
they need to ship a product early and cheaply.

Now comes your idea that says: 'to hell with their tools, we offer ours
on *top* of them and the user does no longer need to deal with X or A
suites'. Wouldn't this approach scare them?

No less than Joe Costello, former CEO of Cadence, has commented that
in the end, only customers can lead the change, not the big 3. And
people wonder why the EDA and chip design industry are perceived as
"sunset industries" nowadays, steadily losing all the innovation we
once had. It is because of the fear of change.

Or maybe because they do not see where is their share in this change.

Plunify is our effort to try to affect a change, but it is not change
for the sake of changing. More and more customers are seeing the
benefits of offloading compute-intensive tasks to pay-by-the-hour
datacenters.

As an end user I'd say that a pay-by-the-hour is the best solution, but
what is the tools vendors gain with this model?

@Sean:

I understand what you said about not having designs that are big
enough to require a server farm, and agree that it is mostly trust,
not (merely) technology that is the issue with entrusting a 3rd-party
in another country with your confidential data.

The point is not only trust, rather liability. Who would be liable for a
leak of information? And how much would that leak cost to the customer
as well as the provider?

[]

For the record, we do encrypt your data before
it is stored, if you want to store it.

Problem with encrypting storage is where the decryption key is stored.
Can you imagine how catastrophic would be a scenario where you *lost*
the decryption key or it has been forged somehow?

And regarding secure transmission I hope you guys are aware of this:
https://www.openssl.org/news/secadv_20140407.txt

[]

We spend all our time making sure that our platform is secure and that
supported design flows function smoothly at scale.

there's only one way to make sure your platform is secure: make it open.
This of course might not be a viable solution for you, but that is the
only solution that would help you build trust and even then, the
heartbleed bug I referred to earlier is a clear example where security
might be a showstopper for your model.

Saying you have put a lot of effort is *all relative*. No matter how
skilled are your network experts and software developers, only a large
user base and a large amount of 'eyes' can guarantee a level of trust
sufficient to migrate on the cloud.

Be sure though that I second your attempt to provide such a service.
Even though I would be more keen to support you if you were adopting an
open standard like OpenStack instead of the AWS.

p.s.: I suggest next time, for readability purposes, you quote text from
others in order to avoid the need to switch back and forth to understand
what they have said. This is what 'quoting' is for.

 

On Friday, April 11, 2014 1:04:47 PM UTC+3, alb wrote:

Now comes your idea that says: 'to hell with their tools, we offer ours
on *top* of them and the user does no longer need to deal with X or A
suites'. Wouldn't this approach scare them?

By "big 3" Harnhua probable meant Synopsys, Cadence and Mentor Graphics.

 

[HT-Lab]

Hi Harnhua,

On 10/04/2014 16:48, harnhua@plunify.com wrote:

Hi,

My name is Harnhua; I'm one of Plunify's founders and I just wanted to chime in on a much-loved topic.

@alb:

Naturally we agree wholeheartedly with what you said. If you are willing and interested, let's have a chat and maybe we can propose a trial project with the vendor to implement the system you envisioned?

@Hans:

I respectfully disagree with your comments - we are proving that it is a viable business model.

I am glad this is the case, I have nothing against cloud based services
and I always applaud new startup doing something new. However, you must
agree with me that having just 2 tool vendors on-board after 4(?) years
gives the impression you are not doing so well. You show ISE in your
demo but don't list them on the tools page?

I also wondered why you are going after the FPGA market were large
regression test are less common.

Do you wonder why the big 3 aren't moving to the cloud? They have tried, and are still trying, but their current sales organizations are simply too deeply entrenched in their lucrative all-you-can-eat models to ever want to change. That's a big obstacle they have to overcome.

I would say it is an obstacle you have to overcome. The EDA vendor is
not going to change their pricing model if they get less money. Most EDA
vendors have a flexible license scheme, you can get 1 or 3 month term
licenses from most of them. Setting up a small in-house regression farm
(assuming FPGA user) is also not a major undertaking. It basically all
comes down to how many simulation licenses you willing to pay for and
not the setup.

> Only the smaller EDA companies see the benefits and are more agile

But unfortunately for the big clients you need the big EDA tools. Nobody
is going to sign-off their $10M ASIC on a new unproven tool. Also the
amount of investment and know-how required to enter this market is
enormous and even if you have something good you will be snapped up by
one of the big three so you are back to square one.

>-- we are working with a few who wish to remain anonymous for now.

I would put some pressure on them to endorse you.

> No less than Joe Costello, former CEO of Cadence, has commented that in the end, only customers can lead the change, not the big 3. And people wonder why the EDA and chip design industry are perceived as "sunset industries" nowadays, steadily losing all the innovation we once had. It is because of the fear of change.

I would say its al about $$$

Plunify is our effort to try to affect a change, but it is not change for the sake of changing. More and more customers are seeing the benefits of offloading compute-intensive tasks to pay-by-the-hour datacenters. We've been inspired by seeing cases where an engineering team accomplished in 3 days tasks that would have taken them a whole month to do!

If you don't mind, may I understand more of your concerns with using a cloud service? That will help educate us on how we can improve.

I have no doubt that cloud services will become more and more popular.
It is just that for the moment I don't see a viable business model
especially if you are going after the FPGA community.

My Mentor Precision tool has a feature called Precise-Explore which
enables me start 16 simultaneous synthesis and P&R runs all from the
comfort of my desktop

I hope I am not too negative and I would be happy if you would prove me
wrong,

Good luck with your business,

Hans
www.ht-lab.com

@Sean:

I understand what you said about not having designs that are big enough to require a server farm, and agree that it is mostly trust, not (merely) technology that is the issue with entrusting a 3rd-party in another country with your confidential data.

The point I'd like to make is, why judge us before you even get to know us? One of our first suggestions to customers is to NOT share their latest and greatest designs if they don't feel good doing so, and just offload their tedious tasks on stable designs, whatever they are comfortable with. For the record, we do encrypt your data before it is stored, if you want to store it. We are Singapore-based, and you can choose European servers if you are concerned about your data falling under US jurisdiction. And we're regular engineers and software developers. Do let's have a chat if you're interested in finding out more.

We spend all our time making sure that our platform is secure and that supported design flows function smoothly at scale. This is what's putting bread on the table so you can be sure that we will move heaven and earth to make our stuff work as customers'd expect it to. As cheesy as it might sound, the belief that Plunify can contribute to our industry as a whole also keeps our team motivated.

Cheers,
Harnhua

 

Hi alb,

Our focus is actually on FPGA design, and on making all the extra resources in grid/cloud computing produce better quality of results in a shorter time -- that I think is the main attraction for people to consider an external compute resource.

Therefore my view of EDA is more generic in nature. Other much more qualified people have expressed their opinions on the current state of the industry, but it seems like more and more end-customers are unhappy with EDA tool sales/licensing models, and have been for a while. But it's gotten to the point where the industry itself appears to suffer--investment money has dried up, the number of "big exits" is declining, fewer and fewer EDA startups are being created, and so on.

maybe they do not see their share in the business model you are
presenting and therefore are simply not interested. What you present as
a win-win solution might not be regarded as such by them.

You're probably right. I think they must see problems, but at the same time, are perhaps searching for the "right models" to remain as profitable as before?

What in your opinion is their advantage in letting you get in this
business as a gateaway to their tools? EDA industry has always worked on
the principle to /federate/ users [1] with their tools to provide them what
they need to ship a product early and cheaply.

Now comes your idea that says: 'to hell with their tools, we offer ours
on *top* of them and the user does no longer need to deal with X or A
suites'. Wouldn't this approach scare them?

On the contrary, we'd like customers to use the current FPGA tools as is, and only offload compute-intensive processes to a grid/cloud computing environment that we help set up. This is so that builds can be scaled up instantly in a guided way to get to design goals. Something like suddenly having "1000 more servers trying strategies to get to timing closure in a day instead of in weeks." We develop plugins, not replacements.

No less than Joe Costello, former CEO of Cadence, has commented that
in the end, only customers can lead the change, not the big 3. And
people wonder why the EDA and chip design industry are perceived as
"sunset industries" nowadays, steadily losing all the innovation we
once had. It is because of the fear of change.

Or maybe because they do not see where is their share in this change.

Yes, in their own way, large as they are, the big EDA 3 face many challenges. Opening up the industry, as you mentioned, is great for the end-user but it must work for the vendors too. For instance, every vendor seems to want an ecosystem, but only around their tools...

As an end user I'd say that a pay-by-the-hour is the best solution, but
what is the tools vendors gain with this model?

Potentially, a great deal more users than before is my claim--the so-called "long tail". They can still charge high hourly prices, and have been doing so for the large customers. Although tool purchase is far from the major cost component of making a chip, it does affect the entire workflow. Furthermore, the population of dabblers, hobbyists, students who will eventually replenish and sustain the industry will benefit from pay-as-you-use models and portability. I'm not saying anything new here, am I? ; )

The point is not only trust, rather liability. Who would be liable for a
leak of information? And how much would that leak cost to the customer
as well as the provider?

As you mentioned earlier, people routinely FTP their files to the foundries.. Who is liable for a leak in those cases, I wonder? (I don't know) I think a good approach is what companies like OneSpin are doing--make online tools that don't require users to transfer source code.

Problem with encrypting storage is where the decryption key is stored.
Can you imagine how catastrophic would be a scenario where you *lost*
the decryption key or it has been forged somehow?

And regarding secure transmission I hope you guys are aware of this:
https://www.openssl.org/news/secadv_20140407.txt

You're describing the kind of technical problem for which I think there is a infinite loop of questions and answers. For example, to get a decryption key, one would have to break into the system first. To break into a system, one would have to first find the system. Security vulnerabilities are present in company networks as well as in Amazon. My (biased) view is that companies like AWS who rely on the cloud for a living have the most incentive to make their systems secure. Of course we patched ours as soon as we found out about vulnerabilities like the one you posted. This is also probably where proper customer education and IT audits come into play. Doubters will always doubt--there will be people who will never contemplate using a cloud service for chip design, but I think with the proper communication and technology, more and more companies will turn to a "cloud" way of designing.

there's only one way to make sure your platform is secure: make it open.
This of course might not be a viable solution for you, but that is the
only solution that would help you build trust and even then, the
heartbleed bug I referred to earlier is a clear example where security
might be a showstopper for your model.

I like your statement very much. Ideally, tools can export non-reversible data so that users don't have to upload source code.

Saying you have put a lot of effort is *all relative*. No matter how
skilled are your network experts and software developers, only a large
user base and a large amount of 'eyes' can guarantee a level of trust
sufficient to migrate on the cloud.

True; it's a chicken-and-egg situation which we can address only by working with customers.

Be sure though that I second your attempt to provide such a service.
Even though I would be more keen to support you if you were adopting an
open standard like OpenStack instead of the AWS.

Thank you for your thoughts and feedback!

p.s.: I suggest next time, for readability purposes, you quote text from
others in order to avoid the need to switch back and forth to understand
what they have said. This is what 'quoting' is for.

Done!

Cheers,
Harnhua

 

Hi Hans,

Thank you for your thoughts!

I am glad this is the case, I have nothing against cloud based services
and I always applaud new startup doing something new. However, you must
agree with me that having just 2 tool vendors on-board after 4(?) years
gives the impression you are not doing so well. You show ISE in your
demo but don't list them on the tools page?

Absolutely agree with you. Building a good EDA platform is an uphill task, and there are so many factors involved to make it successful. So far, what's been mentioned are vendor relationships/motivations, end-user requirements and security. Another one is that the tools themselves are not designed to take advantage of a cloud-like infrastructure. Over the years, engineers have learned to overcome design problems through other means, because not everyone has access to compute resources. Even with ample servers, the perceived gain that the tools bring aren't outweighing the perceived costs, if that makes sense.

So to build a good FPGA/EDA problem, we just have to chip away bit by bit at the different problems. Some flows we have in beta, some we can and cannot release, so please bear with us and work with us if you have a demand for specific tools and flows.

I also wondered why you are going after the FPGA market were large
regression test are less common.

Because we believe that we can use existing FPGA tools to get better quality of results, on top of the "convenience" benefits of a platform.

I would say it is an obstacle you have to overcome. The EDA vendor is
not going to change their pricing model if they get less money. Most EDA
vendors have a flexible license scheme, you can get 1 or 3 month term
licenses from most of them. Setting up a small in-house regression farm
(assuming FPGA user) is also not a major undertaking. It basically all
comes down to how many simulation licenses you willing to pay for and
not the setup.

: )
Yes, I concur what you wrote here for what I tend to call the "convenience" benefits.

But unfortunately for the big clients you need the big EDA tools. Nobody
is going to sign-off their $10M ASIC on a new unproven tool. Also the
amount of investment and know-how required to enter this market is
enormous and even if you have something good you will be snapped up by
one of the big three so you are back to square one.

I would put some pressure on them to endorse you.

I would say its al about $$$

This, I think, has some implications on the ASICs vs FPGAs question and is part of the challenge that small FPGA/EDA startups (including us) have to solve. However it doesn't have to be "small company versus big company" thing. It sounds a bit too idealistic perhaps, but I really think all vendors and the customers need to work together to address this, so that the amount of $ to be made can grow as a whole.

I have no doubt that cloud services will become more and more popular.
It is just that for the moment I don't see a viable business model
especially if you are going after the FPGA community.

My Mentor Precision tool has a feature called Precise-Explore which
enables me start 16 simultaneous synthesis and P&R runs all from the
comfort of my desktop

From the infrastructure perspective, it's great that you have the hardware and licenses to do this, and it's great if this is all that you need -- these are the "convenience" benefits that I mentioned above.

From a quality of results point of view, what if I say that by running our tool from your desktop to run 16 simultaneous synthesis and P&R runs in your server farm / local PC / AWS, you can actually improve your synthesis and P&R results? Is that a better value proposition from your perspective?
(That's what we're working on.)

I hope I am not too negative and I would be happy if you would prove me
wrong,

Good luck with your business,

Thank you!

Cheers,
Harnhua

Hans

www.ht-lab.com







@Sean:



I understand what you said about not having designs that are big enough to require a server farm, and agree that it is mostly trust, not (merely) technology that is the issue with entrusting a 3rd-party in another country with your confidential data.



The point I'd like to make is, why judge us before you even get to know us? One of our first suggestions to customers is to NOT share their latest and greatest designs if they don't feel good doing so, and just offload their tedious tasks on stable designs, whatever they are comfortable with. For the record, we do encrypt your data before it is stored, if you want to store it. We are Singapore-based, and you can choose European servers if you are concerned about your data falling under US jurisdiction. And we're regular engineers and software developers. Do let's have a chat if you're interested in finding out more.



We spend all our time making sure that our platform is secure and that supported design flows function smoothly at scale. This is what's putting bread on the table so you can be sure that we will move heaven and earth to make our stuff work as customers'd expect it to. As cheesy as it might sound, the belief that Plunify can contribute to our industry as a whole also keeps our team motivated.



Cheers,

Harnhua

 

[alb]

Hi Harnhua,

harnhua@plunify.com wrote:

What in your opinion is their advantage in letting you get in this
business as a gateaway to their tools? EDA industry has always worked on
the principle to /federate/ users [1] with their tools to provide them what
they need to ship a product early and cheaply.
Now comes your idea that says: 'to hell with their tools, we offer ours
on *top* of them and the user does no longer need to deal with X or A
suites'. Wouldn't this approach scare them?
[]
On the contrary, we'd like customers to use the current FPGA tools as
is, and only offload compute-intensive processes to a grid/cloud
computing environment that we help set up. This is so that builds can
be scaled up instantly in a guided way to get to design goals.

There might be some technical limitation with some tools. For example I
seem to be stuck with using only one core for Designer (par tool from
Microsemi) and virtualizing 1000 cores wouldn't do much, unless I'm
running 1000 parallel processes with 1000 different sets of
parameters...

Something like suddenly having "1000 more servers trying strategies to
get to timing closure in a day instead of in weeks." We develop
plugins, not replacements.

I'm curious about this, I did not know tools like those can be extended
with plug-ins. Do such feature show on all tools? Can you really plug-in
estentions to simulators, synthesizers, etc.?

[]

people wonder why the EDA and chip design industry are perceived as
"sunset industries" nowadays, steadily losing all the innovation we
once had. It is because of the fear of change.

Or maybe because they do not see where is their share in this change.

Yes, in their own way, large as they are, the big EDA 3 face many
challenges. Opening up the industry, as you mentioned, is great for
the end-user but it must work for the vendors too. For instance, every
vendor seems to want an ecosystem, but only around their tools...

Because their lock-in strategies come from a distorted view of profit.
Hystory has already shown what are the consequences of such strategies
(see 'Unix wars'). Unfortunately proprietary hardware will always be a
fertile ground for proprietary software and lock-in mechanisms that
choke creativity and progress.

As an end user I'd say that a pay-by-the-hour is the best solution, but
what is the tools vendors gain with this model?

Potentially, a great deal more users than before is my claim--the
so-called "long tail". They can still charge high hourly prices, and
have been doing so for the large customers. Although tool purchase is
far from the major cost component of making a chip, it does affect the
entire workflow. Furthermore, the population of dabblers, hobbyists,
students who will eventually replenish and sustain the industry will
benefit from pay-as-you-use models and portability. I'm not saying
anything new here, am I? ; )

Dabblers, hobbysts, students will not throw a dime in this business.
There exists already enough 'free and open' tools that can let people
play around enough to get their projetc/toy/hobby done, and EDAs are
providing free of charge licenses to let them play.

I've always been curious to understand what are the differences between
the software community and the hardware one, and why we haven't yet gone
through the same need to share, contribute and collaborate the same way
the software guys do. In the end my conclusion is that you are always
stuck with a proprietary tool, even if you can download it free of
charge and use it without paying.

[]

Problem with encrypting storage is where the decryption key is stored.
Can you imagine how catastrophic would be a scenario where you *lost*
the decryption key or it has been forged somehow?

And regarding secure transmission I hope you guys are aware of this:
https://www.openssl.org/news/secadv_20140407.txt

You're describing the kind of technical problem for which I think
there is a infinite loop of questions and answers. For example, to get
a decryption key, one would have to break into the system first. To
break into a system, one would have to first find the system. Security
vulnerabilities are present in company networks as well as in Amazon.

To get a decryption key you do not need to get in, it is sufficient that
somebody 'gets out' with it. It is known since long time that secrecy
does not guarantee security and here is an excerpt from the pgp FAQ:

Q: Can the NSA crack PGP (or RSA, DSS, IDEA, 3DES,...)?

A: This question has been asked many times. If the NSA were able to
crack RSA or any of the other well known cryptographic algorithms, you
would probably never hear about it from them. Now that RSA and the other
algorithms are very widely used, it would be a very closely guarded
secret.

The best defense against this is the fact the algorithms are known
worldwide. There are many competent mathematicians and cryptographers
outside the NSA and there is much research being done in the field right
now. If any of them were to discover a hole in one of the algorithms,
I'm sure that we would hear about it from them via a paper in one of the
cryptography conferences.

Doubters will always
doubt--there will be people who will never contemplate using a cloud
service for chip design, but I think with the proper communication and
technology, more and more companies will turn to a "cloud" way of
designing.

This shift may only be driven if big EDAs are willing to let it happen.
That means users *and* new enterpreneurs are tied to a business model
led by somebody else. Compilers vendors back in the late 80s where
facing a dramatic shift because a competitive and much more powerful
tool was distributed free of charge and free of lock-ins (gcc) and there
were companies making a business out of it (Cygnus).

Nowadays there cannot be a 'one man show' like those days and I agree
that is unlikely that someone will start to write an open and free
synthesis tool, but without it our community is bound to the ups and
downs of those big guys who are leading the show.

Saying you have put a lot of effort is *all relative*. No matter how
skilled are your network experts and software developers, only a large
user base and a large amount of 'eyes' can guarantee a level of trust
sufficient to migrate on the cloud.

True; it's a chicken-and-egg situation which we can address only by
working with customers.

If you limit your verification to your customers than you're likely
going to fail. There are tons of incredibly gifted geeks out there and
if you do not open your systems to peer review, than you will never
leverage that power.

Your code will always be *yours* because you know every bit of it, not
because you put a patent on it or made it close to the world.

Al

 

[Tom Gardner]

On 14/04/14 08:48, alb wrote:

I've always been curious to understand what are the differences between
the software community and the hardware one, and why we haven't yet gone
through the same need to share, contribute and collaborate the same way
the software guys do.

Because it is (1) possible and (2) necessary.

1) in some cases it is easy to have a dongle without
obnoxious DRM: the hardware itself

2) inside the hardware there is a lot of highly commercially
sensitive information that does not need to be (and is not)
visible to the customer.

3) the internal structures and performance are imperfectly
understood and modelled. That's a significant problem for
the manufacturer, infeasible if you are trying to keep
third parties aligned.

4) the up-front cost-of-entry (non-recurring engineering)
charges are prohibitive. Starting small in a garage and
then having incremental improvements is no longer an option.

 

[alb]

Hi Tom,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

I've always been curious to understand what are the differences between
the software community and the hardware one, and why we haven't yet gone
through the same need to share, contribute and collaborate the same way
the software guys do.

Because it is (1) possible and (2) necessary.

I'm confused. Are you saying that 'share, contribute and collaborate is
possible and necessary'?
Then what are you trying to say with your following points?

1) in some cases it is easy to have a dongle without
obnoxious DRM: the hardware itself

I don't get this point.

2) inside the hardware there is a lot of highly commercially
sensitive information that does not need to be (and is not)
visible to the customer.

There's a lot of highly commercially sensitive information in your
latest i7 or whatever is the processor you are mounting on your pc, but
it does not prevent you from running a completely free tool to build
software on it.

3) the internal structures and performance are imperfectly
understood and modelled. That's a significant problem for
the manufacturer, infeasible if you are trying to keep
third parties aligned.

sorry but I fail to understand this point as well.

4) the up-front cost-of-entry (non-recurring engineering)
charges are prohibitive. Starting small in a garage and
then having incremental improvements is no longer an option.

I'm certainly not dreaming about that. But I believe there are enough
resources and capabilities, if joint together, that can make a big
change.

 

[Tom Gardner]

On 14/04/14 10:22, alb wrote:

Hi Tom,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
I've always been curious to understand what are the differences between
the software community and the hardware one, and why we haven't yet gone
through the same need to share, contribute and collaborate the same way
the software guys do.

Because it is (1) possible and (2) necessary.

I'm confused. Are you saying that 'share, contribute and collaborate is
possible and necessary'?
Then what are you trying to say with your following points?

Sorry! In the hardware world it is possible and necessary
to avoid collaborating and sharing w.r.t. the internals of
many devices, particularly with FPGAs

1) in some cases it is easy to have a dongle without
obnoxious DRM: the hardware itself

I don't get this point.

That's the "it is possible to avoid..." part.

2) inside the hardware there is a lot of highly commercially
sensitive information that does not need to be (and is not)
visible to the customer.

There's a lot of highly commercially sensitive information in your
latest i7 or whatever is the processor you are mounting on your pc, but
it does not prevent you from running a completely free tool to build
software on it.

They have an extremely comprehensive specification
of what you can rely on seen from the outside. You
can't modify anything on the inside, for many good
reasons.

3) the internal structures and performance are imperfectly
understood and modelled. That's a significant problem for
the manufacturer, infeasible if you are trying to keep
third parties aligned.

sorry but I fail to understand this point as well.

That point is clear, provided that you have some
concept of semiconductor modelling.

4) the up-front cost-of-entry (non-recurring engineering)
charges are prohibitive. Starting small in a garage and
then having incremental improvements is no longer an option.

I'm certainly not dreaming about that. But I believe there are enough
resources and capabilities, if joint together, that can make a big
change.

You need detailed plans as well as dreams. The devil
is, as usual, in the details.

 

[alb]

Hi Tom,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
[]

I'm confused. Are you saying that 'share, contribute and collaborate is
possible and necessary'?
Then what are you trying to say with your following points?

Sorry! In the hardware world it is possible and necessary
to avoid collaborating and sharing w.r.t. the internals of
many devices, particularly with FPGAs

I'm not advocating to share your crown jewels, I'm only advocating for
standards which allows X and Y to build their FPGA while W and Z build
the tool freely. In order to produce perfectly suitable machine code I
do not need to know how the clock is routed in your cpu, neither how you
optimized the carry chain, I simply need to know which are the opcodes
and the registers it uses.

If you want to make a very rough parallel with the FPGA world, I do not
need to know more than the logic provided by a logical cell (which is
documented on the datasheet) and the associated delays, which is also
reported on the datasheet. [1]

A tool that is free as in *libre*, can be a turning point in opening up
our community to a much more effective exchange, with a set of tools
which are constantly growing and increasing design efficiency.

[]

2) inside the hardware there is a lot of highly commercially
sensitive information that does not need to be (and is not)
visible to the customer.

There's a lot of highly commercially sensitive information in your
latest i7 or whatever is the processor you are mounting on your pc, but
it does not prevent you from running a completely free tool to build
software on it.

They have an extremely comprehensive specification
of what you can rely on seen from the outside. You
can't modify anything on the inside, for many good
reasons.

and what does prevent us from having a similar /comprehensive
specification/ for fpga?

3) the internal structures and performance are imperfectly
understood and modelled. That's a significant problem for
the manufacturer, infeasible if you are trying to keep
third parties aligned.

sorry but I fail to understand this point as well.

That point is clear, provided that you have some
concept of semiconductor modelling.

Uhm, I thought I was lacking some *basic* information about
/semiconductor modelling/ therefore I googled it and Wikipedia reports:

Semiconductor device modeling creates models for the behavior of the
electrical devices based on fundamental physics, such as the doping
profiles of the devices.

Internal structure are difficult to model, so what? Do you think my
synthesis tool need to know the physics of my device? Or can it simply
rely on 'inaccurate but good enough models' of logic elements and
delays?

What are the 'third parties' that need to be 'aligned' (to what then?).

4) the up-front cost-of-entry (non-recurring engineering)
charges are prohibitive. Starting small in a garage and
then having incremental improvements is no longer an option.

I'm certainly not dreaming about that. But I believe there are enough
resources and capabilities, if joint together, that can make a big
change.

You need detailed plans as well as dreams. The devil
is, as usual, in the details.

You do not need a detailed plan, you need motivated and talented people.
Often you either lack the motivation or the skills.

Al

[1] I may not have all the insight of what does it take to create a
synthesis tool and I'd be happy to hear it.

 

[Tom Gardner]

On 14/04/14 13:38, alb wrote:

Hi Tom,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
[]
I'm confused. Are you saying that 'share, contribute and collaborate is
possible and necessary'?
Then what are you trying to say with your following points?

Sorry! In the hardware world it is possible and necessary
to avoid collaborating and sharing w.r.t. the internals of
many devices, particularly with FPGAs

I'm not advocating to share your crown jewels, I'm only advocating for
standards which allows X and Y to build their FPGA while W and Z build
the tool freely. In order to produce perfectly suitable machine code I
do not need to know how the clock is routed in your cpu, neither how you
optimized the carry chain, I simply need to know which are the opcodes
and the registers it uses.

If you want to make a very rough parallel with the FPGA world, I do not
need to know more than the logic provided by a logical cell (which is
documented on the datasheet) and the associated delays, which is also
reported on the datasheet. [1]

You almost certainly do need to know more, unless you are
just making a toy tool or one vastly simplified so that
it is best suited for educational purposes.

Start by considering wire delays, routing constraints,
simultaneous switching transients, and many more non-ideal
aspects of operation that need to be considered in modern
FPGAs. Look at a vendor's tool to see the type of
constraints that have to be specified by the user in order
to have a reproducible implementation. Use a vendor's tool
to see the type of warnings that the tool emits.

Have a look at the Xilinx documentation for just one of
its families. Download their "Documentation Navigator-2013.4
Utilities" for their Vivado tool.

A tool that is free as in *libre*, can be a turning point in opening up
our community to a much more effective exchange, with a set of tools
which are constantly growing and increasing design efficiency.

Go ahead and do it. It would help if you have already completed
several designs, since then you will know the pain points that
designers would like removed. There's little point in inventing
yet another way of doing something that is already easy to do.

2) inside the hardware there is a lot of highly commercially
sensitive information that does not need to be (and is not)
visible to the customer.

There's a lot of highly commercially sensitive information in your
latest i7 or whatever is the processor you are mounting on your pc, but
it does not prevent you from running a completely free tool to build
software on it.

They have an extremely comprehensive specification
of what you can rely on seen from the outside. You
can't modify anything on the inside, for many good
reasons.

and what does prevent us from having a similar /comprehensive
specification/ for fpga?

See my point 2. If you don't understand that then it indicates
you haven't implemented a design for a modern FPGA.

Browse the documents in Xilinx's "Documentation
Navigator-2013.4 Utilities"; it might enlighten you.

3) the internal structures and performance are imperfectly
understood and modelled. That's a significant problem for
the manufacturer, infeasible if you are trying to keep
third parties aligned.

sorry but I fail to understand this point as well.

That point is clear, provided that you have some
concept of semiconductor modelling.

Uhm, I thought I was lacking some *basic* information about
/semiconductor modelling/ therefore I googled it and Wikipedia reports:

Semiconductor device modeling creates models for the behavior of the
electrical devices based on fundamental physics, such as the doping
profiles of the devices.

Internal structure are difficult to model, so what? Do you think my
synthesis tool need to know the physics of my device?

It needs to model them in sufficient detail to be
able to get good reliable predictions and implementations.

Or can it simply
rely on 'inaccurate but good enough models' of logic elements and
delays?

Not sufficient.


> What are the 'third parties' that need to be 'aligned' (to what then?).

People like you, to the secret internal non-idealities.

4) the up-front cost-of-entry (non-recurring engineering)
charges are prohibitive. Starting small in a garage and
then having incremental improvements is no longer an option.

I'm certainly not dreaming about that. But I believe there are enough
resources and capabilities, if joint together, that can make a big
change.

You need detailed plans as well as dreams. The devil
is, as usual, in the details.

You do not need a detailed plan, you need motivated and talented people.
Often you either lack the motivation or the skills.

Such people are necessary but not sufficient.

If you don't have a plan then , by definition, you don't
know what you are going to do - let alone how to do it.