Chip 2.0: High Level C to Verilog with Python Bindings
1–10 of 29 posts
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#2This looks fascinating - thanks for sharing!
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#3Very 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.
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#4Very 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/ 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?
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#5As 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.
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#6how different from myhdl [0]
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#7how different from myhdl [0] [0] http://www.myhdl.org/
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.
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#8Very 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/ 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…
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?
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#9As 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 th…
The presence or lack of a reset on a FF isn't exactly the best proxy for hardware quality.
Re: Chip 2.0: High Level C to Verilog with Python Bindings
#10As 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 th…
The presence or lack of a reset on a FF isn't exactly the best proxy for hardware quality.
Strange bugs can happen if the hardware is not correctly initialized and the presence of an asynchronous reset is almost an universal practice when it comes to this.
Not to mention that the coding style of a always@ block might influence certain optimizations in the hardware synthesis tool. If the FF is not explicit in the code, the tool might infer a latch instead, for example.
It's true that there are reasons to use use always@ blocks like the generated code provides but it's not really obvious in this case why it is being used.