«

I am looking at some old code and found that the designer set a port
as an out but then in the bodey of the code included a statement to
set the pin hi-z. Is this acceptable. I have not seen this done before
nor have I seen it mentioned in any VHDL text books / reference
manuals.

RAM_RD_L : out std_logic; -- RAM Read, low true

RAM_RD_L <= Fpga_RD_L when Bus_Control_H = '1' else 'Z';

On Friday, January 11, 2013 9:23:09 AM UTC-5, Guy Gibson wrote:
> I am looking at some old code and found that the designer set a port
> as an out but then in the bodey of the code included a statement to
> set the pin hi-z. Is this acceptable. I have not seen this done
> before nor have I seen it mentioned in any VHDL text books /
> reference manuals.

> RAM_RD_L : out std_logic; -- RAM Read, low true RAM_RD_L <= Fpga_RD_L when Bus_Control_H = '1' else 'Z';

Yes. 'RAM_RD_L' is likely an output of the device that can be driven by other devices on the board which means that the part that you're looking at needs to tri-state that output at times. The statement shown does just that.

Kevin Jennings

Guy Gibson wrote:

> I am looking at some old code and found that the designer set a port
> as an out but then in the bodey of the code included a statement to
> set the pin hi-z. Is this acceptable. I have not seen this done before
> nor have I seen it mentioned in any VHDL text books / reference
> manuals.
>
> RAM_RD_L : out std_logic; -- RAM Read, low true
>
> RAM_RD_L <= Fpga_RD_L when Bus_Control_H = '1' else 'Z';

Acceptable for what? For simulation? Sure! For synthesis? I guess not (but I
have no experience with that).

On Jan 11, 12:37*pm, Paul Uiterlinden <puit...@aimvalley.nl> wrote:
> Guy Gibson wrote:
> > I am looking at some old code and found that the designer set a port
> > as an out but then in the bodey of the code included a statement to
> > set the pin hi-z. Is this acceptable. I have not seen this done before
> > nor have I seen it mentioned in any VHDL text books / reference
> > manuals.
>
> > * RAM_RD_L * * * * : out * std_logic; *-- RAM Read, low true
>
> > * RAM_RD_L <= Fpga_RD_L when Bus_Control_H = '1' else 'Z';
>
> Acceptable for what? For simulation? Sure! For synthesis? I guess not (but I
> have no experience with that).

That is the question, what did the code synthesize to? Is it an
enabled output or did it synthesize as purely an output.

I have found that the original designer created two different top
level modules. In one, he hardcoded this as an output ... bad bad
bad, this read line is also driven by a processor and needs to be
tristated. The second top level module has the code I included in my
original post. I am worried that if a new FPGA is installed with that
code that I will still have an issue. [there are not too many 1280's
left! The limited stock we have is 8 years old]

Le 11/01/2013 15:23, Guy Gibson a écrit :
> I am looking at some old code and found that the designer set a port
> as an out but then in the bodey of the code included a statement to
> set the pin hi-z. Is this acceptable. I have not seen this done before
> nor have I seen it mentioned in any VHDL text books / reference
> manuals.
>
> RAM_RD_L : out std_logic; -- RAM Read, low true
>
> RAM_RD_L <= Fpga_RD_L when Bus_Control_H = '1' else 'Z';

I've always done like that and never had any problem.
How else would you code a tri-state output ?

Nicolas

On 1/11/2013 5:27 PM, Brian Drummond wrote:
> On Fri, 11 Jan 2013 18:37:36 +0100, Paul Uiterlinden wrote:
>
>> Guy Gibson wrote:
>>
>>> I am looking at some old code and found that the designer set a port as
>>> an out but then in the bodey of the code included a statement to set
>>> the pin hi-z. Is this acceptable. I have not seen this done before nor
>>> have I seen it mentioned in any VHDL text books / reference manuals.
>>>
>>> RAM_RD_L : out std_logic; -- RAM Read, low true
>>>
>>> RAM_RD_L<= Fpga_RD_L when Bus_Control_H = '1' else 'Z';
>>
>> Acceptable for what? For simulation? Sure! For synthesis? I guess not
>> (but I have no experience with that).
>
> It d*mn well ought to synthesize.
>
> Easy to check, there ought to be a tristate enable connected to the
> inferred IOB, and that ought to be visible in the RTL viewer.
>
> It certainly works with Xilinx ISE from about ISE 7 onwards, possibly
> earlier.
>
> I also needed to add attributes Keep, Equivalent_Register_Removal and IOB
> to certain signals, or XST would "optimise" duplicated registers on the
> tristate control signals, using one for a bus instead of the ones
> embedded in each IOB. That gave horrible timings, as you can imagine!
>
> - Brian

Heck, go back far enough and tri-state drivers work internally in the
3000 and 4000 series. I think it was in the Spartan and Virtex parts
that they got rid of the internal tri-states.

The a tristate output does not need any special declaration. It is only
when the pin has to be an input as well that you need to declare it as
an inout type. Is that what the concern is about?

Rick

On 1/13/2013 6:34 PM, rickman wrote:
> On 1/11/2013 5:27 PM, Brian Drummond wrote:
>> On Fri, 11 Jan 2013 18:37:36 +0100, Paul Uiterlinden wrote:
>>
>>> Guy Gibson wrote:
>>>
>>>> I am looking at some old code and found that the designer set a port as
>>>> an out but then in the bodey of the code included a statement to set
>>>> the pin hi-z. Is this acceptable. I have not seen this done before nor
>>>> have I seen it mentioned in any VHDL text books / reference manuals.
>>>>
>>>> RAM_RD_L : out std_logic; -- RAM Read, low true
>>>>
>>>> RAM_RD_L<= Fpga_RD_L when Bus_Control_H = '1' else 'Z';
>>>
>>> Acceptable for what? For simulation? Sure! For synthesis? I guess not
>>> (but I have no experience with that).
>>
>> It d*mn well ought to synthesize.
>>
>> Easy to check, there ought to be a tristate enable connected to the
>> inferred IOB, and that ought to be visible in the RTL viewer.
>>
>> It certainly works with Xilinx ISE from about ISE 7 onwards, possibly
>> earlier.
>>
>> I also needed to add attributes Keep, Equivalent_Register_Removal and IOB
>> to certain signals, or XST would "optimise" duplicated registers on the
>> tristate control signals, using one for a bus instead of the ones
>> embedded in each IOB. That gave horrible timings, as you can imagine!
>>
>> - Brian
>
> Heck, go back far enough and tri-state drivers work internally in the
> 3000 and 4000 series. I think it was in the Spartan and Virtex parts
> that they got rid of the internal tri-states.

Xilinx parts had internal tristates through Virtex, Virtex E,
Spartan 2 and Spartan 2e. They went away with Virtex II and
Spartan 3. I often used internal tristate buffers as muxes
in those older parts when I was running low on LUT's. We're
getting a bit off topic here, though...

> The a tristate output does not need any special declaration. It is only
> when the pin has to be an input as well that you need to declare it as
> an inout type. Is that what the concern is about?
>
> Rick

-- Gabor

On Friday, January 11, 2013 3:36:32 PM UTC-6, Nicolas Matringe wrote:
I've always done like that and never had any problem. How else would you code a tri-state output ? Nicolas

Agreed. Just because an output is tri-stated does not mean it is bidirectional. This is how we create open-collector/open-emitter (also called open-drain/open-source) type outputs.

Most FPGA synthesis tools will perform automatic conversion of internal tri-state buses into multiplexers if the target architecture does not support internal tri-states. This works for unidirectional (many drivers, one receiver) as well as bidirectional (many IO ports that drive and receive). In some design architectures, it is much easier/understandable/maintainable to code the tri-state busses than to manually manage the multiplexing. Just leave plenty of comments (and verify that your synthesis tool handles it properly).

Some FPGA synthesis tools (maybe most/all?) will also perform "tri-state pushing" where a chip level tri-state output that needs to be registered can be "retimed" before the tri-state buffer, and the enable for the tri-state buffer also registered. With this technique, you actually (conditionally) assign the output register to 'Z' in RTL, and the synthesis splits that intotwo registers, one for data and another for the implied tri-state buffer enable after the register. In essence, the synthesis tool is "pushing the tri-state" logic to the other side of the register. Then it can push both of those registers into the IOB (assuming the IOB is structured that way) for better timing.

Some synthesizers will combine tri-state to mux conversion with tri-state pushing to allow tri-state busses to "pass through" multiple registers on their way to (or from) the chip level output (or IO).

Read your synthesis manual to find out what it supports.

Andy