Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface
in [FPGA]
|
Prev: Virtex 4 ICAP partial reconfiguration
Next: data2mem
From: Bryan on 27 Apr 2010 10:31 Although based on an older version of ISE and MIG, you may find the MIG designs posted by Avnet to be helpful. www.em.avnet.com/spartan3a-dsp --> Support Files & Downloads. Bryan
From: Berk on 28 Apr 2010 04:25 On 27 Nisan, 17:31, Bryan <bryan.fletc...(a)avnet.com> wrote: > Although based on an older version of ISE and MIG, you may find the > MIG designs posted by Avnet to be helpful. > > www.em.avnet.com/spartan3a-dsp--> Support Files & Downloads. > > Bryan Thanks for the responses guys. I have come across very interesting problems. @Gabor: I checked the pad report and I saw that wrong pins were being assigned for use. (ie: In the UCF file, NET "N5" is used, but the pad report uses a different pin and not N5) I don't know why this happens. Is there something wrong with timing constraints, etc? I have no idea! @RCIngham: I don't have any of the software mentioned on that thread. I am just trying to use, Xilinx ISIM (ISE Simulator), but I'm having trouble because it doesn't launch. @Bryan: I checked those designs, keeping in mind that I could use the UCF file. However, those designs use DCM and differential clock, so the UCF files are different. I tried using the UCF file from the Avnet design on my project, but as I mentioned before, in the pad report different pins are being used! Overall, I think the problem is with the UCF file.
From: Gabor on 28 Apr 2010 13:04 On Apr 28, 4:25 am, Berk <berkgura...(a)gmail.com> wrote: > On 27 Nisan, 17:31, Bryan <bryan.fletc...(a)avnet.com> wrote: > > > Although based on an older version of ISE and MIG, you may find the > > MIG designs posted by Avnet to be helpful. > > >www.em.avnet.com/spartan3a-dsp--> Support Files & Downloads. > > > Bryan > > Thanks for the responses guys. I have come across very interesting > problems. > > @Gabor: I checked the pad report and I saw that wrong pins were being > assigned for use. (ie: In the UCF file, NET "N5" is used, but the pad > report uses a different pin and not N5) I don't know why this happens. > Is there something wrong with timing constraints, etc? I have no idea! > > @RCIngham: I don't have any of the software mentioned on that thread. > I am just trying to use, Xilinx ISIM (ISE Simulator), but I'm having > trouble because it doesn't launch. > > @Bryan: I checked those designs, keeping in mind that I could use the > UCF file. However, those designs use DCM and differential clock, so > the UCF files are different. I tried using the UCF file from the Avnet > design on my project, but as I mentioned before, in the pad report > different pins are being used! > > Overall, I think the problem is with the UCF file. If your pinout doesn't match the UCF file, I would suggest two things: 1) look at the place and route report to see if it is reporting 100% LOCed IOB's. This is near the top of the report and should be right after the number of IOB's used by the design. If not, you should check the UCF to be sure the net names match the design. 2) if it looks like the UCF is being ignored, I have found that cleaning up the project files can sometimes help this. The ISE project keeps some precompiled bits & pieces in an attempt to save time when re-building. My experience has been that the overall time savings is negligible, both with respect to the overall project build time, and especially with respect to the additional time and aggravation tracing down stuff like this. HTH, Gabor
From: Bryan on 28 Apr 2010 14:55 > @Bryan: I checked those designs, keeping in mind that I could use the > UCF file. However, those designs use DCM and differential clock, so > the UCF files are different. I tried using the UCF file from the Avnet > design on my project, but as I mentioned before, in the pad report > different pins are being used! > > Overall, I think the problem is with the UCF file. Use the UCF that comes with the "> S3A1800DSP DDR2 MIG Simplified Verilog User Logic" archive. It has a single-ended clock, LOC-ed to site F13, which matches the 1800A board. That design was hardware tested on an 1800A board, so the UCF is correct. The default pinout from MIG does not match the 1800A board. However, the 1800A board pinout is considered MIG-compliant -- meaning it adheres to all the rules required for the MIG-generated controller. The UCF has to be manually updated to match the board, including Pin Locations as well as some Slice locations. The UCF that I mention above has already had this manual editing performed, as well as having the Verilog user logic code modified with more consistent variable naming and comments. Bryan
From: Brian Drummond on 28 Apr 2010 15:06
On Wed, 28 Apr 2010 10:04:48 -0700 (PDT), Gabor <gabor(a)alacron.com> wrote: >On Apr 28, 4:25�am, Berk <berkgura...(a)gmail.com> wrote: >> Overall, I think the problem is with the UCF file. > >If your pinout doesn't match the UCF file, I would suggest two >things: > >1) look at the place and route report to see if it is reporting >100% LOCed IOB's. This is near the top of the report and should be >right after the number of IOB's used by the design. If not, you >should check the UCF to be sure the net names match the design. > >2) if it looks like the UCF is being ignored, I have found that >cleaning up the project files can sometimes help this. The ISE >project keeps some precompiled bits & pieces in an attempt to >save time when re-building. My experience has been that the >overall time savings is negligible, both with respect to the >overall project build time, and especially with respect to the >additional time and aggravation tracing down stuff like this. > Also check the "Translate" report (.bld file). Sometimes NGDbuild has its own reasons for rejecting a constraint, either because of a clash with another constraint, or some other reason (some constraints are apparently case-sensitive, and some signal names seem to get translated into lower-case during synthesis!) - Brian |