1. Timing predictability (muxing two signals before WE of RAMS,
selecting one of two clocks, etc) Note the alternate implementation
of of nands,nors,aos is does not provide balanced timing due to the
unpredicability of the placements of the individual cells.
2. Avoiding Gate/RTL Simulation mismatch with respect to X
propagation. Most UDP's for mux cells pass known values (0 or 1)
to the output of a mux even though the select line may be "x"
provided both inputs are identical. This is not the case with a
"fractured" mux implementation using the nands/nors,aos, etc.
3. Performance impact: Many synthesis tools use global variables to
guide the selection of muxes over their "fractured" counterpart
implementations. These are general set to reflect the design style
of a particular project, particular performance quirks in a
library, or knowledge of the routing impact of muxes to the
routability in the columns of cells on the final ASIC. For cases
#1 and #2 above, pragmas allow the user to select a few locations
in the RTL where muxes should be used while allowing for the
default mapping algorithm in the rest of the design to give no
preference to muxes.
These are just a few cases, there are others.
I think there is some confusion about the role of the rlt_map_to_mux
pragma. It is not intended to force a mux to be used (after all some
Technology libs dont have muxes), it merely captures the designers
intent of "this should be a mux, trust me I know why I need it here"
without having to inform the synthesis tool of all the
rococo-intricacies associated with the decision to select a mux in a
particular region of a design. In my opinion, it would not be
incorrect for a tool to select a "fractured" implementation when the
rtl_map_to_mux is used ("fractured" implementation could be faster
(small wireload model) and thus the mux replaced during optimization).
The pragma merely helps guide the implementation by telling to tool to
keep the mux in the implementation as long as possible.
> I don't really believe in the source code instructing the synthesizer of which
> algorithm is best. Source code is known so stay around much longer than what
> the original developer thought, and I'm afraid many pragmas would become
> irrelevant in the process.
Consider the alternative: Hand instantiating a technology MUX cell. That
is far less portable to future implementations.
This the view from a synthesis and simulation centric user. Other
views exist and input is welcome.
-Don
==========================================================
Don Hejna Ambit Design Systems, Inc.
408-566-8024 408-566-8000 (main)
djhejna@ambit.com 408-988-3233 (fax)
==========================================================
Alain RAYNAUD writes:
> On Jul 3, 2:10pm, Smith, Douglas J wrote:
> >
> > At the recent face-to-face meeting we discussed pragmas. One of
> > the issues was a means of communicating to a synthesis tool that
> > it should map directly to a multiplexer. As such I have am proposing
> >
> > // rtl_map_to_mux
> >
> > which can be associated with a case or if statement.
>
> Sorry I missed the face-to-face meeting, so maybe this has been discussed
> already.
>
> However, I fail to understand the point of providing such a pragma. What does
> it do?
>
> As a tool writer, what should I do with it? Why not trust the optimizing engine
> to generate whatever logic is best for the target architecture? What if the
> same source code (with the pragma) is used to target completely different
> architecture?
>
> I don't really believe in the source code instructing the synthesizer of which
> algorithm is best. Source code is known so stay around much longer than what
> the original developer thought, and I'm afraid many pragmas would become
> irrelevant in the process.
>
> Basically, such pragmas tend to pollute the code with additional information
> that may or may not be used. And, as you pointed out, one could make up
> hundreds more of these for all kinds of cases. Until a new mapping algorithm
> makes them all obsolete.
>
> Alain.
>
> --
> -----------------------------------------------------------------------
> Alain RAYNAUD META SYSTEMS
> R&D Logic Design Team Batiment Hermes
> 4, rue Rene Razel
> Tel: (33) 01 69 35 10 15 91400 Saclay - FRANCE
> E-Mail: Alain_Raynaud@mentorg.com Fax: (33) 01 69 35 10 10
> -----------------------------------------------------------------------
>