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

[f-cpu] Codesign flow and systemC

Kim Enkovaara a écrit :
> > 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 :)

Sur ! But look at SystemC 2.0 it's far more interresting than SystemC
1.0 (which is purely horrible VHDL in C)

> > 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,

The code written in SystemC (or what ever language of that level :
Esterel, SDL, ...). You always describe communication channel, object,
interface, port and so on. All that could be software or hardware : it's
only task to do.

So with such "high level" language, you start very soon to code, much
bevore specification are stable. So you could reach problem much faster,
and redefined thing earlier.

SystemC could not make the split HW/SW but help the designer to do it.
There is "some" architecture explorer tools in the market to help to do

> > 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/
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/