Different simulated results with block and verilog coding

Hello,

--- Quote Start ---

However, after combining, Quartus II somehow truncate the codes through some optimization mechanism and the codes no longer function as how they were, when they were simulated prior to combining.

--- Quote End ---

I wouldn't expect a particular Quartus problem here. Apparenty, the full design behaves different than intended. When I experienced a similar issue, it turned out in most cases, that the compiler (could be Quartus, ModelSim, whatever) exactly did, what I had coded. Unfortunately I intended something different.

What do you mean exactly with Quartus truncate the code? It could be, that part of the code isn't synthesized at all. This happens usually when either no output depends on the code (= all outputs are effectively unconnected, viewn from the pins) or the output doesn't depend on any input (= is arbitrary or constant, e. g. cause the module has no clock connected or is held constantly in reset). In this case, you surely get a lot of warnings during compilation, that tell more or less exactly what's going to happen.

Apart from such simple cases of bad design assembly, the designs overall structure could actually change a lot by optimisation, cause redundancy is removed as far as possible, also across module boundaries unless you restrict this operation. This won't change functional behaviour but could be an issue in debugging.

For detailed help, more information would be needed.

Regards,

Frank

Hi FvM, thank you so much for viewing into my problem. My meaning of truncating the code is as you said, not synthesized.

I am suspecting my coding could be the problem. Do you have any suggestion as good methods to troubleshoot the coding in this situation: where the code synthesizes properly under a verilog/VHDL form, and does not get synthesized under combined block diagram form?

Hello,

if it would be some kind of problem as I suggested (missing connections), it should be recognizable from Quartus warnings, but may be not easily. But I believe, such a case can also be identified by thorougly tracking the signal flow on a paper or in mind.

One general debug option is a Modelsim simulation of full design. With graphic top level, this requires creating a HDL file for top level, but that's easy and also a testbench for the full design, may be more effort, depending on the designs pin count. In ModelSim, you can more easily watch internal signals during simulation than with Quartus simulator. The other option is to use SignalTap, but it can't obviously watch signals that have been removed in optimization.

Regards,

Frank

Hi,

If I was you I would use the following option in Quartus

Tools -> Netlist Viewer -> RTL viewer.

this can be performed after analysis and elaboration.

This will tell you whether you have connected up your blocks correctly through the use of port maps in your VHDL. floating inputs will cause logic to be optimised away. Also check outputs are connected to other blocks

The other way is too simulate this, ie if you have floating inputs then this will be evident from the waveforms in modelsim

Regards