I want to in the real system, is the input already ready and stable before the 1st clk rising edge?
I mean, if there`s a reset signal, after the reset signal de-assert, the first clk comes, 1st clk. Is the input ready before the 1st signal, or ready at the exact time when the clk rises, thus causing 1 clk delay?
I`m puzzled here, because this would cause my logic to work different. plz tell me how the real input be prepared...
thx in advance...
the reset, or enable signal is asynchronous. If the reset deassert/ enable assert before the clk rise, how is the data_in prepared? As far as i see, if the data_in change at the same time when clk rises, then the first input is wasted... I want to know how to handle this... thx in advance.
if you have a fully async reset, then yes you could have problems as data may violate setup and hold times for the first clock. Often the answer is the make the reset synchronous to the clock. So for an async reset - synchronise it. As long as it is synchronised, it should be ok to then connect to the async reset of the registers.
if you have a fully async reset, then yes you could have problems as data may violate setup and hold times for the first clock. Often the answer is the make the reset synchronous to the clock. So for an async reset - synchronise it. As long as it is synchronised, it should be ok to then connect to the async reset of the registers.
thx a lot, TrickyDicky ^0^.
so is it dominant that in real systems, the designer tend to use synchronous reset signal? People around me always use the async reset...so in most cases can it be called a bad design?
not exactly, as Tricky said - synchronize the reset and use it as async. input to registers;
the advantage of such approach is that the async. reset is an independent input to FPGA cell so
doesn't consume data inputs;