
Chisel: Constructing Hardware in a Scala Embedded Language - archgoon
https://chisel.eecs.berkeley.edu/index.html
======
nickpsecurity
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-...](http://www.cs.berkeley.edu/~kubitron/papers/qarc/pdf/Chisel-q.pdf)

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](http://www.cs.ucsb.edu/~chong/papers/109-Caisson-pldi.pdf)

SHard - a scheme to hardware compiler
[http://scheme2006.cs.uchicago.edu/05-saint-
mleux.pdf](http://scheme2006.cs.uchicago.edu/05-saint-mleux.pdf)

Cx-Lang - A statically-typed, c-like, HLL for hardware [http://cx-
lang.org/](http://cx-lang.org/)

Note: I'd love for some people familiar with ASIC or FPGA design to check out
Cx-Lang to see if it's good for beginners getting results on FPGA's. The I.P.
they sell is so cheap that it's either (a) crap or (b) the result of a
productive, synthesis tool (Cx). Just like to know if it's a decent HLS tool
compared to FPGA or EDA company offerings. Additional advantage that it's open
so it can be reviewed for subversion if one is willing to invest the effort.

~~~
gluggymug
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.

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

~~~
gluggymug
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.

~~~
trsohmers
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.

~~~
jandecaluwe
You have it completely backwards. The best "real engineers" do _not_ "think
directly" on how to solve the problem with registers and combinational logic.
They think about how to solve the problem _functionally_ and let synthesis
take care of the logic as much as possible. MyHDL is ideal for that.

That is how ASICs/FPGAs have been designed by the best teams for the last 2
decades. And it is much more productive than the textual schematic entry you
are describing. There is simply no comparison. Synthesis works.

As for your word-playing attempt: "description" stands for a number of things,
among those "describing behavior". Just check the Verilog/VHDL LRM or MyHDL
manual.

~~~
nickpsecurity
Exactly. It's crazy to even think, outside of analog, that someone would want
to build a modern SOC with RTL directly. Even the full-custom folks like
Intel, correct me if I'm wrong, essentially use a hardware approach where they
can abstract away from and use EDA to synthesize to the stuff they hand-craft.
Most SOC builders simply don't have the labor to waste working at RTL for a
complex design & its inevitable problems. It's why they pay so much to the Big
Three for synthesis tools.

For software people following, it would be like trying to build Microsoft Word
with assembler while competition was using C/C++.

Note: Chuck Moore of Forth fame may be the exception to this rule in SOC
design. Then again, he's an exception to a lot of them. ;)

[http://www.ultratechnology.com/okad.htm](http://www.ultratechnology.com/okad.htm)

~~~
gluggymug
It depends on the project.

For SOCs that I was involved with (DSPs, mobile phone SOC, wifi SOC), you are
bringing together a lot of different IP from various sources. There's no way
to use these HLS tools unless the third parties feel like writing a model for
their IP in your choice of HLS tool language. This means you would have gaps
in _your_ HL design everywhere their stuff fits in. Verification in the high
level language would be tough work until those gaps are filled.

No doubt guys like Intel can use the fancy HLS tools on their SOC because they
own every module in the design. Same goes for the RISCV stuff: They can run
Chisel sims because they wrote every part of the design in Chisel.

The rest of us idiots are doing straight Verilog RTL because SOC level is more
about gluing a lot of different modules together with low level logic. Maybe
there's a tool here or there that generates a little Verilog from some other
language for you but that is very piecemeal.

It really is like building Word with assembler. But your job is more about
linking together static libraries that already work. It's grunt work and
nothing special. Being able to discover a bug via verification is the skillful
part.

This is where the cosimulation that MyHDL supports is so handy. Reading up on
it a bit more, it sounds very promising for the future. The Verilog RTL parts
run in the Verilog simulator while the MyHDL parts run in the MyHDL simulator.

~~~
nickpsecurity
" There's no way to use these HLS tools unless the third parties feel like
writing a model for their IP in your choice of HLS tool language."

I worried about that as it's a common problem in any domain integrating
different languages or models. Sounds like hardware equivalent of wrappers in
cross-language, software development.

"The rest of us idiots are doing straight Verilog RTL because SOC level is
more about gluing a lot of different modules together with low level logic."

That's actually good news and hopeful for people my research supports given
stuff you worked on. If it's really grunt work, then all these amateurs
digging into actual HDL wanting to do great things might get it done if they
leverage FPGA or ASIC-proven I.P. With at least one pro on team, maybe two if
mixed signal. People like me wanting to cheat it without RTL are apparently
screwed lol.

"Being able to discover a bug via verification is the skillful part."

Two have said that in one day. The other person said this: "People can do a
design without much skill and it might mostly work right. People screwing up
on verification can mess up the whole thing." Rings true as I think of mask
costs and Intel's recall.

"This is where the cosimulation that MyHDL supports is so handy."

All this time, I thought co-simulation (i.e. equivalence checking w/ tests)
was standard in your industry. I know Sandia's HW people did it and high
assurance does it between abstraction levels too to catch their gaps. It was
essential to me in the latter as an assumption or structural detail would
change to throw off safety/security properties. You saying equivalence
checking at each layer is _not_ normal in commercial, SOC design? That it's
essentially only the shops using the best EDA tools and such?

Just surprising is all. Would also seem easy if you just use the execution-
trace-based, equivalence checks. You can script those to a degree in most
domains and languages. They're not perfect but I thought that MyHDL feature
was a knockoff of what industry was already doing haha.

~~~
gluggymug
_You saying equivalence checking at each layer is not normal in commercial,
SOC design? That it 's essentially only the shops using the best EDA tools and
such?_

We have a difference in terminology. Co-simulation and equivalence checking
refers to different things in HW and neither are what you are referring to.

Co-sim is when you have two models running in simulation and you could
possibly compare them through time for mismatches. Or you run some sub-modules
of the design in a Verilog simulator and other sub-modules in your HLS tool
simulator and the modules can interact.

Equivalence checking is usually referring to different type of tool called the
formal equivalence checker (FEC). It performs analysis of the two models
without doing simulation with weird algorithms like decision trees. This is
usually used to compare the Verilog RTL to the gate-level netlist as an
additional quality control measure. If you can imagine the synthesis tool,
it's optimizing the logic you expressed in RTL and possibly put a lot of
different gates and signals. The FEC checks that usually.

When you have two cycle-accurate models, you usually would try to do FEC. But
it's typically both Verilog models! There's probably no Chisel-Verilog FEC or
"any HLS"-Verilog FEC tool!

So what you are referring to as co-simulation is typically just called
simulation. That IS standard at each layer so you would be correct: everyone
does simulation. It's just a question of how thorough.

What MyHDL offers in co-simulation is something more. The ability to mix the
MyHDL designs and Verilog RTL designs into one simulation. So if you had a 3rd
party mem cache in Verilog you could connect it to your MyHDL CPU and run a
simulation.

Industry tools do support co-simulation as well! But for me it's a good
surprise that MyHDL manages to knockoff that feature because the other HLS
don't seem to be able to. Maybe they can though, I am not sure. E.g. Chisel
can create a C++ model. I am sure I could hack something together given time.

------
Skooma
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.

~~~
trsohmers
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.

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

~~~
trsohmers
Check out the bottom:
[http://www.myhdl.org/start/whatitisnot.html](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.

~~~
gluggymug
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.

~~~
trsohmers
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.

~~~
gluggymug
I've been skimming through MyHDL stuff. It does support RTL like Chisel
supposedly.

[http://docs.myhdl.org/en/latest/manual/rtl.html](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 the HW process are completely ignored.

And now you are saying you don't test on the generated Verilog from Chisel?
That's no good. No one should just run tests in Chisel. You're delivering HW
not Chisel code as far as I am concerned. That's a few _huge_ steps more in
the flow that need vigorous testing. Where is the quality control?

So much more logic is added to chips during/after synthesis these days and you
have no way to get any of your tests running on that net list.

~~~
trsohmers
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.

~~~
gluggymug
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?

~~~
stephenmm
Actually this is the area that I am most interested in. I am responsible for
writing SystemC models of our designs so that firmware/software guys are able
to work in parallel with RTL development but it takes me some time to create
the models and get the timing reasonably equivalent (AT in SystemC speak) to
the RTL. If I had a flow were the same source could generate cycle accurate
models AND verilog this might be an acceptable answer and allow us to develop
SW/FW much more quickly.

In my world even though hardware takes an extraordinarily long time the FW/SW
is still the long poll in developing complex systems and anything that
shortens the time to $$$ in the door we should probably be looking into.

~~~
gluggymug
That does sound like a good aspect of Chisel. How do they test that the Chisel
RTL and the generated Verilog are equivalent though?

To me I would want a good verification environment that tests one against the
other. Testing just via loading self-checking code into FW/SW is not enough.
That's almost like SW verification. It assumes way too much is working
correctly.

I am fantasizing if its possible to also write the Verification IP in Chisel
AND convert that into a separate c++ library, then you can reuse it in a
commercial Verilog RTL and gate-level simulator via a PLI.

That would serve many purposes and make Chisel useable in a generic flow.

------
bra-ket
it's used by Rex: [http://www.theplatform.net/2015/07/22/supercomputer-chip-
sta...](http://www.theplatform.net/2015/07/22/supercomputer-chip-startup-
scores-funding-darpa-contract/)

~~~
trsohmers
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](http://rexcomputing.com)

~~~
stephenmm
Chisel is potentially a revolution in hardware design and I am following it
intently but I have not heard of anyone creating an actual chip from a
standard fab as of yet. I am trying to make an argument for trying this at my
work but I think until we get some more feedback from people in industry it
may be too risky of an endeavour. It would be great if you would be willing to
share your experiences or know of some papers that would help me build an
argument for trying it out.

~~~
trsohmers
UC Berkeley has taped out ~10-12 chips entirely designed using Chisel through
the standard flow and fabed at TSMC (As low at 28nm) and all have functioned.
My start up has had minimal problems with using Chisel and going through both
Cadence and Synopsys tools (most if not all the problems were user error :P)

Once we get closer to having silicon in hand, I'd love to publish our
experience as both a startup making a new processor in this day and age, along
with using Chisel and other new tools.

------
cmrx64
I've been playing with this for the past few weeks. It's a lot of fun compared
to Verilog or VHDL. The implementation is still young, though, and it's pretty
easy to trigger an undecipherable crash. But I haven't had anything miscompile
yet.

~~~
ci5er
I'm trying to get the Amulet1 (Async/unclocked ARM from Manchester, back in
the day) working as a test project. This, of course, requires Muller C-gate
stuff. I'm having a bit of trouble getting it all to work out.

Have you seen any obvious techniques/methods for unclocked circuits that I am
probably looking right past?

------
minthd
They claim this language is highly parameterized. I wonder how much.

For example can you design a generic processor in such a way that everything
will be parameterized?

~~~
rjsw
They use this language for RISC-V, if you look at the sources you can see the
kind of things that can be parameterized.

