Re: [f-cpu] System C

[Yann Guidon <whygee@f-cpu.org>]

hello,

Bruno Bougard wrote:
> Hello,
> > More generally, i do not believe that SystemC-like development
> > is useful now because it's a low-level thing, mostly bit manipulations
> > on a cycle by cycle basis on an already partitioned design.
> > SystemC is mostly used for "SoC" where the designer must
> > trade-off between HW and SW, but there is no SW needed here :-)
> > It would be useful for a communication protocol analyser,
> > for a MPEG/JPEG stream compressor/decompressor, for specific
> > applications requiring some complex and heavy load where
> > the HW optimisation must be balanced with the latency and costs.
> 
> That's true, and that's the kind of system I am used to cope with ... Anyway,
> System-C or SysC-like libraries can also make your life easier when you try
> to model and simulate a 'system' (it can be a CPU) which is not completely
> refined. The idea is to start the design by discribing a 'data flow' model
> (that sound DSP-like but it can be extented). The interest is that you can
> model a collection of concurrent processes (exactly like in vhdl) that are
> described in high level C. You don't need to be cycle-true at that level.

This is one of the main problem.
Though i use constrained DFG for programming, a superpipelined CPU
has more to do with queuing networks or something like that.
Furthermore, in FC0, the OOOC pipeline has different latencies,
depending on the operation, which makes the DFG a bit more complex...

> Then, you refined your model process by process (fixed-point quantization,
> timed behavior ...)
This has more to do with data characterization and algorithm
range exploration (or something like that, i don't know the exact words).
Of course this is very very useful when you have a specific application
in mind and you want to map it to a FPGA/ASIC and you have to determine
the algorithm's behaviour, stability and the bus width.
The design of a general purpose CPU has other constraints, i think.

> using the support of the library. The output is a FSMD
> model that can be automatically translated into vdhl or verilog for
> synthesis. At any time in the development, you can 'run' (simulate) the
> complete system, even if it is not completely refined.
> 
> Now, this is 'our methodology', I don't say it is the best ...

It is very good for the examples IMEC demonstrated, anyway.

> > This is not the case with F-CPU.
> I don't know it enough to judge fairly
don't worry, it's difficult to learn everything within a day...

however Carlos has recently made available the mail archive
that he extracted from Yahoogroups before we abandonned it.
There are almost 3 years of intense discussions and a lot
of attachements that, when sorted by date, show how the project
evolved.

There is also a "F-CPU manual" but it lags by at least a year.

> > However it is certainly very interesting to learn from the
> > newest design concepts and particularly from IMEC. Maybe F-CPU
> > could find a place, not as a user but as component of new
> > technologies ? Or at least there can be a way to cooperate
> > on implementing a chip ...
> Sure that I would like to have a look at your code. Do you have
> a cvs server ?
there is one at gaos.org but it's not much used.
You can find the manual there. There's also a weekly generated
tarball of the CVS tree at f-cpu.gaos.org IIRC.
look at http://www.f-cpu.org for more URLs.

however the latest source tree was the "stable" released
a few days ago. it is available from http://f-cpu.seul.org/new
and it's a 300KB tgz named "table_yg"something.
Please forgive my naughty hacks and the bad style :-)

> Regards
read you soon,
> Bruno
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/