<div dir="ltr"><div><div><div><div><div><div><div>This is a configuration management question.<br><br></div>We have a hardware description language (HDL) reference design from Analog Devices. This reference design is widely used in industry and academia to get up and off the ground with the platforms that people use for prototyping. We will be incorporating our IP into the reference design. <br><br>Hardware platforms generally consist of an FPGA development board with a radio card attached. There are a finite number of combinations that are explicitly supported in the HDL reference design. You navigate to your combination by traversing a directory tree in the design, choosing your boards as directory names until you get to the leaf node. That's the location you call "make" and it produces the right bitfile and Vivado project, among other things. <br><br></div>In our case, we have been using the zc706 Xilinx FPGA dev board with an ADRV9371 radio card from Analog Devices. For Neptune, a new low-latency OFDM data specification and application, we are using the zcu106 Xilinx FPGA dev board with an ADRV9002 radio card from Analog Devices. Same reference design, different places in the directory structure. <br><br></div><div>See it for yourself here: <a href="https://github.com/analogdevicesinc/hdl">https://github.com/analogdevicesinc/hdl</a></div><div><br></div>The zcu106 was specified by Wally Ritchie (SK), who was our primary investigator and project lead for Phase4Ground and Space. He had a tremendous amount of industry experience and was a thoughtful and highly competent project lead. Phase4Space is now Haifuraiya, our open source HEO/GEO design. <br><br></div>He picked the zcu106 over the zcu102. The zcu106 supports a wide variety of interfaces, including JESD204B, had a nice video chip on it (which turns out to be desirable to #Neptune), and a beefy Ultrascale+ FPGA. However, it doesn't have native support with the radio card that Neptune recently selected, which is the ADRV9002. The zcu102 is what Analog Devices officially supports for the ADRV9002.<br><br></div>In order to get these two boards (zcu106+ARDV9002) to work together, we have to change the constraints file from the zcu102 (which does officially support the ADRV9002) to one that produces working code for the zcu106. <br><br></div>This is often done. It's a popular combination. We're not wrong or weird for wanting to use this combination. However, it requires some extra work. <br><br>The adjustments are easy if you've done it before, but no one has documented it online. So, we will document it. We're in the middle of this process and you can read about it over in our #Neptune Slack Channel. If you happen to have already done this then please help out so we can finish this part faster. <br><br></div><div>The constraints are split up in four different files. There's a board constraints file for the FPGA development board, which you can think of as a base board. There's a constraints file for the radio card, which handles all the signal definitions for signals that go to this card over the FMC connector. <br><br></div><div>There are two other radio card constraints files, one for the CMOS drivers, and one for the LVDS drivers. This is because you choose either CMOS or LVDS when you build the codebase. <br><br></div><div>In between these four files, these are all the constraints used. <br><br></div><div>We have the full constraints file for the new base card direct from Xilinx. One signs in and downloads it. <br><br></div><div>After cutting up this monolithic constraints file and distributing all the changes properly to the split up files in the reference design, we will build and test with a hello world. <br><br></div><div>Assuming this works, and eventually it will because we are stubborn and competent, then we need a way to manage this configuration in our github repo.<br><br></div><div>What is the best way to do this?<br><br></div><div>We have an HDL reference design from Analog Devices that gets regular official updates. <br><br></div><div>We want to customize that design, with the source code coming from a stable/static file from Xilinx. It isn't a 1:1 swap, though. there isn't a monolithic constraints file in the reference design.<br><br></div><div>What is the best way to set this up so that it's as easy to use as possible? <br><br></div><div>I'm looking for specific tactical advice. We used submodules for our custom build for the ADVR9371+zc706. This required us to freeze the HDL reference design to a specific hash. I suspect there's a more elegant way to do this, but I don't know what it is. My goal here is to make the work as easy as possible for our amazing technical volunteers. They should not have to spend time on this if they don't have to. <br></div><div><div><div><div><div><div><div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br></div><div>Thank you!<br></div><div dir="ltr"><div>-Michelle Thompson<br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>