Closed nelsobe closed 5 years ago
I think it's very odd that there are some inconsistencies between the zynq family pdefs. Our working understanding has been that all pdefs within a family should be the same.
Some thoughts:
a set of additional routethrough elements are included in the following defs from group 2: IDELAYE2_FINEDELAY ILOGICE2 IOB18M OLOGICE2
I noticed that there aren't any sites of these types in the devices in group1 (get_sites -filter { SITE_TYPE == "IDELAYE2_FINEDELAY" }
returns empty for example).
This leads me to believe that the pdefs for these site types from group2 are more complete.
I also noticed that there are some additional routethroughs in several other pdefs when you compare them to the pdefs in other series7 families. This includes SLICEL, SLICEM, and more. Should the pdefs for these in the other series7 families have these routethroughs? Or have they been excluded for a reason?
We can get a list of all unique parts (ignoring speed grade and package type) with tincr::get_parts_unique
. I think we should use this list when creating pdefs for the zynq family.
I generated an XDLRC in ISE and then stripped out the PDEFs. You queried Vivado in Tcl. The differences observed may be simply due to how ISE sees things differently than Vivado does.
Further, I think what you are saying is that the sites: IDELAYE2_FINEDELAY ILOGICE2 IOB18M OLOGICE2 won't ever appear in Vivado-generated designs? If so, then it really doesn't matter what we have for PDEFs for them (I have included the ones with the route-throughs in the distribution). Do you agree? Seems kind of odd.
Also, could it be they don't show up for you because they are only alternate site types for other "normal" sites?
I went ahead and used tincr::sites unique 1
to get all unique site types (and alternate-only types) and found that IDELAYE2_FINEDELAY, ILOGICE2, and OLOGICE2 are alternate-only site types for your first group of devices. However, IOB18M didn't appear as a site type (alternate or not) for any of the devices in group 1. For group 2, these site types are not alternate-only. Additionally, the part "xa7z010clg484-1I" doesn't seem to exist. Did you mean to list "xa7z010clg400-1I" in the readme?
I think these sites could still appear in Vivado-generated designs, but I'm not 100% sure. Doesn't Vivado sometimes change a site to an alternate type on its own?
Hi Dallon,
If you look at the script I ran, the part you mention was the next-to-last one and had its results dumped into the ext12 directory. It does exist in ISE apparently.
Prof Nelson
From: Dallon notifications@github.com Reply-To: byuccl/tincr reply@reply.github.com Date: Tuesday, November 14, 2017 at 9:57 AM To: byuccl/tincr tincr@noreply.github.com Cc: nelsobe nelson@ee.byu.edu, Author author@noreply.github.com Subject: Re: [byuccl/tincr] Generated primitive defs for a variety of zynq parts. Comments welcomed. (#72)
I went ahead and used tincr::sites unique 1 to get all unique site types (and alternate-only types) and found that IDELAYE2_FINEDELAY, ILOGICE2, and OLOGICE2 are alternate-only site types for your first group of devices. However, IOB18M didn't appear as a site type (alternate or not) for any of the devices in group 1. For group 2, these site types are not alternate-only. Additionally, the part "xa7z010clg484-1I" doesn't seem to exist. Did you mean to list "xa7z010clg400-1I" in the readme?
I think these sites could still appear in Vivado-generated designs, but I'm not 100% sure. Doesn't Vivado sometimes change a site to an alternate type on its own?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/byuccl/tincr/pull/72#issuecomment-344324883, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APjxbutGaBVlmC7Dj5tZmoHrd2-D_sPEks5s2caMgaJpZM4QcY8y.
[http://home.byu.edu/home/sites/default/files/mono1web.jpg]
Have confirmed that in each case, the differences are the ISE does not output site routethroughs for site types that are alternate-only for a given part. So, that is not an issue.
See #94.
Generated primitive defs for a variety of zynq parts and combined them into a single collection of zynq primitive defs.
See the generate directory for a README.txt file and scripts used and an explanation of an inconsistency found in the family's pdefs. In short, the issue is that the pdefs are not identical for all parts I tried (the generate/README.txt gives details).
The reason for also including the scripts used to generate them is to make it simpler for someone else to do something similar if needed or to extend this.