quick survey...Would it be of value to provide cheap on-chip one time programmablememory in an FPGA like Cyclone II?Say 1-10Mbit depending on density.It would be field or user programmable either via a programmer (veryfast) or by user logic.It would be very secure (anti-copy) for: secure s/w code with on-chip processor secure data storage configuration data(s) etc.Please share your thoughts on the value (I would pay X% premium) andthe type of ways you would use it?Thanks in advanceAtoris

Yes.Can you clarify - would this need Supra Voltages/Currents, orcan the FPGA program itself, while running. ( eg could anNV event log be created ? )First one is easy, X = 0 :)An interesting question. From a wider industry perspective, there is a trend in the Microcontroller sector, to offer MASK devices, where a couple ofyears ago the party line was 'we will now only make FLASH'. This must be driven by a number of factors, and clearly customerdemand, because of** MASK is always going to be lower cost (fewer process steps, and testing)** Zero risk of field bit erasure** No programming needed at customer end.** Some apps stipulate that high voltage must be needed for program, so they want to _guarantee_ errant software cannot jump into the FLASH loader Block erase routines, for example :) Designers love Flash, because they can change it easily, but thereare many products that are code-stable, and the bean-counters preferthe lowest cost options. So, back to your Cheap OTP...

NV on-chip memory?

Sep 28, 2004 42 Replies

Rate this thread:

Martin Schoeberl 21 years ago

would

this

of the

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:

formatting link

because it

clearly

512 Kb

vote

for

Vote

Jim Granville 21 years ago

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.

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

Vote

Martin Schoeberl 21 years ago

about

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.

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.

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:

formatting link

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required