Vivado Implementation failure for 1000 MBit Ethernet

[KireinaHoro]

I'm trying to reproduce the SoC for the VCU118 board. After enabling 1000 MBit support for the Ethernet peripheral, Vivado implementation will fail with the following messages:

Command: opt_design
Attempting to get a license for feature 'Implementation' and/or device 'xcvu9p'
INFO: [Common 17-349] Got license for feature 'Implementation' and/or device 'xcvu9p'
Running DRC as a precondition to command opt_design

Starting DRC Task
INFO: [DRC 23-27] Running DRC with 8 threads
ERROR: [DRC INBB-3] Black Box Instances: Cell 'eth0.e1/m1000.u0/gtxc0' of type 'greth_gbitc' has undefined contents and is considered a black box.  The contents of this cell must be defined for opt_design to complete successfully.
INFO: [Project 1-461] DRC finished with 1 Errors
INFO: [Project 1-462] Please refer to the DRC report (report_drc) for more information.
ERROR: [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.

Time (s): cpu = 00:00:12 ; elapsed = 00:00:10 . Memory (MB): peak = 8333.207 ; gain = 47.984 ; free physical = 23609 ; free virtual = 25108
INFO: [Common 17-83] Releasing license: Implementation
19 Infos, 1 Warnings, 1 Critical Warnings and 2 Errors encountered.
opt_design failed
opt_design: Time (s): cpu = 00:00:12 ; elapsed = 00:00:10 . Memory (MB): peak = 8333.207 ; gain = 48.016 ; free physical = 23609 ; free virtual = 25108
ERROR: [Common 17-39] 'opt_design' failed due to earlier errors.

INFO: [Common 17-206] Exiting Vivado at Thu Jun  4 16:36:32 2020...
[Thu Jun  4 16:36:33 2020] impl_1 finished
WARNING: [Vivado 12-8222] Failed run(s) : 'impl_1'
    ERROR: bistream not found; synthesis failed

The menu for the 1000 MBit option in make grlib-xconfig:

I'm relaunching the flow without 1000 MBit support to see if this is the problem, the synthesis is spinning now. Update: things went past DRC with 1000 MBit support off. Seems like an issue with the GbE MAC IP?

• OS: CentOS 7.7
• CAD tools versions: Vivado 2019.2

[paulmnt]

For peripherals like Ethernet, ESP is leveraging the open-source library GRLIB by Cobham Gaisler. Even though the GRLIB configuration GUI allows you to select Gigabit Ethernet, the IP is not part of the open-source release of GRLIB. You may obtain the missing RTL from Cobham by paying a license fee.

We are considering integrating other open-source Ethernet peripherals that support Gigabit, however this could take a while, because other IPs do not include the second MAC, named EDCL in the GRLIB documentation.

ESP leverages the EDCL for fast access to the SoC through the ESPLink application running on a client computer. Without that, loading programs, including Linux, into memory would have to be done via JTAG, resulting in much longer booting time. Therefore, before replacing the Ethernet IP we must reimplement the support for debug via Ethernet on another open-source device.

[KireinaHoro]

I see. I would suggest mentioning that somewhere in the documentation in case people just go through the options and try things out (and fail like in this case).

Are there plans for supporting third-party IPs (e.g., MACs from Xilinx for the FPGAs, just like MIG) to provide ethernet access? A faster link would be better, especially when working with transceivers that do not work well with the 100M MAC. EDCL functionality can still be kept by leaving GRETH in place.

[paulmnt]

Yes, we will add a clearer note about not to change the GRLIB configuration, except for the MAC and IP pairs for EDCL. There are, in fact, other options that wont' work because they require changing the FPGA top as well.

As for supporting Xilinx IP, we'd rather pick an open source one. The reason is that ESP is leveraging FPGAs for prototyping, but the back-end flow for ASIC is well in the works. The final goal of ESP is to have an agile methodology for heterogeneous chip design. Xilinx IPs, unfortunately closed source, are not suitable for the ASIC flow, so we tend not to use them as much as possible, with the exception of the DDR controller, for which there is no open alternative.

[KireinaHoro]

That may sound a little bit confusing, as you certainly cannot expect to have open source version for all peripheral IPs used in the SoC, especially when you're targeting ASIC; for example, one could possibly use Cadence MACs or USB peripherals, which are not open source but are provided in the form of (possibly encrypted) RTL. The Xilinx IPs are the same by this consideration.

And I can get the point that supporting IPs from a specific vendor would be effort that's not justified for the final target, so I'd like to know if there will be a guide to integrate custom peripheral IPs (in the IO block). The current setup of UART and Ethernet is far from enough.

2020年6月4日(木) 23:41 Paolo Mantovani notifications@github.com:

Yes, we will add a clearer note about not to change the GRLIB configuration, except for the MAC and IP pairs for EDCL. There are, in fact, other options that wont' work because they require changing the FPGA top as well.

As for supporting Xilinx IP, we'd rather pick an open source one. The reason is that ESP is leveraging FPGAs for prototyping, but the back-end flow for ASIC is well in the works. The final goal of ESP is to have an agile methodology for heterogeneous chip design. Xilinx IPs, unfortunately closed source, are not suitable for the ASIC flow, so we tend not to use them as much as possible, with the exception of the DDR controller, for which there is no open alternative.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sld-columbia/esp/issues/48#issuecomment-638933519, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3ROOXMYMV4MNAYVYCWFY3RU66EDANCNFSM4NSNYIXA .

[paulmnt]

The release of the ESP project on GitHub is all about open-source hardware. We certainly don't expect that all possible peripherals can be found as open-source IPs, but for those that are absolutely required to create an ESP instance (i.e. UART, Ethernet and memory), we try to use open IPs as much as possible. Memory is clearly not possible for now.

Having said that, so far we've focused on tutorials to integrate accelerators, as ESP is meant to facilitate the design and integration of heterogeneous processing elements. We want our users to be able to design custom systems, using their specialized accelerators, or designing new ones from their algorithms as quickly and easily as possible. Nonetheless, I do understand that some users might be interested in integrating proprietary peripherals for I/O as well and that there is not enough documentation yet to guide them in this process.

If the peripheral interface is AXI, AHB or APB, hardware integration is not complicated at all. The I/O tile hosts an AHB bus controller and an APB bus controller and all peripherals are currently attached there. If necessary, an AHB-to-AXI bridge can be instantiated as well.

In time we will certainly provide all users with documentation about the I/O tile, but for now, If you have a specific component in mind, such as the Xilinx Ethernet MAC, we will try to support you in modifying the memory map and routing tables generator to have processors communicate with a new device on the I/O tile.

You can also reach us through the esp-info email address (see our contact page).

[KireinaHoro]

Thanks for the clarification and patience!