UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
9,789 Views
Registered: ‎09-07-2011

Tri-state to Mux Conversion

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?

 

0 Kudos
11 Replies
Teacher rcingham
Teacher
9,771 Views
Registered: ‎09-09-2010

Re: Tri-state to Mux Conversion

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.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Explorer
Explorer
9,762 Views
Registered: ‎09-07-2011

Re: Tri-state to Mux Conversion

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

 

 

 

 

0 Kudos
Historian
Historian
9,750 Views
Registered: ‎02-25-2008

Re: Tri-state to Mux Conversion


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

----------------------------Yes, I do this for a living.
0 Kudos
Explorer
Explorer
9,745 Views
Registered: ‎09-07-2011

Re: Tri-state to Mux Conversion

Nevertheless, I'm looking to understand this feature. I will ask Xilinx directly. Thanks.
0 Kudos
Xilinx Employee
Xilinx Employee
9,722 Views
Registered: ‎08-17-2011

Re: Tri-state to Mux Conversion

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.

 

- Hervé

SIGNATURE:
* New Dedicated Vivado HLS forums* http://forums.xilinx.com/t5/High-Level-Synthesis-HLS/bd-p/hls
* Readme/Guidance* http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

* Please mark the Answer as "Accept as solution" if information provided is helpful.
* Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Explorer
Explorer
9,674 Views
Registered: ‎09-07-2011

Re: Tri-state to Mux Conversion

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.

 

0 Kudos
Highlighted
Contributor
Contributor
9,406 Views
Registered: ‎06-07-2012

Re: Tri-state to Mux Conversion

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

Teacher rcingham
Teacher
9,390 Views
Registered: ‎09-09-2010

Re: Tri-state to Mux Conversion

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

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Newbie gah4
Newbie
3,998 Views
Registered: ‎08-21-2015

Re: Tri-state to Mux Conversion

I don't see anything wrong with wired-OR or wired-AND, as long as you know what it is doing inside the chip.

 

In the case of new designs, there are better choices.  (AND-OR or OR-AND), but when converting an existing TTL design that uses open-collector gates and pull-up resistors, wired-AND logic more accurately represents what it is doing.

 

It is convenient in that you can add/remove modules without complications, rerun the synthesis tools, and get the right result.

0 Kudos
Voyager
Voyager
1,359 Views
Registered: ‎04-21-2014

Re: Tri-state to Mux Conversion


geoffbarnes wrote:

 

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

 

...

 


 

The synthesizer supports converting descriptions of internal tri-states to muxes to gain market share of ASIC and ancient FPGA conversion, mostly.  Engineers don't have to rewrite their pre-exisiting code, leading to lower cost of adoption thanks to shorter development time.  

***Many of us who help you are just FPGA enthusiasts, and not Xilinx employees. If you receive help, and give kudos (star), you're likely to continue receiving help in the future. If you get a solution, please mark it as a solution.***
0 Kudos
Xilinx Employee
Xilinx Employee
1,288 Views
Registered: ‎07-01-2010

Re: Tri-state to Mux Conversion

@geoffbarnes

 

If you are looking for an option in XST to convert tri-state logic you can use "Convert Tristates to Logic" constraint.XST replaces the internal tristates of those devices with equivalent logic using the Convert Tristates to Logic (TRISTATE2LOGIC) constraint.

 

For details on the usage and limitations refer to the XST user Guide

 

-Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos