
Chip 2.0: High Level C to Verilog with Python Bindings - Immortalin
https://github.com/dawsonjon/Chips-2.0
======
sweden
As an hardware engineer, I'm always skeptical of these homebrewed high level
design flows, they usually never seem to translate to good hardware.

And it seems to be the case for this one too. I quickly generated some Verilog
code from one of the given examples and I was surprised to see flip-flops
without reset. Also, not all registers are even being reset'ed at all.

I have some serious doubts about the quality of the hardware generated by this
tool.

~~~
tripletao
No need for async reset in most FPGA flows--the flops all start at zero, or
whatever you initialize them to. Adding one anyways may bloat your area, and
has no benefit. (Like, if you don't trust the FPGA's own power-on-reset logic,
then how do you expect it to get configured?)

~~~
analognoise
This. GP's comment is way old school. For most FFs in your designs, reset is
unnecessary.

Ken Chapman at Xilinx wrote some wonderful whitepapers about that; look them
up. Join us in enlightenment, brother.

~~~
sweden
It's not old school, it's standard practice in the ASIC design industry.

You mentioned those papers but you didn't link them, so I will have to guess
that this is the one in order to address your comment:

\-
[https://www.xilinx.com/support/documentation/white_papers/wp...](https://www.xilinx.com/support/documentation/white_papers/wp272.pdf)

I guess the keyword here is "FPGA design". The author of the paper argues that
the FPGA already offers an abstraction layer that allows the designer to
ignore the problem for certain occasions in order to save up on area.

> The good news is that 99.99% of the time, the timing of the reset release
> really doesn't matter. (...) However, if you have ever had one of the
> circuits that doesn’t work the first time, then maybe you have encountered
> one of the 0.01% cases and have been unlucky enough to have released the
> reset at the wrong time.

> A design implemented in a Xilinx FPGA does not require insertion of a global
> reset network. For the vast majority of any design, the initialization state
> of all flip-flops and RAM following configuration is more comprehensive than
> any logical reset will ever be. There is no requirement to insert a reset
> for simulation because nothing will be undefined.

But it doesn't mean it is 100% correct as this design would be very poor if it
was ever translated to an ASIC. I guess since this project is done with FPGA
design in mind, the strict ASIC design rules don't apply here.

~~~
tripletao
Not really a question of degree of correctness. Optimizing for FPGA vs. ASIC
implementation are just different problems. Approaches that are optimal for
one may be sub-optimal or outright wrong for the other.

------
ris
_Very_ interesting that this doesn't seem to lean on any existing compiler
toolchains - it all appears hand written from compiler through cpu generation.

I wonder how the results compare to something like TCE
[http://tce.cs.tut.fi/](http://tce.cs.tut.fi/) which takes advantage of the
LLVM ecosystem.

Given the lack even of advanced c-compiler optimizations and the inherent
drawbacks of FPGAs, can this even beat the power or speed performance of a
software implementation running on e.g. a modern ARM core?

~~~
TomVDB
I wish the documentation gave more details about the whole conversion process.

I'm guessing that the RISC core gets optimized by dropping instructions that
aren't needed for a particular C program.

But does it have some kind of heuristic to determine whether or not to drop an
instructions based on how often it's used? Or is it just a greedy "If the C
compiler generates instruction A, then add instruction A to the CPU" decision?

------
aylons
Very interesting. Please take note that this is not your usual transpiler such
as MyHDL or Migen:

"Behind the scenes, Chips uses some novel techniques to generate compact and
efficient logic - a hybrid of software and hardware.

Not only does the compiler translate the C code into CPU instructions, it also
generates a customised pipelined RISC CPU on the fly. The CPU provides the
optimal instruction set for any particular C program."

I'll test it out soon and post about it.

~~~
patrickg_zill
I wonder what it would do if you compiled a small Lisp or Scheme interpreter
that included eval with it.

~~~
aylons
I'm not sure if I have the software skills for that (my compilers course is
still pending in Coursera), but will try to do it!

However, I would not raise my expectations that much.

~~~
UncleEntity
You could try one of the minischeme implementations floating around github
without too much fuss.

Not sure how FPGAs do their thing but a swapping out fgets() with something
else and setting up the garbage collector to use one block of memory would
probably be necessary I'd imagine.

~~~
aylons
The FPGA architecture is not the problem here. This Chips thing works on
another level of abstraction: it will generate a small RISC CPU and run the
interpreter it compiles. So, maybe I can try to port
[http://armpit.sourceforge.net/](http://armpit.sourceforge.net/) or something
like this.

But I don't expect not very interesting to happen. The " CPU optimization"
will not result on a Lisp Machine. It will probably just compile the
interpreter as usual and prune unnecessary instructions.

------
ddcc7
Does anyone know how this compares to LegUp [0], an academic HLS tool for C to
Verilog? Apparently that tool has also been commercialized into a startup [1].

[0] [http://legup.eecg.utoronto.ca](http://legup.eecg.utoronto.ca)

[1] [http://www.legupcomputing.com](http://www.legupcomputing.com)

------
Cieplak
If you have the money/business, BlueSpec is the best tool for high level
synthesis.

[http://bluespec.com/54621](http://bluespec.com/54621)

------
pasabagi
This looks fascinating - thanks for sharing!

------
bedros
how different from myhdl [0]

[0] [http://www.myhdl.org/](http://www.myhdl.org/)

~~~
TomVDB
Completely different.

myhdl is an alternative to Verilog, but it's still RTL.

This tools takes the C code, compiles it to a custom assembler language and
embeds the generate assembler code as a ROM in a custom generated RISC
processor.

~~~
bedros
there's no mention of that in first few paragraphs

~~~
TomVDB
Indeed, there is not.

I had to run the example design to fully understand what it's trying to do.

