Flip-flops to Build a Clock Divider - Example in Vivado nor synthesising

[AndyHook1970]

Hi There,

I am new to FPGA development and verilog.

I have a Basys 3 Board and I and I am trying to synthesise the "Flip-flops to Build a Clock Divider" example shown on the Digilent website, but I keep getting this error :-

[Synth 8-2576] procedural assignment to a non-register Q is not permitted 

 

I have attached my design and constraint files.

 

I would really appreciate some help to get me over this first hurdle.

Andy 
 

dff.v flipFlopDivider.v Basys-3-Master.xdc

[xc6lx45]

module dff(
    input D,
    input clk,
    input rst,
    output reg Q
    );

[xc6lx45]

just for completeness, "reset strategy" is a fairly complex topic by itself. E.g. what are the implications of being edge sensitive on two different signals, does the FPGA hardware even support this (it sets off a red warning light, I'd have to look into the synthesized design if I had to deal with this construct but it seems suspicious in FPGA land).

On toy projects, many problems just won't show. Later in a physically large design with fast clocks it opens a barrel-of-worms with 10-inch teeth, can you guarantee each and every timing relationship between rst and clk everywhere on the die (on ASIC this might be different if you know the clock is guaranteed to be off on rst but that's a different world and I'm still not convinced I'd do this)

Conventionally, you'd write the functionality as follows

reg [26:0] ct;
wire LED = ct[26];
always @(posedge clk) begin
    ct <= ct + 27'd1;
    if (rst) // note rst is sampled on posedge(clk)
        ct <= 27'd0;
end

Feel free to replace the addition with explicit D FF equations but the overall "look" should be the same (think in terms of Moore/Mealy machines, data moving register-to-register through combinational clouds)

[xc6lx45]

and one more thought: It may be that the dff.v design was actually trying to infer the register I added in the first post ("edge-sensitive latch") on Q and newer tool versions don't allow for such creative use of the language. I might be wrong but apparently this example has worked once.

[zygot]

Inferred latches by the synthesis tools are generally a very bad thing to let slide. Usually you get a much more subtle warning that most people ignore, until it bites them where it hurts later in the project. If the synthesis tool tells you that it finds your code confusing then I'd try to accommodate the synthesis tool because, in the end, you need it to be correct a lot more than it needs you to be correct.  Unfortunately, tracking down the actual problem with warnings and errors for programmable logic tools is every bit as bad, or more so, than for software warnings and errors, depending on the compiler.

When starting out with HDL development sometimes it's best to just follow by example unless the goal is just to learn about the tool behavior. Like C compilers HDL synthesis and simulation tools from different or even the same vendor do NOT always infer the intent of the source code in exactly the same way.

Unlike people who write HDL source code the tools have no regrets.