Xilinx Tristate Registration

You need to check the compatibility of the control and clock signals that may be common resources in the IOB between the output register and the tristate register. Any conflict will mess up the packing before the synthesizer contemplates proper replication for bussed signals. I'd go straight to FPGA_Editor for this information.

If you don't find a conflict that *would* keep these from packing, try using the IOB=3DTRUE attribute applied to the tristate primitives in the .ucf file. This last item might require you to instantiate primitives if you don't get a nice name you can select uniquely through wildcards.

Have fun pushing the rope!

- John_H

Hi Brad, What John_H said ^. There are limited clock resources to the IOBs. My additional suggestion is to use FPGA editor to visualise the problem. Cheers, Syms.

Like he said! Whooops!

Can you separate the register from the tri-state?

I have always coded this (in Verilog) as

input pin; ... reg pin_en; reg pin_out;

assign pin = pin_en ? pin_out : 1'bz;

Then I assign to pin_en and pin_out however I want, although usually with an always @(posedge clk).

The flip-flop will map into the IOB if the resource is available, otherwise into the array.

Brad

If you have a similar tristate function on more than one register it may be your synthesiser being clever and removing a "duplicate" register. If reduced like that then when you get to the back end a single tristate register can't be mapped into the I/O and be shared and hence ends up in the fabric. Have a look at the remove duplicate register synthesis options and turn that off and see if that solves your issue.

John Adair Enterpoint Ltd. Home of Craignell. The obsolete component solution.

"John Adair" wrote >

Thanks John (Symon and John_H too).

I do use the FPGA editor to visualize the placement of the logic. Is there a faster method through a report? And I don't see any incompatibility between the tristate clock and the data_out clock. And I have the remove duplicate register synthesis option off. I even tried to introduce bogus independent data into the tristate output so the synthesiser would not be able to see duplicate registers. These didn't work.

What did work is that I moved the registration of the tristate and the data_out to the top module. This was fairly easy to do by cutting the if clk'event and clk='1' line, changing the sensitivity from clk to a list of combinatorial signals, and using a clocked process in the top module to assign the submodules tristate and data_out.

I have the IOB primitives in a separate submodule as I have seen Xilinx often do on their memory models. So one has this heirarchy: top / \ IOBs work

This is probably a Xilinx ISE9.2 bug.

The data_out signals were properly placed with or without the registration in the top module. The tristate signals were not.

Brad Smallridge AiVision

I've previously had problems with XST + hierarchy + registered tristates, with a 'fix' being placing the IO tristate stuff all at the top level.

It sounds like you found a workaround already, but here's an old post on getting this to work for S3 with XST 6.x and 7.x, see the tristate comments in the code snippets and archive:

Brian

Active high enables often don't push into the IOB. I would suggest rather:

assign pin = pin_en ? 1'bz : pin_out;

But in the end I've found that duplicate register removal also prevents pushing tristate registers into the IOB's (if more than one pin has the same tristate function). Also providing the registered function in a lower level module, but the tristate function at the top level will prevent the push. i.e. the assign pin ... statement in the top level module, but the clocked always blocks for pin_en in a lower level module.

Regards, Gabor

What would be nice is a latched IOB tristate primitive.

Brad Smallridge AiVision

You can make your own. This was done for a DDR reference design (forget which one). The issue is not that the registers need to be at the top of the hierarchy, but at the same level as the pin. So if you have a module that contains all of the IOB components and assign the pin in the port mapping, it should do what you want.

Regards, Gabor