Synthesis

[geoffbarnes]

Been playing with using tri-states internally as logic..    Since the synthesizer can infer muxes from "tri-state" RTL, it becomes a convenient short hand as you can "add"  terms to the mux as you need.

Anyways, I've noticed that the unspecified select states of the inferred mux will default to 1. 

For example :

mux_out <= term0 when sel='0' else 'Z';

mux_out <= term1 when sel='1' else 'Z';

As expected, results in :

                 sel

                 _|_

term0  --| 0     |

               |         |-- mux_out

term1  --| 1     |

                 -----

But :

mux_out <= term0 when sel='0' else 'Z';

Results in :

                 sel

                 _|_

term0  --| 0     |

               |         |-- mux_out

       '1'  --| 1     |

                 -----

In this case, the sel is not 0, the synthesizer assumes the mux_out should be a 1.   This is consistent with the synthesizer assuming the mux_out node is "pulled up" when nothing is driven. 

Anyway to change this behaviour so that the default is a ZERO?  This would be akin to a pull down.

Any thoughts?   Am I missing something?

[rcingham]

mux_out <= term0 when sel='0' else '0';

IMHO designing your RTL to have internal tri-states when the technology doesn't support them is not a clever thing. YMMV.

[geoffbarnes]

The issue is when there are multiple terms to the mux, for example:

If you have an incomplete definition:

mux_out <= term0 when sel="00" else 'Z';

mux_out <= term1 when sel="01" else 'Z';

mux_out <= term2 when sel="10" else 'Z';

ISE XST synthesizes this to basically :

case (sel)

    when 0 : mux_out <= term0;

    when 1 : mux_out <= term1;

    when 2 : mux_out <= term2

    when others => mux_out <= '1';

end case

Just a little curious since "tri-state to mux inference" is supported, but there's no clear way to specify what the default should be when sel="11".

[bassman59]

---

geoffbarnes wrote:

Been playing with using tri-states internally as logic..    Since the synthesizer can infer muxes from "tri-state" RTL, it becomes a convenient short hand as you can "add"  terms to the mux as you need.

Any thoughts?   Am I missing something?

---

The argument against doing this is that your simulation doesn't match the resulting hardware.

That's to be avoided for the obvious reasons.

[geoffbarnes]

Nevertheless, I'm looking to understand this feature. I will ask Xilinx directly. Thanks.

[herver]

Hi Geoff, 

The previous expert's answers should be enough.. I assume you don't want to start a circular argument?

Tri-states are not supported by internal logic in the FPGA and the synthesis tool interprets what you describe by the 2-state building blocks primitives it has.

Your MUX example worked, and other examples may work because the 'Z' state may be safely replace by a 0-or-1 level signal. That applies to mux or if-then-else constructs.

Taking the argument the other way around: it's not supported. Period. So, when your design using unsupported constructs "fails" ot "doesn't work" what do you expect?

The answer is simple: nothing.

[geoffbarnes]

Of course we know there are no "tri-states" inside the FPGA.   However, the tools do allow us to use tri-state semantics to infer logic.   For that to happen, I'm guessing someone at Xilinx must of had to think about it and then pay somebody to add the feature into XST?

I was surprised that the few synthesizers I tried did convert tri-states into logic.  But I guess when you think about it, it's just another way to describe behaviour and it could be another tool in the toolkit.  I did find that caveat when a mux is not  completely described, which is why I thought I would bounce it off the folks on this forum.

Anyways, for the purpose I had in mind, I've found that the Verilog wor (wired or) type is supported and it nicely infers an OR function, fed by all the "drivers" of the net.  Never realized that before.   (Keep in mind there are generally no "wired or" structures in an FPGA).

Unfortunately, XST does not support resolution functions in VHDL, which I'm pretty sure is the only way to do a wired OR.

I was surprised that Quartus Synthesis will actually synthesize user resolution functions, so you can write something which looks a multidriver, but in the resolution function you create a cloud of logic that works it all out.

Neat.

[jlarin]

Hi,

What you want to do is to use the following attributes:

 attribute tristate2logic_pullup: string;
    attribute tristate2logic_pullup of DATABUS: signal is "no";    -- 0 in case the bus is not driven

I have taken that from http://forums.xilinx.com/xlnx/board/crawl_message?board.id=SYNTHBD&message.id=3387

In the synthesis log, you will see something like " Unit UNITNAME: 3 internal tristates are replaced by logic (pull-up no): "

Please note the "no" instead of "yes"

In older ISE (8.x I think), there used to be a command line option to control that: -tristate2logic_pullup no

I just tried it with ISE 13.2 and it doesn't work.  It is a sad thing that Xilinx Employee try to convince you that your are wrong to try to do that, because tri-state just happen to do exactly what is often needed.

For example, if I have multiple variations of my project which can be controlled by 3 generics.

genfa: if USE_FEATURE_A generate

           featurea port map

           (input  => input,

           outputreadback => readbackbus);

end generate;

genfb: if USE_FEATURE_B generate

        featureb port map

        (input => input,

        outputreadback => readbackbus);

end generate;

genfc: if USE_FEATURE_C generate

     featurec port map

     (input => input,

     outputreadback => readbackbus);

end generate;

Then, by turning on or off the USE_FEATURE_x I can change the behavior of the code automagically. The alternative to code manually a mux is complex and error prone. Technically, there are 8 possibilitied with 3 features that can be turned on and off.  Three features isn't so bad to build the mux, but what happens when there are 30 modules that generate various readbackdata that needs to be muxed? How many possibilitied need to be taken care? How many signals need to be declared?  Also, with a tri-state, every sub-module knows when it has to drive the bus. With an explicit mux, you must add this address decoding at the top level to replicate the same address decode than what is done inside the module. This isn't the cleanest way to do it.  Tristate is cleaner.

You have to understand that VHDL is just a language that enables the translation of abstract concept into electronic hardware.  A AND exists. A OR exists.  But a IF isn't an electronic primitive.  It is the synthesis tool that takes that concept and generates a mux, a flip flop with or without a Clock Enable etc. 

Is there anything in VHDL that would behave like the wired-or of verilog, beside the tri-state?

jf

[rcingham]

> Is there anything in VHDL that would behave like the wired-or of verilog, beside the tri-state?

Only useful if the synthesizer supports it. Which it doesn't. And you might as well assume never will. So write what the synthesizer DOES understand, and is a good match for the FPGA fabric.