All of the MIG IP support for versions of Vivado on my Win10 box, which is 2019.1 and later, have a problem. If I want to create a MIG core for a new project, just supplying a .prj file isn't sufficient. For boards like the Genesys2 the master constraints files supplied by Digilent don't include the DDR interface pins. But even if it did there would still be a problem: the Vivado MIG wizard simply can't understand .xdc file where pin locations and other pin constraints like IOSTANDARD are in the same line. I've verified this with correct ,prj files and xdc files for boards from other vendors. The only way to create a usable constraints file for use by the Vivado MIG IP tool is to enter the pins manually. And this is really a painful process.
Digilent could ease the pain for it's customers using an all HDL design flow. Here are a few possibilities:
1) add the DDR constraints to the master constraints files making sure to supply the location constraints separately from the other constraints. This would be the most helpful.
2) add the DDR constraints to the master constraints using it's current approach. Users would still have to create a special DDR constraints file that Vivado can understand, but at least they could avoid doing so manually.
3) add a DDR constraints file that Vivado MIG IP understands to the current vivado-boards-master repository. This is where Digilent sticks it's MIG .prj files, so this would be convenient. This would work equally as well as option 1.
When making a reference to creating ucf/xdc files that the Vivado MIG Wizard understands this not only means separating location constraints from the others, but also choosing the signal naming format that the IP wants to see. Xilinx will not fix the IP so at least make using it a but less onerous.
There's really no reason why Vivado can't just import a valid .prj file into the MIG wizard... but it can't. All of the necessary information is already in the .prj file. Forcing users to also supply an .xdc file just causes unnecessary frustration. Expecting Xilinx to fix it's tools is unreasonable but expecting board vendors to provide useful source material isn't.
Question
zygot
All of the MIG IP support for versions of Vivado on my Win10 box, which is 2019.1 and later, have a problem. If I want to create a MIG core for a new project, just supplying a .prj file isn't sufficient. For boards like the Genesys2 the master constraints files supplied by Digilent don't include the DDR interface pins. But even if it did there would still be a problem: the Vivado MIG wizard simply can't understand .xdc file where pin locations and other pin constraints like IOSTANDARD are in the same line. I've verified this with correct ,prj files and xdc files for boards from other vendors. The only way to create a usable constraints file for use by the Vivado MIG IP tool is to enter the pins manually. And this is really a painful process.
Edited by zygotDigilent could ease the pain for it's customers using an all HDL design flow. Here are a few possibilities:
1) add the DDR constraints to the master constraints files making sure to supply the location constraints separately from the other constraints. This would be the most helpful.
2) add the DDR constraints to the master constraints using it's current approach. Users would still have to create a special DDR constraints file that Vivado can understand, but at least they could avoid doing so manually.
3) add a DDR constraints file that Vivado MIG IP understands to the current vivado-boards-master repository. This is where Digilent sticks it's MIG .prj files, so this would be convenient. This would work equally as well as option 1.
When making a reference to creating ucf/xdc files that the Vivado MIG Wizard understands this not only means separating location constraints from the others, but also choosing the signal naming format that the IP wants to see. Xilinx will not fix the IP so at least make using it a but less onerous.
There's really no reason why Vivado can't just import a valid .prj file into the MIG wizard... but it can't. All of the necessary information is already in the .prj file. Forcing users to also supply an .xdc file just causes unnecessary frustration. Expecting Xilinx to fix it's tools is unreasonable but expecting board vendors to provide useful source material isn't.
Link to comment
Share on other sites
0 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now