cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
7,142 Views
Registered: ‎10-01-2013

Can someone explain keep heirarchy and tristate buffers to me?

Jump to solution

I have the following I2C interface code which should instantiate a tri-state buffer in one of my sub modules:

 

  w_SCL_PAD_IN <= io_i2c_scl;
  io_i2c_scl   <= w_SCL_PAD_OUT when w_SCL_PAD_OE_L = '0' else 'Z';

 

It took me forever to realize that the tools were removing this tri state buffer when I had the keep heirarchy synthesis attribute set to NO.  I had to set it to either SOFT or YES, both of those work.  I'm not sure I understand why this was happening.  Is recommended design practice to instantiate all of your tristate buffers at the highest level to avoid this problem?

0 Kudos
Reply
1 Solution

Accepted Solutions
Guide
Guide
9,352 Views
Registered: ‎01-23-2009

actually it is a required practice to instantiate all your tristate buffers at the highest level (ie chip level) to avoid this problem because there are no tristate buffers anywhere else. Tristate output buffer only exists at the chip IO and there are no internal tristates in Xilinx FPGAs. So all tristate has to be converted to 2 wire interface (output and output_enable) internally till it gets to the chip boundary.

 

Lets not confuse levels of hierarchy (which is an RTL abstraction) and the FPGA boundary. While it is true that the top level ports of your top module become ports of the FPGA, other than that, there is no relationship between hierarchy and your design. Just because there are no tristates "internal" to the FPGA, doesn't necessarily mean that the tristate buffer has to be at the top level of hierarchy. An "inout" port of an internal module is just an abstraction, and doesn't actually map to anything, so it is syntactically legal to have a tristate buffer down many levels of logic, and then port the resulting tristated signal up to the top level of your hierarchy (using inout ports), and out of the chip. In other tools (i.e. ASIC tools) this is perfectly legal and handled properly, and this doesn't require any internal tristates. The only thing that the "no internal tristates rule" means is that a tristated signal must go only to the ports of the FPGA - whether directly or through hierarchy.

 

That being said, it is a Xilinx recommendation (not hard requirement, though, at least as far as I know) to place your IBUFs, OBUFs and IOBUFs at the top level of the hierarchy. But, it is not correct for the tools to remove the buffer silently, no matter what.

 

If it is a hard requirement that the buffer needs to be at the top (and, again, I don't think it is), then the tools should error out saying something like "Tristated signal detected in a lower level of the design". It is never acceptable for the tools to generate incorrect logic.

 

This is a bug, and a webcase should be filed on it.

 

Avrum

View solution in original post

6 Replies
Teacher
Teacher
7,140 Views
Registered: ‎03-31-2012
actually it is a required practice to instantiate all your tristate buffers at the highest level (ie chip level) to avoid this problem because there are no tristate buffers anywhere else. Tristate output buffer only exists at the chip IO and there are no internal tristates in Xilinx FPGAs. So all tristate has to be converted to 2 wire interface (output and output_enable) internally till it gets to the chip boundary.
- 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
Reply
Guide
Guide
9,353 Views
Registered: ‎01-23-2009

actually it is a required practice to instantiate all your tristate buffers at the highest level (ie chip level) to avoid this problem because there are no tristate buffers anywhere else. Tristate output buffer only exists at the chip IO and there are no internal tristates in Xilinx FPGAs. So all tristate has to be converted to 2 wire interface (output and output_enable) internally till it gets to the chip boundary.

 

Lets not confuse levels of hierarchy (which is an RTL abstraction) and the FPGA boundary. While it is true that the top level ports of your top module become ports of the FPGA, other than that, there is no relationship between hierarchy and your design. Just because there are no tristates "internal" to the FPGA, doesn't necessarily mean that the tristate buffer has to be at the top level of hierarchy. An "inout" port of an internal module is just an abstraction, and doesn't actually map to anything, so it is syntactically legal to have a tristate buffer down many levels of logic, and then port the resulting tristated signal up to the top level of your hierarchy (using inout ports), and out of the chip. In other tools (i.e. ASIC tools) this is perfectly legal and handled properly, and this doesn't require any internal tristates. The only thing that the "no internal tristates rule" means is that a tristated signal must go only to the ports of the FPGA - whether directly or through hierarchy.

 

That being said, it is a Xilinx recommendation (not hard requirement, though, at least as far as I know) to place your IBUFs, OBUFs and IOBUFs at the top level of the hierarchy. But, it is not correct for the tools to remove the buffer silently, no matter what.

 

If it is a hard requirement that the buffer needs to be at the top (and, again, I don't think it is), then the tools should error out saying something like "Tristated signal detected in a lower level of the design". It is never acceptable for the tools to generate incorrect logic.

 

This is a bug, and a webcase should be filed on it.

 

Avrum

View solution in original post

Professor
Professor
7,124 Views
Registered: ‎08-14-2007

It's actually OK to infer tristate buffers in a lower level module as long as the pad signal doesn't branch.  i.e.  you can have a single top level inout port connected to a single lower level module inout port (and so on if you want to go further down the hierarchy).

 

I've done pretty much what you posted in my own Verilog code and did not see any effects from setting keep hierarchy to "no."  What part are you targetting, and what version of ISE?

-- Gabor
0 Kudos
Reply
Visitor
Visitor
7,106 Views
Registered: ‎10-01-2013

I definitely do not branch my signal off anywhere.  It goes straight from the pin, one module down into my I2C module and doesn't go anywhere else.  I'm interested in getting to the bottom of this, because it doesn't make much sense to me.  I would think that setting keep hierarchy to YES would have a negative effect rather than fixing the problem. 

 

I'm using ISE 14.6 on Windows and targeting a Spartan 6.

0 Kudos
Reply
Professor
Professor
7,098 Views
Registered: ‎08-14-2007

As Avrum said, it looks like a bug.  If you can, open a web case.  If you don't have access to the webcase system, then your best bet is to reduce the code as much as possible to something that still shows the problem and post it here.

-- Gabor
0 Kudos
Reply
Visitor
Visitor
3,475 Views
Registered: ‎03-31-2016

Since Xilinx no longer supports ISE and Vivado doesn't support Spartan 6 (mistake on their part) filing a webcase will do no good.  You will have to use Soft to get around this bug.

 

0 Kudos
Reply