configuration SRAM cells in Xilinx/Altera FPGAs

[raj]

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.

3. 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

 

[rickman]

raj wrote:

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.

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.

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

Yes, or even integrated.

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

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

 

[raj]

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




rickman <spamgoeshere4@yahoo.com> wrote in message news:<410660E4.D29D86B6@yahoo.com>...

raj wrote:

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.

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.

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

Yes, or even integrated.

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

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
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]

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:

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

rickman <spamgoeshere4@yahoo.com> wrote in message news:<410660E4.D29D86B6@yahoo.com>...
raj wrote:

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.

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.

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

Yes, or even integrated.

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

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

 

[Philip Freidin]

On 27 Jul 2004 21:38:07 -0700, rajarsheeb@yahoo.com (raj) wrote:

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

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

http://www.fpga-faq.com/archives/55100.html#55101

There is a wealth of detailed info available at www.uspto.gov
for example patent 4,870,302 would be a good place to start.

start here: http://patft.uspto.gov/netahtml/search-bool.html

Others that might interest you include:

5631577
5598424
5742531
5995988

Philip Freidin


===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

 

[Austin Lesea]

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.

Austin

rickman wrote:

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:

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

rickman <spamgoeshere4@yahoo.com> wrote in message news:<410660E4.D29D86B6@yahoo.com>...

raj wrote:

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.

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.


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

Yes, or even integrated.


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

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.

 

[rickman]

Austin Lesea wrote:

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.

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

 

[Austin Lesea]

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.....

Austin

rickman wrote:

Austin Lesea wrote:

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.


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.

 

[rickman]

Austin Lesea wrote:

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?).

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.

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

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.

I know, radical.

Hardware vs. 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
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

 

[Austin Lesea]

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.

Austin

rickman wrote:

Austin Lesea wrote:

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?).


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.



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


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.


I know, radical.

Hardware vs. 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.

 

[Bret Wade]

rickman wrote:

(SNIP)

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.

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

 

[raj]

Hi Philip,

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

--raj

Philip Freidin <philip@fliptronics.com> wrote in message news:<2gpeg0da7n78n2vj1ohasuhhcjnul595ap@4ax.com>...

On 27 Jul 2004 21:38:07 -0700, rajarsheeb@yahoo.com (raj) wrote:
Thanks Rick for your inputs.
Can you suggest some pointers regarding these?
--raj

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

http://www.fpga-faq.com/archives/55100.html#55101

There is a wealth of detailed info available at www.uspto.gov
for example patent 4,870,302 would be a good place to start.

start here: http://patft.uspto.gov/netahtml/search-bool.html

Others that might interest you include:

5631577
5598424
5742531
5995988

Philip Freidin


===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

 

[Jim Granville]

Austin Lesea wrote:

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.
snip

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