Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chisel: Constructing Hardware in a Scala Embedded Language

chisel.eecs.berkeley.edu

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#11

Post by gluggymug »

trsohmers wrote: post #9
Skooma wrote: post #8

In my opinion, Chisel feels like "lets write Verilog with Scala syntax." I personally see MyHDL as a better approach as you can leverage existing libraries for generating code (i.e. use scipy to generate the coefficients for your FIR filter). One plus is Chisel generates C++ code for testing your design which is a huge speed increase versus simulating Verilog.

The biggest problem with MyHDL in my opinion (As someone using Chisel to make a commercial processor) is its (non existent) "real" simulation capabilities. If something is not cycle accurate (the way that Chisel's C++ simulator is), you can not really be positive of anything...and you don't want to get to physical design and find out you can't meet timing.

You saying MyHDL is not cycle accurate? Could you give a citation for that?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#12

Post by trsohmers »

gluggymug wrote: post #11
trsohmers wrote: post #9

Earlier quoted context omitted.

The biggest problem with MyHDL in my opinion (As someone using Chisel to make a commercial processor) is its (non existent) "real" simulation capabilities. If something is not cycle accurate (the way that Chisel's C++ simulator is), you can not really be positive of anything...and you don't want to get to physical design and find out you can't meet timing.

You saying MyHDL is not cycle accurate? Could you give a citation for that?

Check out the bottom: http://www.myhdl.org/start/whatitisnot.html

I should say that in generating Verilog or VHDL from MyHDL, you can do proper simulations with that... but Chisel's C++ simulator is significantly faster than a Verilog simulator, while still being cycle accurate.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#13

Post by gluggymug »

nickpsecurity wrote: post #10

Chisel is a nice toolkit that proved itself in the Rocket processor. One of the more unusual uses of it was Chisel-Q for quantum computing: http://www.cs.berkeley.edu/~kubitron/papers/qarc/pdf/Chisel-... Chisel is pretty well-known in academic, hardware community. So, here's a few that you might have not heard of. Caisson - language-based security meets HDL http://www.cs.ucsb.edu/~chong/papers/109-Caisson-pldi.pdf SH…

Just took at look at the cx-lang website. I think it may be too weird for a beginner looking for results. I've been in ASIC & FPGA engineering for 15+ years. The design flow I think they use is more like writing a program that gets translated into hardware. Very different from the regular methodology. Sounds great but there's a big leap between that and getting your FPGA working. For a beginner, it's too much to take on.

I think maybe Chisel and those others would be easier.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#14

Post by nickpsecurity »

gluggymug wrote: post #13
nickpsecurity wrote: post #10

Chisel is a nice toolkit that proved itself in the Rocket processor. One of the more unusual uses of it was Chisel-Q for quantum computing: http://www.cs.berkeley.edu/~kubitron/papers/qarc/pdf/Chisel-... Chisel is pretty well-known in academic, hardware community. So, here's a few that you might have not heard of. Caisson - language-based security meets HDL http://www.cs.ucsb.edu/~chong/papers/109-Caisson-pldi.pdf SH…

Just took at look at the cx-lang website. I think it may be too weird for a beginner looking for results. I've been in ASIC & FPGA engineering for 15+ years. The design flow I think they use is more like writing a program that gets translated into hardware. Very different from the regular methodology. Sounds great but there's a big leap between that and getting your FPGA working. For a beginner, it's too much to take…

Yeah, I was actually hoping it was a high-level synthesis tool. I appreciate your review on the ease-of-use aspect.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#15

Post by gluggymug »

trsohmers wrote: post #12
gluggymug wrote: post #11

Earlier quoted context omitted.

You saying MyHDL is not cycle accurate? Could you give a citation for that?

Check out the bottom: http://www.myhdl.org/start/whatitisnot.html I should say that in generating Verilog or VHDL from MyHDL, you can do proper simulations with that... but Chisel's C++ simulator is significantly faster than a Verilog simulator, while still being cycle accurate.

Okay this is getting weird. I just read your link so this is all from my first impressions.

MyHDL is talking about co-simulation on the gate-level netlist. They do not recommend it. However they say MyHDL can do co-simulation on Verilog RTL. That will be cycle accurate I believe.

As I understand it Chisel can't even do co simulation at all. Am I incorrect? Essentially once you translate your Chisel design to verilog you basically can't reuse your verification environment for the RTL simulation or the gate-level. How are you going to check timing if you wrote all your tests in Chisel?

So Chisel seems worse than MyHDL but neither can support verifying a gate-level sim so you are somewhat screwed either way. It's just a matter of how badly screwed you are.

That's kinda the problem with all these tools I believe. A while ago someone posted about Clash. Same issue.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#16

Post by gluggymug »

nickpsecurity wrote: post #14
gluggymug wrote: post #13

Earlier quoted context omitted.

Just took at look at the cx-lang website. I think it may be too weird for a beginner looking for results. I've been in ASIC & FPGA engineering for 15+ years. The design flow I think they use is more like writing a program that gets translated into hardware. Very different from the regular methodology. Sounds great but there's a big leap between that and getting your FPGA working. For a beginner, it's too much to take…

Yeah, I was actually hoping it was a high-level synthesis tool. I appreciate your review on the ease-of-use aspect.

I think it is a high level synthesis tool like a SystemC etc.

My concern for a beginner would be how to get your high level design integrated into the FPGA. For a beginner, there are a lot of what-ifs that they are probably going to stumble on.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#17

Post by Skooma »

trsohmers wrote: post #7
bra-ket wrote: post #5

it's used by Rex: http://www.theplatform.net/2015/07/22/supercomputer-chip-sta...

Hey, CEO of REX here... would be happy to answer questions. P.S. We're hiring Chisel developers! If you don't know chisel, but want to learn and have RTL experience, we'd love to have you learn on the job! Check out our website: http://rexcomputing.com

What differentiates your company's Neo Chip vs Adapteva's Epiphany co-processor?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#18

Post by trsohmers »

gluggymug wrote: post #16
nickpsecurity wrote: post #14

Earlier quoted context omitted.

Yeah, I was actually hoping it was a high-level synthesis tool. I appreciate your review on the ease-of-use aspect.

I think it is a high level synthesis tool like a SystemC etc. My concern for a beginner would be how to get your high level design integrated into the FPGA. For a beginner, there are a lot of what-ifs that they are probably going to stumble on.

Chisel is not high level synthesis, which is one of the reasons why I love it. You are actually describing the circuit itself, with is what a hardware description language is supposed to do. While describing the function of a circuit like MyHDL and many other languages have tried to do it cute, they have never come close to a real engineer thinking of how to solve the problem with registers and combinational logic directly.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#19

Post by trsohmers »

Skooma wrote: post #17
trsohmers wrote: post #7

Earlier quoted context omitted.

Hey, CEO of REX here... would be happy to answer questions. P.S. We're hiring Chisel developers! If you don't know chisel, but want to learn and have RTL experience, we'd love to have you learn on the job! Check out our website: http://rexcomputing.com

What differentiates your company's Neo Chip vs Adapteva's Epiphany co-processor?

A number of things... The first thing is that Neo is not a coprocessor, it is a fully independent many core processor. To quickly go over the basics:

1. Neo has a 64 bit core, and conforms the IEEE 754-2008 Floating Point standard... Epiphany is 32 bit, and is not fully IEEE compliant (along with only being capable of single precision FP).

2. The existing Epiphany chips cap out at 32KB of local memory per core (with the Epiphany IV having a total of 2MB of on chip memory), while the planned Neo chip will have 128KB of local memory per core (32MB of on chip memory).

3. Epiphany is limited to using it's 4 eLink (based on ARM's AXI interface) connectors to access the outside world, and would typically be connected to either other Epiphany chips or to its host processor. Each eLink port only supports 1.6GB/s bidirectional traffic, giving a total of 6.4GB/s of aggregate chip bandwidth. For Neo, we have developed a new 96GB/s (bidirectional, 48GB/s each way) interface with either 3 or 4 interfaces per chip, giving an aggregate chip-to-chip bandwidth of 288-384GB/s.

4. Neo can directly address DRAM attached to it, instead of having to go through a host processor.

5. Neo is a Quad issue VLIW core (capable of a 64 bit ALU op, 1 64 bit FPU op/2 32 bit FPU ops, and 2 load/store ops every cycle) compared to Epiphany's standard superscalar core (Capable of 1 32 bit ALU op, 1 32 bit FPU op, and 1 load/store op per cycle).

All of this adds up to actually being a commercially viable (for industry, not hobbyists) processor. Above all, memory bandwidth has been what kills Epiphany and completely prevents it from reaching their advertised performance.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#20

Post by trsohmers »

gluggymug wrote: post #15
trsohmers wrote: post #12

Earlier quoted context omitted.

Check out the bottom: http://www.myhdl.org/start/whatitisnot.html I should say that in generating Verilog or VHDL from MyHDL, you can do proper simulations with that... but Chisel's C++ simulator is significantly faster than a Verilog simulator, while still being cycle accurate.

Okay this is getting weird. I just read your link so this is all from my first impressions. MyHDL is talking about co-simulation on the gate-level netlist. They do not recommend it. However they say MyHDL can do co-simulation on Verilog RTL. That will be cycle accurate I believe. As I understand it Chisel can't even do co simulation at all. Am I incorrect? Essentially once you translate your Chisel design to verilog…

Chisel doesn't require co simulation, as it is actually RTL in itself... it describes actual logic (registers and gates) instead of the functionality of the chip (as MyHDL does). Chisel being actually RTL makes it much easier for actual hardware engineers to use, but still allows for very powerful paramaterization that cuts down on total number of lines that have to be written. I would even say that it being embedded within Scala helps software engineers who have basic knowledge of hardware be able to be much more productive than if they were trying to write in Verilog.

Getting into my opinion here: High level synthesis has never been (and I doubt for a long time) able to beat an experienced RTL engineer because of that fact that a software description (such as MyHDL, Clash, SystemC, etc) of a piece of logic will never map perfectly to hardware. Chisel doesn't have this problem, as you are just describing (or "constructing") the logic itself. No "translation" process happens, and thus you don't have any problem actually simulating at the same RTL level as Verilog.

Post reply on HN