Common subexpression elimination in Chisel elaboration?

[Øyvind Harboe]

I wrote a function in a module that I use extensively. 

However, Chisel figures out that although this function is invoked 4 times, it's only really referring to 4 different expressions and the Verilog is quite terse.

Of course synthesis would figure out the same thing, but the disadvantage of leaving this to synthesis is that the Verilog becomes bloated, so much better to have Chisel do this!

Nice!

Is there a blurb about the Chisel common subexpression elimination capabilities somewhere?

[Jack Koenig]

Thanks for the positive feedback :)

As far as I know, we don't really describe the optimizations done nor the motivation for doing so.

I know you were asking more about the "what?" than the "why?", but I've been meaning to write something up on the motivation so this thread is now my excuse to at least put something down in text:

Users often assume we do optimizations to improve the QoR (ie. power, performance, and area) of the design. This is not really the motivation. Synthesis tools do a much better job than we could dream to and it's not really worth duplicating that effort. The reasons we do optimizations are:

1. To make our Verilog friendlier to the tools

2. To make the Verilog friendlier to read

3. To make compilation run faster

4. To enable certain design patterns

(1) is the primary goal, and it is _related_ to QoR because our optimizations do help ensure that the Verilog matches certain patterns expected by the tools.

(2) This one is counterintuitive so bear with me for a moment. While it is often true that optimizations remove stuff that users would like to see and this can be confusing and frustrating, in most cases, the optimizations make the Verilog _more clear_, and you really want them on. This is hard to illustrate with simple examples, but in complex generators there is *a lot* of garbage that is extremely distracting if it isn't cleaned up. I'm not going to pretend that we've found the right balance of when to optimize vs. when to not (and we need to do better), but that's the basic idea.

(3) is the least important of the goals but it is nice when things run faster.

(4) is somewhat subtle and needs further explanation than I can do off the top of my head. Basically, when writing a generator with lots of parameters, sometimes it's simpler to express logic unconditionally and rely on optimizations to remove it if it's not needed. For example, If you have a generator using TileLink, the version of the protocol you're implementing may or may not implement all of the channels. While at some point you need to implement or not implement a channel, there's often lots of glue logic where it's more convenient to not worry about that and just connect things through as if the entire protocol is being implemented. This then relies on optimizations to remove the unused channels or it will be extremely confusing (with lots of lint warnings) in the Verilog. I think this is another area where we could do better, perhaps making these design patterns more explicit, but they are pretty common in rocket-chip and related projects.

I hope this explanation is useful to someone.

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/5760ad21-7652-4b03-9a6e-d89e2b0b0b28n%40googlegroups.com.

[Kashif Inayat]

Dear Jack Koenig,

Indeed you are right, we might not need to duplicate the effort as synthesis tool will make the optimization.

Besides optimization, other isssue is readability of the verilog code. Being hardware engineer I believe, the RTL generated through CHISEL is not human readable, which makes verification step difficult in chip designing process. E.g.: If there is a bug in your verilog code, it might take weeks or at least days to debug or fix in CHISEL generated RTL instead hours.

In long story short, there is a gap in the way CHISE generate design RTL and the way an hardware engineer/expert will make the RTL.

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CAFooY_R%2B3HEji5e%3DnhOmiW-kEkMMg3TyAdbTdx8y_CTwPBTdxw%40mail.gmail.com.

[Øyvind Harboe]

This was very helpful. Thanks!

I find that it is oftentimes easier and clearer to write Chisel code that describes a fully general case and then specialize modules where Chisel strips away all the cruft not needed in the special cases that are actually realized in Verilog. I find that the optimizations that Chisel have increases readability enormously in these cases. It also reduces FUD about what synthesis can and cannot do in terms of optimizations.

Writing out the special cases by hand in Verilog is error prone and hard to maintain for this sort of code.

You received this message because you are subscribed to a topic in the Google Groups "chisel-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chisel-users/Jr1d3AlVnlo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CAFooY_R%2B3HEji5e%3DnhOmiW-kEkMMg3TyAdbTdx8y_CTwPBTdxw%40mail.gmail.com.

--

Øyvind Harboe
+4791786146