home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / verilog / 485 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.5 KB
  1. Path: sparky!uunet!optilink!manley
  2. From: manley@optilink.COM (Terry Manley)
  3. Newsgroups: comp.lang.verilog
  4. Subject: Summary : execution of always blocks
  5. Message-ID: <13701@optilink.COM>
  6. Date: 21 Dec 92 23:57:00 GMT
  7. References: <ABAIR.92Dec18020726@parsons.sps.mot.com> <Dec19.124345.50968@halcon.dpi.udec.cl>
  8. Organization: DSC/Optilink Access Products
  9. Lines: 86
  10.  
  11. Thanks for all the responses.  I got a lot of great answers.
  12.  
  13. To summarize:
  14.  
  15. (Please let me know if I've screwed this up)
  16.  
  17. The following verilog code:
  18.  
  19. always @(posedge Clk) c = b;
  20. always @(posedge Clk) b = a;
  21.  
  22. should not be written since the order of execution of the assignments
  23. is not specified as part of the verilog language - as a side issue it
  24. is important to note that different vendors simulators may behave
  25. differently as a result. 
  26.  
  27. Solution 1:
  28.  
  29. I described:
  30.  
  31.     always @(posedge Clk)
  32.       begin 
  33.         c = b;
  34.         b = a;
  35.       end
  36.  
  37. Note that here order of execution is specified.
  38. This however forces these assignments into the same always block. 
  39.  
  40. Solution 2:
  41.  
  42. Use intra assignment delays:
  43.  
  44.     always @(posedge Clk) c = #1 b;
  45.     always @(posedge Clk) b = #1 a;
  46.  
  47. This effectively creates temp variables:
  48.  
  49. at posedge clock:
  50.     tempb = b
  51.     tempa = a
  52.  
  53. 1 time unit later:
  54.     c = tempb
  55.     b = tempa
  56.  
  57. Now it doesn't matter which order the always statements execute.
  58. (You can also use #0 if you don't want the delay)
  59.  
  60. It was also pointed out that in this simple case only a single
  61. delay is necessary on the assignment you want to execute last, ie:
  62.  
  63.     always @(posedge Clk) c = b;
  64.     always @(posedge Clk) b = #0 a;
  65.  
  66.  
  67. Solution 3:
  68.  
  69. Use non-blocking assignments:
  70.  
  71.     always @(posedge Clk) c <= b;
  72.     always @(posedge Clk) b <= a;
  73.  
  74. This works because verilog evaluates (and stores) the right hand side
  75. of each assignment before performing the assignment.  Others have
  76. suggested using a delay here:
  77.  
  78.     always @(posedge Clk) c <= #1 b;
  79.     always @(posedge Clk) b <= #1 a;
  80.  
  81. This works, but is unnecessary, and may add the undesired delay
  82. (You could use #0, to avoid the delay, but since you don't need
  83. it why put it in at all?)
  84.  
  85. Comment: My end goal is to write code to be synthesized using
  86. synopsys.  To my mind it seems 'dirty' to have to include delay
  87. statements in the verilog to get the behavioral code to run properly.
  88. Synopsys has no problem generating the right logic for the original
  89. hunk of code but as we all know it doesn't simulate.  From the
  90. responses I've received it looks like Solution 3 is the best from the
  91. standpoint of not requiring delays.
  92.  
  93. Thanks again,
  94.  
  95. dave
  96. manley@optilink.com
  97.