UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor sravanke
Visitor
1,391 Views
Registered: ‎06-22-2015

Constraining system synchronous output from FPGA to ASIC

Jump to solution

 

 Hello,

 

Following is the FPGA interface where I need some assistance. 

 

 temp.jpg

 

TOOL: Vivado 2017.2

FPGA: Artix

 

There is a clock synthesizer on the PCB which generates two clocks of the same frequency and phase wiz. clk_osc_fpga and clk_osc_asic respectively. The FPGA feeds the clk_osc_fpga to a PLL and generates the clk_int signal having the same frequency as the input. Note that the PLL output is not in a Zero-Phase mode. The clk_int feeds some sequential logic which is fed to the ASIC which is clocked via the clk_osc_asic.

 

Now the question is simple? How do I ensure that the Vivado timing analyzer achieves positive slack on the IO port "data"? 

 

As per my understanding, the set_output_delay makes sure that the data-driven from an FPGA meets the setup and hold requirements of the external chip. The constraints use various timings like [tCO tSU tH tREM tREC] of the external chip, PCB trace delay, clock skew etc for the estimation. This theory is pretty clear to me except the "use of clock".

 

Should I use the clk_osc_fpga as a virtual clock? Do I need to tell the Vivado STA about the phase differences involved between the ASIC clock and FPGA clock? How do I estimate the clock delays(network delay only I guess) inside the FPGA? 

 

Sorry I've added lot of questions... Please let me know if I've overlooked something.

Cheers.

 

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
1,233 Views
Registered: ‎01-23-2009

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

But as I had mentioned in my question, the MMCM used to generate the clk_init is not in "Phase Aligned Mode".  So there can be a phase lag or lead between the clk_init and the clk_osc_fpga even if they are of the same frequency. Hence the phase difference exists between the clk_init and the clk_osc_asic. In that case, the default setup-hold relationship might look something like this:

 

It is irrelevant what mode you put your MMCM in - in fact it is irrelevant what is in the FPGA at all.

 

The constraints tell the tools the requirements of the external device; the external device has a setup and hold requirement with respect to the clock it receives, which is the clock output of the clock synthesizer. This is clk_osc_asic (or clk_osc_fpga, which are the same clock). The external device doesn't know and doesn't care that there is an internal clock that has a different phase - it needs the output to conform to the timing with respect to it's clock.

 

Regardless of the mode of the MMCM, the tools will analyze the timing of the inside of the FPGA and tell you whether you meet the requirements of the external device. The mode of the MMCM, along with many other factors (the kind of clock architecture used, the programmable phase delay of the MMCM, and many other things) will will affect the timing, and ultimately determine whether the implemented design in the FPGA will meet the requirements imposed by the external device.

 

This means depending on the phase difference between the clk_init and clk_osc_asic, I might have an unrealistic setup or hold relation.

 

Yes, it's true that the requirements of the external device may be impossible to meet with the MMCM in a particular mode, but that just means that your system won't work with the design you have.

 

Again, the constraints describe the system requirements for the FPGA system. It is the responsibility of you (and the tool in some cases) to design an architecture that can meet these system requirements. If you do so, then the timing analysis of the interface will pass, otherwise it will fail.

 

Avrum

0 Kudos
5 Replies
Historian
Historian
1,378 Views
Registered: ‎01-23-2009

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

This is really the simplest type of interface to constrain. In fact, the very definition of how set_output_delay matches exactly with this interface...

 

Your two external clocks (clk_osc_asic and clk_osc_fpga) are identical in terms of phase and frequency. As a result, there is no need to define both - the description for one is equally valid for the other. So you need only create one clock. Now this clock is then going to be used for two things

  - defining the clock that enters the FPGA - this will be used by the PLL to automatically generate clk_in and constrain internal paths

     - since it is connected to the ASIC, you need to specify this when the clock is generated

  - defining the reference for the ASIC, which is what the set_output_delays are related to

     - an output delay can use any clock that already exists, whether it is connected to anything or not

 

create_clock -name clk -period <period>  [get_ports <input clock port of FPGA>]

 

set_input_jitter <jitter value> [get_clocks clk] <jitter_value>; # You should always set a jitter on the clock

 

Now the output delays can be defined with respect to this clock, since it is the same as the ASIC clock. The -max of the output delay is the required setup time of the ASIC plus the longest board delay. The -min of the output delay is the negative of the required hold time of the FPGA plus the shortest board delay.

 

That's all that is necessary. Everything past this point is only if you want to get fancy...

 

 

For example, you can explicitly describe the board latency of the two clocks.

 

create_clock -name fpga_clk -period <period>  [get_ports <input clock port of FPGA>]

create_clock -name asic_clk -period <period>  ; # This is a virtual clock

 

set_clock_latency -source <clk_fpga_board_delay> [get_ports <input clock port of FPGA>]

set_clock_latency -source <clk_asic_board_delay> [get_clocks clk_asic]

 

And now set the output delay with respect to clk_asic.

 

You can even get fancier and specify minimum and maximum board delays with the set_clock_latency.

 

Avrum

Visitor sravanke
Visitor
1,270 Views
Registered: ‎06-22-2015

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

@avrumw

 

  • Got your point on setting the output delay constraints using the clk_osc_fpga pin. But as I had mentioned in my question, the MMCM used to generate the clk_init is not in "Phase Aligned Mode".  So there can be a phase lag or lead between the clk_init and the clk_osc_fpga even if they are of the same frequency. Hence the phase difference exists between the clk_init and the clk_osc_asic. In that case, the default setup-hold relationship might look something like this:

 

xilinx.jpg

This means depending on the phase difference between the clk_init and clk_osc_asic, I might have an unrealistic setup or hold relation. So the next logical step might be to look at the phase difference between the two clocks and use a multicycle path constraint. Or should I use the phase alignment option in MMCM settings? 

 

  • MMCM Phase Align Mode confusion:

If I enable the Phase Align option in the MMCM, does that mean the MMCM tries to eliminate the phase difference between all the output clocks and the input clock? Or is it just one output clock which can be phase adjusted?

xilinx_mmcm.jpg

 

Tags (2)
0 Kudos
Historian
Historian
1,234 Views
Registered: ‎01-23-2009

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

But as I had mentioned in my question, the MMCM used to generate the clk_init is not in "Phase Aligned Mode".  So there can be a phase lag or lead between the clk_init and the clk_osc_fpga even if they are of the same frequency. Hence the phase difference exists between the clk_init and the clk_osc_asic. In that case, the default setup-hold relationship might look something like this:

 

It is irrelevant what mode you put your MMCM in - in fact it is irrelevant what is in the FPGA at all.

 

The constraints tell the tools the requirements of the external device; the external device has a setup and hold requirement with respect to the clock it receives, which is the clock output of the clock synthesizer. This is clk_osc_asic (or clk_osc_fpga, which are the same clock). The external device doesn't know and doesn't care that there is an internal clock that has a different phase - it needs the output to conform to the timing with respect to it's clock.

 

Regardless of the mode of the MMCM, the tools will analyze the timing of the inside of the FPGA and tell you whether you meet the requirements of the external device. The mode of the MMCM, along with many other factors (the kind of clock architecture used, the programmable phase delay of the MMCM, and many other things) will will affect the timing, and ultimately determine whether the implemented design in the FPGA will meet the requirements imposed by the external device.

 

This means depending on the phase difference between the clk_init and clk_osc_asic, I might have an unrealistic setup or hold relation.

 

Yes, it's true that the requirements of the external device may be impossible to meet with the MMCM in a particular mode, but that just means that your system won't work with the design you have.

 

Again, the constraints describe the system requirements for the FPGA system. It is the responsibility of you (and the tool in some cases) to design an architecture that can meet these system requirements. If you do so, then the timing analysis of the interface will pass, otherwise it will fail.

 

Avrum

0 Kudos
Visitor sravanke
Visitor
1,228 Views
Registered: ‎06-22-2015

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

As I understand the only thing I could do is to adjust the MMCM phase on the FPGA internal clock such that there is a minimum phase difference between it and the ASIC clock. I do accept that there can be unrealistic requirements otherwise. Also there is a an asynchronous RESET connection between the FPGA and ASIC. So how do I constraint the reset recovery and removal times? Still using set_output_delay right?

 

I had a doubt on the MMCM Phase Modes. I have an MMCM with multiple clock outputs which clock would have the phase correction? C0 or all the clocks? Could you please clarify?

 

Other than that I think I got the answer.

0 Kudos
Xilinx Employee
Xilinx Employee
1,159 Views
Registered: ‎05-14-2008

Re: Constraining system synchronous output from FPGA to ASIC

Jump to solution

"I had a doubt on the MMCM Phase Modes. I have an MMCM with multiple clock outputs which clock would have the phase correction? C0 or all the clocks? Could you please clarify?"

---All MMCM outupt clocks will be phase aligned.

 

"Also there is a an asynchronous RESET connection between the FPGA and ASIC. So how do I constraint the reset recovery and removal times?"

---As you stated, it is an asynchronous RESET. Because it is asynchronous, we don't know the relationship between the clock and the reset. So I would expect set_output_delay does not do the trick. We need to know how you expect the reset signal to work between the FPGA and the ASIC to see if there is a way to constrain it.

 

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos