Reply by John Larkin July 7, 20102010-07-07
On Mon, 5 Jul 2010 21:02:15 -0700 (PDT), Bryan
<bryan.fletcher@avnet.com> wrote:

>John, > >Thanks for your patience. I have been in contact with your FAE, and >he now has the document. If he hasn't gotten it to you within a day >or two, please let me know. > >Bryan
Bryan, Got it, thanks. It's looking like V12.1 of the Xilinx software is much friendlier to Spartan6's than 11 was. Things compile bigger, but seem to be closer to right. We just redesigned a block of 32 8-pole 48-bit-wide IIR digital lowpass filters, from 6500 LUTs down to about 280, so they will compile under 12.1. Maybe 12.1 (or 12.2) and your procedure will fix our DRAM problems. John
Reply by Bryan July 6, 20102010-07-06
John,

Thanks for your patience.  I have been in contact with your FAE, and
he now has the document.  If he hasn't gotten it to you within a day
or two, please let me know.

Bryan
Reply by John Larkin July 3, 20102010-07-03
On Wed, 30 Jun 2010 18:50:42 -0700 (PDT), Bryan
<bryan.fletcher@avnet.com> wrote:

>I work for Avnet, which seems not to be too popular with this crowd, >but I will share my experience anyway. I have a project with >XC6SLX16-2CSG324 and LPDDR that seems to work well with MIG 3.3 in ISE >11.4. Granted, we are only running at 200 MHz. We do not provide a >200 MHz input to the chip. We have a 66 MHz oscillator input to the >FPGA. It is true that by default, MIG generates a design that assumes >the native system clock is the same as the memory clock. The only >clocking customization that MIG allows is the choice between single- >ended or differential clock. However, since MIG provides all the HDL >sources for the clock infrastructure, it is possible to modify the >clocking structure to generate the correct memory clock given any >system clock that meets the specifications of the PLL. > >I have some instructions that explains step-by-step how to do this for >the Avnet board (www.em.avnet.com/spartan6lx-evl). If you are >interested, please contact Avnet Technical Support (www.em.avnet.com/ >techsupport). In addition to this LPDDR example, Xilinx provides >working hardware examples for DDR2 on the SP601 and DDR3 on the >SP605. Avnet has another board with DDR3 that has been proven out at >800 Mbps in hardware (www.em.avnet.com/spartan6lx150t-dev). > >The other critical thing to do with these DDR designs is proper PCB >layout and termination, without which the design will fail. Xilinx >provides some very specific layout guidelines in UG388 that need to be >followed if you want the full memory interface performance. > >Xilinx recently published revised specifications for the MCB. See >http://www.xilinx.com/support/answers/35818.htm >The Spartan-6 Memory Controller Block (MCB) has new data rate >specifications and performance modes for DDR2 and DDR3 interfaces as >specified in version 1.5 of the Spartan-6 FPGA Data Sheet (DS162): >http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf > >You should also be aware of the MIG Design Advisory Answer Record. >http://www.xilinx.com/support/answers/33566.htm > >Bryan >Avnet
Bryan, We (I work with Rob) have contacted our tech support guy at Avnet, and asked him for your doc. After about six interchanges, we still can't get our hands on it. John
Reply by RCIngham July 1, 20102010-07-01
[snip]
> >If you're going to do an S6 design using the MIG, I would _strongly_ >recommend that you bring in a clock at the bus frequency that you're >looking for from an external pin (the only thing that the MIG supports) > The MIG will make available to you a CLK0 output that is a PLL >buffered version of that external clock, which you can then use in the >rest of your design. Or, if you want it at a different frequency, just >give the MIG it's own damn oscillator. > >Or see whether brands A or L might be any better. Do keep in mind that, >as near as can be told from the 7 series info, Xilinx is killing the >hard MCB concept. Looks like it didn't quite click. > >-- >Rob Gaddi, Highland Technology >Email address is currently out of order
May not be necessary for V4, if the memory speed isn't very high. For a PCB-tester FPGA design, I derived the 200MHz DDR2 memory clock from 32MHz (using a tandem pair of DCMs), and all was well. As mentioned, PCB layout and especially routing are critical for these components. The company had to re-spin the boards to get the DDR2s to work. --------------------------------------- Posted through http://www.FPGARelated.com
Reply by Bryan June 30, 20102010-06-30
I work for Avnet, which seems not to be too popular with this crowd,
but I will share my experience anyway.  I have a project with
XC6SLX16-2CSG324 and LPDDR that seems to work well with MIG 3.3 in ISE
11.4.  Granted, we are only running at 200 MHz.  We do not provide a
200 MHz input to the chip.  We have a 66 MHz oscillator input to the
FPGA.  It is true that by default, MIG generates a design that assumes
the native system clock is the same as the memory clock.  The only
clocking customization that MIG allows is the choice between single-
ended or differential clock.  However, since MIG provides all the HDL
sources for the clock infrastructure, it is possible to modify the
clocking structure to generate the correct memory clock given any
system clock that meets the specifications of the PLL.

I have some instructions that explains step-by-step how to do this for
the Avnet board (www.em.avnet.com/spartan6lx-evl).  If you are
interested, please contact Avnet Technical Support (www.em.avnet.com/
techsupport).  In addition to this LPDDR example, Xilinx provides
working hardware examples for DDR2 on the SP601 and DDR3 on the
SP605.  Avnet has another board with DDR3 that has been proven out at
800 Mbps in hardware (www.em.avnet.com/spartan6lx150t-dev).

The other critical thing to do with these DDR designs is proper PCB
layout and termination, without which the design will fail.  Xilinx
provides some very specific layout guidelines in UG388 that need to be
followed if you want the full memory interface performance.

Xilinx recently published revised specifications for the MCB.  See
http://www.xilinx.com/support/answers/35818.htm
The Spartan-6 Memory Controller Block (MCB) has new data rate
specifications and performance modes for DDR2 and DDR3 interfaces as
specified in version 1.5 of the Spartan-6 FPGA Data Sheet (DS162):
http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf

You should also be aware of the MIG Design Advisory Answer Record.
http://www.xilinx.com/support/answers/33566.htm

Bryan
Avnet
Reply by Rob Gaddi June 30, 20102010-06-30
On 6/30/2010 5:53 PM, Aaron Holtzman wrote:
> On Jun 21, 2:45 pm, Rob Gaddi<rga...@technologyhighland.com> wrote: >> Right now I'm working on two S6 projects, both of which are absolute >> disasters due to problems with the toolchain. My DRAM problem from a >> month ago, Xilinx ultimately told me was my problem and they washed >> their hands of it. > > Why does Xilinx think it is your problem? I am about to start layout > on an S6 board and hope to avoid this problem (which seems to be > common!). Thanks. > > cheers, > aaron
My specific problem was that I wanted to use the PLLs in the chip to generate a memory bus clock frequency that wasn't equal to the oscillator frequency. This turns out to be an absolute nightmare, and is what Xilinx left me hanging on. If you're going to do an S6 design using the MIG, I would _strongly_ recommend that you bring in a clock at the bus frequency that you're looking for from an external pin (the only thing that the MIG supports) The MIG will make available to you a CLK0 output that is a PLL buffered version of that external clock, which you can then use in the rest of your design. Or, if you want it at a different frequency, just give the MIG it's own damn oscillator. Or see whether brands A or L might be any better. Do keep in mind that, as near as can be told from the 7 series info, Xilinx is killing the hard MCB concept. Looks like it didn't quite click. -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by Aaron Holtzman June 30, 20102010-06-30
On Jun 21, 2:45=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> Right now I'm working on two S6 projects, both of which are absolute > disasters due to problems with the toolchain. =A0My DRAM problem from a > month ago, Xilinx ultimately told me was my problem and they washed > their hands of it. =A0
Why does Xilinx think it is your problem? I am about to start layout on an S6 board and hope to avoid this problem (which seems to be common!). Thanks. cheers, aaron
Reply by Sebastien Bourdeauducq June 30, 20102010-06-30
On Jun 22, 4:16=A0am, Randy Yates <ya...@ieee.org> wrote:
> The linux version of the 12.1 ISE is a joke: custom build scripts, > separate library directories, custom bashrc entries required, etc. (as > opposed to an RPM and use of the system libraries).
As far as I can tell, all other versions of ISE also had this problem. I think the nastiest new thing about 12.1 is that WebTalk "feature" you cannot normally disable when using WebPack. I think you should not _have_ to tell Xilinx how you use their devices. S=E9bastien PS. Disabling Webtalk on 12.x is as simple as deleting the cURL library from the ISE directories.
Reply by Uwe Bonnes June 23, 20102010-06-23
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
...
> I understand your criticisms of the Spartan-6 production availability > over the last few months. If you check the distributor stocking > levels over the next 1-2 months you will see rapid improvement in this > area.
Digikey now lists the full family, also as non-stock, with e.g. XC6SLX4-2TQG144C-NC expected August 4 at 8.12 Euro at 31 pieces. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply by John Larkin June 22, 20102010-06-22
On Tue, 22 Jun 2010 13:59:46 -0700 (PDT), Aaron Holtzman
<aholtzma@gmail.com> wrote:

>On Jun 21, 2:45&#4294967295;pm, Rob Gaddi <rga...@technologyhighland.com> wrote: >*snip* >> Right now I'm working on two S6 projects, both of which are absolute >> disasters due to problems with the toolchain. &#4294967295;My DRAM problem from a >> month ago, Xilinx ultimately told me was my problem and they washed >> their hands of it. > >Anyone else notice that they seem to have dropped the memory >controller block (MCB) from the X7 product lineup? Not a great vote of >confidence for the current Spartan-6 implementation. >
We have a DDR2 ram interfaced to a S6/45. We can't get it to work. John