🚀 go-pugleaf

In article <13665@optilink.COM> manley@optilink.COM (Terry Manley) writes:

   Ok, I've got a 'newbie' question.

   What's the story with this language?

Since I just took a class on Verilog, I'll try to answer your question.
It's a good test to see if I learned anything :) I am sure I will be
corrected if I am wrong.

   More specifically why doesn't the following work:

   reg a,b,c;

   always @(posedge Clk) c = b;
   always @(posedge Clk) b = a;

The assignments occur on the posedge of the Clk, but there is nothing in
this structure that says which should occur first. In theory they should
occur at the same time, but this setup does not guarantee this. If you
want that you should use the fork ... join construct.

   When the following does:

   always @(posedge Clk)
     begin
	   c = b;
	   b = a;
     end

In this case, the action will start on the posedge of Clk. Then, because
you used a begin ... end block, versus the fork ... join, the assignments
will take place sequentially. 

	c gets the value of b
	b gets the value of a

This all takes place in zero time. To have these occur in parallel, you
could use:

	always @(posedge Clk)
	  fork
		c = b;
		b = a;
	  join

However, this has the same problem as the two always blocks, there is no
control over which will take place first. I can't remember the exact syntax,
but there is a way to specify that the values of b & a are first saved and
then the assignments take place. This allows them to occur in any order, but
get the results you are after.

   In the first case for some reason verilog may perform the "b = a"
   assignment first, thereby throwing away the expected value that c was
   going to get.  We've even seen cases where in a given simulation
   sometimes it works correctly, sometimes it doesn't.

   Ideally one would want the data transfer at the posedge of the clock
   to behave like digital logic, that is it would, in this case behave
   like a shift register.  Instead we get what looks like a shift
   register with a bad hold time problem. 

   So what is the story with multiple always blocks?
   Is this something to worry about between modules?
   How about between modules in different files?

If the actions occur within separate modules, you need to have event controls
to ensure the actions take place in the order you want if that matters.


   --
   dave
   manley@optilink.com

--
Alan Bair             		AMCU DSCS
Motorola, Inc.            	    (Design Software &
Mail Stop OE-320		     Computer Services)
6501 William Cannon Dr. West	
Austin, TX  78735-8598          abair@parsons.sps.mot.com