FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal


Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 01-27-2006, 05:35 PM
Simon Southwell
Posts: n/a
Default Delta time updates and race hazards

I'm looking for a method to update a wide register (or set of
registers)from the ports of a test element module with a narrower
output, in delta time without a race condition hazard occuring.

In the cut down example below the module 'block' has a byte output
(value) and an index (Idx). To update an external register that's 32
bits wide, 4 values are needed each cycle. To update in delta time an
output 'Update' is toggle for each value and a value 'UpdateComplete'
is returned after the single update on which 'block' is waiting.
Externally an always block triggers on 'Update' and does the partial
update of 'Register' dependant on 'Idx', using blocking assignments. At
the end, 'UpdateComplete' is toggled.

Now the question is, is it guaranteed that Idx and Value will have
changed before the 'always @(Update)' is triggered. Blocking
assignments are used in 'block', but since they are exported onto
ports, and then through wires, implying continuous assignments, is it
the case that these assignments could get reordered so that,
externally, 'Update' changes before either Idx or Value (or both)? Or
is it the case that all affected continuous assignments are resolved,
and placed on the event queue before the next internal blocking
assignment is calculated?

In the real code I'm putting together (a 'virtual processor'
co-simulation element), the interface for the 'block' equivalent is
generic, as the element may be connected to any arbitrary external
environment and need to update any number of registers in a delta
cycle. I'm trying to avoid putting false delays in for each update
(i.e. #1 between block's Value assignment and the Update toggle), and
also, if possible, hierarchical references (e.g. blk.Update).

It appears to simulate correctly (on VCS), even turning on delta cycle
display in the waveforms and inspecting the ordering, but maybe I got
lucky. So is what I have guaranteed safe, or is there a better (but
still clean) method to achieve the goal?

code is given below.



module block (Clk, Update, UpdateComplete, Idx, Value);

input Clk;
input UpdateComplete;

output Update;
output [1:0] Idx;
output [7:0] Value;

reg Update;
reg [1:0] Idx;
reg [7:0] Value;
integer Count;

Update = 0;

always @(posedge Clk)
Count = 4;

while (Count)
Count = Count - 1;
Idx = Count[1:0];
Value = $random;
Update = ~Update;



module test;

wire Update;
wire [1:0] Idx;
wire [7:0] Value;

reg Clk;
reg [31:0] Register;
reg UpdateComplete;

block blk (Clk, Update, UpdateComplete, Idx, Value);

Clk = 1;
UpdateComplete = 1;
forever Clk = #1000 ~Clk;

always @(Update)
if (Idx == 2'b00)
Register[7:0] = Value;
else if (Idx == 2'b01)
Register[15:8] = Value;
else if (Idx == 2'b10)
Register[23:16] = Value;
Register[31:24] = Value;

UpdateComplete = ~UpdateComplete;


Reply With Quote
  #2 (permalink)  
Old 01-27-2006, 07:30 PM
Posts: n/a
Default Re: Delta time updates and race hazards

This is not guaranteed to work by the language definition. The
execution order of the statements in the sequential block is
guaranteed, and each blocking assignment is guaranteed to update the
reg before the next statement executes (which is why it is called a
blocking assignment). But as you feared, the continuous assignments to
the wires on the outside of the ports could occur in any order, as
could the actual updates to the wires resulting from those continuous
assignments. It is definitely not the case that continuous assignments
triggered by a blocking assignment will always be evaluated before the
statement following the blocking assignment; there are simulators that
will not do this.

A real simulator will not use a nondeterministic ordering, and the
ordering it uses may allow this code to work. For example, it might
always append events to the event queue, in which case the output nets
would update in the same order as the regs. But the language
definition says that this is not guaranteed.

You might be able to get something guaranteed by using nonblocking
assignments for your Update reg. A nonblocking assignment is
guaranteed not to update until after all your blocking assignments and
associated continuous assignments are complete.

Reply With Quote


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
Digital Delta-Sigma DAC Davy Verilog 9 01-18-2006 01:30 PM
RACE condition detection [email protected] Verilog 1 09-26-2005 06:26 AM
TIME borrowing in synthesis whizkid Verilog 1 11-02-2004 04:39 PM
ANN: Project VeriPage Updates Swapnajit Mittra Verilog 0 09-03-2004 01:15 AM
race condition sridhar Verilog 3 04-26-2004 06:57 AM

All times are GMT +1. The time now is 10:29 PM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved