Thread: issue
View Single Post
  #4 (permalink)  
Old 09-15-2006, 06:21 AM
Rob Dekker
Guest
 
Posts: n/a
Default Re: issue


"rik" <[email protected]> wrote in message news:[email protected] ups.com...
> Thanks Jerry for your reply.
> I had some typos in my question. the code is like,
>
> always @(ipconfig)
> if ( ipconfig)
> begin
> if (shiftreg_dr[34:32] == `ADDR_BASE)
> base_addr_reg = shiftreg_dr[31:0];
> .........
>
> always @(bus_done, fill)
> if (fill & bus_done)
> begin
> base_addr_reg = base_addr_reg + 1;
> bus_address = base_addr_reg;
> .....................
> ....................
>
> The bottomline is, my base_addr_reg will be initialized in the ipconfig
> mode and it will be used and incremented in fill mode. People can say
> why I am not using under the same always block.
> One thing is for sure that fill and ipconfig doesnot coexist.


This will probably (hopefully) simulate as you intended, but synthesis will have a problem with it.
You can write (in English, to us) that fill and ipconfig do not coexist, but a synthesis tool would
have to figure that out from the Verilog code. If it cannot (and most synthesis tools will not even
try to find out mutual exclusivity for multiple always block assignments) then the synthesis tool
will issue an error. Something like "base_addr_reg has multiple drivers" or so.

Why do you want to put the two assignments in two always blocks ?
Even for your own peace of mind, it probably makes sense to code it up in one always block,
so that you know for sure that EVEN IF fill and ipconfig CAN coexist (be active simultaniously)
that the model will still behave in a predictable way.
And it will synthesize ! And it will be obvious that you have to then also think how the signals
(such as 'bus_address') should behave while the model is in the 'initialization' mode.
Even if that means that their value can be 'dont-care' ('x').
That is hardware-oriented Verilog thinking.

So, many reasons to assign a 'base_addr_reg' only in one always statement.

Rob

>



Reply With Quote