Does research work about hardware software codesign of embedded system make a sense in industry?

I suppose I will throw my $0.02 into the hat, since part of my mission in my most recent "life" was to study co-simulation options, as a soft- ware developer working *inside* an IC design team.

IME, it is difficult to get buy-in on the software side, at least when drving the process from an ASIC design group. Seems the logic simula- tors used by the IC designers intimidate the software developers, with their plethora of arcane options and commands. Moreover, many software developers--even EE's accustomed to "programming down to bare metal"-- do not especially want to decode simulator waveforms[1], to determine whether their software is working.

On the hardware side, making a cosimulation setup adquate for the soft- ware developers can get pretty hairy, too. It may be necessary to com- bine what would ordinarily be a large number of separate, design unit test benches, to simulate enough of *the system containing* the DUT to provide anywhere near the coverage available with a physical prototype and "load box".

I have heard that there is a good ROI in time-to-completion, when both teams (hardware and software) buy into the process; but haven't witnes- sed it, personally, except in projects small enough that hardware and software engineers work side-by-side, anyway, and co-design happens as a natural consequence, without need for formal tools or processes.

-----

[1] With the possible exception of nutcases like myself, who consider logic analyzers to be a preferred debugging tool; and even I have occasionally asserted that "Sometimes, there's no good substitute for a 'real'[2] load box!" [2] Yes, I think calling a load box "real" is ironic, too.