Forum Discussion
Altera_Forum
Honored Contributor
17 years agoThe input clock is indeed drived from MCU and all the control signals (for read/write) from MCU is indeed synchronous with this clock. However, the point of this piece of code is to map some other external IOs from other devices (namely FEC chip, SerDes, XFP and external PLLs) to an address space so MCU can access/control the status of these external devices. For those input/output, most of them are asyn signals. Should I take precaution for them (use two DFFs at the first stage to synchronous them)? Or I can ignore them because they change so infrequently (and miss read them in one clock cycle simply doesn't matter) that in real operation, it doesn't matter that much?
Also, please explain why there's no race condition? For example, the FSM will change state on every rising edge of clock and also on the same rising edge of clock, FSM must produce output signals which depends on the CURRENT STATE. Wouldn't this changing of state be in a race condition with the output signals? If not, is it because Altera Quartus II is smart enough to detect such code style and avoide it by itself? TIA --- Quote Start --- I assumed that your input clock is derived from processor clock, in this case all bus signals are actually synchronous, you have to observe setup and hold times however. If the bus signals are unrelated to clk, reliable operation can't be expected. As I already mentioned, we simply have to assume, that the interface is cooperating correctly with coldfire bus signals. You have to check this. P.S.: The latter is also my comment on your last question. The FSM as such has no race conditions, as far as I see. But this doesn't guarantee correct timing of bus signals. I don't know the respective requirements and can't suggest a solution. --- Quote End ---