The most likely cause though as far as I can tell from what you have posted comes down to the way you are simulating the code. It would be good if you posted the code you used for simulation.
It is entirely possible that if you are using something like blocking statements to generate both the oe
signal and clk
signals in a testbench setup that the simulator gets confused and deasserts oe
a very short amount of time before the rising edge of the clock which you wouldn't necessarily be able to see on a waveform view (it would look like it was changed on the clock edge), but would (in an RTL simulation at least) result in the behaviour you are seeing.
In practice it wouldn't happen as all the logic including the oe
signal would be synchronous.
I'm going to post this bit as part of my answer rather than a comment as it allows better code formatting, but consider this alternative arrangement:
always @(posedge clk) begin
if (reset) begin
oe_hold <= 1'b0;
end else begin
if (oe && (oe_hold | we)) begin
oe_hold <= 1'b1;
end else begin
oe_hold <= 1'b0;
end
end
end
Notice how now rather than trying to set oe_hold to \$0\$, then at the same time (non-blocking!) trying to set it to a \$1\$ if the conditional was true. Now it specifically sets it to \$0\$ only if it wasn't true. The if/else is of course equivalent to simply: oe_hold <= (oe && (oe_hold | we));
.
This may or may not help with the issue depending on how your simulation software handles the conflicting assignment of your code. In practice it seems to synthesize to the same thing (in Quartus II at least), but I have seen odd behaviour from some simulators getting confused with certain constructs.
Note: I added some extra begin
/end
statements, though that was only to improve readability.
I also want to pick up on something in your question, you mentioned driving one signal on one clock edge and another on the opposite clock edge. In synchronous logic you should try to avoid this as it can lead to timing issues in the design - you basically make all your setup requirements twice as stringent (because the effective clock frequency is doubled!). Everything in a synchronous circuit should be clocked on the same edge.
oe_hold
gets 0 for every input combination. So I'd expect it to go low whenever there is a clock rising edge. \$\endgroup\$oe
. My guess isoe
is assigned with a blocking assignment. \$\endgroup\$oe = 1'b0
withoe <= 1'b0
? I can only assume it is an issue with the simulator as if you synthesize it you get a clocked register as expected. \$\endgroup\$