Undriven outputs of a module in Quartus II Synthesis

[Ang Zhi Ping]

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

 

[glen herrmannsfeldt]

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

 

[KJ]

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

 

[mnentwig]

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 th
output driver "go into high-impedance state", possibly with som
pullup-/down resistor. This is hardware-dependent.
The simulator can put "tri-state" on any wire but the synthesis tool wil
not allow you to create floating nodes within the FPGA, at least no
physically.



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

 

[Ang Zhi Ping]

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

 

[KJ]

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.

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

 

[rickman]

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

 

[Ang Zhi Ping]

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

 

[Ang Zhi Ping]

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

 

[rickman]

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