UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
8,530 Views
Registered: ‎05-24-2013

Weird Problem with SPI based on Design Goal Choice

Jump to solution

Hello, 

 

I am working on an image sensor with registers interfaced through SPI. I am getting a 100 MHz clock from the clock generator and reducing it to 12.5 MHz to feed the sensors SPI CLK. Now my problem is, if I set the "Design Goal" to "Area Strategy 1", I get wrong values readback from the sensor(bits toggle and produce wrong values). However if I set the "Design Goal" to "Timing Performance with IOB Packing", everything is fine. I can read and write to SPI without a problem.

 

Now I suspect that the clock behaviour changes based on which strategy I have choosen. The question is, what is different between these two strategies that it leads to such functional difference?

 

I am working with ISE 14.7 on a Spartan 6 FPGA.

 

Thanks&Regards,

Berk 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
16,527 Views
Registered: ‎05-24-2013

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

Anyway, adding KEEP attribute to the clock register solved the issue. I verified in FPGA Editor as well, that now the output buffer is placed correctly. But still any explanations for this behaviour would be appreciated.

5 Replies
Community Manager
Community Manager
8,480 Views
Registered: ‎06-14-2012

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

This might be related to a specific switch rather than entire Design goal. You can investigate that by going to the Implementation properties. Thats how we debug this further.

This seems a corruption or incorrect logic case which would be a potential bug.

It may be related to the IOB register packing.(Guess!)

 

As you have a workaround with Design goal as Timing performance, you can continue with the same as you ahve also functionally verified your design. I would also recommend to do a HW validation before freezing this as a workaround.

 

Regards

Sikta

 

 

0 Kudos
Adventurer
Adventurer
8,473 Views
Registered: ‎05-24-2013

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

Thanks for the answer. I checked the hardware and it looks ok.

 

I looked at the switches on both projects. There are 3 differences and all of them are in XST:

 

1) Optimization Goal: Speed (Good) vs Area (Bad)

2) Optimization Effort: High (Good) vs Normal (Bad)

3) Register Balancing: Yes (Good) vs No (Bad)

 

But sadly, I do not have an explanation for this. To me, both option sets should act functionally identical or am I mistaken? Could it be that more stable clock edges are produced when I decide to go with the speed path?

0 Kudos
Adventurer
Adventurer
8,460 Views
Registered: ‎05-24-2013

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

I found the problem by looking at the designs in the FPGA Editor. SPI CLK is responsible for this malfunctioning. 

On the bad design, the signal is not placed into an output buffer before driving the pin:

 

SPI_Bad.PNG

 

On the good design, it is placed properly:

 

SPI_Good.PNG

 

The question is, why it is not getting mapped into an Output buffer? I have the option "Pack I/O Registers into IOBs" set to true. And I also do not see any warning in the reports which state that any of the register have been removed. Do I have to instantiate them manually? Even in that case isn't there something wrong with that, since the tools should do this automatically?

0 Kudos
Adventurer
Adventurer
8,449 Views
Registered: ‎05-24-2013

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

Looking at the synthesis report, I found something like this:

 

INFO:Xst:3226 - The RAM <Mram_i[5]_X_26_o_Mux_6_o> will be implemented as a BLOCK RAM, absorbing the following register(s): <spiclk_r>
    -----------------------------------------------------------------------
    | ram_type           | Block                               |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 8-word x 1-bit                      |          |
    |     mode           | write-first                         |          |
    |     clkA           | connected to signal <clk>           | rise     |
    |     enA            | connected to internal node          | low      |
    |     weA            | connected to signal <GND>           | high     |
    |     addrA          | connected to signal <(i<5>,i<1:0>)> |          |
    |     diA            | connected to signal <GND>           |          |
    |     doA            | connected to signal <spiclk_r>      |          |
    -----------------------------------------------------------------------
    | optimization       | area                                |          |
    -----------------------------------------------------------------------

So the register spiclk_r which drives the clock Pin is realised as a BRAM instead of LUTs. But still, why is this keeping the tool from placing an output buffer? Is it a general rule that BRAMs driving the outer world pins will not be routed through an output buffer?

0 Kudos
Highlighted
Adventurer
Adventurer
16,528 Views
Registered: ‎05-24-2013

Re: Weird Problem with SPI based on Design Goal Choice

Jump to solution

Anyway, adding KEEP attribute to the clock register solved the issue. I verified in FPGA Editor as well, that now the output buffer is placed correctly. But still any explanations for this behaviour would be appreciated.