0
\$\begingroup\$

I have a general question about multiple state machine logic designs. Think of a system having multiple finite state machines with a single clock and rising edged flip flops. These machines share some of their input and output data. So the outputs of some machines can be the inputs of other machines.

My question is, since all the machines use the same clock and rising edge, wouldn't there be a confusion at the rising edges where also the input data changes?

To explain in figures: This figure below shows a convenient data and clock time diagram.(bottom signal is clock, top signal is input data) There is no change in the input signal at the rising edge of the clock.

enter image description here

But here the input data has a falling edge at the rising edge of the clock. This seems problematic to me:

enter image description here

And the thing is, in a multiple state machine system with single clock every transition of a bit happens at the same time all over the design. So for me, unless I come up with a method the edges of data and clock always overlaps. I want to know if there are methods to avoid this(like shifting the phase of clock for every machine etc.). Or maybe this isn't a problem at all, and I am missing something here? If so I would also want to learn why I'm thinking wrongly.

\$\endgroup\$
1
  • \$\begingroup\$ You have a state machine, where clock transitions cause state changes. You have unclocked inputs feeding into state machine. This is bad. Simple solution is to add flip-flops with negative clock to buffer inputs feeding into your state machine. Data transitions on negative clocks, states on positive. \$\endgroup\$
    – StainlessSteelRat
    Dec 19, 2016 at 23:47

2 Answers 2

Reset to default
1
\$\begingroup\$

In practice where a single clock is properly distributed around the design the output signals can be considered to arrive after the clock that created them. The clock has to cause the actual transition of a flop output and then the signal has to propagate through several layers of logic before it reaches the next flop. These delays are much larger than the small errors in clock timing.

\$\endgroup\$
6
  • \$\begingroup\$ So you are basically saying since every data output will be result of the same clock edge, there will always be a delay on data right? I actually made some simulations in Xilinx using verilog and experienced the issue that I mentioned in my question. So maybe this occured because my simulation was made without adding any delays and the simulation treated all the gates ideal with 0 delay? \$\endgroup\$
    – packt
    Dec 19, 2016 at 22:17
  • \$\begingroup\$ Correct 0 delay from clock to data input to the next flop never occurs. I used to design ASICs and a lot of time and effort goes into getting all the clocks changing at the same time and ensuring that there is sufficient delay between flip-flops. If you are doing this in a FPGA or similar I am sure this has been taken care of and you shouldnt worry about it. \$\endgroup\$
    – RoyC
    Dec 19, 2016 at 22:27
  • \$\begingroup\$ @packt In case you are wondering the process to ensure that this is the case is called Static Timing Analysis. All FPGA design flows have some timing constraints editor which tells the autorouting tool what it needs to achieve, and some timing analysis tool to verify there are no setup violations (clock edge arrives before data). \$\endgroup\$
    – Tom Carpenter
    Dec 19, 2016 at 22:37
  • \$\begingroup\$ OP, where @RoyC says that for FPGAs "this has been taken care of", the way this is done is that the flip-flops in an FPGA are designed to have "zero hold time" (you can google this for more info). \$\endgroup\$
    – The Photon
    Dec 19, 2016 at 22:40
  • \$\begingroup\$ Thanks guys was not sure of the FPGA flow Synopsys used to take care of this for us. \$\endgroup\$
    – RoyC
    Dec 19, 2016 at 22:42
1
\$\begingroup\$

For cycle-based simulation, we assume that the clock edge occurs simultaneously everywhere in the design. In ASIC design (including the people who design the FPGAs that I use), a great deal of work goes into getting close to this ideal.

When looking at simulation waveforms, in mind that all of the signals that look like they occur at the same time the clock changes actually change (at least) a little later. At least they should. In fact, Verilog has issues with race conditions that can cause problems in simulation. And I've had simulation issues in VHDL when gating a clock, deriving one clock from another, or assigning a clock to/from an array or record.

When synthesizing a design to FPGA or ASIC, the clock edge does not occur simultaneously throughout the design. If a change in the wire driving a flip-flop changes too soon after the clock, we call this a "hold time violation." These violations will show up in the static timing analysis that should be part of your place-and-route tool flow. In my FPGA experience, hold time violations are very rare. The few I have seen came from mistakes in specifying the clock constraints.

Usually the problem is on the other end. In your simulation, all of the flip-flops driven by your clock appear to change instantly, and their results are instantly available to whatever logic needs them. In real hardware, there is some delay between the clock edge and the flip-flop output ("clock-to-Q" time), and there is a some delay between the flip-flop output and the next flip-flop input due to delays in routing and logic gates. When these delays get too big, you will see a "setup time violation" in your timing report. Fixing setup and hold violations is the process called "timing closure."

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.