More beginner's verilog questions

With regards to the clock - the design has a counter, but all the
counter does is count the number of pulses that come in.  I can't see
how a seperate clock would be required for a counter.

Also, are there some sort of standars for using a clock?  Can you flag
an input as being a clock such that the synthesizer would do something
special/different with it?  Or is it just a input that you deal with in
your own way?

Thnx,
Reza

I have used the following book and it has been very helpful.

Modeling, Synthesis, and Rapid Prototyping with the VERILOG (TM) HDL
by Michael D. Ciletti

"Reza Naima" <google@reza.net> wrote in message 
news:1135064071.868137.197590@z14g2000cwz.googlegroups.com...
>I bought a book a book recommended by one of the application engineers
> at a reseller of Xilinx  (Verilog HDL), and it described verilog very
> well.  But it didn't distinguish between what was used for simulation
> and what is synthesizeable.  So my first bit of code (if you look at
> the link) worked fine on the simulator, but it relied heavily on
> constructs that could not be synthesized.  I then asked for
> recommendations on books, and was told that there were no good ones.
> Hence I'm hoping I can get some pointers to reference code, or some
> help debugging the code I wrote.
>
> Thnx,
> Reza
> 

Reza,
Well,What is it that you have thought of the RTL of the counter you
would like to code?

Santosh -

I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :

module counterLatch32(counter_increment, in, reset, enable, out);
    input in;
    input counter_increment;
    input reset;
    input enable;
    output [31:0] out;

    reg [4:0] index;
    reg [31:0] out;

	always @(posedge counter_increment or posedge reset) begin
		if (!reset)
			index <= index + 1;
		else
			index <= 5'b00000;
	end

	always @(posedge enable)
		out[index] <= in;

endmodule

I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful?  I'm still getting errors.  Just
this one so far....

ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.


reza

   Hmm, right now I don't see what it's complaining about, since the asynchronous reset is active 
high.  My suggestion would be to rearrange the blocks a little.  Try something like:

  	always @(posedge counter_increment or posedge reset) begin
  		if (reset)
  			index <= 5'b00000;
  		else
  			index <= index + 1;
  	end


	Am I missing something obviously wrong with the sensitivity list here?  Or is it just a problem 
with the synthesiser?


Reza Naima wrote:
> Santosh -
> 
> I'm not sure if I understand your question, or what an RTL stands for.
> Based on the feedback, I rewrote the module so it looks like this (and
> is much simpler looking) :
> 
> module counterLatch32(counter_increment, in, reset, enable, out);
>     input in;
>     input counter_increment;
>     input reset;
>     input enable;
>     output [31:0] out;
> 
>     reg [4:0] index;
>     reg [31:0] out;
> 
> 	always @(posedge counter_increment or posedge reset) begin
> 		if (!reset)
> 			index <= index + 1;
> 		else
> 			index <= 5'b00000;
> 	end
> 
> 	always @(posedge enable)
> 		out[index] <= in;
> 
> endmodule
> 
> I still don't see a need for a clock - can someone shed some light into
> a case where a clock would be helpful?  I'm still getting errors.  Just
> this one so far....
> 
> ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
> condition for <index> is incompatible with the event declaration in the
> sensitivity list.
> 
> 
> reza
> 

I believe that you need to give XST hints to infer logic that maps onto
the architecture.  I was at a Xilinx presentation where they used the
RSE letters to denote the order of priority that operations need to
be entered in order to map onto the flip-flop efficietnly:
always @(posedge clk)
  if (Reset)
     // reset stuff 1st
  else if (Set)
    // set stuff second
  else if (Enable)
   // enabled logic last

This is because of the priority of the Reset/Set/Enable functions built
into
the flip-flops.

It could be that the original code fragment confuses the code
generator.

John P

See the things in you design which are always @ (posedge xyzzy) begin
foo <= bar, the xyzzy is a clock, even if you don't call it clock.
The foo <= bar is an "edge clocked" flip-flop/register. Things happen
on the posedge of the xyzzy clock.  If the clock is "periodic" hooked
up to some kind of oscillator, then it is obvious that it is a
clock. However, even if the clock is not periodic, it is still a clock
and it tells "when" something happens.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  compres@world.std.com
Compiler Resources, Inc.       Web Site   :  http://world.std.com/~compres  
23 Bailey Rd                   voice      :  (508) 435-5016
Berlin, MA  01503  USA         fax        :  (978) 838-0263  (24 hours)
------------------------------------------------------------------------------

Reza Naima wrote:
> Santosh -
>
> I'm not sure if I understand your question, or what an RTL stands for.
> Based on the feedback, I rewrote the module so it looks like this (and
> is much simpler looking) :
>
> module counterLatch32(counter_increment, in, reset, enable, out);
>     input in;
>     input counter_increment;
>     input reset;
>     input enable;
>     output [31:0] out;
>
>     reg [4:0] index;
>     reg [31:0] out;
>
> 	always @(posedge counter_increment or posedge reset) begin
> 		if (!reset)
> 			index <= index + 1;
> 		else
> 			index <= 5'b00000;
> 	end
>
> 	always @(posedge enable)
> 		out[index] <= in;
>
> endmodule
>
> I still don't see a need for a clock - can someone shed some light into
> a case where a clock would be helpful?  I'm still getting errors.  Just
> this one so far....

THINK HARDWARE.  What sort of logic will this code create?

Answer: some flip-flops.  And flip-flops require a clock to change
state.  In the example you give above, the signal counter_increment is
used as the flops' clock input.  (You might want to read the synthesis
tool manual to learn why.)

The other gotcha that you probably don't realize is that the signal
enable will ALSO be used as a clock for the flips in the signal out.
On every rising edge of enable, the value of in will be clocked into
out.  Again, a simple perusal of the synthesis tool manual will explain
why.

> ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
> condition for <index> is incompatible with the event declaration in the
> sensitivity list.

That's because your code doesn't follow the templates for synthesizable
flip-flops.  Specifically, you can't do anything "more complex" than
assigning constants (the reset values) to the flops in the if (reset
...) clause.

The other reason for the error is that the asynchronous reset has
priority over the synchronous update.  You've coded it such that the
synchronous update has the higher priority.

-a

Reza Naima wrote:
> I think John answered the question by stating that the clock is useful
> for syncronization and debugging, but ultimatly it seems as if I am
> correct in my assertion that a clock is not explicitly required.

Not knowing the details of your design makes it a bit difficult to tell
whether a global clock is necessary, but the reason for synchronous
design (the entire design clocked by a global clock) is that is
simplifes timing analysis and helps to ensure that the design will
actually work.

> Digital electronics design seems a bit vague - can you be a bit more
> specific?  There are verilog-specific courses offered in my program
> (I'm in graduate school) - but I think it's an overkill for my needs.

I'm actually talking about Digital Electronics Design 101 -- back to
basics.

> Alas, the current project I'm working can't wait for me to take more
> classes.  Either this is implemented in a CPLD or else I'll have to use
> discrete components.  I'm going to follow some of Art's suggestions and
> see how far I can get.

Can the project wait for you to develop the skills to ensure that it is
successful?

> With regards to a wait(), I figured the compiler/synthesizer would
> generate some sort of clock/counter with some sort of comparator to
> trigger the event.  I was hoping that the synthesizers were a bit
> smarter than they seem to be.

The synthesizers _are_ very smart, but you don't want them to be too
smart.  The tools are capable of generating logic that may be
functionally correct, but may be too large to fit in a chip, or may not
run at the required speed, or both.  Writing concise descriptions
allows the tools to produce a more optimal result.

-a

>> I still don't see a need for a clock - can someone shed some light into
>> a case where a clock would be helpful?  I'm still getting errors.  Just
>> this one so far....
>>
>> ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
>> condition for <index> is incompatible with the event declaration in the
>> sensitivity list.
>>
>>
>> reza
>>

Asynchronous logic does not belong in FPGAs.  They are not designed for 
it and the tools don't support it (especially static timing analysis).
Wires in FPGAs have delays associated with them that are on the same 
order of magnitude as the delays through the logic primitives.

While your ripple count structure is a viable clock structure, it does
have some things you need to watch out for: 1), the outputs do not 
update all at once, rather the lsb changes, then the next bit and so on, 
hence the name ripple count.  As the counter gets wider, the maximum 
count speed at which you can extract a usable count diminishes (but note
that if you don't need the lower order bits, this can be faster than a
synchronous counter).  2) The input is sensitive to glitches on the 
input signal.  Mechanical switches will 'bounce', so you'll need to 
include logic to filter out the multiple switch closures that happen
every time you actuate the switch.

Timing analysis (studying the time delays in your circuit to make sure 
that it will run as fast as you need it to and that it won't break 
because of signals getting somewhere either too fast or too late) is 
much easier in a synchronous design (one where a common clock is 
distributed to all the flip-flops in the design) because each timing 
path is punctuated by the flip-flops...you only need to evaluate the 
propagation delay time from flip-flop to flip-flop.  In an async system, 
you need to take into account the propagation delays on all paths from 
the input to the output to make sure you don't have race conditions that 
would upset the proper operation of your circuit.  Also, synchronous 
design eliminates the dynamic hazards you need to deal with in an async 
design.

Even asynchronous resets are bad for FPGA design.  First, the tools 
don't trace the delay paths for the asynchronous reset through the 
flip-flop, so you could wind up with timing hazards and not be aware of 
it.  Second, there are start up hazards which have been discussed ad 
nauseum here in the past.  If you really need an async behavior, for 
whatever reason, just connect the external async reset to the PROGRAM 
pin on the FPGA.