Re: pragmas (map_to_mux, etc.)

Stefen Boyd (stefen@boyd.com)
Wed, 05 Aug 1998 09:28:28 -0700

At 01:56 PM 8/4/98 -0500, Smith, Douglas J wrote:
>>From a standard point of view we don't necessarily want to specify how
>any particular synthesis tool shall implement fixed functionality.
>However, from a practical users point of view it is not possible, for
>example, to tell a synthesis tool that a certain signal shall be used as
>the enable to a flip-flop, or that an if statement shall map to an 8-1
>multiplexor.
>
>If we start adding a lot of new implementation specific pragmas
>we are specifying how the synthesis tool shall work. For example,
>one synthesis tool could implement an 8-1 multiplexer faster
>in gate level primitives, rather than being told specifically to map
>to am 8-1 multiplexer.

Of all the stages of synthesis, the mapping stage has the
greatest effect on the results. That's why we often write
such strange code... it's the only way to make the tools
start in the right place. Once an initial choice has been
made for implementing an hdl construct, there is often little
the optimization stage can do (muxes often can't be recognized).

Having said that, I believe we should make it clear that
compiler directives such as `synthesis_map_to_mux are not
supposed to force a mux to be implemented... they are
supposed to force the tool to *start* with a mux. If after
mapping the design, the optimization stage notices that it's
faster to implement the mux with two input and & or gates
that's ok.

Perhaps some of the directives that would stick around
during optimization are outside the scope of what this
working group wants to standardize, but directives that
aid the mapping are valuable.

Regards,
Stefen

--------------------

Stefen Boyd
__
| \ ____
|_/_ |
| \ |__
|___/oyd |
|___nterprises
stefen@boyd.com
(408)739-BOYD
(408)481-9658 (fax)