Re: gEDA-user: HELP with Icarus Verilog, 0.7!

["Samuel A. Falvo II" <sam.falvo@falvotech.com>]

On Tuesday 06 April 2004 11:30 am, Mike Jarabek wrote:
>     This situation usually indicates that there is contention on the
> bus.  If you have other structures like the three state assignment, in

I checked and I checked, and I checked again.  According to the source 
code, as I understand it, nothing should have been driving the bus while 
writing to the registers (except the test bench, that is).  There is no 
reason that I can see for the registers to be loaded with uncertain 
values.

Still, all the same, I'd like to know a known-good technique for modeling 
three-state buses with Icarus.  I've yet to find online or other 
documentation relating to this.  My introductory Verilog book has 
constructs which are not supported by Icarus, so I cannot use those.

>     If this is meant to be synthesisable code, you might want to
> re-code your block to be synchronous.  i.e. add a system clock and use

It is synchronous now.  I've since recoded the behavioral model to adhere 
to Wishbone (which is amazingly close to the 6502 interface I wanted to 
use originally).  I'm sure it's still not perfect, but at least 
everything simulates nicely now.  :)

I still have to change the blocking = assignments to <= assignments 
though.  I'll do that a bit later.

Since I don't have any chip programmers at the moment, I am deferring 
creation of synthesizable code, because such code is inherently 
dependent on the synthesis tool used.  I don't expect Icarus' synthesis 
tools to handle Xilinx Spartan II-series FPGAs or Cypress CPLDs.  I've 
not seen such support documented.

> flip-flops, like this: (Your code had a race condition on writing the
> register. If both _RXMASKx_E signals changed state during the same
> time step, the results written back into the register will be
> simulator dependant. This is because the same destination register
> appears in more than one always block and Verilog does not guarentee
> which one will be executed first.)

I re-read this four times, and I can't make out what you are saying.  
What do you mean by "same destination register?"  And why would it 
matter if they appeared in multiple always-blocks?  I have one always 
block for the reset, and one for the register writes.  Is this what 
you're referring to, possible contention of writing to the registers 
while reseting?

>     always@(posedge CLK or negedge RST)
>        if(RST == 1'b0) begin
>             rxmask <= 16'h0000;    /* Put your reset value here */
>        end
>         else begin
>
>             if(_RXMASKL_E == 0 )
>                 rxmask[7:0] <= DB[7:0] ;   /* Note that you can do a
> part assign to a multi-bit register */
>
>             if( _RXMASKH_E == 0 )
>                 rxmask[15:8] <= DB[7:0];
>
>         end

Why can't I write this instead:

  always @(posedge CLK_I) begin
    if( RXMASKL_E )  // changed to active high signal for convenience
      rxmask[7:0] <= DAT_I[7:0];
    if( RXMASKH_E )
      rxmask[15:8] <= DAT_I[7:0];
  end

  always @(RST)  // level sensitive, asynchronous reset
    if( ~_RST )
      rxmask <= 16'h0040;
  end

I figure that if the various _E signals are ANDed with _RST, then no race 
condition can ever occur, as then the _E signals would be conveniently 
ignored for as long as _RST is asserted.

Thanks for taking the time to reply.  It's greatly appreciated.  I'll 
admit to being a total newbie at this, as this is my first foray into 
programmable logic, ever.  I'm still a discrete component TTL kind of 
person.  :)

--
Samuel A. Falvo II