15 Dec
2018
15 Dec
'18
3:32 p.m.
Hi Rod,
take some microcontroller and some serial flash memory.
With best regards
Gerhard
-----Urspr?ngliche Nachricht-----
Von: cctalk [mailto:cctalk-bounces at classiccmp.org] Im Auftrag von
cctalk-request at classiccmp.org
Gesendet: Samstag, 15. Dezember 2018 19:00
An: cctalk at classiccmp.org
Betreff: cctalk Digest, Vol 51, Issue 15
Send cctalk mailing list submissions to
cctalk at classiccmp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.classiccmp.org/mailman/listinfo/cctalk
or, via email, send a message with subject or body 'help' to
cctalk-request at classiccmp.org
You can reach the person managing the list at
cctalk-owner at classiccmp.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of cctalk digest..."
15 Dec
15 Dec
3:45 p.m.
New subject: Core memory emulator using non volatile ram.
Serial flash has an endurance between 10K-100K writes per cell so I think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
On Sat, Dec 15, 2018, 3:33 PM Gerhard Kreuzer via cctalk <
cctalk at classiccmp.org wrote:
Hi Rod,
take some microcontroller and some serial flash memory.
With best regards
Gerhard
-----Urspr?ngliche Nachricht-----
Von: cctalk [mailto:cctalk-bounces at classiccmp.org] Im Auftrag von
cctalk-request at classiccmp.org
Gesendet: Samstag, 15. Dezember 2018 19:00
An: cctalk at classiccmp.org
Betreff: cctalk Digest, Vol 51, Issue 15
Send cctalk mailing list submissions to
cctalk at classiccmp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.classiccmp.org/mailman/listinfo/cctalk
or, via email, send a message with subject or body 'help' to
cctalk-request at classiccmp.org
You can reach the person managing the list at
cctalk-owner at classiccmp.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of cctalk digest..."
3:51 p.m.
New subject: Core memory emulator using non volatile ram.
On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
Serial flash has an endurance between 10K-100K writes
per cell so I think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU,
it will perform VERY poorly, as these memories need to erase
a page at a time, and the erase takes milliseconds. So,
writing ONE SINGLE word at a time would invoke an erase
cycle each time, slowing it to 1/1000 or worse the speed of
the original core memory. Also, most old CPUs have the
memory timing built into the CPU, and can't handle a memory
that says "wait".
Jon
4:15 p.m.
New subject: Core memory emulator using non volatile ram.
On Dec 15, 2018, at 12:51 PM, Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
Anything FLASH related is quickly going to have issues because of the limited write
endurance (1000s of cycles only). It?s one of the issues that I?m facing with the disk
emulators that I?m (trying to) work on. But it works better there because of the block
nature of disks (and I?m using a larger FLASH than necessary to allow for wear leveling
plus some really heavy duty error correction?had to refresh myself on error coding theory
again).
For core replacements, as I?ve said previously, I prefer MRAM. They?re as fast as SRAM
(35-55ns) with unlimited write endurance, 10+ year data retention and non-volitive
(implied by the data retention). Other than the 3.3v interfaces (and SMT?but almost
everything is SMT these days) they?re ideal.
TTFN - Guy
Serial flash has an endurance between 10K-100K
writes per cell so I think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU, it will perform VERY
poorly, as these memories need to erase a page at a time, and the erase takes
milliseconds. So, writing ONE SINGLE word at a time would invoke an erase cycle each
time, slowing it to 1/1000 or worse the speed of the original core memory. Also, most old
CPUs have the memory timing built into the CPU, and can't handle a memory that says
"wait?. 
4:18 p.m.
New subject: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk <cctalk at classiccmp.org
wrote:
On 12/15/2018 02:45 PM, Anders Nelson via cctalk
wrote:
If you paired it with a microcontroller, you might be able to implement a
log device and then manage to logical to physical translation ala FTLs in
SSD land... but it would be ugly as heck and you'd still have the stall to
worry about when you got to the end of the erase block... better
performance, but maybe beyond a cheap uc...
Warner
Serial flash has an endurance between 10K-100K
writes per cell so I think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU,
it will perform VERY poorly, as these memories need to erase
a page at a time, and the erase takes milliseconds. So,
writing ONE SINGLE word at a time would invoke an erase
cycle each time, slowing it to 1/1000 or worse the speed of
the original core memory. Also, most old CPUs have the
memory timing built into the CPU, and can't handle a memory
that says "wait".
4:24 p.m.
New subject: Core memory emulator using non volatile ram.
On Dec 15, 2018, at 1:18 PM, Warner Losh via cctalk
<cctalk at classiccmp.org> wrote:
On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk <cctalk at classiccmp.org
wrote:
And my question is why go through all of that pain when an FRAM or MRAM
device can do this with no hackery?
What you?re describing is the very definition of an ?impedance mismatch?.
You?re trying to use a block oriented device as a byte device and attempting
to paper over the differences. I think the end result would be less than
satisfactory in almost every measurable dimension.
TTFN - Guy
On 12/15/2018 02:45 PM, Anders Nelson via cctalk
wrote:
If you paired it with a microcontroller, you might be able to implement a
log device and then manage to logical to physical translation ala FTLs in
SSD land... but it would be ugly as heck and you'd still have the stall to
worry about when you got to the end of the erase block... better
performance, but maybe beyond a cheap uc? Serial flash has an endurance between 10K-100K
writes per cell so I think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU,
it will perform VERY poorly, as these memories need to erase
a page at a time, and the erase takes milliseconds. So,
writing ONE SINGLE word at a time would invoke an erase
cycle each time, slowing it to 1/1000 or worse the speed of
the original core memory. Also, most old CPUs have the
memory timing built into the CPU, and can't handle a memory
that says "wait".
4:30 p.m.
New subject: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018, 2:25 PM Guy Sotomayor Jr <ggs at shiresoft.com wrote:
If you paired it with a microcontroller, you might be able to implement a
log device and then manage to logical to physical translation ala FTLs in
SSD land... but it would be ugly as heck and you'd still have the stall to
True. Lessening the pain still doesn't make it right :). MRAM or FRAM does
sound a lot simpler to use...
Warner
On Dec 15, 2018, at 1:18 PM, Warner Losh via
cctalk <
cctalk at classiccmp.org> wrote:
On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk <
cctalk at classiccmp.org
wrote:
> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote:
>> Serial flash has an endurance between 10K-100K writes per cell so I
think
>> that would break down quickly.
Wear-leveling on a serial device would
be
very slow...
If you intend to use it as main core memory on an old CPU,
it will perform VERY poorly, as these memories need to erase
a page at a time, and the erase takes milliseconds. So,
writing ONE SINGLE word at a time would invoke an erase
cycle each time, slowing it to 1/1000 or worse the speed of
the original core memory. Also, most old CPUs have the
memory timing built into the CPU, and can't handle a memory
that says "wait".
worry about when you got to the end of the erase
block... better
performance, but maybe beyond a cheap uc?
And my question is why go through all of that pain when an FRAM or MRAM
device can do this with no hackery?
What you?re describing is the very definition of an ?impedance mismatch?.
You?re trying to use a block oriented device as a byte device and
attempting
to paper over the differences. I think the end result would be less than
satisfactory in almost every measurable dimension.
4:48 p.m.
New subject: Core memory emulator using non volatile ram.
On 12/15/18 1:30 PM, Warner Losh via cctalk wrote:
True. Lessening the pain still doesn't make it
right :). MRAM or FRAM does
sound a lot simpler to use...
How about nvRAM? Faster, with high capacity. Stores into flash
(every CMOS RAM cell is paired with a flash cell) when the supply drops
below a certain level; restores data to RAM upon power-up.
http://www.cypress.com/products/nvsram-nonvolatile-sram
--Chuck
16 Dec
16 Dec
11:21 p.m.
New subject: Core memory emulator using non volatile ram.
On 12/15/2018 03:51 PM, Jon Elson via cctech wrote:
On 12/15/2018 02:45 PM, Anders Nelson via cctalk
wrote:
The only place where Flash or similar tech fits is applied to the mass
storage problem such as replicating
a RF/DF32 multihead disk.
The cycle life is a limiting factor for things like swapping drums/disks
but for something that's
read mostly its ok.
Core is RAM, and not serial anyway.
Allison
Serial flash has an endurance between 10K-100K
writes per cell so I
think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU, it will
perform VERY poorly, as these memories need to erase a page at a time,
and the erase takes milliseconds.? So, writing ONE SINGLE word at a
time would invoke an erase cycle each time, slowing it to 1/1000 or
worse the speed of the original core memory.? Also, most old CPUs have
the memory timing built into the CPU, and can't handle a memory that
says "wait".
Jon
11:50 p.m.
New subject: Core memory emulator using non volatile ram.
On Dec 16, 2018, at 8:21 PM, allison via cctech
<cctech at classiccmp.org> wrote:
On 12/15/2018 03:51 PM, Jon Elson via cctech wrote:
Frankly even in those applications (RF11/DF32) I?d use MRAM (available in 2Mx8)
rather than FLASH because (a) it?s byte addressable (b) it has unlimited write endurance
(c) it looks like SRAM so there?s no erase cycle (or blocks) to deal with so it makes
the hardware easier (e.g. it should be possible to implement one of those controllers
just with logic and not require a microprocessor).
BTW, that?s what I use for the emulators that I?m working on (when I have time?in
short supply at the moment).
I also use them even when I do use FLASH as I can use it as a buffer/cache to help
absorb some of the write/overwrite cycles and to be able to handle (non-volatile) full
FLASH block operations and for wear leveling (tracking and block remapping). That
way I don?t have to deal with a PMIC and battery. MRAMs also have a >20 year data
retention as well (something you don?t have with a battery?if the battery dies, you
loose everything).
TTFN - Guy
On 12/15/2018 02:45 PM, Anders Nelson via cctalk
wrote:
The only place where Flash or similar tech fits is applied to the mass
storage problem such as replicating
a RF/DF32 multihead disk.
The cycle life is a limiting factor for things like swapping drums/disks
but for something that's
read mostly its ok. Serial flash has an endurance between 10K-100K
writes per cell so I
think
that would break down quickly. Wear-leveling on a serial device would be
very slow...
If you intend to use it as main core memory on an old CPU, it will
perform VERY poorly, as these memories need to erase a page at a time,
and the erase takes milliseconds. So, writing ONE SINGLE word at a
time would invoke an erase cycle each time, slowing it to 1/1000 or
worse the speed of the original core memory. Also, most old CPUs have
the memory timing built into the CPU, and can't handle a memory that
says "wait".
Jon
2078
days inactive
2080
days old
9 comments
7 participants
participants (7)
-
allisonportable＠gmail.com -
anders.k.nelson＠gmail.com -
cclist＠sydex.com -
elson＠pico-systems.com -
gerhard.kreuzer＠liftoff.at -
ggs＠shiresoft.com -
imp＠bsdimp.com