configuration SRAM cells in Xilinx/Altera FPGAs

Hello everybody,

I am not new to the world of FPGAs but have not found enough literature regarding the SRAMs used for configuration. I need some inputs, help or pointers(papers, articles) from the FPGA community regarding these. There are very few literature relating to this(May be I am not looking in the right places).

  1. Are these SRAM cells arranged in a big nxn array like normal SRAM memory, or they are in small chunks of memories distributed all over the FPGA layout.

2.Are they physically placed adjacent to their corresponding CLB/Switch boxes.

  1. As interconnects are fixed after configuration i guess they should always be read only mode, hence should be different from LUTs SRAM cells.

Your inputs will really be helpful to me.

regards

--raj

Reply to
raj
Loading thread data ...

Physically they are scattered all over the chip. Each bit of memory controls a single transistor or mux input in the chip. The (pass) transistors are used to control routing or are used in the LUT ram mux. The muxes are used inside the logic elements to connect different inputs and outputs to provide the exact configuration of logic and FFs that you need.

Yes, or even integrated.

In reality they don't typically distinguish between routing and LUT config memory. Both can be read back. This is useful for high reliability systems where the device is read back to verify the configuration has not changed due to electrical noise and/or radiation.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Thanks Rick for your inputs. Can you suggest some pointers regarding these?

--raj

Reply to
raj

I'm not sure what you mean by pointers. If you mean references, then I could recommend the data sheets. But most of what you are asking about is not needed to use the chips, so it is not talked about a lot. The readback operation is discussed in app notes mainly. Check the Xilinx and Altera web sites for app notes on your topic. Also, if you can get your hands on a paid copy of the Xilinx software, they have a chip level editor that shows a pretty accurate layout of the chip. But even this will not really show you details of the config memory, it is just assumed to be there and work invisibly.

raj wrote:

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Have a look at a similar reqest and my response at:

formatting link

There is a wealth of detailed info available at

formatting link
for example patent 4,870,302 would be a good place to start.

start here:

formatting link

Others that might interest you include:

5631577 5598424 5742531 5995988

Philip Freidin

=================== Philip Freidin snipped-for-privacy@fpga-faq.com Host for

formatting link

Reply to
Philip Freidin

Rick,

I know you are referring to FPGA_Editor.

FPGA_Editor is a software view of the part function, and really has very little to do with the hardware....

Many make the mistake of assuming that the hardware looks just like the editor view (internally here at Xilinx those not in IC design), and find out later that it is a fantasy perpetrated by the software group to represent the actual functionality at a level that is easy to deal with, and understand.

Aust> I'm not sure what you mean by pointers. If you mean references, then I

Reply to
Austin Lesea

I haven't used the tool in a few years, but if it is not close to the hardware, then it is way more complex looking than it needs to be. I have had to do a few hand routes and it is a real PITA to try to understand anything about how the routing works by looking at the graphical view. I am sure a more schematic method of showing the interconnects would been more useful and perhaps easier to develop and maintain.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Rick,

And thus the battle is joined.....again

Yes, well, we have only been at this for twenty years now, and we are still refining the whole process. Routing by hand is a pretty useful thing to know (when all else fails, or there is something that just has to be done a certain way), but it is also something that leads to the longest time to market, so it naturally does not get much attention (why should it, when it delays the sale of a part?).

One issue in making FPGA_Editor look like the hardware schematic, is that we have to make the hardware view match the software view.

I know, radical.

Hardware vs. Software.....

Aust> Aust>

Reply to
Austin Lesea

That rational actually makes no sense. If I could get a given product to market without hand routing, I would. I only use the chip editor when it is absolutely required. I don't need any encouragement from tools that are hard to use.

The most recent example I can remember is a very short path from one pin to another for muxing a clock and sending back out of the chip. I needed a total delay below a specific number which was possible within the chip, but the tool would not use the fastest route. The pinout had been picked to optimize this, but the standard tool got in the way. So every time I routed the design, I had to tweek that one route in the chip editor regardless of the time to market impact. Besides, the time to market is fixed... my overtime is not. I'd rather spend a few extra minutes every time I do a route than fight a tool for weeks.

So how would that make it different? The software view is *very* abstract. The view in the chip editor contains lots of eccentric twists and turns in routes with little info on what can connect to what. I fail to see how that *matches* the software.

This is the sort of comment that you can leave out if you are trying to communicate. I have no idea what you are trying to say, just that you are being sarcastic.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Rick,

There is nothing I can say to you to that seems to explain anything at all, so I will stop now (trying to explain why the software and hardware differ in their view of the chip).

No sarcasm whatsoever.

Hand tweaking an occasional path is just what FPGA_Editor does best, so I am glad it is useful in your designs.

I am surprised that you could not get the same results by using a local constraint, but then, I have already stated I am not a software expert.

They do a wonderful job of addressing software bugs, however.

Aust> Aust>

Reply to
Austin Lesea

(SNIP)

Hi Rick,

If as you say, you haven't used FPGA Editor in a few years, then you haven't seen the relatively new feature, Directed Routing. It would be useful for your example in that you would only need to manually route the connection once and then save the directed routing constraints to the UCF file. From that point on, the PAR routing will be determined by the constraint. See Tools --> Driected Routing Constraints.

This feature can also be used along with RPMs to replace the functionality of routed hard macros. As long as the relative pin locations and routing resources are the same as the original case, the directed routing constraints will work.

This doesn't address the issue of manually routing in the first place which I agree is difficult.

Regards, Bret

Reply to
Bret Wade

Hi Philip,

Thanks for those US patent references. It contains a detailed info of almost all the things i looked for..

--raj

Reply to
raj

I believe rickman was talking about the routing aspect, so he does not require, nor expect, that the hardware view should match the software view. The SW only has to display the routing choices, ideally in a delay-proportional manner - ie it is information the tools already have, it is just not as easy to visually scan for 'oops' results. The std human eyeball is very good at inspecting a route-pattern, and seeing too-long paths. Given the trends in modern flows, perhaps this visual inspect tool could have a histogram option, that plots local-flight-times by route-segment ?

-jg

Reply to
Jim Granville

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.