Quartus II Compiler inferring latch for a DFF

[humandude]

I'm using a DFF module included with my Quartus II / ModelSim (web edition) installation in my Quartus project, but when I compile the project I get the following message:

"Inferred latch for "q" at dffep.v(18)"

The source file is located at C:/altera/13.1/quartus/eda/fv_lib/verilog/dffep.v. It is a user-defined primitive and it is a D flip-flop with enable, async set, and async reset. The RTL Viewer confirms that the module was interpreted as a latch. However, this is incorrect behavior. What am I missing here?

[ak6dn]

You don't say what device family you are using. That is is pretty old version of Quartus, might it be Cyclone II?

If so, Cyclone II LE block only has one async control mode, either set or clear. Not possible to have both async clear and set inputs.

So Quartus can't map directly to that LE primitive DFF and has to synthesize it as a latch, if both clear and set are used.

That being said, why are you even using that DFF primitive in your source code? Why not just write the verilog for an inferred register?

wire clk, rst, d;
reg q;
always @(posedge clk or posedge rst) if (rst == 1) Q <= 0; else Q <= D;

[humandude]

Are you saying it is not possible to have two async control inputs for one logic element? I would imagine the compiler would create the necessary mapping to generate as many control inputs the user decides to implement, possibly using more than one LE if necessary. I'm not sure, but that's my thought process.

I was able to get past the inferred latch issue by making one change to the UDP (dffep.v). That is, I replaced every instance of "?" with "x". Seeing as that stopped the inferred latch warning, I can only assume that the compiler does not know how to deal with a value that can be 0, 1, or x.  But it can interpret a value that can be either 0 or 1. Writing code for a DFF is easy, but I think there's much to learn about user defined primitives and how Quartus deals with them!

[ak6dn]

Two async inputs for one logic element? It depends on the device family. For Cyclone II, no it is not. For some others, yes.

If you are using UDPs just to see what they are and can do, it could be a interesting thought experiment.

But as a practical logic implementation technique, IMHO you are going down a big rathole that is rather useless these days.

UDPs are so limited. Exactly one output port. One to ten input ports. No bus ports (ie, all ports are one bit wide). Either in or out, no bidir ports.

Instead of programming in a higher level language and letting the tool do the mapping, you are writing custom assembly language.

Personally I would say forget UDPs altogether and write in verilog at a higher level, but that is just my recommendation based on 40+ years of experience. YMMV.

[Farabi]

Hello,

Do you have test case I can use? To make sure we have same design to debug with.

regards,

Farabi

[Farabi]

Hello,

We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

regards,

Farabi