Author Topic: Has anyone replaced HP8591(E) SRAM by FRAM?  (Read 6872 times)

0 Members and 1 Guest are viewing this topic.

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #25 on: January 12, 2025, 02:41:15 am »
Ok, I think I have a schematic and a very preliminary PCB. Could you please take a look and see if you can find any error?

Thanks,
Miti
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #26 on: January 14, 2025, 09:03:07 pm »
I would suggest a 10k pullup on /CE to make sure it stays high through power cycle, as per the FM22L16 datasheet.

In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?
 

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #27 on: January 15, 2025, 12:40:15 am »
Very well done.  :-+
U6 is missing in the PCB view.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #28 on: January 15, 2025, 01:38:32 am »
Very well done.  :-+
U6 is missing in the PCB view.

This is dynamic. I've already modified the schematic. As I said, the PCB was very preliminary.
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #29 on: January 15, 2025, 02:01:48 am »
I would suggest a 10k pullup on /CE to make sure it stays high through power cycle, as per the FM22L16 datasheet.

In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Good catch with the pull-up resistor, thanks!
OK, I will in the weekend. Meanwhile here's a scope shot with LLW (CH1), LOE (CH2) and the address LSB (CH3). It looks like I caught a read, two write cycles, and another partial read.
« Last Edit: January 15, 2025, 02:06:14 am by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #30 on: January 15, 2025, 08:13:33 pm »
In parallel with the RAM board design I’m thinking of a solution to copy the content of the HP module into my FRAM module. I don’t want to go through the pain of entering the calibration constants and the EMC personality. I’m thinking of two possible (approachable) solutions:
1. Make an adapter from the Molex connector to a DIL connector, together with some logic as needed, and use a programmer, such as TL866, to read and write the memory. Select a 5V 256k x 16  flash for the device.
This would be the preferred solution to save the content in a binary file.
2. Make an adapter with two Molex connectors and a header for an Arduino Mega 2560. I would connect both modules in the same time, data and address lines are connected together, and Arduino would give the address lines and the control signals to copy from the source into the destination. The disadvantage of this approach is that it would be a blind copy.

I would prefer the first approach but for that I would need to know the pinout of the adapter used with TL866. For example AM29F400 is a 5V only flash that seems to be a good candidate but needs an adapter from 44 pin SOP or from 48 pin TSOp to 40 pin ZIF socket and I don’t have the pinout or the schematic.
Does anyone have the schematic of such adapter?

Cheers,
Miti
« Last Edit: January 15, 2025, 08:57:41 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #31 on: January 15, 2025, 09:58:17 pm »
In parallel with the RAM board design I’m thinking of a solution to copy the content of the HP module into my FRAM module. I don’t want to go through the pain of entering the calibration constants and the EMC personality. I’m thinking of two possible (approachable) solutions:
1. Make an adapter from the Molex connector to a DIL connector, together with some logic as needed, and    use a programmer, such as TL866, to read and write the memory. Select a 5V 256k x 16  flash for the device.
This would be the preferred solution to save the content in a binary file.
2. Make an adapter with two Molex connectors and a header for an Arduino Mega 2560. I would connect both modules in the same time, data lines are connected together, and Arduino would give the address lines and the control signals to copy from the source into the destination. The disadvantage of this approach is that it would be a blind copy.

I would prefer the first approach but for that I would need to know the pinout of the adapter used with TL866. For example AM29F400 is a 5V only flash that seems to be a good candidate but needs an adapter from 44 pin SOP or from 48 pin TSOp to 40 pin ZIF socket and I don’t have the pinout or the schematic.
Does anyone have the schematic of such adapter?

Cheers,
Miti
I've done approach #2 with a Silabs C8051F581, except I made the processor spit out on its serial port a hex dump of what it was reading and then captured that on a computer.  So, I ended up with a binary image of the SRAM.  See:

   https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1013805/#msg1013805

I had to do it in 2 or 4 passes because the Silabs part did not have enough GPIO pins.  If I were to do it again, I would use something with enough pins to cover all the address and data pins, like a STM32F767 on a NUCELO dev board (NUCLEO-F767ZI, about USD$25).  The GPIO pins on the STM32F767 are almost all 5V tolerant (109 out of 112 pins), so you could go with direct jumpers with no intervening logic or current limiting resistors.  Since you're dealing with SRAM, there are no timing issues and you can go as slow as you want.

I did not do the SRAM writer part, but once the SRAM binary image was available, it would be easy to plug the connector into the new SRAM and go the other way.  The STM32F767 has 2MB of flash, so once you have the SRAM image, you could build it into the binary, load it into the STM32F767, and proceed with the writing.

The EMC personality and flatness correction constants can both be reloaded via GPIB, but I agree it is a pain.  The EMC personality can also be copied to an intermediate 128k RAM card (HP 85702A), and then copied back, but they are hard to find for sane prices.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #32 on: January 15, 2025, 11:49:48 pm »
I've done approach #2 with a Silabs C8051F581, except I made the processor spit out on its serial port a hex dump of what it was reading and then captured that on a computer.  So, I ended up with a binary image of the SRAM.  See:

   https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1013805/#msg1013805

I had to do it in 2 or 4 passes because the Silabs part did not have enough GPIO pins.  If I were to do it again, I would use something with enough pins to cover all the address and data pins, like a STM32F767 on a NUCELO dev board (NUCLEO-F767ZI, about USD$25).  The GPIO pins on the STM32F767 are almost all 5V tolerant (109 out of 112 pins), so you could go with direct jumpers with no intervening logic or current limiting resistors.  Since you're dealing with SRAM, there are no timing issues and you can go as slow as you want.

I did not do the SRAM writer part, but once the SRAM binary image was available, it would be easy to plug the connector into the new SRAM and go the other way.  The STM32F767 has 2MB of flash, so once you have the SRAM image, you could build it into the binary, load it into the STM32F767, and proceed with the writing.

The EMC personality and flatness correction constants can both be reloaded via GPIB, but I agree it is a pain.  The EMC personality can also be copied to an intermediate 128k RAM card (HP 85702A), and then copied back, but they are hard to find for sane prices.

Isn't this more like approach #1 but using the Silabs instead of the programmer?
In approach #2 the Arduino boards does not see the data, it only generates the addresses and the control signals for both, source and destination.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #33 on: January 16, 2025, 12:08:12 am »
...
Isn't this more like approach #1 but using the Silabs instead of the programmer?
In approach #2 the Arduino boards does not see the data, it only generates the addresses and the control signals for both, source and destination.
Yes.  I was seeing the difference between your approaches as using a processor vs. using a programmer.  But I get it now - #2 goes back-to-back with the modules.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #34 on: January 16, 2025, 06:52:03 pm »
The programmer approach is a good idea.

Since the memory module is writable on a byte basis, you could read/write the image in two slices, first lower bytes and then upper bytes.  On the TL866, you could select a 256k x 8 NVRAM chip, such as the 5V Dallas DS1249AB or DS1249Y.  The DS1249 is a 32-pin DIP and does not need a mystery adapter, and I think is supported by the TL866 (and a lot of other programmers).

If you wanted a contiguous SRAM image for some reason, there are tools to re-interleave the lower and upper byte-wide images.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #35 on: January 16, 2025, 11:11:53 pm »
The programmer approach is a good idea.

Since the memory module is writable on a byte basis, you could read/write the image in two slices, first lower bytes and then upper bytes.  On the TL866, you could select a 256k x 8 NVRAM chip, such as the 5V Dallas DS1249AB or DS1249Y.  The DS1249 is a 32-pin DIP and does not need a mystery adapter, and I think is supported by the TL866 (and a lot of other programmers).

If you wanted a contiguous SRAM image for some reason, there are tools to re-interleave the lower and upper byte-wide images.

That's a very good idea, thank you Mark!
I got stuck with the 16 bit idea and it didn't occur to me that by reading/ writing 8 bits at a time I don't need the adapter anymore.
In fact I think TL866 II Plus is 8 bit and the adapter multiplexes the upper and lower block. :-+

Edit: Tested with an FRAM chip and it works.  :clap:
Edit 1: And if I select DS1250 instead of DS1249, the /LB , /UB multiplexing can be done automatically using the address MSB and it creates a single file.
« Last Edit: January 17, 2025, 03:22:38 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #36 on: January 17, 2025, 08:24:47 pm »
Interesting idea on using the MSB to control the upper/lower byte selection.  But when connecting the memory module, how does the upper byte get multiplexed onto the DS1250 [D7..D0] pins on the programmer?

I thought of another thing wrt the memory module: LUSERRAM0 and LUSERRAM1 are mutually exclusive, so they can't be wired to address lines.  More properly, those are really select inputs so they should be handled by connecting them to the pin assigned to /CE pin on the programmer.

At the moment, I'm seeing a four pass solution using a DS1245Y or DS1245AB (128k x 8 ).

    Programmer      Module         
    ----------      ----------
1)  /CE        -->  LUSERRAM0   
    [D7..D0]   ---  [MD7..MD0]
    /WE        -->  LLW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]
 
2)  /CE        -->  LUSERRAM1   
    [D7..D0]   ---  [MD7..MD0]
    /WE        -->  LLW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]

3)  /CE        -->  LUSERRAM0   
    [D7..D0]   ---  [MD15..MD8]
    /WE        -->  LUW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]
 
4)  /CE        -->  LUSERRAM1   
    [D7..D0]   ---  [MD15..MD8]
    /WE        -->  LUW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]


For the read operations on the original module, I would probably tie LLW and LUW high through a resistor to whatever is supplying power to the module, independent of what the programmer is doing, just to make sure no writes are triggered by accident.

Edit:  I guess it's really 8 passes, if you want to multiply by a pass for read and a pass for write.
« Last Edit: January 17, 2025, 08:28:15 pm by MarkL »
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #37 on: January 17, 2025, 09:23:49 pm »
I'll throw this out there, but it's also possible to read the entire SRAM via GPIB.  It could serve as a backup, but to be honest I've never tried to put the GPIB output back into SRAM to see if it works.

There is an undocumented command:

  mbrd START,BYTES

where START is the starting address, and BYTES is the number of bytes to dump.  Both are in decimal.  Results are returned in "A-block" format.  See the programmer manual for details on A-block (page 3-24), but I'll summarize by saying it's a binary format and limited to 32767 bytes.  So, BYTES can't exceed 32767.

The SRAM module is mapped into the processor memory starting at 0x00f80000 (16252928 decimal), and ends at 0x00ffffff (16777215 decimal).  That's 524288 bytes.

If you wanted to try dumping all of SRAM, you would need to set up a loop and submit GPIB commands like this:

  mbrd 16252928,16384
  mbrd 16269312,16384
  mbrd 16285696,16384
  ...
  mbrd 16760832,16384

It would be interesting to know if this roughly matches whatever you extract from the original module.  Of course it won't be exact because it's a running system.  And you could also try writing the mbrd output into the new module with the programmer and see if everything is there, like your cal constants and EMC personality.

Obviously none of this is needed for your approach.  I disassembled my SRAM module reader long ago and I'm mostly curious if this works, having discovered the hidden mbrd command sometime later.

So, if you're in the mood in the future...

EDIT: Bummer, but this doesn't work.  See: https://www.eevblog.com/forum/repair/has-anyone-replaced-hp8591(e)-sram-by-fram/msg5801109/#msg5801109
« Last Edit: January 30, 2025, 08:47:33 pm by MarkL »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #38 on: January 17, 2025, 10:29:43 pm »
Interesting idea on using the MSB to control the upper/lower byte selection.  But when connecting the memory module, how does the upper byte get multiplexed onto the DS1250 [D7..D0] pins on the programmer?

Two 4451 to multiplex 16 bit to 8 bit. The selection line is A18 ( DS1250 has A18 to A0 address lines).

I thought of another thing wrt the memory module: LUSERRAM0 and LUSERRAM1 are mutually exclusive, so they can't be wired to address lines.  More properly, those are really select inputs so they should be handled by connecting them to the pin assigned to /CE pin on the programmer.

Yes they can. LUSERRAM0 is connected directly to A17 and LUSERRAM1 through an inverter to the same A17.
/CE cannot be used in this case.

For the read operations on the original module, I would probably tie LLW and LUW high through a resistor to whatever is supplying power to the module, independent of what the programmer is doing, just to make sure no writes are triggered by accident.

Yes, for reading the source, LLW and LUW are connected through pull-ups to Vcc and disconnected from /WE for write protection For writing I have to create the logic between /WE and A18 that holds LLW or LUW low as needed. Something similar to what’s in my FRAM schematic.

Edit: I’ll put it in a schematic, I may be missing something, it’s all in my head for now.
« Last Edit: January 17, 2025, 10:38:15 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #39 on: January 18, 2025, 12:37:13 am »
Certainly with the addition of various logic it's possible to make any scenario work.

Since moving the SRAM contents only needed to be done once, I was trying to keep it simple and make the programmer do all the work without building any additional circuitry.  My 8 step proposal uses jumpers and a resistor or two.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #40 on: January 18, 2025, 04:34:45 am »
Certainly with the addition of various logic it's possible to make any scenario work.

Since moving the SRAM contents only needed to be done once, I was trying to keep it simple and make the programmer do all the work without building any additional circuitry.  My 8 step proposal uses jumpers and a resistor or two.

By the time I draw the schematic, I cut the wires, I strip, I solder, I curse... I'd rather have it done right and order it together with the main board.

Edit: This also can be used as test platform. If reading and writing works on this adapter, it is more likely to work in the spectrum analyzer.
« Last Edit: January 18, 2025, 01:38:25 pm by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #41 on: January 18, 2025, 07:00:47 pm »
Something like this. I've looked for a proper switch instead of a jumper but boy oh boy! $10 for a proper slide switch? What a world, what a world...
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #42 on: January 18, 2025, 09:33:57 pm »
In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Here it is. Ok, LLW (and I assume LUW as well, from my previous scope shots most writes are 16bits, but I ran out of channels  ;D) does toggle with peripherals, so what? If no RAM is selected, both FRAM and the buffer are disabled. The write cycle is ignored.
Do you see any conflict in the attached scope shots? What else do you think I should look at?

Cheers,
Miti
« Last Edit: January 18, 2025, 09:42:46 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #43 on: January 21, 2025, 11:48:14 pm »
In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Here it is. Ok, LLW (and I assume LUW as well, from my previous scope shots most writes are 16bits, but I ran out of channels  ;D) does toggle with peripherals, so what? If no RAM is selected, both FRAM and the buffer are disabled. The write cycle is ignored.
Do you see any conflict in the attached scope shots? What else do you think I should look at?

Cheers,
Miti
I don't see anything that might be problem.

Yes, I agree it doesn't matter if LLW or LUW or anything else toggles on peripheral access.  I was asking for triggering on LUSERRAMx so that various signal timings could be verified only when the SRAM is active.  The previous trigger settings were capturing ALL writes (on LLW), which included SRAM and everything else.

The only other thing you could poke at is some of the address lines to make sure they are stable before or exactly when LUSERRAMx goes low.  The FRAM address setup time (tAS) is 0ns and is latched on /CE going low.  The original SRAM does not latch the address, so it operates a little differently.  But I would be surprised if any address lines are changing after LUSERRAMx goes low.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #44 on: January 22, 2025, 03:22:28 pm »
Thanks Mark, I appreciate your input!
I think our write cycle is controlled by /WE.
The thing is that LUSERRAM0 is part of the FRAM address so the address changes when it goes low so address and /CE may change in the same time when RAM0 is selected. Maybe I should delay /CE through two more inverters. I’ve also delayed the /LB and /UB through two more inverters each so they are delayed relative to LLW and LUW when they, and consequently /WE, go high. One more thing that worries me is changing /LB and /UB after /CE goes low. Those lines are set before /CE in /WE controlled cycle, but they do change after in /CE controlled cycle, in the FRAM data sheet.  :-//
I guess I’ll have to test to be sure it works.

Edit: I think my write cycle looks something like this.
« Last Edit: January 22, 2025, 03:45:08 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #45 on: January 22, 2025, 08:53:01 pm »
Hmmm...  I was thinking you would control the write cycle with /CE (Mode 2):

Addresses would be stable (presumably - need to verify) before or conincident with /CE.  /CE is LUSERRAM0*LUSERRAM1.  A17 is LUSERRAM0.  When /CE falls, the correct address is latched, and it doesn't matter yet on /LB and /UB.

For read, /OE is LOE, LLW and LUW stay high.

For write, LLW and LUW would drive /LB and /UB, respectively, and /WE is LLW*LUW.  LOE stays high.  The write happens on the rising edge of /CE.  The timing diagram is not showing any constraints on /WE since the cycle is terminated by /CE (although I would have liked to see *something* on the diagram).

If this doesn't work out for some reason, a possible fallback could be 2x 8x256k FRAMs.  Or even 4x 8x128k FRAMs.  The memory interface has already de-multiplexed the control signals, and it would be more of a "drop-in" application for which this FRAM was designed.

Also, it would be worthwhile to validate the behavior of /CE on power up and power down cycles.  The DS1210 is providing protection against spurious writes for the old memory.  The FRAM requires that /CE (or /WE) follows Vdd down to 0V and back up again to prevent spurious writes.  This may be a concern since the FRAM will still be operating after the processor has gone out to lunch due to low voltage.  The processor is probably being held in reset during those times, but even reset circuits bail out when the voltage gets low enough, and I'm not seeing a lockout voltage specification for the FRAM.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #46 on: January 22, 2025, 09:21:03 pm »
I wish those chips existed. Check Digikey, Mouser, LCSC. This is the only chip with healthy stock and decent price. I may go with two FM22L16 and use half of each.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2333
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #47 on: January 23, 2025, 12:06:36 am »
I wish those chips existed. Check Digikey, Mouser, LCSC. This is the only chip with healthy stock and decent price. I may go with two FM22L16 and use half of each.
Sorry, I didn't look first.  You're right, there doesn't seem to be a 8x256k.  But there is FM28V100 which is 8x128k for $21 ea. at Mouser.  Four of them would be a little more expensive than two FM22L16, so probably doesn't make sense.  A solution that uses a single FM22L16 is worth jumping through some hoops.

If you read the operation detail in the FM22L16 datasheet, I think the write cycle I described would work.  There's just not a timing diagram that represents it.

Cypress has another technology call nvSRAM, e.g. CY14B104 which is 8x512K or 16x256K.  It has 20 year retention, which is less than FRAM, but the interface is pure SRAM so might be a little easier.  One oddity is that it has a 20ms startup time and an 8ms shutdown time, but that's probably ok (would need to verify 859x reset circuit).  Another nice thing is that it has a specified lockout threshold of 2.65V.  Availability is ok.  Something to think about if the FRAM doesn't work out.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #48 on: January 23, 2025, 12:20:33 am »
Sorry, I didn't look first.  You're right, there doesn't seem to be a 8x256k.  But there is FM28V100 which is 8x128k for $21 ea. at Mouser.  Four of them would be a little more expensive than two FM22L16, so probably doesn't make sense.  A solution that uses a single FM22L16 is worth jumping through some hoops.

Check FM22L16 at LCSC.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1500
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #49 on: January 23, 2025, 01:35:33 am »
Hmmm...  I was thinking you would control the write cycle with /CE (Mode 2):

Addresses would be stable (presumably - need to verify) before or conincident with /CE.  /CE is LUSERRAM0*LUSERRAM1.  A17 is LUSERRAM0.  When /CE falls, the correct address is latched, and it doesn't matter yet on /LB and /UB.

For read, /OE is LOE, LLW and LUW stay high.

For write, LLW and LUW would drive /LB and /UB, respectively, and /WE is LLW*LUW.  LOE stays high.  The write happens on the rising edge of /CE.  The timing diagram is not showing any constraints on /WE since the cycle is terminated by /CE (although I would have liked to see *something* on the diagram).

If this doesn't work out for some reason, a possible fallback could be 2x 8x256k FRAMs.  Or even 4x 8x128k FRAMs.  The memory interface has already de-multiplexed the control signals, and it would be more of a "drop-in" application for which this FRAM was designed.

Also, it would be worthwhile to validate the behavior of /CE on power up and power down cycles.  The DS1210 is providing protection against spurious writes for the old memory.  The FRAM requires that /CE (or /WE) follows Vdd down to 0V and back up again to prevent spurious writes.  This may be a concern since the FRAM will still be operating after the processor has gone out to lunch due to low voltage.  The processor is probably being held in reset during those times, but even reset circuits bail out when the voltage gets low enough, and I'm not seeing a lockout voltage specification for the FRAM.

Actually I am considering connecting /CE to GND and playing with /WE, /OE only. The way I see the signals in the spectrum analyzer, it uses /WE controlled writing so it would need a bit more intelligence that some gates to change that... I think.
Fear does not stop death, it stops life.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf