Xilinx MIG v2.3 Spartan3A-DSP DDR2 Interface

Hey everyone,

I have been struggling to use the MIG to generate a memory interface
to the DDR2 device. First some background info: I am using the Xilinx=AE
Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with
MIG v2.3.

I have created the MIG from GUI and played around with it. I also
edited the UCF file (just changed the locations basically, did not
mess around with timings). I cannot do any simulation because I am
using Windows 7 and apparently, simulation doesn't work (or maybe some
other problem).

Anyway, the thing is I can download the code to the device and I can
see all the signals go up and down in correct times. (like init_done,
user_cmd_ack, user_data_valid etc.) Then I try to write some data to
the memory, I can see user_cmd_ack go high, then I assert burst_done,
then I can see user_cmd_ack go low. (which means write is succesful,
right?) However, whenever I try to 'read' from the memory, I always
get x"00000000" no matter what the address is. What can be wrong with
it?

Thanks for the help.

On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
> Hey everyone,
>
> I have been struggling to use the MIG to generate a memory interface
> to the DDR2 device. First some background info: I am using the Xilinx=AE
> Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with
> MIG v2.3.
>
> I have created the MIG from GUI and played around with it. I also
> edited the UCF file (just changed the locations basically, did not
> mess around with timings). I cannot do any simulation because I am
> using Windows 7 and apparently, simulation doesn't work (or maybe some
> other problem).
>
> Anyway, the thing is I can download the code to the device and I can
> see all the signals go up and down in correct times. (like init_done,
> user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> the memory, I can see user_cmd_ack go high, then I assert burst_done,
> then I can see user_cmd_ack go low. (which means write is succesful,
> right?) However, whenever I try to 'read' from the memory, I always
> get x"00000000" no matter what the address is. What can be wrong with
> it?
>
> Thanks for the help.

DDR2 timing is not easy to meet in the Spartan parts, so you really
can't just muck around with the pinouts.  If you changed the location
of any memory pins you need to re-run the MIG configuration GUI and
use the option to "Verify UCF".  This tells MIG to generate new
timing and directed routing constraints based on the pin locations
from your actual design.

By the way I thought that the Starter boards come with a pre-built
version of the MIG design.  Have you looked into that?

Regards,
Gabor

On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote:
> On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
>
>
>
>
>
> > Hey everyone,
>
> > I have been struggling to use the MIG to generate a memory interface
> > to the DDR2 device. First some background info: I am using the Xilinx=
=AE
> > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 wi=
th
> > MIG v2.3.
>
> > I have created the MIG from GUI and played around with it. I also
> > edited the UCF file (just changed the locations basically, did not
> > mess around with timings). I cannot do any simulation because I am
> > using Windows 7 and apparently, simulation doesn't work (or maybe some
> > other problem).
>
> > Anyway, the thing is I can download the code to the device and I can
> > see all the signals go up and down in correct times. (like init_done,
> > user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> > the memory, I can see user_cmd_ack go high, then I assert burst_done,
> > then I can see user_cmd_ack go low. (which means write is succesful,
> > right?) However, whenever I try to 'read' from the memory, I always
> > get x"00000000" no matter what the address is. What can be wrong with
> > it?
>
> > Thanks for the help.

Hello,

> DDR2 timing is not easy to meet in the Spartan parts, so you really
> can't just muck around with the pinouts. =A0If you changed the location
> of any memory pins you need to re-run the MIG configuration GUI and
> use the option to "Verify UCF". =A0This tells MIG to generate new
> timing and directed routing constraints based on the pin locations
> from your actual design.

Actually, I did just that. First, I let MIG create a 'wrong' UCF file.
Then I changed the pinouts correctly. Then I
selected "Update Design" and pointed it to my newly edited UCF file.
Then, it changed the pinouts and timings.
But there is no change in the output. By the way I am changing the UCF
file under the user_design folder. I think
this is correct. How can I verify if I'm having a UCF error or
something else?

> By the way I thought that the Starter boards come with a pre-built
> version of the MIG design. =A0Have you looked into that?
> Regards,
> Gabor

Yeah, I did that but my Starter board is not supported.

Thanks a lot.

On Apr 26, 10:10=A0am, Berk <berkgura...@gmail.com> wrote:
> On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
>
> > > Hey everyone,
>
> > > I have been struggling to use the MIG to generate a memory interface
> > > to the DDR2 device. First some background info: I am using the Xilinx=
=AE
> > > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 =
with
> > > MIG v2.3.
>
> > > I have created the MIG from GUI and played around with it. I also
> > > edited the UCF file (just changed the locations basically, did not
> > > mess around with timings). I cannot do any simulation because I am
> > > using Windows 7 and apparently, simulation doesn't work (or maybe som=
e
> > > other problem).
>
> > > Anyway, the thing is I can download the code to the device and I can
> > > see all the signals go up and down in correct times. (like init_done,
> > > user_cmd_ack, user_data_valid etc.) Then I try to write some data to
> > > the memory, I can see user_cmd_ack go high, then I assert burst_done,
> > > then I can see user_cmd_ack go low. (which means write is succesful,
> > > right?) However, whenever I try to 'read' from the memory, I always
> > > get x"00000000" no matter what the address is. What can be wrong with
> > > it?
>
> > > Thanks for the help.
>
> Hello,
>
> > DDR2 timing is not easy to meet in the Spartan parts, so you really
> > can't just muck around with the pinouts. =A0If you changed the location
> > of any memory pins you need to re-run the MIG configuration GUI and
> > use the option to "Verify UCF". =A0This tells MIG to generate new
> > timing and directed routing constraints based on the pin locations
> > from your actual design.
>
> Actually, I did just that. First, I let MIG create a 'wrong' UCF file.
> Then I changed the pinouts correctly. Then I
> selected "Update Design" and pointed it to my newly edited UCF file.
> Then, it changed the pinouts and timings.
> But there is no change in the output. By the way I am changing the UCF
> file under the user_design folder. I think
> this is correct. How can I verify if I'm having a UCF error or
> something else?
>
> > By the way I thought that the Starter boards come with a pre-built
> > version of the MIG design. =A0Have you looked into that?
> > Regards,
> > Gabor
>
> Yeah, I did that but my Starter board is not supported.
>
> Thanks a lot.

Well the obvious thing you can do is check the pad report
to make sure the correct pinout is in use.  You can also go
into the FPGA editor and check that your MIG-related pins
have all the appropriate registers in the IOB tiles.

Then there's the obvious stuff like checking your clock
and reset inputs to be sure they're hooked up properly.
I've often started going down a head-scratching path
with DDR designs only to find that the active-low
reset input was connected to an active high reset signal,
or that the DCM was being reset be a register clocked
on its own output (this doesn't work with DCM's because
the CLK0 output shuts off when reset is active).

HTH,
Gabor

>On Apr 26, 10:10=A0am, Berk <berkgura...@gmail.com> wrote:
>> On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote:
>>
>>
>>
>> > On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote:
>>
>> > > Hey everyone,
>>
>> > > I have been struggling to use the MIG to generate a memory
interface
>> > > to the DDR2 device. First some background info: I am using the
Xilinx=
>=AE
>> > > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1
=
>with
>> > > MIG v2.3.
>>
>> > > I have created the MIG from GUI and played around with it. I also
>> > > edited the UCF file (just changed the locations basically, did not
>> > > mess around with timings). I cannot do any simulation because I am
>> > > using Windows 7 and apparently, simulation doesn't work (or maybe
some
>> > > other problem).

There is another thread about that, see:
http://www.fpgarelated.com/usenet/fpga/show/92403-1.php

>>
>> > > Anyway, the thing is I can download the code to the device and I
can
>> > > see all the signals go up and down in correct times. (like
init_done,
>> > > user_cmd_ack, user_data_valid etc.) Then I try to write some data
to
>> > > the memory, I can see user_cmd_ack go high, then I assert
burst_done,
>> > > then I can see user_cmd_ack go low. (which means write is
succesful,
>> > > right?) However, whenever I try to 'read' from the memory, I always
>> > > get x"00000000" no matter what the address is. What can be wrong
with
>> > > it?
>>
>> > > Thanks for the help.
>>
>> Hello,
>>
>> > DDR2 timing is not easy to meet in the Spartan parts, so you really
>> > can't just muck around with the pinouts. =A0If you changed the
location
>> > of any memory pins you need to re-run the MIG configuration GUI and
>> > use the option to "Verify UCF". =A0This tells MIG to generate new
>> > timing and directed routing constraints based on the pin locations
>> > from your actual design.
>>
>> Actually, I did just that. First, I let MIG create a 'wrong' UCF file.
>> Then I changed the pinouts correctly. Then I
>> selected "Update Design" and pointed it to my newly edited UCF file.
>> Then, it changed the pinouts and timings.
>> But there is no change in the output. By the way I am changing the UCF
>> file under the user_design folder. I think
>> this is correct. How can I verify if I'm having a UCF error or
>> something else?
>>
>> > By the way I thought that the Starter boards come with a pre-built
>> > version of the MIG design. =A0Have you looked into that?
>> > Regards,
>> > Gabor
>>
>> Yeah, I did that but my Starter board is not supported.
>>
>> Thanks a lot.
>
>Well the obvious thing you can do is check the pad report
>to make sure the correct pinout is in use.  You can also go
>into the FPGA editor and check that your MIG-related pins
>have all the appropriate registers in the IOB tiles.
>
>Then there's the obvious stuff like checking your clock
>and reset inputs to be sure they're hooked up properly.
>I've often started going down a head-scratching path
>with DDR designs only to find that the active-low
>reset input was connected to an active high reset signal,
>or that the DCM was being reset be a register clocked
>on its own output (this doesn't work with DCM's because
>the CLK0 output shuts off when reset is active).
>
>HTH,
>Gabor
>

Which is why I have found simulation to be so useful.

But beware the odd case when the simulation model doesn't match the
synthesised behaviour! In my experience, MiG 2.3 DDR2 controllers seem to
be ok for Virtex-4.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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

On 27 Nisan, 17:31, Bryan <bryan.fletc...@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.

On Apr 28, 4:25=A0am, Berk <berkgura...@gmail.com> wrote:
> On 27 Nisan, 17:31, Bryan <bryan.fletc...@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

> @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

On Wed, 28 Apr 2010 10:04:48 -0700 (PDT), Gabor <gabor@alacron.com> wrote:

>On Apr 28, 4:25&#4294967295;am, Berk <berkgura...@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