> On Sep 10, 2015, at 7:28 AM, Greg King <greg.king5@verizon.net> wrote: > > On 2015-09-10 1:24 AM, Jim Brain wrote: >> On 9/10/2015 12:11 AM, Nate Lawson wrote: >>> I think the problem is here: >>> >>> ### >>> assign reset_in = (reset_en ? 0 : !reset); //if soft >>> reset, 0, otherwise !reset >>> register #(.WIDTH(6)) cart_config1_reg(clock, reset_in, >>> cart_config1_reg_ce, data[5:0], cart_config1); // active high reset. >>> ### >>> >>> If the external reset line goes low (which it does when you set >>> reset_en to do a soft reset), reset_in goes high and the config >>> register is reset. Just stop passing reset_in to the config register >>> and get it from a different source. >> If external reset lines goes low, but I did so with the soft reset >> functionality, then reset_in will be 0, according to the above. It will >> be that way until the next falling clock, given the always block. > > When is the reset line released? Does it happen _before_ that falling clock? Maybe, you have a race condition on the release: reset_in sees the release before reset does; therefore, it gets a pulse from !reset. Yes, I agree. Continuous assignment, wires, etc. aren’t registered, so you have to be sure about relative timing of the signals. Personally, I’m not comfortable with using continuous logic from external sources until it’s been registered on a clock edge. There’s too much potential for glitches from ringing etc. -Nate Message was sent through the cbm-hackers mailing listReceived on 2015-09-11 22:01:05
Archive generated by hypermail 2.2.0.