NV on-chip memory?

> Martin- It makes sense that integrating ram replacing external memory
would
> reduce pin count etc, the confusing part of your message is realted to
this
> thread being NV memory oriented.  Do you want your 128KB on chip memory
> truly for ram or for code storage?  Does that relate to the NV aspect
of the
> discussion for those low density devices you mention?
> -cheers

It does not direct relate to the NV aspect, but Paul was talking about
the SRAM contained in an FPGA. So I throwed in my larger SRAM wish. For
code memory I'm happy with larger serial Flash chips when I can access
them from the FPGA. Here the pin count is not so problematic and I know
Flash integration is problematic from the technology point.

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/


>
> "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
> news:pIF7d.330373$vG5.20442@news.chello.at...
> > > Incorporating extra functionality in an FPGA is usually done
because it
> > > provides some additional advantage beyond absorbing external
> > components.
> > > Let's look for a second at incorporating volatile RAM.  Altera
clearly
> > > thinks it is worth including medium-sized SRAM blocks (hence the
512 Kb
> > rams
> > > in Stratix and Stratix II).  Designs often require one or two large
> > RAMs
> > > (off-chip) for long-term data storage, and a few medium RAMs for
> > buffering
> >
> > I would like to add my 'wish-list' for an FPGA:
> > As I'm working with processors in FPGA I always need external SRAM:
> > costing money, PCB space, routing troubles, more pins...
> > I would like to see more SRAM on-chip. I don't need it as super-fast
> > dual-ported block RAMs. I would be happy with a single port 10-20ns
> > access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in
> > EP1C3-EP1C12 devices. When the system memory is integrated I will
vote
> > for smaller packages: tqfp100 or even tqfp44. The idea is the same as
for
> > microcontrollers in very small packages.
> > And an open documentation (not only as feature in NIOS) how to write
to
> > the serial config Flash from within the FPGA.
> >
> > my 2c
> > Martin
> > ----------------------------------------------
> > JOP - a Java Processor core for FPGAs:
> > http://www.jopdesign.com/
> >
> >
> >
>
>

Martin Schoeberl wrote:
>>Martin- It makes sense that integrating ram replacing external memory
> 
> would
> 
>>reduce pin count etc, the confusing part of your message is realted to
> 
> this
> 
>>thread being NV memory oriented.  Do you want your 128KB on chip memory
>>truly for ram or for code storage?  Does that relate to the NV aspect
> 
> of the
> 
>>discussion for those low density devices you mention?
>>-cheers
> 
> 
> It does not direct relate to the NV aspect, but Paul was talking about
> the SRAM contained in an FPGA. So I throwed in my larger SRAM wish.

This Code-Ram  should also be able to be Wide path and split, so
that multiple cores can be supported, with wide opcodes if desired.

Given the relatively high Static Icc now of FPGAs, it would also
make sense to look at Self-refresh DRAM - DRAM is much more die
efficent.


> For code memory I'm happy with larger serial Flash chips when I can access
> them from the FPGA. Here the pin count is not so problematic and I know
> Flash integration is problematic from the technology point.

Serial 'Data Storage' Flash is getting better all the time, and could 
serve as code memory in some instances. 'Jumps outside the Cache' would
be relatively costly, but the streaming speeds are getting quite good.

-jg

> > It does not direct relate to the NV aspect, but Paul was talking
about
> > the SRAM contained in an FPGA. So I throwed in my larger SRAM wish.
>
> This Code-Ram  should also be able to be Wide path and split, so
> that multiple cores can be supported, with wide opcodes if desired.
>
Now you are opening the the wish list to this SRAM block. Perhaps that's
one problem for such a feature. If A & X would integrate such a block
they have to satisfy too many diverse requests. However, you can
implement different interfaces to this block (split, multi port) by your
own logic with multi-cycle access.

> Given the relatively high Static Icc now of FPGAs, it would also
> make sense to look at Self-refresh DRAM - DRAM is much more die
> efficent.
This would make the usage of the RAM more complicated. You have to
account for the busy cycles introduced by DRAM refreshing. And AFAIK DRAM
is a little different process that 'standard' cmos.

> Serial 'Data Storage' Flash is getting better all the time, and could
> serve as code memory in some instances. 'Jumps outside the Cache' would
> be relatively costly, but the streaming speeds are getting quite good.
I would generally copy the code into the RAM befor execution. With an
on-chip RAM you could perhaps abandon the instruction and code cache.

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/