Online C-to-FPGA tool

Hello,

My name is Nadav and I am the author of http://www.C-to-Verilog.com ;
This website allows FPGA developers to take regular C code and
"compile" it into Verilog. The Verilog code can be verified with the
auto generated test-bench and then synthesized to an FPGA. The
compiler tries to "pipeline" as much code as possible to get a design
which is fast, operates at high frequencies and takes as few resources
as possible (LUT, DSPs, BRams, etc).

I would appreciate any feedback.

Nadav Rotem

Hi,

I like to give you a first feedback before having a look at your tool
just based on your announcement.

On 13 Dez., 12:18, Nadav Rotem <nadav...@gmail.com> wrote:
> compiler tries to "pipeline" as much code as possible to get a design
> which is fast, operates at high frequencies and takes as few resources
> as possible (LUT, DSPs, BRams, etc).
>
> I would appreciate any feedback.

It sounds wrong to me when you convert an algorithm by "pipeline as
much as possible to get high frequencies and take as few resources as
possible".
You should give the user the abbility to select between high frequency
and few resource usage by additional constraints, because high
frequency and few resource usage are typically contradictional
tradeoffs.

bye Thomas

This sounds interesting,
thanks for sharing. i'll try it sometime

On Dec 13, 2:51=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> Hi,
>
> I like to give you a first feedback before having a look at your tool
> just based on your announcement.
>
> On 13 Dez., 12:18, Nadav Rotem <nadav...@gmail.com> wrote:
>
> > compiler tries to "pipeline" as much code as possible to get a design
> > which is fast, operates at high frequencies and takes as few resources
> > as possible (LUT, DSPs, BRams, etc).
>
> > I would appreciate any feedback.
>
> It sounds wrong to me when you convert an algorithm by "pipeline as
> much as possible to get high frequencies and take as few resources as
> possible".
> You should give the user the abbility to select between high frequency
> and few resource usage by additional constraints, because high
> frequency and few resource usage are typically contradictional
> tradeoffs.
>
> bye Thomas

On Dec 13, 9:51=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> Hi,
>
> I like to give you a first feedback before having a look at your tool
> just based on your announcement.
>
> On 13 Dez., 12:18, Nadav Rotem <nadav...@gmail.com> wrote:
>
> > compiler tries to "pipeline" as much code as possible to get a design
> > which is fast, operates at high frequencies and takes as few resources
> > as possible (LUT, DSPs, BRams, etc).
>
> > I would appreciate any feedback.
>
Hi Thomas,

Thank you for the feedback. I agree with what you have said. First, I
identify the parallelism. Later I decide which parts I want to
exploit.

I let the user decide between several trade-offs. The user needs to
decide between "cycles for completion" "design size" and "design
frequency".

The users cannot control these directly but only via the number or
resources they assign to the circuit (example: memorts, multipliers,
etc). Also, the properties of the resources they assign will determine
the frequency. A 5-stages multiplier will operate at a much higher
clock frequency than a 2-stages pipelined multiplier. This is also
configurable. The video in the website shows some of the configuration
options.

Nadav Rotem

> It sounds wrong to me when you convert an algorithm by "pipeline as
> much as possible to get high frequencies and take as few resources as
> possible".
> You should give the user the abbility to select between high frequency
> and few resource usage by additional constraints, because high
> frequency and few resource usage are typically contradictional
> tradeoffs.
>
> bye Thomas