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?
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.