Undriven outputs of a module in Quartus II Synthesis

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

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.

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

Kevin Jennings

Snip

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

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

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.

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.

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.

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

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

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.

You're right.

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

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.