[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tr:Rep:Re: [f-cpu] "Tree"
On Fri, 11 Jan 2002, Kim Enkovaara wrote:
> > I rather have the opinion that after the chip is ready and the
> > software starts to use it the problems show up - 2 years lost.
> > And imagine - who can spend more than 2 years time to market?
> If that happens then there is something wrong in the organization. The
> normal way to work succesfully is to have SW people in ASIC design reviews
> to give input how they would want the interface. "Half" of my job
> currently is to discuss with SW guys about ASIC configuration and pinpoint
> their needs also. If they have good suggestions that are easy to do then
> they should be part of the ASIC. If the interface fails, I think it
> usually pinpoints problems in the communication between USW and HW.
> > After 2 years time the premiss may have changed completely.
> > Some ASICs were cancelled right when they were finished and
> > working.
> Cancellation might not mean that HW/SW interface is bad. It might mean
> that the whole product is not needed. The world needed other things
> than what was an edugated guess from the upper level management. Products
> are always gambling, not all of them succeed. I think it is better to
> cancel product if there is no need for it.
> > Why use more time? If one has HW quirks either the definition
> > was sh.. or one has overlooked something fundamental or one
> > tried to save time from simulation (pressing schedule).
> > And - and that is my biggest concern - one didn't know how
> > the software will use the interface later.
> If HW side doesnät know how SW wants to use the chip then there is a
> problem in communication. Company like that can't survive, you can't fix
> that with new description language. I'm verification guy and at least in
> my projects we try to verify the interfaces SW wants to use and in the
> same way SW uses the interfaces. But my team uses advanced OO
> verification tools to write test benches that are quite comples, more like
I have seldom read an answer which is so true!
There are lots of communication problems between HW and SW.
Only few of the companies I worked for didn't have them. There
always seemed to be that ravine between hardware and software
thinking and talking. Somehow I was always standing in the
middle - building the bridge - taking a look at the problem
and finding the source of it. But neither software guys nor
hardware guys were happy about the solution when the cause
was on their side. They didn't really work together.
And that's exactly what I mean, hardware and software guys
aren't usually building ONE team. They are foolishly divided
into company divisions in all big companies (that I worked
for). This produces a concurrency where you don't need it
at all. I hope this is better within your company.
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/