cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
okar
Visitor
Visitor
10,391 Views
Registered: ‎02-28-2013

XST inferring tristate buffer

hello,

it seems there is a problem with XST inferring tristate buffers.
See the following code:

 

*******************************
entity tmp is
  port (
    i_sda_ena   : in std_logic;
    b_sda_1      : inout std_logic;
    b_sda_2      : inout std_logic
        );
end entity;

architecture tmp_arc of tmp is

signal test: std_logic;

begin

  b_sda_2 <= '0' when i_sda_ena = '1' else 'Z'; -- line 53
  test <= '0' when b_sda_2 = '0' else '1';
  b_sda_1 <= test;

end architecture;
*******************************


in XST Report:
...
    Found 1-bit tristate buffer for signal <b_sda_1> created at line 53
...

synthesis schematic shows:
b_sda_1 is OBUFT
b_sda_2 is OBUF

-> thats wrong synthesized code


But if I write instead:

 

 b_sda_1 <= '0' when i_sda_ena = '1' else 'Z'; -- line 53
 test <= '0' when b_sda_1 = '0' else '1';
 b_sda_2 <= test;

 

in XST Report:
...
    Found 1-bit tristate buffer for signal <b_sda_2> created at line 53
...

synthesis schematic shows:
b_sda_1: OBUFT
b_sda_2: OBUF

thats what I expected

 

Can anyone explain this behavior of XST?

I use PlanAhead 14.5 and Spartan6

Thanks

 

0 Kudos
10 Replies
bassman59
Historian
Historian
10,385 Views
Registered: ‎02-25-2008

Oh, that's weird.

----------------------------Yes, I do this for a living.
0 Kudos
athandr
Xilinx Employee
Xilinx Employee
10,367 Views
Registered: ‎07-31-2012

Hi,

 

CHeck in simulation to verify the behavior.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
eilert
Teacher
Teacher
10,330 Views
Registered: ‎08-14-2007

Hi,

that's really kind of irritating at first glance.

But I think the ISE-XST programmers did a really good job here.

 

Simulation shows the expected behavior, but for synthesis one has to think in terms of physics.

 

So you are feeding back the tristate signal to switch the other output (b_sda_1).

  A physical input can react to '0' or '1', but feeding in a pure 'Z' would cause something unpredictable.

 

To convert a 'Z' to something useful, you can use a pullup for instance, meaning the 'Z' would be seen as a '1'.

In that case the b_sda_1 output will become '1' too. (like you wrote in the VHDL source)

If you decide to use a pulldown instead the selector will always see a '0' and b_sda_1 will remain '0' all the time.

 

In any case b_sda_1 will be equal to b_sda_2.

 

So everything's fine and no HW-ressources are wasted.

 

Only exception is if you miss to add a pullup or pulldown resistor.

But then you are to blame for causing a CMOS input to float.

(If you chose a TTL input there's an implicit pullup behavior.)

 

Edit:

The synthesis messages might be irritating, but who knows what kind of iterations XST has to go through to find out that both outputs are equal, and for the hardware it doesn't matter which port name is chosen to drive the two pins. Take a look at the RTL-Synthesis schematic. 

The Technology-Schematic also looks interesting. Let me do a post-par sim...

 

Edit2:

and here are the results:

 

 Now you can see that the simulator does not know what to make from the 'Z' signal feeding the output driver of b_sda_1.

So everythings correctly assigned according to the VHDL source.

I have not used any pullup or pulldown here, just default settings. The result might change if you decide to make some useful settings in the UCF file.

 

Have a nice synthesis

   Eilert

 

0 Kudos
vijayak
Xilinx Employee
Xilinx Employee
10,326 Views
Registered: ‎10-24-2013

Hi,
Also check in ISE 14.7
Thanks,Vijay
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
okar
Visitor
Visitor
10,311 Views
Registered: ‎02-28-2013

Hi,

 

thanks for the replies.

 

@eilert 


In any case b_sda_1 will be equal to b_sda_2.
So everything's fine and no HW-ressources are wasted.

 

b_sda_2 is an open drain signal with external pullup (on pcb). There are several devices with open drain output on the pcb driving this signal (wired-or). So b_sda_2 should be a tristate buffer.

b_sda_1 is just a copy of this signal on another pin and should be pushpull.

 

The signal levels seen at both pins are equal, but for the function it's necassary that b_sda_2 is a tristate buffer like the 1. version of vhdl source.

 

Same behavior in ISE 14.7.

 

Thanks, okar

 

0 Kudos
eilert
Teacher
Teacher
10,307 Views
Registered: ‎08-14-2007

Hi Okar,

so you intended this but were just wondering about the strange message in the XST report?

 

btw.

I just did a small test.

This code gives the same HW-Results:

 

  b_sda_2 <= '0' when i_sda_ena = '1' else  'Z';

  b_sda_1 <= b_sda_2;

 

So you don't need the test signal and the conditional assignment to it at all.

It also gives the same stange message about using a tristate buffer for b_sda_1.

 

Have a nice synthesis

  Eilert

0 Kudos
geoffbarnes
Explorer
Explorer
10,284 Views
Registered: ‎09-07-2011

It does seem weird that the OBUFT followed "b_sda_1"  and not "line 53" when you swapped b_sda_1 and b_sda_2.

 

 

Another thing is that b_sda_1 is declared as an INOUT -  if I understand  it really should be just a normal OUT.  This might help  XST make the right choice.

 

 

0 Kudos
eilert
Teacher
Teacher
10,260 Views
Registered: ‎08-14-2007

Hi,

when you are using b_sda_1 just as an output the out declaration is sufficient.

I changed and tested this in the very beginning.

Still it makes no difference to the results.

You get the funny message but the actual assignments match with the code.

 

Have a nice synthesis

  Eilert

 

0 Kudos
avrumw
Expert
Expert
10,246 Views
Registered: ‎01-23-2009

I am a big fan of inferring logic wherever possible, but in this case, wouldn't it just be easier to instantiate the IOBUF component? The T input is (not i_sda_in), the I input logic 0, the O output is b_sda_1 and the IO inout is b_sda_2...

 

Avrum

0 Kudos
okar
Visitor
Visitor
5,318 Views
Registered: ‎02-28-2013

Hi,

 

I thought there is something special with my vhdl code that activates that behavior of xst. But it seems it is just a failure of xst, so I have to take care of it.

Sure, using an IOBUF component or declaring b_sda_1 as output would avoid the problem.

 

 

thanks for the replies

okar

0 Kudos