Forum Discussion
Altera_Forum
Honored Contributor
13 years agoThanks dave_59. Your pointers worked. Also the delays to solve the race condition is great. But that only affects the simulation, not the actual hardware that is created, right? Of course it is important to simulate what will really happen in the hardware.
I appreciate the help a lot since I'm really new to this and have to get a design finished this week! One more question if I may. In order to make things work with the delays in there I have to change the way the write signal is used. I can either used the negedge (which will wait until long after the cpldbus is stable), or I could use an always_latch construct which will continuously follow the value of cpldbus until wr goes false. The only problem with doing that is you might get some unknown value from the cpldbus until it has stabilized (after the delay). Its probably better to use the negedge idea so that we have synchronous changes and never have some unknown data going through. Style-wise I wonder if its better to write separate processes for the address latch and the wr operation, like this (seems clearer to me):
always_ff @ (negedge ale)
addr = cpldbus;
always_ff @ (negedge wr)
begin
if (addr == 0) outbit = cpldbus;
if (addr == 1) outbit = cpldbus;
end