Blog
Comment
WKetel
The comments about "hardware guys" and "software guys" are certainly on point. ...
cdhmanning
These days most of the functionality normally comes from software, not hardware. ...
Co-design – Myth or Reality?
Brian Bailey
7/26/2011 10:30 AM EDT
I think it was probably 17 years ago when I started to attend co-design conferences. At that time they were very academic in nature and they concentrated mostly on the most optimal way to automatically partition a design written in C, Java, or some other language into hardware and software.
The interfaces were always the sticky area and most of the algorithms just assumed that communications was free both in terms of performance and resources. Some of the later ones did take this into account, but not in very flexible ways. We even started to see commercial tools in the area, not just from startups, but from Cadence – with the Felix, VCC – whatever name you preferred to call it by.
But all of this research and the tools went by the wayside. I think the primary reason was they all assumed a single thread, a single function, a single processor, a single bus – and the list could go on. Now designing and partitioning between hardware and software for such a system is not really that difficult and so the tools didn’t provide enough value to warrant their adoption.
I remember one person describing VCC as being a huge user interface on a spreadsheet. We were already beginning to see multi-processor systems emerge and it was clear that a single application solution was not going to cut it. Who wants a phone that can only make voice calls?
So things went quiet for a long time and it is only recently that I have started to see interest rising again. However, it is not the same as before, and I believe it is based on different needs, although some of the others may resurface later. What we do know is that the systems of today are a lot more complex and defy complete static analysis, such that the notion of an optimal partition or indeed anything automatic is not on the table. This creates both a need and a constraint as I have written about in the past.
So what is changing and what is needed? I think the thing that we all accept and has almost become a cliché is that software is now defining much of the functionality. That is a little scary when software is usually behind the hardware development and is on the critical path. I also think because as hardware people we don’t like to think that the success of a product is not under our control.
In addition, performance is related to how the hardware resources are going to be used by software, and that means we have to analyze how the software interacts with the hardware, requiring dynamic analysis. To enable this we have to ensure that the software folks have the necessary tools to give them a fighting chance – something that we really hadn’t done in the past.
Of course, by this I mean a model of the hardware that is available to them early enough in the development process that they can perform real work on it, test and debug code and over time perhaps even get to do some optimization based on the hardware, and get them intimately involved in things such as power conservation. I think we have learned that functionality is not the only aspect of a product that has to work well, performance, battery life, ergonomics and many other factors play into the definition of a winning product, and these are combined hardware/software functions.
In the words of Immanuel Kant, who was the inventor of the term co-design, “to put a question one has to have some information or knowledge”, and this is exactly where we are today. I am not sure that we yet know the right questions to ask, but we are beginning to learn how to make information available to the software folks. Once you have information, you can use intelligence to turn that information into knowledge, and then you can start to form the right questions. When we find the same question being asked by many people then we can look for ways to make that more easily obtainable, and if this affects design decisions, then there is the possibility to automate that aspect of the process in the future.
One such area that may lead to co-design is based on code profiling. We have seen several companies who can extract performance information from running code on a virtual prototype, use that to make decisions about what to partition into hardware and then various degrees of help in completing that task. Automation is still only possible in a tiny fraction of cases, but tools that can reduce the chance of mistakes, or do some of the grunt work will likely succeed, so long as the cost and benefits are in balance.
I would also like to give a shout-out to Neil Johnson who has been writing about a similar subject recently in his blog and comes at it from a different perspective.
We are now on the right track to co-design, rather than the track that the early research took.
Brian Bailey – keeping you covered.
If you found this column to be of interest, visit Programmable Logic Designline where you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
The interfaces were always the sticky area and most of the algorithms just assumed that communications was free both in terms of performance and resources. Some of the later ones did take this into account, but not in very flexible ways. We even started to see commercial tools in the area, not just from startups, but from Cadence – with the Felix, VCC – whatever name you preferred to call it by.
But all of this research and the tools went by the wayside. I think the primary reason was they all assumed a single thread, a single function, a single processor, a single bus – and the list could go on. Now designing and partitioning between hardware and software for such a system is not really that difficult and so the tools didn’t provide enough value to warrant their adoption.
I remember one person describing VCC as being a huge user interface on a spreadsheet. We were already beginning to see multi-processor systems emerge and it was clear that a single application solution was not going to cut it. Who wants a phone that can only make voice calls?
So things went quiet for a long time and it is only recently that I have started to see interest rising again. However, it is not the same as before, and I believe it is based on different needs, although some of the others may resurface later. What we do know is that the systems of today are a lot more complex and defy complete static analysis, such that the notion of an optimal partition or indeed anything automatic is not on the table. This creates both a need and a constraint as I have written about in the past.
So what is changing and what is needed? I think the thing that we all accept and has almost become a cliché is that software is now defining much of the functionality. That is a little scary when software is usually behind the hardware development and is on the critical path. I also think because as hardware people we don’t like to think that the success of a product is not under our control.
In addition, performance is related to how the hardware resources are going to be used by software, and that means we have to analyze how the software interacts with the hardware, requiring dynamic analysis. To enable this we have to ensure that the software folks have the necessary tools to give them a fighting chance – something that we really hadn’t done in the past.
Of course, by this I mean a model of the hardware that is available to them early enough in the development process that they can perform real work on it, test and debug code and over time perhaps even get to do some optimization based on the hardware, and get them intimately involved in things such as power conservation. I think we have learned that functionality is not the only aspect of a product that has to work well, performance, battery life, ergonomics and many other factors play into the definition of a winning product, and these are combined hardware/software functions.
In the words of Immanuel Kant, who was the inventor of the term co-design, “to put a question one has to have some information or knowledge”, and this is exactly where we are today. I am not sure that we yet know the right questions to ask, but we are beginning to learn how to make information available to the software folks. Once you have information, you can use intelligence to turn that information into knowledge, and then you can start to form the right questions. When we find the same question being asked by many people then we can look for ways to make that more easily obtainable, and if this affects design decisions, then there is the possibility to automate that aspect of the process in the future.
One such area that may lead to co-design is based on code profiling. We have seen several companies who can extract performance information from running code on a virtual prototype, use that to make decisions about what to partition into hardware and then various degrees of help in completing that task. Automation is still only possible in a tiny fraction of cases, but tools that can reduce the chance of mistakes, or do some of the grunt work will likely succeed, so long as the cost and benefits are in balance.
I would also like to give a shout-out to Neil Johnson who has been writing about a similar subject recently in his blog and comes at it from a different perspective.
We are now on the right track to co-design, rather than the track that the early research took.
Brian Bailey – keeping you covered.
If you found this column to be of interest, visit Programmable Logic Designline where you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
|
|
|
|
|
Navigate to related information
nosnhojn
7/26/2011 11:25 AM EDT
brian, nice post and thanks for mentioning the agilesoc blog. I 100% agree with you when you suggest we hardware folks aren't even sure yet what questions we should be asking software teams. I'm convinced that'll remain a problem until the structure of an SoC team changes. My opinion includes doing away with hardware "teams" and software "teams" that sit in different org hierarchies. Developers on both sides need to sit as part of the same *product* team. We learn from the questions we ask. They learn from the questions they ask. Too much guessing and assuming right now and I don't think better technology can fix that.
No guarantees that makes things any better of course... but I sincerely doubt that kind of shake-up would hurt!
neil
Sign in to Reply
dyson_
7/28/2011 5:42 AM EDT
Brain
Its informative reading the comments on Neil's blog and interesting, but also saddening, to learn that things seem to have remained more or less the same in the SoC world as they were in the system (lots of ASICs + PCBs and racks n' stuff) world 10-15 years ago. The problems existed before we had SoCs. No doubt the issues are now more critical as product development cycles get shorter and fixing a single SoC is a lot more expensive.
Sounds like what is needed is more about organisation and cultural change than tools.
Sign in to Reply
Max the Magnificent
7/28/2011 9:49 AM EDT
Brain? Let's not make him big-headed (grin)
Sign in to Reply
dyson_
7/28/2011 11:01 AM EDT
Good point. Spotted the typo. just after clicking submit button. Shame there isn't an "edit" (or should that be idiot) button.
Sign in to Reply
nosnhojn
7/28/2011 12:23 PM EDT
dyson_, thanks for flipping through my blog!
I'll admit to leaning more toward "eye-opening" than "saddening" wrt to org barriers in co-design. A recognition that the organizational barriers actually exist is important. Pair that with the will to address org barriers and we give teams an opportunity to bring practical solutions to co-design that involve the technology of course but also team based development frameworks. I reckon that's an exciting step forward, even if it has taken a while to figure out :)
Sign in to Reply
RWatkins
7/28/2011 10:25 AM EDT
Brian,
So now I am lost. All of the effective co-design projects I have seen and been involved in were of a different nature. These were distributed processing, distributed functionality projects where the co-design was by separation of actual functional blocks of hardware and firmware that talked to other such functional blocks. In this approach, the high level functionality could be allocated and several teams could attack their respective functional block to achieve schedule and risk goals.
In my experience, trying to develop a large and complex project by sending software developers off to do their work in one direction and hardware developers in another direction never works because the hardware developers find needs to change structure, and the software developers find insurmountable or hobbling hardware limitations that are best addressed by cooperation.
A real co-design is where a truly clear definition of a block of functionality allows a small team of capable engineers to work together as a group to get a good and fast and inexpensive result. No special tools are needed for this, but evaluation or development boards for processing resources are very helpful, and breadboards allow the early detection of issues that change design approaches in hardware and firmware.
Sign in to Reply
BrianBailey
7/28/2011 11:04 AM EDT
I agree that in many organization, the hardware and firmware groups have worked in fairly close cooperation. What you seem to be describing (sorry if I get it wrong) is a hardware/hardware partitioning process. You also seem to be describing a board level system where things such as breadboards are possible. What we are seeing in SoCs is a growing amount of hardware/software partitioning and where until recently there was nothing on which to run software until the first chips came back from the fab. With virtual prototypes now operating fast enough to actually run software on a model of the hardware, it becomes possible to start having the two groups operate more concurrently than they have in the past. Also, the cost of manufacturing chips means that one chip probably has to be useable in a whole family of products, again pushing more of the actual functionality into software.
It is always possible that you are one of the lucky few where the application software team and the hardware and firmware teams actually all talk and cooperatively agree on structures and partitions and each provides the necessary tools to the other such that they can get their jobs done at the same time. Most people are still waiting for that to become reality.
Sign in to Reply
RWatkins
7/28/2011 11:14 AM EDT
Actually, I have not yet been involved with a project that's livelihood depended on software being developed for not-yet-existent silicon processing platforms. The use of FPGA/CPLD/uC/DSP silicon, merged together onto a single die for SOC functionality would seem to beg a breadboard using the known good functional blocks that were tested in silicon prior to merging. I personally would have some issues with a vendor providing functional blocks for which no demonstration and evaluation hardware was available.
Sign in to Reply
Grant Martin
7/31/2011 3:53 PM EDT
Steady on, Brian. Early Felix/VCC at Cadence Alta did not assume "a single thread, a single function, a single processor, a single bus". At least, we were looking at heterogeneous 2-processor systems such as late 90's cell phones with a control processor (eg. ARM) running user interface and the primitive "Apps" of that day (eg. an address book), and a DSP and hardware blocks doing voice encoding/decoding and handling baseband. Granted, not so complex and with much easier partitioning decisions than today, but still, not quite as simple as you make out in your note.
I think the reasons Felix/VCC failed are more complex than your summary. I agree with your point that systems of the late 90's were not complex enough to require a lot of tools to "muddle through", and I think most designers "muddled through". It is also a fact that Felix/VCC preceded the standardisation of SystemC and its de facto adoption by the industry - by a long time. This meant that users had to build models in a proprietary format, and the history of HDLs tells us that is viewed as undesirable and is a real barrier to adoption. Finally, the lack of IP models in any format, standard or proprietary, meant that any use of a codesign tool required an a priori somewhat exhausting modelling effort - leading to a real chicken/egg adoption dilemma. But it was not for lack of attention to SW that Felix/VCC failed.
Now, of course, the situation is quite different. There are standard modelling approaches, a standard integration language (SystemC, which is quite capable of integrating models written in C/C++), more IP models that can be integrated, and the systems are way too complex, as you cite, to just "muddle through". Especially because they are software dominated with many processors and hardware blocks. In 2011, "Muddling through will not do".
Sign in to Reply
cdhmanning
7/31/2011 7:32 PM EDT
Any organisation where you have a "hardware team"and a"software team" is screwed. You need hardware and software skills working together in the same team. Without that you will always end up with hardware people tweaking designs without understanding the software implications, or vice versa.
"hat is a little scary when software is usually behind the hardware development and is on the critical path". That happens because people don't do multi-target development. Build PC-based simulators where you can build and test most of the code. That way you can get a huge head start. PC-based development is often a lot faster with better tools and near infinite resources when compared to targets.
Design tools often fail because they're sold as silver bullets and underdeliver or force some pre-defined architecture and fail to fit in with reality. In truth a word processor can often do the job as well. Ultimately co-design is a people problem - not a technical one - and tools can just make the interactions more constrained and complex.
Sign in to Reply
dang
8/1/2011 11:22 AM EDT
There is a very large human factor involved. HW team is focused getting the documentation out to the vendor and making sure what they get back matches. SW team input is likely to complicate their design, causing delays and risk. HW guys see SW as only a problem and not part of the solution. Development tools that abstract impl technology might help but then the engineers need to be able to handle the abstraction. Not many of either of those.
Sign in to Reply
cdhmanning
8/2/2011 10:57 PM EDT
These days most of the functionality normally comes from software, not hardware. Increasingly, the hardware is just life support for software.
I don't know how many times I've been impacted by a HW guy has decided to change something because he felt it was aesthetically more pleasing without understanding that the change was going to cost weeks or more of software effort.
NB however that the opposite seldom hapens. How often does a SW guy change something that forces a HW guy to make a change? The problem is that management see HW as stuff that can't change but software is trivial to change.
Bottom line is that the HW and SW need to be designed together. Nobody makes any changes anything without first checking the implications.
Sign in to Reply
WKetel
8/3/2011 10:20 AM EDT
The comments about "hardware guys" and "software guys" are certainly on point. One additional impediment is that usually they think entirely differently. Aside from that, trying "abstraction" with hardware is a bit like walking on a cloud, not very solid. Once again, a lot of the problems could be solved by having a much better description of what the ultimate product would be. Of course, after the initial fuzzy-ball description, an absolutely complete detailed description of each and every function is part of the package. At that point, the hardware and software guys should be able to use the same words, unfortunately they don't even speak similar languages.
Sign in to Reply