FPGA timing, signaling between processes

[gahelton]

This question relates to sending signals between two processes, and timing concerns.

I have a system where Process A sends a signal to Process B. The signal is one clock cycle long beginning on the positive edge. Process B needs to capture this signal, do the requested logic, then signal a complete signal back to Process A, one cycle long, beginning on the positive edge of Process B clock. Ideally, Process A clock and Process B clock are the same clock (not withstanding any clock skew due to routing. (See attached picture).

My question is this. What are the pitfalls of such a design ? Can I guarantee that Process B, and Process A will see the signals from each other with a system like this ? It seems as if there were clock or data skew between processes that the signal may be missed. Would it be better to have Process B looking for the do_something signal on the falling edge of the clock . Likewise, sending the do_something_complete signal on the falling edge ? This out of phase clock relationship would take away the uncertainty of where the data is latched - wouldn't it ?

Of course, simulation works just fine like this, but will it always work once synthesised and loaded ?

Thanks.

 

[FvM]

If both circuits are fed by the same clock, timing analysis guarantees skew margins so that data can be transferred consistently between them. Not only a single handshake bit but also multi bit values.

 

[KlausST]

Hi,

please do a sketch.

I don´t understand why you need a signal back? What is it used for?
Without further information .. I don´t see a need for it in a system with a common clock.
All should by in sync anyways.

Keep in mind: This is hardware, where all signals are processed in parallel. This is not a software - unless you coded some microcontroller into the FPGA.

Klaus

 

[FvM]

There are many cases where you have bidirectional handshake between design blocks. Imagine e.g. a bus read interface with variable latency, utilizes at least a read_request and read_data_valid signal. Standard timing for single clock domain is similar to post #1 waveform.

 

[KlausST]

Hi,

I fully agree.
But still the opposite exists ... and is not that rare.

My idea was to transfer some data.
Examples:
* Writing to an SRAM. All that´s necessary is to keep on timings. And the SRAM never gives it`s status nor ACK back to the controller. (Read is the same)
* writing to a DAC
* data transfer via SPI

And especially here when all data is processed within an FPGA ... and all have the same clock source...

With the OP´s example (every single byte to be acknowledged) .. I think about a DFF. One full clock cycle for the DFF to capture the data. And there is no reason for the DFF not to capture the data ... It simply has to capture the data.
(At least I would code it this way ... and constrain it this way. There might be other solutions)


********

Something different when one talks about a whole block of data (as far as I understand the OP, he does no block processing).
Like audio processing of 1024 bytes/words using an FFT.
Then one not only needs a control signal back, but one additionally need a place to store the incoming data. Something like a FIFO, SRAM, dual 1024 byte buffer...


Klaus

 

[ThisIsNotSam]

This question relates to sending signals between two processes, and timing concerns.

I have a system where Process A sends a signal to Process B. The signal is one clock cycle long beginning on the positive edge. Process B needs to capture this signal, do the requested logic, then signal a complete signal back to Process A, one cycle long, beginning on the positive edge of Process B clock. Ideally, Process A clock and Process B clock are the same clock (not withstanding any clock skew due to routing. (See attached picture).

My question is this. What are the pitfalls of such a design ? Can I guarantee that Process B, and Process A will see the signals from each other with a system like this ? It seems as if there were clock or data skew between processes that the signal may be missed. Would it be better to have Process B looking for the do_something signal on the falling edge of the clock . Likewise, sending the do_something_complete signal on the falling edge ? This out of phase clock relationship would take away the uncertainty of where the data is latched - wouldn't it ?

Of course, simulation works just fine like this, but will it always work once synthesised and loaded ?

Thanks.

View attachment 186324

others already answered that this is the trivial scenario you have for two blocks on the same clock domain. the tools will make sure timing is respected, including all sources of jitter you can think of.

about the solution of using the negedge: it effectively takes half a cycle from your computation time. what used to 'fit' in a full clock period now has to fit in half. if the computation in question is the bottleneck of the system, then you have to slow down the clock for every block out there. it is rarely a good solution to try to mix edges to fix a timing issue, potential or real. 99.9% of the time your logic should respond to one edge and one edge only.

 

[gahelton]

Thank you for the replies. I will use single pulse, positive edge aligned for both signals as shown. As far as the "do_something_complete" feedback signal from Process B to Process A, Process B may be many clock cycles long (like a 32 bit multiply or divide). The calling process (Process A) needs to know when the operation is complete so it can continue with the result. For any Process B that will complete in one cycle cycle, the feedback signal won't be used.