[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tr:Rep:Re: [f-cpu] "Tree"

> Humm :D Juste one question, are you a quite young designer with 5 or 10
> years of experiences, no ?

Yes, but I have seen few very big projects already from the ASIC side:)

> The typical design is made more or less as follow :
> - specification : mainly with hand and paper
> - then design partition hard/soft
> - then you start to code the HW
> - and then the SW (but you could start the soft ware more or less in the
> same time and the following funny point is the merge ;)

Yes that is the flow I was trying to explain. All projects I have seen
have been like this. I have been in tfew projects that described ASIC at
behavioral level and I think that took quite big amount of resources. That
helped verification but not the whole process.

> Codesign aren't only simulated SW with HW, it's a way of design. The
> idea is to clearly describe your specification. Formal language are the
> best for that because it will proove some properties. Todays tool's
> maker try to implement "runnable specification". SystemC is born with
> that idea in mind.

I think the problem is how to describe the system. Think about a system
that has tens of thousands of pages of text describing the functionality.
It is not easy to describe system like that with any description language.
In what phase can you start real HW implementation? I think it is quite
futuristic still to think that you can create some working HW from very
high level system descriptions. Todays tools are very far from that. Even
simple behavioral synthesis didn't really work (Synopsys BC).

And if you have read SystemC for example at RTL level it is very ugly.
Even ABEL is easier to read :)

> So you try to push the SW/HW split as far as you can to find the best
> cut. So you avoid redesign or late problem. It's well know that later a
> problem is found, more costly it is. I have even read that cost are 10x
> at each level.

I don't think system description languages really help the HW/SW
interface. It still needs much manual labor and talented SW and HW guys
fighting what should be done in each side. SW and HW people just have so
different way of thinking the solutions. What is easy in SW might be
impossible in HW and other way around. I don't really see how automatic
tools could have more kowledge than humans in that work phase. I have not
seen any real benefits from SystemC style design and I have tried to find
them. And many other designers have not found the benefits either (read
for example deepchip.com).

Of course I hope that someone founds the silver bullet to speed up the
design, but I don't think it has been found yet,

> So, by using SystemC, you are supposed to win a lot of time, the feed
> back are quicker and much more efficient.

That is the theoretical view. But is it really true. At least I think it
is not. I'd like to see real examples how time was really spared and talk
to engineers that managed to do that.

To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/