Counter, synthesize problems

[adacho94]

Hi, I have problems with my counter. Sorry for my poor english  Register should be reset on the posedge of signal x1 and should be increased on the posedge of CLOCK. I know that register can be changed only in one always process, but I don't know how do that. The error is:
Line 33: Signal register[11] in unit blagam_o_synteze is connected to following multiple drivers:

 

blagam_o_synteze.v

[D@n]

The "multiple" drivers error is actually pretty easy to understand, if poorly worded: it means that there are multiple times in your HDL where you specify what the value for a particular register (or wire) should be.  In your case, you have multiple always blocks specifying what the value of "register" should be.  This is not allowed.  You can have only one always block specifying the value of a register.

I think what you want is something like an "always @(posedge CLOCK, posedge x1)", then place your logic within that block.

It sounds like what you are trying to do with x1 is to implement something like an asynchronous RESET.  While such resets are not that uncommon, they tend to be quite problematic.  Xilinx discusses them, together with examples of them (such as where I got the always block example above), and a discussion of their problems, in their white paper, "HDL Coding Practices to Accelerate Design Performance."  I would strongly recommend it as required reading for anyone working with FPGAs.

Dan

[adacho94]

Thanks, this link contains many valuable information, with examples similar to my question, for example 
always @(posedge CLK, posedge RST)
if (RESET) Q <= 1'b0;
else Q <= A | (B & C & D & E);

The problem is, that I want to reset counter ONLY on the rising edge of x1. I think that when I use similar method to this example, counter can be reset on the rising edge of CLK when x1 is on high state.

[NAEastland]

I think for this example it might be helpful to frame what it is that is going on with your code. I am not sure this is correct, but I am assuming you are worried about a 'false' reset, meaning that the reset signal x1 is still high when the clock triggers the block. You can add another variable in your reset condition that indicates if x1 has been de-asserted, 'AND'ing those two signals together. This is just a suggestion though if you want to keep the design asynchronous, and I would encourage you as well to consider using synchronous resets if you can.

-Nate