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

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

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

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




rickman <s...@yahoo.com> wrote in message
news:<4...@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
> 
> r...@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

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 <s...@yahoo.com> wrote in message
news:<4...@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

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

On 27 Jul 2004 21:38:07 -0700,
r...@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
p...@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

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 <s...@yahoo.com> wrote in message
news:<4...@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.
> 
> 

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

r...@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,

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

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

r...@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,

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