Undriven outputs of a module in Quartus II Synthesis

I have a module which does not drive certain output ports for certain
operation modes, and that simulates fine in Modelsim. How would Quartus
II (or any other synthesis software) handle undriven ports? Will it
synthesize into something which may cause logic to behave in an
unpredictable manner?

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Ang Zhi Ping <angzhiping@gmail.com> wrote:

> I have a module which does not drive certain output ports for certain
> operation modes, and that simulates fine in Modelsim. How would Quartus
> II (or any other synthesis software) handle undriven ports? Will it
> synthesize into something which may cause logic to behave in an
> unpredictable manner?

If you drive them Z, the outputs should tristate, if X then they
will be either 0 or 1, whatever the synthesis finds easier.

What to you mean by "unpredictable"?

-- glen

Hi,

two constructs come to mind, "undefined" and "tri-state".
For the first, I tell the synthesis tool "do what you like, I don't care".
During operation, the logic value can be anything. Assign "undefined"
explicitly to enable better optimizations.

The other one is "tri-state". For an off-chip connection, you can tell the
output driver "go into high-impedance state", possibly with some
pullup-/down resistor. This is hardware-dependent. 
The simulator can put "tri-state" on any wire but the synthesis tool will
not allow you to create floating nodes within the FPGA, at least not
physically.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Wednesday, May 14, 2014 9:37:50 AM UTC-4, Ang Zhi Ping wrote:
> I have a module which does not drive certain output ports for certain
> operation modes, and that simulates fine in Modelsim. How would Quartus
> II (or any other synthesis software) handle undriven ports? 

Run Quartus and you will find out.  What you will see in the synthesis report is that those undefined outputs will be driven to 0.

> Will it synthesize into something which may cause logic to behave in an
> unpredictable manner?
> 

No, it will behave as if you had explicitly set the outputs to 0.

Kevin Jennings

On 14/5/2014 10:15 PM, glen herrmannsfeldt wrote:
> Ang Zhi Ping <angzhiping@gmail.com> wrote:

Snip

> If you drive them Z, the outputs should tristate, if X then they
> will be either 0 or 1, whatever the synthesis finds easier.

According to ModelSim, they appear as X. I guess synthesis tools
defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.

> What to you mean by "unpredictable"?

That these 'X' values may propagate to other parts of the hardware logic
on the FPGA.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On 5/16/2014 10:13 PM, Ang Zhi Ping wrote:
> On 14/5/2014 10:15 PM, glen herrmannsfeldt wrote:
>> Ang Zhi Ping <angzhiping@gmail.com> wrote:
>
> Snip
>
>> If you drive them Z, the outputs should tristate, if X then they
>> will be either 0 or 1, whatever the synthesis finds easier.
>
> According to ModelSim, they appear as X. I guess synthesis tools
> defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.

Yes, you need to drive all inputs to a known value to get meaningful 
behavior.  You seem to be talking about outputs of a module being not 
driven.  I don't understand that.  How can the code not drive the 
output?  If you specify output values only for certain input values, the 
output will be held to the previous values for the undefined input 
conditions which is also known as a memory element or a flip-flop.


>> What to you mean by "unpredictable"?
>
> That these 'X' values may propagate to other parts of the hardware logic
> on the FPGA.

Yes, that is the point of the value 'X' or 'U'.  It usually indicates 
and error and will propagate through the design to all affected parts. 
The simulation value 'X' won't alter the logic inferred.  That is 
defined by your code.  But static inputs are often removed from the 
design because they aren't needed to define the logic.  '0' AND anything 
is always a '0', so the AND gate driven by a '0' is removed.  Logic 
driven by an 'X' often produces an 'X' regardless of the other inputs, 
so no logic needs to be produced in that case, just an 'X' generator.

Can you explain why you don't define an output value for some "modes" 
and not others?  What does "mode" correspond to in your design?  Is the 
mode defined by some of the logic inputs or is this a parameter to the 
code that defines the type of module you intend to be generated?

There might be a way to do what you are looking for, but I can't say 
because I don't understand what you are doing.

-- 

Rick

On Friday, May 16, 2014 10:13:35 PM UTC-4, Ang Zhi Ping wrote:
>=20
> According to ModelSim, they appear as X. I guess synthesis tools
> defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.
>=20

No.  As I stated in my first post, those outputs will be driven to 0 by Qua=
rtus.  Simply check the synthesis report.  That assumes that those undriven=
 outputs are connected to something.  An unconnected output will not be syn=
thesized at all since it will be optimized out.

>=20
> > What to you mean by "unpredictable"?
>=20
> That these 'X' values may propagate to other parts of the hardware logic
> on the FPGA.
>=20

That's what you should expect.  If you have an output that has no logic beh=
ind it then that output will get assigned an unknown ('U') and that unknown=
 will propagate downstream.

Kevin Jennings

On 17/5/2014 5:30 PM, rickman wrote:
> On 5/16/2014 10:13 PM, Ang Zhi Ping wrote:
>> On 14/5/2014 10:15 PM, glen herrmannsfeldt wrote:
>>> Ang Zhi Ping <angzhiping@gmail.com> wrote:
>>
>> Snip
>>
>>> If you drive them Z, the outputs should tristate, if X then they
>>> will be either 0 or 1, whatever the synthesis finds easier.
>>
>> According to ModelSim, they appear as X. I guess synthesis tools
>> defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.
> 
> Yes, you need to drive all inputs to a known value to get meaningful
> behavior.  You seem to be talking about outputs of a module being not
> driven.  I don't understand that.  How can the code not drive the
> output?  If you specify output values only for certain input values, the
> output will be held to the previous values for the undefined input
> conditions which is also known as a memory element or a flip-flop.

Apparently undriven outputs is legal syntax in Verilog. Quartus emit a
warning on undriven ports though.

>>> What to you mean by "unpredictable"?
>>
>> That these 'X' values may propagate to other parts of the hardware logic
>> on the FPGA.
> 
> Yes, that is the point of the value 'X' or 'U'.  It usually indicates
> and error and will propagate through the design to all affected parts.
> The simulation value 'X' won't alter the logic inferred.  That is
> defined by your code.  But static inputs are often removed from the
> design because they aren't needed to define the logic.  '0' AND anything
> is always a '0', so the AND gate driven by a '0' is removed.  Logic
> driven by an 'X' often produces an 'X' regardless of the other inputs,
> so no logic needs to be produced in that case, just an 'X' generator.
> 
> Can you explain why you don't define an output value for some "modes"
> and not others?  What does "mode" correspond to in your design?  Is the
> mode defined by some of the logic inputs or is this a parameter to the
> code that defines the type of module you intend to be generated?

I have a datapath which does not need to read/write to some BRAMs for
certain modes, whereas it needs for others.

The mode is determined by an input port, and not a parameter.

> There might be a way to do what you are looking for, but I can't say
> because I don't understand what you are doing.
> 

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On 17/5/2014 7:07 PM, KJ wrote:
> On Friday, May 16, 2014 10:13:35 PM UTC-4, Ang Zhi Ping wrote:
>>
>> According to ModelSim, they appear as X. I guess synthesis tools
>> defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.
>>
> 
> No.  As I stated in my first post, those outputs will be driven to 0 by Quartus.  Simply check the synthesis report.  That assumes that those undriven outputs are connected to something.  An unconnected output will not be synthesized at all since it will be optimized out.

You're right.

>>
>>> What to you mean by "unpredictable"?
>>
>> That these 'X' values may propagate to other parts of the hardware logic
>> on the FPGA.
>>
> 
> That's what you should expect.  If you have an output that has no logic behind it then that output will get assigned an unknown ('U') and that unknown will propagate downstream.
> 
> Kevin Jennings
> 

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On 5/17/2014 8:29 AM, Ang Zhi Ping wrote:
> On 17/5/2014 5:30 PM, rickman wrote:
>> On 5/16/2014 10:13 PM, Ang Zhi Ping wrote:
>>> On 14/5/2014 10:15 PM, glen herrmannsfeldt wrote:
>>>> Ang Zhi Ping <angzhiping@gmail.com> wrote:
>>>
>>> Snip
>>>
>>>> If you drive them Z, the outputs should tristate, if X then they
>>>> will be either 0 or 1, whatever the synthesis finds easier.
>>>
>>> According to ModelSim, they appear as X. I guess synthesis tools
>>> defaults unassigned logic to 'X'. They are definitely not driven to 'Z'.
>>
>> Yes, you need to drive all inputs to a known value to get meaningful
>> behavior.  You seem to be talking about outputs of a module being not
>> driven.  I don't understand that.  How can the code not drive the
>> output?  If you specify output values only for certain input values, the
>> output will be held to the previous values for the undefined input
>> conditions which is also known as a memory element or a flip-flop.
>
> Apparently undriven outputs is legal syntax in Verilog. Quartus emit a
> warning on undriven ports though.

No one said it was illegal syntax.  It is not valid semantics for 
describing synthesizable hardware.


>>>> What to you mean by "unpredictable"?
>>>
>>> That these 'X' values may propagate to other parts of the hardware logic
>>> on the FPGA.
>>
>> Yes, that is the point of the value 'X' or 'U'.  It usually indicates
>> and error and will propagate through the design to all affected parts.
>> The simulation value 'X' won't alter the logic inferred.  That is
>> defined by your code.  But static inputs are often removed from the
>> design because they aren't needed to define the logic.  '0' AND anything
>> is always a '0', so the AND gate driven by a '0' is removed.  Logic
>> driven by an 'X' often produces an 'X' regardless of the other inputs,
>> so no logic needs to be produced in that case, just an 'X' generator.
>>
>> Can you explain why you don't define an output value for some "modes"
>> and not others?  What does "mode" correspond to in your design?  Is the
>> mode defined by some of the logic inputs or is this a parameter to the
>> code that defines the type of module you intend to be generated?
>
> I have a datapath which does not need to read/write to some BRAMs for
> certain modes, whereas it needs for others.
>
> The mode is determined by an input port, and not a parameter.

Here is your fallacy.  If the mode is determined by an input port, the 
hardware can't change between different modes.  You are thinking in 
terms of the software without understanding what hardware will be 
produced.

Ok, so what *does* the data path need to do?  Describe exactly what it 
does without disconnecting things.

To be honest, I'm not sure I understand your problem.  In all the time I 
have designed logic, I have never considered a situation where I didn't 
define an output.  I think you could look at the problem in a better 
way, but since I don't know your problem, it is hard for me to say.

-- 

Rick