Live data from Hacker News

Chisel: Constructing Hardware in a Scala Embedded Language

chisel.eecs.berkeley.edu

31–40 of 59 posts

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#31

Earlier quoted context omitted.

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…

I've been skimming through MyHDL stuff. It does support RTL like Chisel supposedly. http://docs.myhdl.org/en/latest/manual/rtl.html So it should simulate RTL and give you cycle accurate waves. No gate level sim for either tool means you're dead meat which ever way you go, so I am not sure why I am even bothering to look at this stuff. The respective merits of each approach is somewhat pointless when crucial steps in…

Of course we do all of our real tests on the generated verilog. (Note: There is a big difference between generated verilog, in the Chisel sense, and synthesized verilog, in the MyHDL sense). We use Chisel to write our RTL and do quick and dirty testing with our gold model, and if that matches up, we generate the verilog and do the "real" testing from that point. This whole flow is a iterative process that can happen several times a day, or once a week, depending on how much development is going on. This of course leaves out the other steps once you synthesize the verilog for either a FPGA or VLSI tools, which we also do.

What you linked to there seems to be a "mode" (Can't think of a better name to describe it at the moment), similar to how you can embed verilog or C++ into Chisel.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#32

Earlier quoted context omitted.

I've been skimming through MyHDL stuff. It does support RTL like Chisel supposedly. http://docs.myhdl.org/en/latest/manual/rtl.html So it should simulate RTL and give you cycle accurate waves. No gate level sim for either tool means you're dead meat which ever way you go, so I am not sure why I am even bothering to look at this stuff. The respective merits of each approach is somewhat pointless when crucial steps in…

I have some of the same concerns and would like to see someone from industry who has actually done it before I spend much more time on it. My additional question is then how did the academics do it? There are some tools that negate some/most of the need for gate sims but at my company we still do not ship without SOME gate sims.

@gluggymug

You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#33

Earlier quoted context omitted.

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 I agree with you on that. For a beginner I think a high level language is the wrong direction to go because it's taking them further away from the method of designing a HW solution. It's adding another layer of abstraction.

That's what people said about going to 3GL's. I'm glad, for my day-to-day computing, that most went in the other direction (pro 3GL's). Software people can't get the kind of results hardware people can while using HLS techniques. That's obvious. Yet, the existing research shows they should be able to get quite a bit of results with little knowledge of hardware. EDA tools actually solved most of the hard parts. Only t…

I think maybe the HLS can get you a core design but then when you try to use it and integrate into an FPGA you will have to deal with the low level issues of registers and combinatorial logic. This is fine for the experienced HW person, but not for the beginner. In other words, the HLS is better for the experienced HW designer than the beginner even though it looks like its easy.

Unfortunately there is no infrastructure for you to build onto. It's like a blank slate. All the I/O needs to be done right. It's very seldom just instantiating wires unless your design is blazingly simple. And if it were simple you wouldn't need an FPGA in the first place. A generic coprocessor would kick most FPGAs butts.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#34

Earlier quoted context omitted.

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 I agree with you on that. For a beginner I think a high level language is the wrong direction to go because it's taking them further away from the method of designing a HW solution. It's adding another layer of abstraction.

That's what people said about going to 3GL's. I'm glad, for my day-to-day computing, that most went in the other direction (pro 3GL's). Software people can't get the kind of results hardware people can while using HLS techniques. That's obvious. Yet, the existing research shows they should be able to get quite a bit of results with little knowledge of hardware. EDA tools actually solved most of the hard parts. Only t…

Still , Cx - lang is having a real hard time to find customers. So what's missing ?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#35

Earlier quoted context omitted.

I have some of the same concerns and would like to see someone from industry who has actually done it before I spend much more time on it. My additional question is then how did the academics do it? There are some tools that negate some/most of the need for gate sims but at my company we still do not ship without SOME gate sims.

@gluggymug You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?

How do I get my test stimulus into my simulator? And where is my checking?

Hypothetically I wrote my tests and checkers in Chisel. I now want to run a gate level simulation of my tests. I asked the same thing to the Clash guys. Can it do that?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#36

Earlier quoted context omitted.

I have some of the same concerns and would like to see someone from industry who has actually done it before I spend much more time on it. My additional question is then how did the academics do it? There are some tools that negate some/most of the need for gate sims but at my company we still do not ship without SOME gate sims.

@gluggymug You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?

@gluggymug (2nd... don't know why the 'reply' button doesn't appear below your comment)

Yep. Check out this https://github.com/ucb-bar/rocket-chip ... there are plenty of testing options you can do, including waveform vcd testing.

EDIT: Also, relevant paper: http://www-inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab3-... ... check out the part regarding test harness

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#37

Earlier quoted context omitted.

I've been skimming through MyHDL stuff. It does support RTL like Chisel supposedly. http://docs.myhdl.org/en/latest/manual/rtl.html So it should simulate RTL and give you cycle accurate waves. No gate level sim for either tool means you're dead meat which ever way you go, so I am not sure why I am even bothering to look at this stuff. The respective merits of each approach is somewhat pointless when crucial steps in…

Of course we do all of our real tests on the generated verilog. (Note: There is a big difference between generated verilog, in the Chisel sense, and synthesized verilog, in the MyHDL sense). We use Chisel to write our RTL and do quick and dirty testing with our gold model, and if that matches up, we generate the verilog and do the "real" testing from that point. This whole flow is a iterative process that can happen…

Ok. If you do the majority of your testing on the generated Verilog, I am not sure what the point of the Chisel C++ cycle accurate simulator is. I thought that ran on the Chisel RTL.

What simulator do you use to test the generated Verilog? And what language do you write the tests in?

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#38

Earlier quoted context omitted.

@gluggymug You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?

@gluggymug (2nd... don't know why the 'reply' button doesn't appear below your comment) Yep. Check out this https://github.com/ucb-bar/rocket-chip ... there are plenty of testing options you can do, including waveform vcd testing. EDIT: Also, relevant paper: http://www-inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab3-... ... check out the part regarding test harness

(Yeah you can't reply straight away)

Looking at a lot of stuff you referenced.

I think my definition of tests is a lot more generic than yours. Taking a look at your links it seems tests are written in RISC-V machine code? The code will execute some functionality of the CPU and check for an expected response then possibly through a logging IO from the chip send a pass/fail message to the test harness or update a status register that is polled.

They run Verilog simulation on RTL and gate-level using Synopsys VCS. (At least they didn't skip it! Which is good!)

This is a very specific way of doing stuff that really only applies to this particular core with very little I/O.

We don't do it this way in industry. (This is where a throw a drink in the face of whichever Berkley academic that put this crap together.) The last time I saw something like this was maybe 1999-2000. It is terrible. Usually testing is done at the interfaces.

A real-world design has lots of I/O. For me, a test generically should stimulate the inputs to the design as well as have code for the CPU if it exists. Checkers check the outputs of the design for correct behavior. These stimuli and checkers are written in the verification language of your choosing. This is the standard approach. More checkers peek into signals inside the design itself usually.

If that stuff is written in Chisel so it can be simulated by the C++, then you are screwed for the RTL and gate-level. This is what I am saying.

The RISC-V test harness pretty much only has a clock and reset for inputs, Some sort of host bus. That's it! And the tests are assembly code or whatever.

If your design is not a CPU, what would your test be? say it's a HW cryptography encoder thing, no code to load into a memory.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#39

Earlier quoted context omitted.

That's what people said about going to 3GL's. I'm glad, for my day-to-day computing, that most went in the other direction (pro 3GL's). Software people can't get the kind of results hardware people can while using HLS techniques. That's obvious. Yet, the existing research shows they should be able to get quite a bit of results with little knowledge of hardware. EDA tools actually solved most of the hard parts. Only t…

I think maybe the HLS can get you a core design but then when you try to use it and integrate into an FPGA you will have to deal with the low level issues of registers and combinatorial logic. This is fine for the experienced HW person, but not for the beginner. In other words, the HLS is better for the experienced HW designer than the beginner even though it looks like its easy. Unfortunately there is no infrastruct…

Ok that all makes more sense. One of my potential flows was actually having the amateurs build lost of functionality (eg accelerators, device protocols) with HLS tools that a hardware engineer could finalize for FPGA. Would save on the rare labor. What do you think of that model vs exclusively leveraging HW people?

Far as ASIC's, I'd just get HW people, haggle on the tools, use free one's if possible (see Qflow), and do a MPW run for prototyping/production. eASIC's 90nm maskless stuff, potentially. Start it on 180nm-350nm, though, as there's lots of cheap masks and fab capacity there.

Re: Chisel: Constructing Hardware in a Scala Embedded Language

#40
post #34

Earlier quoted context omitted.

That's what people said about going to 3GL's. I'm glad, for my day-to-day computing, that most went in the other direction (pro 3GL's). Software people can't get the kind of results hardware people can while using HLS techniques. That's obvious. Yet, the existing research shows they should be able to get quite a bit of results with little knowledge of hardware. EDA tools actually solved most of the hard parts. Only t…

Still , Cx - lang is having a real hard time to find customers. So what's missing ?

That's part of what I'm trying to find out. To be fair, most open-source, high-level synthesis tools don't have a lot of customers. Even Chisel doesn't have near as many users as its successes deserve. That's common for ASIC or FPGA tools that aren't the big name.

For now, my preliminary answer is that people: (a) just use Altera and Xilinx HLS tools for FPGA because they're cheap and work well with their products; (b) use HLS tools from big three EDA companies on ASIC design; (c) straight up do HDL (majority probably) for ASIC as experienced HW engineers are used to doing anyway and use good RTL synthesis. Against the competition, there's no comparison of free/open synthesis tools except in price and subversion risk. Those are my reasons for investigating them, though, so I continue to get feedback on what I find.

Note: Not sure of your HW expertise. If you're not a HW person, I'll note that anything synthesized for ASIC's needs to have a rock-solid method because mistakes are expensive. Even older processes still cost hundreds of thousands for the masks that print an instance of a design. Production engineers are hesitant to use unproven technology when $$$ are on the line.

Post reply on HN