Xilinx Tristate Registration

My tristate signals are not being placed
in the IOBs. They are clocked signals,
always all on or all off, depending on
reading or writing, and the registration
happens the fabric, not in the IOB. The
data_out signals are registered in the
IOB's correctly.

I have had this issue before with ISE7.1
and now again with 9.2. In the Synthesis
properties under Xilinx Specific Options
I changed the defaults Registration
Duplication to check and the Pack I/O
Registers into IOBs to Yes. No effect.

I really don't want these options anyway.
I really only want the tristate signals
properly placed in the IOBs along with
the data out signals. The defaults should
be OK elsewhere.

Can anyone help?

Brad Smallridge
AiVision.com

On Mar 14, 3:28=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> My tristate signals are not being placed
> in the IOBs. They are clocked signals,
> always all on or all off, depending on
> reading or writing, and the registration
> happens the fabric, not in the IOB. The
> data_out signals are registered in the
> IOB's correctly.
>
> I have had this issue before with ISE7.1
> and now again with 9.2. In the Synthesis
> properties under Xilinx Specific Options
> I changed the defaults Registration
> Duplication to check and the Pack I/O
> Registers into IOBs to Yes. No effect.
>
> I really don't want these options anyway.
> I really only want the tristate signals
> properly placed in the IOBs along with
> the data out signals. The defaults should
> be OK elsewhere.
>
> Can anyone help?
>
> Brad Smallridge
> AiVision.com

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

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13tlvrisdh1a212@corp.supernews.com...
> My tristate signals are not being placed
> in the IOBs. They are clocked signals,
>
> Brad Smallridge
> AiVision.com
>
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. 

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:frf7mi$pkq$1@aioe.org...
> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
> news:13tlvrisdh1a212@corp.supernews.com...
>> My tristate signals are not being placed
>> in the IOBs. They are clocked signals,
>>
>> Brad Smallridge
>> AiVision.com
>>
> 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.


On 14 Mar, 22:28, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> My tristate signals are not being placed
> in the IOBs. They are clocked signals,
> always all on or all off, depending on
> reading or writing, and the registration
> happens the fabric, not in the IOB. The
> data_out signals are registered in the
> IOB's correctly.
>
> I have had this issue before with ISE7.1
> and now again with 9.2. In the Synthesis
> properties under Xilinx Specific Options
> I changed the defaults Registration
> Duplication to check and the Pack I/O
> Registers into IOBs to Yes. No effect.
>
> I really don't want these options anyway.
> I really only want the tristate signals
> properly placed in the IOBs along with
> the data out signals. The defaults should
> be OK elsewhere.
>
> Can anyone help?
>
> Brad Smallridge
> AiVision.com

"John Adair" wrote >
> 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.

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







 

Brad wrote:
>
> I have the IOB primitives in a separate submodule as I have seen
> Xilinx often do on their memory models.
>
 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:

http://groups.google.com/group/comp.arch.fpga/msg/afce49b66c1989aa

Brian

On Mar 14, 9:59 pm, p...@coho.org wrote:
> 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.

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

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

What would be nice is a latched IOB tristate primitive.

Brad Smallridge
AiVision