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

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

Kim Enkovaara a écrit :
> > crapy C-style VHDL : to much heavy ! SystemC 2.0 is
> > quite nice and intriduice concept as channel,
> > interface, port and events. This stuff are really
> > usefull for specification for Hardware as for
> > software. You could create your simulator then refine
> > it until to understand what is better to put in
> > hardware or software (for example : how much
> > automative must be the SRB).
> I think biggest problem with SystemC style approach is that it is quite
> different compared to the real design process of many products. It's quite
> academic thinking that the product is first defined with some system
> language and only after that the implementation starts.
> For example if the product has an ASIC the ASIC design starts quite much
> before other designers even know about the product. ASIC design usually
> takes that 1.5-2 years. USW/higher level SW guys are still in their old
> projects during the start of ASIC phase. And ASIC is the critical path
> usually in products. If you design the system at system SW level before
> ASIC project it usually means substantial amount of system level code.
> Even if that code is directly usable in the end product the TTM is longer.
> ASIC project can be started later because the system description takes so
> long time. On the other hand if the ASIC is specified in done
> with traditional means and system SW design for example starts at the same
> time, time is saved.
> I think the real question is can the time used in system interface
> optimization saved in later stages of design. Usually competent designers
> can do quite good HW/SW interface (fortunately this list has HW guys :)).
> Can you really save the time needed to fix some HW quirks in SW by using
> much more time to design the interface.

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

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 ;)

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 don't thing it the best idea because to run something, you _must_
allmost finish a kind of simulation of your system. But at least, you
don't need to write synthetisable stuff.

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.

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


> *************************************************************
> 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/