Quartus Version: Quartus Prime 20.2 Pro
Device Family: Cyclone 10 GX
I wanted to use some of my vhdl modules, where I set initial values to input ports in the entity's port list:
... LIBRARY ieee; USE ieee.std_logic_1164.all; LIBRARY lpm; USE lpm.all; ENTITY counter_32updnld IS PORT ( sload : IN STD_LOGIC; data : IN STD_LOGIC_VECTOR (31 DOWNTO 0); updown: IN STD_LOGIC := '1'; -- Up-counter if port is left unconnected. clock : IN STD_LOGIC; clk_en : IN STD_LOGIC := '1'; -- Always enabled if port is left unconnected. cnt_en : IN STD_LOGIC := '1'; -- Always enabled if port is left unconnected. aclr : IN STD_LOGIC; q : OUT STD_LOGIC_VECTOR (31 DOWNTO 0); cout : OUT STD_LOGIC ); END ENTITY counter_32updnld; ...
Using those vhdl modules in former Quartus Projects (lite editions) while leaving ports 'clk_en' and 'cnt_en' unconnected, the counter worked as expected.
Doing the same with Quartus Prime Pro 20.2 (and 19.4 aswell), the counter doesn't count. It seems, that unconnected ports are forced to '0' by synthesis. But I don't even get a warning or information message about that.
If I connect those ports to '1' the counter works correctly.
Is there a setting I missed?
Best regards, Harald
Just to clarify what you're saying, you've always had those initial values set for the 3 ports, but you always left them unconnected when instantiating counter_32updnld elsewhere. Is that accurate?
Can you run a simulation or use Signal Tap to see that those inputs get set to 1 (or not) in hardware? If a signal can't be initialized, there would normally be a message or something about it. It might be hidden in the Compilation Report somewhere which would be why you didn't see it, but it's strange that this would change with 19.4. What was the last version of the software you used where it worked correctly?
Yes, that's correct. For example, I created a block symbol file (.bsf), added that symbol to my top-level block diagram/schematic file (.bdf) and left those 3 ports unconnected:
Using that in Quartus Prime 19.4 Pro or 20.2 Pro the counter does nothing in that case. If I connect the ports "clk_en" and "cnt_en" to "vcc" in TopLevel, the counter works but counts downwards (as the port "up/n_dn" is left unconnected).
I just tried the same instantiation in another project using Quartus Prime Version 20.1.0 Build 711 06/05/2020 SJ Lite Edition and checked the correct behaviour of the counter in the programmed device (Cyclone IV).
So moving from Lite/Standard to Pro could certainly be the issue here. Synthesis in Pro has more stringent checks than Lite/Standard so you may not be able to do this in Pro (though there should be some type of warning message; can you double-check to see if you missed any messages or check the compilation report?).
If you're only using a schematic for the upper-level design (instead of HDL coding), I'm not sure what kind of checks are done at the higher level. Can you try the same design but instantiate the counter in HDL code instead of a schematic? Leave the entries in the PORT MAP empty or use the OPEN option in the mapping (for example, updown => open).
I did a test with instantiating the counter inside a vhdl file (wrapper_#), created a symbol file for that wrapper (which I had to do in Lite Edidion as Pro Edition didn't support that) and connected it in my project's TopLevel schematic.
I did that in 2 ways:
Wrapper_01 counts upwards, wrapper_02 doesn't count at all.
If I connect wrapper_02 ports "clk_en" and "cnt_en" to vcc in TopLevel, it counts downwards.
So it seems to me that ports in schematics are treaded differently in Lite and Pro Edition of Quartus Prime.