[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[f-cpu] Codesign and SystemC
- To: <email@example.com>
- Subject: [f-cpu] Codesign and SystemC
- From: <firstname.lastname@example.org>
- Date: Fri, 11 Jan 2002 09:03:57 GMT
- Delivered-To: email@example.com
- Delivered-To: firstname.lastname@example.org
- Delivered-To: email@example.com
- Delivery-Date: Fri, 11 Jan 2002 04:04:19 -0500
- Reply-To: firstname.lastname@example.org
- Send-By: 220.127.116.11 with Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; FR 15/06/2000)
- Sender: email@example.com
i answer to JG, but my mailer didn't want to copy
On Thu, 10 Jan 2002, nicO wrote:
> 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.
Ohh! But even with SystemC you can't really
can't just write your software and move the sw/hw
BECAUSE you already have to write those parts
C that you want to be able to put into hardware
means you aren't really using a new method but a new
- the division is done also in relatively early
stages of the
>>>> The split must NOT be done at early stage. It
will be done at the LATER point. Why because
dependanding of performance you want, you could do to
choose to put thing inside a pure static hardware
engine, a application specific cpu or in pure
software. This choice could only be "well" done after
fine analysys of the algorythme. Todays a choice is
made and the algorythme sould feet in it. So you take
udge DSP to have enough marges, in case of problem.
SystemC are C++ so your could always start to write
things in pure software style and then you refine
your model to have working hardware (after split) (an
other advantage is the speed 1000 x quicker than VHDL
What I would want is to write just a normal program
have a tool that extracts me the parts of my complete
functionality that can be put into hardware. I don't
restrictions on the programming style side. And I
>>>>There isn't any restriction ! They come when you
want to synthetis things after the split, when
performance requirement are well known and
tool that tells me about the achievable performance
every step of the development process. Only then you
make intelligent decisions.
>>>> Some tools exist to do that : eArchitect from i
don't know which compagny, ... They call that :
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/