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
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
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 (
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
Can you explain how ? Is it clear from the Stratified Event queue (I mean the evaluation order ?)
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
Have something to add? Share your thoughts — no account required.
Ask the community — no account required