cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
1,196 Views
Registered: ‎01-27-2016

Remote configuration of SPI flash- how to tri-state Artix 7

We would like to be able to reprogram our SPI flash using the SPI port of an external processor. The SPI flash(s25fl256s) is currently connected to our Artix 7 xc7a75t device so that we can configure the FPGA on power up from the flash in SPIx4 mode.

My question is how do I get the Artix 7 device to tri-state the pins that are connected to the SPI flash. We are pulling down the PROG_B line, however this does not appear to tri-state the pins so that the other SPI master from our external processor can control the SPI bus.

I have read through the ug470 document, but I cannot find the answer to my question. Thanks for your help.

 

 

Bill

0 Kudos
18 Replies
Highlighted
Teacher
Teacher
1,188 Views
Registered: ‎07-09-2009

The IO pins are put into the state defined by the PUDC_B pin ( pull up or floating )

page 27 https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf

having said that, I'd have assumed the Programer would over power the FPGA pull ups...

 

One thought , prog_b is an edge sensetiv esignal, it can no tbe used to hold up the fpga ocnfiguratoin,

so Im wondering , are you also controling the init_b . to hold off the fpga starting to try to configure ?

 

Out with scope, see what you have on the SPI pins to the flash.

 

Assuming you have the fpga conected to JTAG, you can program the flash via JTAG using the stadard Vivado programming tools . That should prove that the SPI / Flash path can work.

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Participant
Participant
1,133 Views
Registered: ‎01-27-2016

Thanks for your response. We can program the fpga via the jtag and can also indirectly program the flash via the JTAG with the Vivado tools so the connections seem to be correct.

The issue is we want to be able to remotely reload the SPI flash directly via a SPI bus from a processor.

We have tried pulling both the PROG_B and INIT_B lines low, but when we look at the SPI pins on the FPGA they appear to be oscillating.

0 Kudos
Highlighted
1,116 Views
Registered: ‎10-23-2019

I am a collegue of 'centercitybill' working on the same issue.

1. You said "The IO pins are put into the state defined by the PUDC_B pin"
And docs say "Active-Low PUDC_B input enables internal pull-up resistors on the SelectIO pins after power-up and during configuration".
Are the SPI configuration pins 'SelectIO' pins? I wasn't sure if that is talking generally about IOs on the chip, and/or the dedicated configuration SPI pins. But I agree with you the driving microprocessor should be able to over power the FPGA pull ups regardless.

2. "are you also controling the init_b"? 
From a powered on and running state we ground both PROG_B and INIT_B. I can see the FPGA goes into 'reset/not configured' state (and does correctly return to normal function once those signals are released).

3. "you can program the flash via JTAG using the stadard Vivado programming tools . That should prove that the SPI / Flash path can work."

As centercitybill said, we do exercise this path and have confirmed it works fine (no microcontroller connected to SPI bus at that time). We cannot physically acess the FPGA in order to connect JTAG cables in the production environment so we want to be driving the flash SPI bus directly. We just need the FPGA to get off the bus, tristate its pins. We know the micro can drive SPI correctly.

4. It should be noted that our FPGA configuration mode pins are set to M[2:0]=001 Master SPI mode. This is so the FPGA can be SPI master when readings its configuration from flash. Currently we cannot change this setting (i.e. to Slave or JTAG mode) since it requires physical access to the FPGA which we do not have in production. Is it possible that we will need to have the micro driving these mode signals as well as PROG_B+INIT_B?

5. "Out with scope, see what you have on the SPI pins"
I scoped the chip select (CS) and clock (CLK) pins to start.

When the micro is idle (no active SPI transfer occuring) things look reasonable:
CLK = constant LOW ~500mV (probably being weekly pulled up?)
CS = constant HIGH 3.3V

But when the micro goes to drive the SPI bus everything breaks:

CLK = Garbage signal barely resembling square wave

CS is even weirder - strange rapid oscilating between 0-3.3V

Screenshot from 2019-10-23 09-45-44.png


This bad behavior on the CLK and CS pins continues until I physically disconnect the CS signal from the micro.

So it really seems like FPGA is still driving signals onto the SPI bus.
How can we ensure all of the FPGA SPI signals are tristated?

Thanks

0 Kudos
Highlighted
Teacher
Teacher
1,103 Views
Registered: ‎07-09-2009

Ill double check,

But a few things

 

the 500 mV on the clock is WRONG.

   If it was pulled up by the FPGA it would be at 3v3,

      Im assuming the micro is off the bus at this point ?

 

You are waiting for power to come up before you take prog_b and init_b low ?

 

Good point about the FPGA pins, in SPI maste rmode, are they tri stated when prog_b / init_b are low ?

 

Good to se ethat you can access the SPI from the JTAG / FPGA ,  it proves that you have a good JTAG and you have a good SPI / flash conection, its not a miss wried thing.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
1,085 Views
Registered: ‎10-23-2019

"the 500 mV on the clock is WRONG."
I'm not sure whats going on here. The micro is not actively doing a SPI transfer. I don't know if that means it is tri-stating its SPI signals or driving them with inactive values (CS high, clock not switching). If I physically disconnect the micro from the shared SPI bus I see the micros SPI clock is low exactly 0.0V  (tristated or driven low idk?). On the FPGA side, it is powered up and in a funcitonal state, I then ground PROG_B and INIT_B. At this point, with the micro still disconnected, I see that the FPGA the FPGA's SPI clock is high 3.3V.

It is when I make the SPI bus connection that I see the, now shared, SPI clock signal hovering at ~500mV.

Looks like the FPGA wants a idle HIGH clock and micro wants idle LOW clock? What I really need is for the FPGA to tri-state its clock output and allow micro to drive.

You are waiting for power to come up before you take prog_b and init_b low ?

Yes, as mentioned above, the FPGA/board is up and running fine before I then ground PROG_B and INIT_B.

Good point about the FPGA pins, in SPI maste rmode, are they tri stated when prog_b / init_b are low ?
I don't know. They don't seem to be tristated since I am having trouble driving those signals...
FPGA SPI clock is high. Is that driven high? Or pulled high as per 'pull up during configuration' (PUDG_B) pin? If its pulled high that should be workable. But if the FPGA is driving high thats a problem.


Again, coming back to the primary issue:
With the FPGA in SPI master mode M[2:0]=001, how can I tri-state/highZ the SPI signals coming out of the FPGA (CCLK,FCS_B, MOSI)? So far PROG_B and INIT_B don't seem to do it.

0 Kudos
Highlighted
Teacher
Teacher
1,078 Views
Registered: ‎07-09-2009

Agree thats your primary problem, you cant seemto program the spi with the micor and the fpga connected.

were just trying to debug the cause , since I dont have the board here, Im having to guess what it could be, as I have used what sounds very similar to what you have myself and it work'd, which makes me wonder abotu the micor , but I'm open to othe rideas.

interesting that with no micro conected, the voltages go correct.

Do you have external pull up on the CS line ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
1,068 Views
Registered: ‎10-23-2019

Yes the CS line has external pull ups.


Regarding pull ups - with PROG_B and INIT_B grounded the only signals coming out of the FPGA should be 'pulled' defaults, correct? The FPGA should not be driving, high or low, any signals during this time? Can you confirm that as correct?

If the FPGA is just pulling signals (be that internal or external) then it seems like there should be no problem with the micro on the bus driving those signals as it pleases. Is it possible that the combination of an FPGA external pull up and default internal pull up (PUDC) could together be 'pulling strong enough' as to stop the micro from driving the signal?

0 Kudos
Highlighted
Teacher
Teacher
1,052 Views
Registered: ‎07-09-2009

regarding one thing
the fpga pull ups are very high resistance,
https://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf
page 3, has Rupd in the range of uA, which is 10's of Kohm equivilent,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Teacher
Teacher
1,049 Views
Registered: ‎07-09-2009

regarding the IO pins used in SPI configuration

Ive been reading up on this

http://ece-research.unm.edu/pollard/classes/595/ug470_7Series_Config.pdf

page 20 shows that the SPI data pins are GPIO once configured,and the cclk is a configuration dedicated pin.

 

it was the clock I think you had problem with ?  ( sorry on tablet, cant in reality open many screens to look back once Im tying an answer )

we have this statment on page 12.

"• In Master configuration modes, the 7 series device drives CCLK from an internal
oscillator. To select the desired frequency, BitGen -g ConfigRate option is used.
The BitGen section of the Command Line Tools User Guide provides more information.
After configuration, the CCLK is turned OFF unless the persist option is selected or
SEU detection is used. The CCLK pin is 3-stated with a weak pull-up."

 

And this seems to be on the right track

 

https://www.xilinx.com/support/answers/51473.html

 

which seems in bitgen you need to specify "Bitgen -g persist:no" , else the clock pin will keep being a clock output as you have seen, 

 

Im betting that in bit genthe default is "Bitgen -g persist:yes"

If I rember , this is an option on vivado , right click on the options to see them, 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
1,026 Views
Registered: ‎10-23-2019

I came across the "CCLK is turned OFF unless the persist option is selected" in bitgen as well.

I didn't think it was relevant in my particular case since we are grounding PROG_B and INIT_B. I didnt think anything from the bitstream, like the persist option, would still be in effect within the FPGA.

Now that you mention it, I think its still worth try next time I'm in the lab. Maybe I don't even need to take the FPGA down if it deactivates the SPI interface after config anyway?

Willl follow up. Thanks.

0 Kudos
Highlighted
963 Views
Registered: ‎10-23-2019

Regarding bitstream/device properties:
First off, this is with the FPGA up and running. PROG_B and INIT_B are NOT grounded.

PERSIST: 
I have been building with configuration pins PERSIST=NO. Meaning that "CCLK is turned OFF" after configuration.

CCLK Pin Pull: I had been building with this set to PULLUP. Meaning that CCLK is pulled up after configuration is complete.

This seems to match what I had been seeing: Scoping the FPGA's CCLK I saw a constant HIGH. The micro idles with a constant LOW clock. When I physically connect the micro's clock to the FPGA/flash SPI clock I see that ~500mV clock signal which you said was wrong. FPGA is pulling HIGH while micro is driving LOW maybe?


I then changed the CCLK pin pull setting and rebuilt the bitstream.
CCLK Pin Pull = PULLNONE. Meaning that CCLK is floating/not pulled after configuration is complete.

Now when I scope the clock on the micro and the FPGA I see the same constant LOW 0.0V. Then when I physically connect the micro's clock to the FPGA/flash SPI clock I see a constant LOW 0.0V (instead of incorrect ~500mV).

I feel confident that the FPGA is not driving CCLK after configuration. The micro has no problem driving the clock as needed.


It should be noted that, if I do ground PROG_B and INIT_B, as I expected, the bitstream configuration saying "CCLK Pin Pull = PULLNONE" is lost and the clock again is default pulled high (probably because of  pull up during config PUDC pin?). Again, when FPGA and micro clocks are connected I see the ~500mV on the clock line.

0 Kudos
Highlighted
958 Views
Registered: ‎10-23-2019

I want to follow up on the state of the FPGA's chip select FCS_B signal. Again, this is after the FPGA has been configured. PROG_B and INIT_B are not grounded in this case since I am experimenting with bitstream config properties.

Idling with the micro and FPGA disconnected I see:
FPGA FCS_B = HIGH 3.3V
Micro CS = HIGH 3.3V
Which is correct for an idle SPI bus active low CS.

As mentioned, I know the micro's SPI bus works fine. Disconnected from FPGA, during a SPI transfer, micro's CS goes LOW as expected for a while and then returns to HIGH.


However, when I physically connect the micro's CS and the FPGA's FCS_B I see some strange behavior. 
Inactive,idling looks fine. CS is HIGH 3.3V as expected.
However, when the micro goes drive CS low I see that CS never actually gets to 0.0V. Instead I see CS drop from 3.3V down to ~ 1.3V and then return to 3.3V. Seems like the FPGA is stopping the micro from driving all the way to 0.0V?

Is there any control over the behavior of the FPGA's FCS_B pin after configuration like there was for CCLK?
I want to tristate/pull-none the FCS_B pin like I did for CCLK.

Highlighted
Teacher
Teacher
937 Views
Registered: ‎07-09-2009

I honestly think you are more of an expert than me
Im now interested in what you find,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
928 Views
Registered: ‎10-23-2019

We are now pursuing other configuration options.

I have yet to find the answer to this question:

With the FPGA set to Master SPI mode M[2:0]=001, how can I tri-state all of the FPGA's SPI configuration pins (CCLK, FCS_B, MOSI, DIN(MISO)) such that a separate SPI master can use the bus?

CPU (master) ----\/
                             |
FPGA (master) ---*--- > Flash (slave).


I am now investigating what control the 'user' FPGA logic has over the SPI flash pins after configuration in order to recreate something like the typical JTAG->FPGA->Flash indirect programming flow.

0 Kudos
Highlighted
910 Views
Registered: ‎01-22-2015

@juliandeepwave 

I am now investigating what control the 'user' FPGA logic has over the SPI flash pins after configuration in order to recreate something like the typical JTAG->FPGA->Flash indirect programming flow.

Sorry that I can’t answer your original question about sharing the Flash SPI interface with the FPGA.  However, I think that your SPI sharing is an uncommon approach to the FPGA configuration problem.   I encourage you to look at the more common approaches – as you are doing.

One common approach that might accomplish other things you are trying to do is called the Slave Serial mode described by Fig 2-2 of UG470. 
Slave_serial_mode.jpg

In this mode you send the .bin configuration files directly to the microprocessor, which then writes them to the flash over its dedicated SPI connection to the flash.  Then, at power-up of the board, the microcontroller selects one of the .bin files found in the flash and writes it to the FPGA.  I have often thought Slave Serial mode to be one of the best configuration modes – because of the flexibility associated with the microcontroller and the fact that you are not tied to a specific, Xilinx-approved flash.  That is, you can use any flash that you can make your microprocessor talk with.  Being flash-flexible was a big deal a few years ago when flash manufacturers where not keeping up with demand and 6-month lead times for a flash purchase were common.  For this approach you’ll need a separate communications interface that allows you to send .bin files to the microprocessor – perhaps a simple serial interface that goes to an Ethernet-to-serial convertor (eg. Lantronix’s XPORT).   Using such an interface would allow remote update of the FPGA configuration – very cool!

Another approach is to stay with Master SPI Configuration mode (see Fig 2-12 of UG470) but use some method to send the .bin file into the FPGA which then writes the .bin file to flash (as you suggested).  Using the FPGA to write the .bin file to flash is not too tricky.  After the FPGA is configured and running, all the interface lines between the flash and the FPGA shown in Fig 2-12 of UG470 can be accessed by the HDL you have written.  The only tricky part is that the CCLK line must be accessed indirectly via the STARUPE2 primitive (see page 592 of UG953(v2019.1)).  You have choices for getting the .bin file into the FPGA.  You could use a simple serial connection to the standard IO pins of the FPGA.  This serial connection could come from the ethernet-to-serial converter that I mentioned above – again, giving you the capability to remotely update the FPGA configuration.  

Be sure to also look at Multiboot (Chapter 7 of UG470) if you are going to do remote update of the FPGA configuration.  With Multiboot, you can fallback to a known good configuration automatically if your remote update of the configuration fails.

So, there’s some ideas for you.  You’ll need lots of code to make it all work.  Although, you might find some Xilinx IP that saves you from writing all the code yourself.

Cheers,
Mark

Highlighted
903 Views
Registered: ‎10-23-2019

No worries - I agree it appears to be an uncommon approach.

Slave Serial I wanted to try. And then found out the M[1] mode pin is pulled down on my board. Was about to rip out the resistor to allow internal pull up to work but now considering custom indirect programming in master spi mode as something to try first.

Everything you said about master spi mode is a huge relief. I was really hoping it could be done as you described. Now to do it :)

Thanks man

0 Kudos
Highlighted
882 Views
Registered: ‎10-23-2019

For some future soul to try (hopefully not me in several days) if indirect programming isn't an option:

If we really can control the SPI bus from user HDL after configuration then perhaps we can manually instatiate some kind of tristated IOBUF to drive pins like FCS_B?

0 Kudos
Highlighted
824 Views
Registered: ‎01-22-2015

@juliandeepwave 

…perhaps we can manually instatiate some kind of tristated IOBUF to drive pins like FCS_B?

Table 2-4 in UG470 lists all the FPGA pins used during configuration of the FPGA.  These pins have two types:  dedicated or multi-function.  When the pin has type=multi-function then your application can use the pin as standard IO after FPGA configuration is complete.  The FCS_B is a multi-function type pin.  So, your application can specify FCS_B to have an IBUF, OBUF, or IOBUF.

…which gets us back to your original idea of having the microprocessor and FPGA share the flash SPI bus.  If you specify FCS_B to be an input (have an IBUF) then your microprocessor can drive FCS_B after the FPGA is configured !

However, Table 2-4 of UG470 says CCLK is a “dedicated” pin, which means your application is restricted when it comes to using this pin after FPGA configuration is complete.  As I mentioned previously, your application can toggle CCLK indirectly by using the STARTUPE2 primitive – but that is (perhaps) all the control you have over CCLK.  This could be a bummer for your original shared-SPI idea because this could mean that your microprocessor might not be able to drive CCLK.  However, the lab testing you reported suggests that the Artix-7 has automatically specified CCLK to be an input after configuration (Master-SPI mode) is complete.  So, it seems that your microprocessor can drive CCLK !

So, maybe your original shared-SPI plan will work after all.  That is, in your application, you can specify that all FPGA connections to the flash are to be inputs – and you can hope that the FPGA continues to automatically configure CCLK as an input after configuration.  Then, after FPGA configuration, your microprocessor should have full control of the flash SPI bus.