Config Spartan3 in serial slave mode

Hi,

I have a design where a Spartan XL was replaced by a Spartan 3. The FPGA is configured by an ATmega MCU which loads the configuration file into the FPGA. This procedure works fine with the old board and the Spartan XL, but with the Spartan 3 I have the trouble that I never get the DONE signal, after the configuration is done.

I see data going over the DIN line into the Spartan 3 and an active clock signal. As I did not change anything on the ATmega software this should be fine.

I generated the binary for the Spartan 3 and enabled the setting for "Drive DONE Pin High", to have the DONE signal being driven.

As the ATmega uses 3.3V the Spartan is used in the 3.3V compatibility mode for configuration. I am just not sure about the VCCO_4 signal, as the data sheet is for my understanding a bit confusing. In the design that I am using it is tied to 3.3V. Is that correct or does it need to be connected to 2.5V during configuration?

Is there anything else I need to consider with the serial slave mode when switching from Spartan XL to Spartan 3?

Thanks for the help.

Guenter

Reply to
Guenter Dannoritzer
Loading thread data ...

Uzytkownik "Guenter Dannoritzer" napisal w wiadomosci news:coggir$g8a$00$ snipped-for-privacy@news.t-online.com...

see if CCLK is present when the last byte was sent to fpga.

krzysiek

Reply to
Krzysztof Szczepanski
[snip]

Do I have to add some CCLK cycles after I have sent the last data? I recognized there are a bunch of new settings in the ISE6.3 in comparison to the 4.1 which I used for the Spartan XL.

The ATmega code applies the data, creates a rising edge for the CCLK and in the next loop toggles the CCLK.

I have to check whether there is a falling edge after the last data bit is applied, at least it has a rising edge.

The same code worked fine with the Spartan XL. Is there a differenc with the Spartan 3?

Guenter

Reply to
Guenter Dannoritzer

Try it. Faster than waiting for answers from a newsgroup.

There have been (many?) problems in that area. A few extra clocks won't cost much.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

When you find out the answer please post a reply to the group. I am facing the same problem. I am trying to configure the digilent spartan-3 board using slave serial mode using a USB controller. The same setup works for a spartan-II but not for spartan-3. I already tried adding extra clocks. That did not help.

Sumit sumit snipped-for-privacy@nojunk.c-nit.net

Reply to
Sumit Gupta

One trick in this area...

If the chip you are trying to program is daisy chained to another chip, you can program the pair of them from one serial data stream.

The first chip will eat the bits it needs, then pass the others. So set things up to pretend there is a chip down there. Program it too, and see if any bits come out. Compare when they start coming out with when you expect them to...

I haven't had to do any work in this area for many years. In the old days, the data book description was all there after you had read it a few times.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

Have you monitored the INIT line? I belive it will go low if there is an error during configuration. If not, and DONE is not high, then likely you have not sent enough data or clocks or both.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

OK I found the problem in my case. The USB controller pin which connects to CCLK of FPGA, also connects to a user I/O pin of the FPGA. I had this so that the USB controller could talk to the FPGA after configuration and it was working for spartan-II becasue I guess that user I/O pins are floating till the configuration completes. But in case of spartan-3, the logic on these pins during configuration is controlled by the HSWP_EN pin of the FPGA. The digilent board ties this pin to GND thus making the user I/O pins to be pulled up to VCCO. This was hurting cclk and the configuration. I rewired the connections a little bit differently and its now working.

Sumit

Reply to
Sumit Gupta

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.