cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
aponchak1
Visitor
Visitor
357 Views
Registered: ‎02-11-2020

What to expect when using .edf files compiled for Artix-7, in a Kintex-7 project, or vice versa?

Jump to solution

I've been provided a project which has mostly EDF files (i.e. no HDL source) and that have been built for Artix-7 (Zynq-7020). I'm now tasked with using the EDF (Artix-7) files to target a platform that is based on a Kintex-7 (Zynq-7030).

What should I expect when using EDFs built for the same family (Zynq-7000) but different fabric (Artix-7 vs Kintex-7)?

The Artix-7 is for cost-effective designs, while the Kintex-7 is for high-performance...

Do I miss out on performance optimizations by using Artix-7 EDFs, but really targeting a Kintex-7 device?

I'd certainly expect timing issues if the situation were reversed, i.e. using EDFs built for Kintex-7 but targeting an Artix-7.

0 Kudos
1 Solution

Accepted Solutions
barriet
Xilinx Employee
Xilinx Employee
329 Views
Registered: ‎08-13-2007

I'm pretty sure that this is not an officially supported flow.

That said, you are in much better shape than something like Virtex-6 vs Spartan-6, which although had the same series name but were actually very different device families in terms of clocking, I/O, even primitives like the BRAM and DSP.

7 series was the first "unified architecture" so much of the primitives are in common.

The obvious differences here include:
Artix-7 uses GTP transceivers and HR I/O...
Kintex-7 uses GTX and HR or a mix of HR/HP I/O depending on the device... Virtex-7 is similar to this but largely almost all HP - and GTX, GTH, or GTZ depending on the device.
Zynq-7000 depends on the device - e.g. 7Z030/7Z045/7Z100 are Kintex-7 on the PL side, 7Z010 and 7Z020 are Artix-7.

Although Kintex-7 (and Virtex-7) has significantly faster fabric than Artix-7 - the generic fabric primitives should generally be the same.

So the performance will obviously be different. Datasheet limits apply.


If the netlist is using associated primitives because of the different I/O (see ug471) or different transceivers, you'll likely run into issues.

But for something that is largely a netlist with clocking (BUFG, PLL/MMCM) and internal fabric primitives (FFs like FDCE, LUT6, RAMB36E1, DSP48E1, etc.)

It could be good to check here to see cases where the primitives I mentioned above are different too - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/7series_hdl.pdf

But it might be a smooth experience overall by happenstance, even though you are off the yellow brick road.

To be clear, this is probably not a tested or supported flow, but for many cases, synthesis may have ended up producing similar or the same results (ignoring timing optimizations based on constraints and the associated performance differences).

I/O (SelectIO and GTs) could be an issue here depending on the interface.
See https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf pages 13-14 for an example.

So if your netlist had an IBUF or OBUF that had an IOSTANDARD of LVCMOS33 applied in the netlist instead applied at the typical xdc file level, I'd expect an issue if it tries to target this in a K7 HP bank without overriding it.

There might be a few more potential issues I'm initially overlooking.

View solution in original post

4 Replies
barriet
Xilinx Employee
Xilinx Employee
330 Views
Registered: ‎08-13-2007

I'm pretty sure that this is not an officially supported flow.

That said, you are in much better shape than something like Virtex-6 vs Spartan-6, which although had the same series name but were actually very different device families in terms of clocking, I/O, even primitives like the BRAM and DSP.

7 series was the first "unified architecture" so much of the primitives are in common.

The obvious differences here include:
Artix-7 uses GTP transceivers and HR I/O...
Kintex-7 uses GTX and HR or a mix of HR/HP I/O depending on the device... Virtex-7 is similar to this but largely almost all HP - and GTX, GTH, or GTZ depending on the device.
Zynq-7000 depends on the device - e.g. 7Z030/7Z045/7Z100 are Kintex-7 on the PL side, 7Z010 and 7Z020 are Artix-7.

Although Kintex-7 (and Virtex-7) has significantly faster fabric than Artix-7 - the generic fabric primitives should generally be the same.

So the performance will obviously be different. Datasheet limits apply.


If the netlist is using associated primitives because of the different I/O (see ug471) or different transceivers, you'll likely run into issues.

But for something that is largely a netlist with clocking (BUFG, PLL/MMCM) and internal fabric primitives (FFs like FDCE, LUT6, RAMB36E1, DSP48E1, etc.)

It could be good to check here to see cases where the primitives I mentioned above are different too - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/7series_hdl.pdf

But it might be a smooth experience overall by happenstance, even though you are off the yellow brick road.

To be clear, this is probably not a tested or supported flow, but for many cases, synthesis may have ended up producing similar or the same results (ignoring timing optimizations based on constraints and the associated performance differences).

I/O (SelectIO and GTs) could be an issue here depending on the interface.
See https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf pages 13-14 for an example.

So if your netlist had an IBUF or OBUF that had an IOSTANDARD of LVCMOS33 applied in the netlist instead applied at the typical xdc file level, I'd expect an issue if it tries to target this in a K7 HP bank without overriding it.

There might be a few more potential issues I'm initially overlooking.

View solution in original post

aponchak1
Visitor
Visitor
308 Views
Registered: ‎02-11-2020

Thanks barriet, your explanation makes sense, i.e. internally, A7 and K7 are basically the same but there's still some risk, however the biggest issue are likely be encountered at the I/O level (generally speaking).

In my case, since I'm building a project with A7 EDFs targeting a K7, then I'm probably 'safe', since this is a slow (A7) to fast (K7) device migration. However, going the other way (i.e. K7->A7), I'll most likely encounter flying monkeys, especially if the design leverages unique K7 I/O resources.

With this in mind, I'll review the various datasheets and proceed to the castle.

0 Kudos
avrumw
Expert
Expert
296 Views
Registered: ‎01-23-2009

It probably wouldn't be much different going from a K7 -> A7. The EDF is a synthesized netlist (not an implemented one). The final timing of the design is determined at implementation time (during place and route and optimization). While it is true that synthesis is timing driven, and it is possible that synthesis for a K7 could make different speed/area tradeoffs for the same RTL if it were targeting an A7, the reality is that there isn't that that the synthesis tool can/will do "differently" depending on the speed of the device - you might end up with a slower design on the A7 than if the synthesis had originally been done for the A7, but that difference may be small or even negligible.

Similarly, going in the direction you are going (A7 -> K7) you may be missing out on some of these area/power/performance optimizations - the synthesis tool may have decided to use larger/more power hungry implementations of a sub-circuit on the assumption that a lower area/power solution would be too slow to meet your target in the A7. If this was originally targeted at the K7, it might have made lower area/power choices. But again, this is not likely to be very significant.

So what @barriet talked about (I/O differences, GTx differences, etc...) are going to be your problems regardless of direction (K7->A7 or A7->K7).

Also, if these .edf files are primarily for sub-modules (rather than the complete top design), then integrating them into a new top will likely be smoother than if the .edf is for the entire synthesized design.

Avrum

barriet
Xilinx Employee
Xilinx Employee
282 Views
Registered: ‎08-13-2007

@avrumwAgreed.

In the old days, I used to attempt to isolate my clocking (e.g. DCM, PLL, MMCM) and I/O structures (e.g. DDR) to a clean isolated level right under the top-level to minimize porting changes cleanly but recognize that is a challenge these days, especially with GT based cores like 25GE...

@aponchak1I should also perhaps clarify that nothing I said above should try to be extended to unique situations like the MIG DDR3 controller on 7 series... To achieve that level of performance (e.g. 1866Mbps in a 4:1 or 800Mbps in a 2:1 configuration) - it often uses the I/O & clocking in less than obvious/publicly documented ways... But I wouldn't expect you to have that in your EDIF netlist anyway.

0 Kudos