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

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 03-29-2005, 04:33 AM
Mark McDougall
Guest
 
Posts: n/a
Default newbie verilog question

In reference to the following code snippet:

always @(posedge ata_dior)
begin
dout = mem[ addr ];
dout_en = 1;
end

always @(posedge ata_dior)
begin
dout_en = 0;
end

I can't find any doco, tutorial etc that explains exactly what the
'dout_en' waveform will look like. Gut instinct tells me that it will
remain at 0, but it's only a guess.

Can any verilog gurus explain what will happen? And why something might
be coded like this?

TIA
Regards,
Mark
Reply With Quote
  #2 (permalink)  
Old 03-29-2005, 07:10 AM
Bert Cuzeau
Guest
 
Posts: n/a
Default Re: newbie verilog question

Mark McDougall wrote:
> In reference to the following code snippet:
>
> always @(posedge ata_dior)
> begin
> dout = mem[ addr ];
> dout_en = 1;
> end
>
> always @(posedge ata_dior)
> begin
> dout_en = 0;
> end
>


Are you sure of the code ?
It looks like something typically wrong
(the result is impredictible -race condition- since it depends on the
order the always blocks are evaluated.

Bert

Reply With Quote
  #3 (permalink)  
Old 03-29-2005, 04:35 PM
John_H
Guest
 
Posts: n/a
Default Re: newbie verilog question

"Mark McDougall" <[email protected]> wrote in message
news:[email protected]

<snip>

> Can any verilog gurus explain what will happen? And why something might
> be coded like this?


<snip>

The results may be consistent according to the Verilog Language Reference
Manual but I wouldn't expect it.

It would be coded this way because someone doesn't know what they're doing.
The blocking assignment (=) rather than the non-blocking assignment (<=) is
a flag that the person writing the code is green, the assignment of dout_en
in different always blocks suggests they don't even know what they're trying
to do.

This, of course, is only an opinion from someone exposed constantly to
professional designs.


Reply With Quote
  #4 (permalink)  
Old 03-30-2005, 04:18 AM
Mark McDougall
Guest
 
Posts: n/a
Default Re: newbie verilog question

John_H wrote:

> It would be coded this way because someone doesn't know what they're
> doing. The blocking assignment (=) rather than the non-blocking
> assignment (<=) is a flag that the person writing the code is green,
> the assignment of dout_en in different always blocks suggests they
> don't even know what they're trying to do.
>
> This, of course, is only an opinion from someone exposed constantly
> to professional designs.


Thanks for taking the time to reply.

The code was taken from the test bench for the opencores IDE controller.
And I'm very quickly beginning to concurr with your assessment of the
author of the testbench.

I started expanding on the bench to add my own tests, only to be
frustrated with my inability to read from the simulated device. I was
stumped because the existing tests, which read from the simulated
device, all pass.

On closer inspection I find that values read from the simulated device
actually contain 'ZZZZ' in the lower 16 bits. All the existing tests use
an inequality test to verify the data read back after a write, which of
course fails the condition if one operand contains ZZZZ and the errors
are never flagged. The testbench passes even though it can't read any
data from the device.

So as far as I, admittedly a verilog newbie, can tell, the testbench is
completely useless.

Would love somebody to prove me wrong!?!

Regards,
Mark
Reply With Quote
  #5 (permalink)  
Old 03-31-2005, 10:28 PM
info_
Guest
 
Posts: n/a
Default Re: newbie verilog question

John_H wrote:


> The results may be consistent according to the Verilog Language Reference
> Manual but I wouldn't expect it.


Can you explain how ?
Is it clear from the Stratified Event queue (I mean the evaluation order ?)


Reply With Quote
  #6 (permalink)  
Old 04-01-2005, 12:29 AM
johnp
Guest
 
Posts: n/a
Default Re: newbie verilog question

Mark -

In testbenches, you typically want to be VERY careful to not let Z or X
values
accidently slip through as "don't cares". A lot of times, I'll code
testbenches like:
reg [15:0] expect;
reg [15:0] actual;

expect = 16'1234;
// get the actual value set...

if (actual !== expect)
begin
---complain---
end

Note the ! = = type compare. This means identically not-equal, no
"don't cares"
allowed. There is a corresponding === (3 equal signs).

Note that the OpenCores stuff is quite useful, but I usually have to
triple check
the code (and fix stuff) before I use it. It's usually a great
startying point for
study.

I hope this helps.

John P

Reply With Quote
Reply

Bookmarks

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
Verilog newbie question lei Verilog 9 05-28-2008 07:40 AM
A question from a verilog newbie. Jim Huang Verilog 3 04-22-2005 08:03 PM
Question from a Verilog Newbie TookieClothespin Verilog 2 03-01-2005 03:32 AM
Verilog/XST newbie question Cornel Arnet Verilog 3 09-20-2004 01:09 AM
Verilog Newbie Question Kate Smith FPGA 5 02-25-2004 12:06 AM


All times are GMT +1. The time now is 09:06 PM.


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