Xilinx Spartan 3 configuration

R

rickman

Guest
I am looking at the data sheet for the Spartan 3 parts trying to figure
out how to configure them. It seems like it is the same as most of the
other families, but there is one note that I don't completely
understand. Section 3, page 12, has the following text...

Figure 5: Waveforms for Master and Slave Parallel Configuration
Notes:
1. In a given CCLK cycle, when RDWR_B transitions High or Low while
holding CS_B Low, the next rising edge on the CCLK pin will abort
configuration.



This is not exactly the same as XAPP176 describing the Spartan II
configuration, page 14...

While CS is High, the Slave Parallel interface does not expect any data
and ignores all CCLK transitions. However, WRITE must continue to be
asserted while CS is asserted. If WRITE is High during a positive CCLK
transition while CS is asserted, the FPGA aborts the operation.



In the first case it sounds as if the abort condition is created by CS-
being low and an edge on the RDWR- signal followed by a rising edge on
CCLK (without making it clear if this also has to be during CS- low).

In the second case, it is just the state of the two signals, sampled at
the rising edge of CCLK which will create an abort.

If I am trying to use the CS- WR- and IO signals from an MCU to control
this, the difference between these two descriptions is significant. Am
I making this more difficult than it is? Can I connect the signals as
shown below and make this work ok?

MCU FPGA Write NO
--- ---- Byte Write
CS- RD_WR- ----_______------______---
WR- CCLK -----_____--------____----
IO CS- -_____________------------


The other thing I am not clear about is how to use these same signals
after configuration. It looks like I have to set "persist" to off if I
want to put these signals on the MCU bus after config in order to have a
bus interface to the chip. But if I want to perform partial
reconfiguration, I think I have to have "persist" set to on, no? Does
this mean I will have to double up on all these signals, one for
(re)configuration and one for operation?

I seem to recall that the Lucent chips allowed you to use the MCU
interface after configuration. Do the Xilinx chips have that as well?

--

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
 
Rick,

abort happens asynchronously (doesn't need to see CCLK rising edge for
it to take place). And to avoid this, CS must be deasserted first.

The data pins will be asynchrounously driven by the FPGA with the
WRITE_B changes to high, but the status words (cfgerr_b, dalign, rip,
in_abort_b, 4'b1111) is clocked out to data pin [7:0] by CCLK

Regards, Wei

rickman wrote:
I am looking at the data sheet for the Spartan 3 parts trying to figure
out how to configure them. It seems like it is the same as most of the
other families, but there is one note that I don't completely
understand. Section 3, page 12, has the following text...

Figure 5: Waveforms for Master and Slave Parallel Configuration
Notes:
1. In a given CCLK cycle, when RDWR_B transitions High or Low while
holding CS_B Low, the next rising edge on the CCLK pin will abort
configuration.



This is not exactly the same as XAPP176 describing the Spartan II
configuration, page 14...

While CS is High, the Slave Parallel interface does not expect any data
and ignores all CCLK transitions. However, WRITE must continue to be
asserted while CS is asserted. If WRITE is High during a positive CCLK
transition while CS is asserted, the FPGA aborts the operation.



In the first case it sounds as if the abort condition is created by CS-
being low and an edge on the RDWR- signal followed by a rising edge on
CCLK (without making it clear if this also has to be during CS- low).

In the second case, it is just the state of the two signals, sampled at
the rising edge of CCLK which will create an abort.

If I am trying to use the CS- WR- and IO signals from an MCU to control
this, the difference between these two descriptions is significant. Am
I making this more difficult than it is? Can I connect the signals as
shown below and make this work ok?

MCU FPGA Write NO
--- ---- Byte Write
CS- RD_WR- ----_______------______---
WR- CCLK -----_____--------____----
IO CS- -_____________------------


The other thing I am not clear about is how to use these same signals
after configuration. It looks like I have to set "persist" to off if I
want to put these signals on the MCU bus after config in order to have a
bus interface to the chip. But if I want to perform partial
reconfiguration, I think I have to have "persist" set to on, no? Does
this mean I will have to double up on all these signals, one for
(re)configuration and one for operation?

I seem to recall that the Lucent chips allowed you to use the MCU
interface after configuration. Do the Xilinx chips have that as well?
Click to expand...
 
Chen Wei Tseng wrote:
Rick,

abort happens asynchronously (doesn't need to see CCLK rising edge for
it to take place). And to avoid this, CS must be deasserted first.

The data pins will be asynchrounously driven by the FPGA with the
WRITE_B changes to high, but the status words (cfgerr_b, dalign, rip,
in_abort_b, 4'b1111) is clocked out to data pin [7:0] by CCLK

Regards, Wei
Click to expand...
I just want to make sure I understand this correctly. I belive what you
are saying is that the Spartan 3 data sheet is correct and xapp176 is
not correct and this section should be ignored, right?

What did I miss? Does xapp176 only apply to the Spartan II and the
Spartan 3 has changed? I have gone back over xapp176 and it describes
in great detail how these controls work.

"WRITE may be de-asserted and re-asserted as many times as necessary,
just as long as it is Low before the next rising CCLK edge."

However, I must say I still have not figured out how to connect the FPGA
to a CPU data bus without a CPLD in between.

--

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
 
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>...
However, I must say I still have not figured out how to connect the FPGA
to a CPU data bus without a CPLD in between.
Click to expand...
Why? What's the issue here?

Jake
 
Jake Janovetz wrote:
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>...
However, I must say I still have not figured out how to connect the FPGA
to a CPU data bus without a CPLD in between.

Why? What's the issue here?
Click to expand...
I want to find a way to connect this programming interface directly to
the CPU as if it were a peripheral device. So far I have not figured
out a way to do that.

Most CPUs provide a WR- signal that changes *within* the CS- being
active. So that would trigger an abort if connected directly. Further,
there is no signal equivalent to the CCLK coming from an MCU.

I also don't understand what Chen meant by having to clock out the
"status words" with CCLK. I have been reading XAPP176 which applies to
Spartan II since I don't see a similar document on the Spartan 3. I
don't see where reading "status words" is discussed. I also don't see
this in the Spartan 3 data sheet

But I can say I have finally figured out the documentation on the bit
stream format. Maybe it is just me, but I find the Xilinx documentation
on configuration is very cryptic. I had to read and reread that section
over a dozen times to finally understand all the difficult parts.

I also want to have my FPGA design be able to use this same interface,
but not give up partial reconfiguration. At this point I am pretty sure
the only way to map my FPGA design to the CPU bus and still retain the
ability for partial reconfiguration is to have *two* separate interfaces
on the FPGA. So I will have to have two sets of data bus pins and two
sets of WR-, CS-, etc on the FPGA.


--

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
 
Rick,

Abort status words get clocked out after Abort. I've also sent you a
seperate e-mail on this.

Regards, Wei

rickman wrote:
Jake Janovetz wrote:

rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>...

However, I must say I still have not figured out how to connect the FPGA
to a CPU data bus without a CPLD in between.

Why? What's the issue here?


I want to find a way to connect this programming interface directly to
the CPU as if it were a peripheral device. So far I have not figured
out a way to do that.

Most CPUs provide a WR- signal that changes *within* the CS- being
active. So that would trigger an abort if connected directly. Further,
there is no signal equivalent to the CCLK coming from an MCU.

I also don't understand what Chen meant by having to clock out the
"status words" with CCLK. I have been reading XAPP176 which applies to
Spartan II since I don't see a similar document on the Spartan 3. I
don't see where reading "status words" is discussed. I also don't see
this in the Spartan 3 data sheet

But I can say I have finally figured out the documentation on the bit
stream format. Maybe it is just me, but I find the Xilinx documentation
on configuration is very cryptic. I had to read and reread that section
over a dozen times to finally understand all the difficult parts.

I also want to have my FPGA design be able to use this same interface,
but not give up partial reconfiguration. At this point I am pretty sure
the only way to map my FPGA design to the CPU bus and still retain the
ability for partial reconfiguration is to have *two* separate interfaces
on the FPGA. So I will have to have two sets of data bus pins and two
sets of WR-, CS-, etc on the FPGA.
Click to expand...
 
rickman <spamgoeshere4@yahoo.com> wrote in message news:<40476B76.3E2C7BC8@yahoo.com>...
I want to find a way to connect this programming interface directly to
the CPU as if it were a peripheral device. So far I have not figured
out a way to do that.

Most CPUs provide a WR- signal that changes *within* the CS- being
active. So that would trigger an abort if connected directly. Further,
there is no signal equivalent to the CCLK coming from an MCU.
Click to expand...
Oh, an asynchronous bus interface. Yeah, that would be a bit more
difficult.

But I can say I have finally figured out the documentation on the bit
stream format. Maybe it is just me, but I find the Xilinx documentation
on configuration is very cryptic. I had to read and reread that section
over a dozen times to finally understand all the difficult parts.
Click to expand...
The only funny stuff I've run across is documented in App502. Bit
ordering on the D0..D7 bus (taken care of on-board -- who calls D0
MSB???) and the search for the 0xFF start codes in the .bit file.
Though, admittedly, I haven't done partial reconfig.

I also want to have my FPGA design be able to use this same interface,
but not give up partial reconfiguration. At this point I am pretty sure
the only way to map my FPGA design to the CPU bus and still retain the
ability for partial reconfiguration is to have *two* separate interfaces
on the FPGA. So I will have to have two sets of data bus pins and two
sets of WR-, CS-, etc on the FPGA.
Click to expand...
Yeah, there doesn't appear to be a 'selectMAP select' pin, eh?

Jake
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top