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

Re: [f-cpu] System C



hello !

Bruno Bougard wrote:
> 
> Hello,
> 
> I recently discover your project
how ? :-)

> and I guess I can contribute a little
> bit to it. I am working in an interuniversitary microelectronics
> research center in belgium (imec) and we are active in different field
> including SoC design technologies.

It is nice to see someone from IMEC again on the list !
I know this institute because i have seen the presentation
booths during the DATA exhibitions and they are always interesting.

And guess what ? I have a collector ! it's a IMEC mouse pad
made from a recycled PCB :-)

one or two years ago (?) i saw that someone from IMEC was
subscribed but i don't remember any conversation with him.

> We are developping some EDA tools to
> support it, including a C++ class library that can be seen as 'the basis
> of System C'. This is exactly the same philosophy: It enable integrated
> HW/SW (co-)simulation with different refinement level (from data flow to
> RTL) and it can also be used to generate synthetizable vhdl or verilog
> code. The library is really stable (more than System C ;-) and has
> already been used internally for several high-ends designs (inclusing a
> cable-modem, a 802.11a-like (it was before the standard) baseband
> transceiver, ...). You can have more information on
> http://www.imec.be/desics/design_technology_top.html
> It can be used freely even it is not really under GPL.

We are already full-steam into VHDL coding.
In fact the largest part of the work is dealing with
low-level things.
When i tried to make some C simulations, when i tried
to analyse the scheduler, it appeared that C is not adapted
to this task. Or maybe i wanted to write VHDL code in C.

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.
This is not the case with F-CPU.

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

> Regards and best wishes
thank you, happy new year and please post often,

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