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

0 Members and 1 Guest are viewing this topic.

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #50 on: January 23, 2025, 02:59:05 pm »
I’ve checked a professional design for the FRAM safe power up schematic. They pull /ZZ low with the reset line from the supervisor.  :-//
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #51 on: January 24, 2025, 01:30:39 am »
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.
Sure, a grounded /CE could work too.  LUSERRAM0 and LUSERRAM1 need to be involved to gate /WE and /OE since you already have at least one scope capture where LLW is going low with LUSERRAM0 and LUSERRAM1 staying high, and another where LOE is going low with LUSERRAM0 and LUSERRAM1 staying high.

If you use /CE, the gating can stay in the FRAM instead of doing it externally.  But I think either approach will work.

Great idea to look at how other implementations do controlled power up/down.  But interesting that Cypress didn't point out /ZZ explicitly in the datasheet as an option to help with power up/down.

The FRAM needs 450us to wake up after /ZZ high, so using /ZZ not completely a slam dunk.  If tied to the processor /RESET, the processor might have already started before the FRAM wakes up.  I'm not seeing a timing spec for /RESET high to start execution in the 68HC000 datasheet.  Maybe you could use a local reset supervisor driving /ZZ that triggers on +5D reaching 3.0V or so.  At that point the processor is being held in reset and it's a matter of the voltage ramp on +5D passing 3.0V and HPWRUP going high (wherever that's coming from - looks like the power supply).

Or you could keep /WE (or /CE) tracked to Vdd until you know the processor is safely being held in reset (like until 4.5V).  That's what the datasheet wants and it's more of a deterministic approach since this design is not in control of the processor, reset circuit, or power supply characteristics.

EDIT:  In the design you were looking at that used /ZZ, they could have anticipated the FRAM wakeup time in the firmware and delayed before accessing it.  In which case /ZZ is an easy and simple approach.
« Last Edit: January 24, 2025, 01:47:25 am by MarkL »
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #52 on: January 24, 2025, 03:38:59 am »
Thanks Mark!
I did some basic timing analysis of a write cycle and I think I have a winner... or a wiener, we'll see what the proper spelling is when I test it.
I am using CE in the end and I'll have to think a bit more about the power up/dn protection but basically this schematic should work.
One unknown part is changing /LB, /UB after address and /CE change, but figure 13 in the datasheet gives me hope.
The time division is 10ns. I may need to use slower 74HC14 for longer delays if 74LVC is too fast. The oscillator may also need experimental tuning but as I like to say, electronic engineering is not an exact science... all the time.

Edit: Maybe this would work for power up/dn. Schematic updated.
« Last Edit: January 24, 2025, 05:07:14 am by Miti »
Fear does not stop death, it stops life.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #53 on: January 24, 2025, 04:07:07 am »
Great idea to look at how other implementations do controlled power up/down.  But interesting that Cypress didn't point out /ZZ explicitly in the datasheet as an option to help with power up/down.

The FRAM needs 450us to wake up after /ZZ high, so using /ZZ not completely a slam dunk.  If tied to the processor /RESET, the processor might have already started before the FRAM wakes up.

.................

EDIT:  In the design you were looking at that used /ZZ, they could have anticipated the FRAM wakeup time in the firmware and delayed before accessing it.  In which case /ZZ is an easy and simple approach.

Yes, I saw that 450us and I didn't like it. And as you said, the SW may wait for the FRAM in that application.

Maybe you could use a local reset supervisor driving /ZZ that triggers on +5D reaching 3.0V or so.

There is a reset supervisor on the HP RAM board and on my board. Actually I think it is the only reset supervisor, it doesn't make sense to have more than one as you cannot run the SA without the RAM board.

Or you could keep /WE (or /CE) tracked to Vdd until you know the processor is safely being held in reset (like until 4.5V).  That's what the datasheet wants and it's more of a deterministic approach since this design is not in control of the processor, reset circuit, or power supply characteristics.

That is what I have to explore. If the LUSERRAMx signals came from the processor, I could assume they are held hi-z during reset and just pull high the U11 inputs, but they come from U114 (PAL) and it doesn't have a reset input so I don't know what is doing during reset. LxW come from some gates so no luck there either.

Miti
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #54 on: January 24, 2025, 04:00:12 pm »
...
There is a reset supervisor on the HP RAM board and on my board. Actually I think it is the only reset supervisor, it doesn't make sense to have more than one as you cannot run the SA without the RAM board.

There is indeed a TL7705ACD supervisor (U3) on the memory board, but it is not providing reset functions to the rest of the unit.  The only thing it's doing is protecting the RTC (U106, RTC72421) from spurious writes when +5D is out of spec.  It's the only place where the LPF (power fail detect) signal is going.  Why they chose to put this function on the memory board, I don't know.

The system reset is controlled via a signal coming out of the power supply, HPWRUP (J13-37, aka "WRUP").  This eventually makes it to the LRST (/RESET) input on the processor. See "POWER UP" block K on the processor schematic.

The two DS1210S on the memory card (U4, U5) are providing the write protection for the old memory by preventing LUSERRAM0 and LUSERRAM1 from getting to the chip selects when +5D is out of spec (<4.62V typ).
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #55 on: January 24, 2025, 05:08:45 pm »
Thank you Mark for the info!
In this case I’ll need to do some scoping. TL7705 reset pulse, with 100pF capacitor is only 1.3us, the supervisor that I selected is 1.7ms. We may have a problem here.

Edit1: I may have to use the same TL7705 supervisor, it is still active.
Edit2: Wait a minute, the FRAM power up time is 450us…. I knew that but it didn’t occur to me until now that this may not work. If the reset time from the power supply is less than that, this FRAM cannot be used.  |O
« Last Edit: January 24, 2025, 06:43:35 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #56 on: January 24, 2025, 10:13:23 pm »
Thank you Mark for the info!
In this case I’ll need to do some scoping. TL7705 reset pulse, with 100pF capacitor is only 1.3us, the supervisor that I selected is 1.7ms. We may have a problem here.

Edit1: I may have to use the same TL7705 supervisor, it is still active.
Edit2: Wait a minute, the FRAM power up time is 450us…. I knew that but it didn’t occur to me until now that this may not work. If the reset time from the power supply is less than that, this FRAM cannot be used.  |O
That's what I would do - just duplicate their circuit for the TL7705.  That chip and its supporting components is really an island on this board, and it's driving the RTC which has nothing to do with the new memory design.  Substituting a different reset circuit could only introduce issues for the RTC.  Maybe you could take advantage of the LPF output for your FRAM write protect scheme.

The FRAM power up time may be ok.  The FRAM Vdd_min is 2.7V.  So, the FRAM gets a head start as +5D ramps to 5.0V, plus whatever timer the power supply is using to release the reset line.  You should take a look with a scope.  You want a really wide margin here since you don't know what the variability will be from system to system.  Unfortunately there are no schematics or detailed enough specs for the power supply to even guess at what the HPWRUP delay might be.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #57 on: January 24, 2025, 11:24:21 pm »
re: FRAM power up time...

The MC68HC000 datasheet says in AC Electrical Specifications footnote (pg 3-54):

   4.  For power-up, the MC68HC000 must be held in the reset state for 100 ms to allow stabilization of on-chip circuitry.

So, if HP did their design correctly to meet this spec, the FRAM will have plenty of time for its 450us power up.  But I would still check it with a scope.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #58 on: January 25, 2025, 03:19:12 am »
re: FRAM power up time...

The MC68HC000 datasheet says in AC Electrical Specifications footnote (pg 3-54):

   4.  For power-up, the MC68HC000 must be held in the reset state for 100 ms to allow stabilization of on-chip circuitry.

So, if HP did their design correctly to meet this spec, the FRAM will have plenty of time for its 450us power up.  But I would still check it with a scope.

Yes, they designed it well. The first ... something, I cannot call it activity, on the LUSERRAM0 line happens after more than 200ms of stable 5V.
The real activity starts after almost 1ms.
What do you think about my timing diagram in reply #52?

Edit: I've added the power down sequence. The LUSERRAM0 activity stops at about 4.6V, can't be very precise with an 8 bit scope. That means that if I use the  monitor on my board to disconnect /CE at power up/dn, I cannot do it in the middle of an access, so the threshold of my monitor must be below 4.6V to start the power down sequence for the FRAM after the processor stops accessing it.
« Last Edit: January 25, 2025, 02:39:02 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #59 on: January 25, 2025, 09:33:51 pm »
So, there's gobs of time on startup - that's good.

The idling on power up after 200ms (after the very brief LUSERRAM0 blip) could be a further startup delay implemented by the firmware, or maybe it's polling a sub-system waiting for it to be ready.  But it doesn't really matter; just an observation.

Good idea to look at the power down.

On power down, the processor is not paying attention to any impending power fail signal that I can see.  Either the power supply pulls down /RESET and stops it, or the DS1210 inhibits access to the SRAM chips and it crashes.  It would be good to know who is calling it quits first.

The DS1210 triggers between 4.50V and 4.74V, with a typical value of 4.62V.  Given your scope capture, it could be /RESET (HPWRUP from the power supply) or one or both of the DS1210.  You can find out for certain by capturing the processor /RESET and both memory /CE. 

If it is the DS1210, I guess it's possible the processor could be in the middle of a 16-bit word write and one of the DS1210 has not triggered yet, resulting in only one byte of the word being written.  Software can deal with that scenario for critical data, but who knows what they did.  I'm hoping it's the /RESET that stops everything, since that is being driven by the power supply and it certainly knows when power is going out, but your scope capture implies otherwise.

I will look at the timing diagram.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #60 on: January 25, 2025, 11:56:42 pm »
...
What do you think about my timing diagram in reply #52?
The timing looks like it would work for the FRAM, but I'm not sure you need to go through all the trouble for extra delays on /LB, /UB, and /WE.  I also looked the schematic.  Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

If you read the text of how the various signals work, the FRAM is very forgiving in the order in which things happen.  As I mentioned before, the write occurs on the rising edge of /WE or /CE.  /LB and /UB have to be setup 25ns before that (tBLC).  /LB and /UB can coincide with /WE (or /CE) since it's the rising edge that matters and the /LB and /UB hold time is 0ns (tBH).  Said another way, /LB and /UB must not change 25ns before either /WE or /CE goes high.

The address has to be stable 0ns (tAS) before /CE goes low, but if they change afterwards the new address is latched and it operates in a /CE low cycle.

Maybe try this:  You have the following control signals coming into the board: LUSERRAM0, LUSERRAM1, LOE, LLW LUW.  The FRAM inputs are /CE, /UB, /LB, /WE, /OE.  Write the logic equations for the FRAM inputs in terms of the incoming signals.  Or sometimes it's clearer to write out all the combinations in a truth table, in this case 32 rows, with inputs on the left and the desired outputs on the right.  Then it might be easier to see if any gate delays, one-shots, or any other signal massaging is necessary.

EDIT: And another FRAM input to include, if you do equations or a table, is A17.
« Last Edit: January 26, 2025, 12:05:36 am by MarkL »
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #61 on: January 26, 2025, 03:43:20 am »
Good idea to look at the power down.

On power down, the processor is not paying attention to any impending power fail signal that I can see.  Either the power supply pulls down /RESET and stops it, or the DS1210 inhibits access to the SRAM chips and it crashes.  It would be good to know who is calling it quits first.

The DS1210 triggers between 4.50V and 4.74V, with a typical value of 4.62V.  Given your scope capture, it could be /RESET (HPWRUP from the power supply) or one or both of the DS1210.  You can find out for certain by capturing the processor /RESET and both memory /CE. 

If it is the DS1210, I guess it's possible the processor could be in the middle of a 16-bit word write and one of the DS1210 has not triggered yet, resulting in only one byte of the word being written.  Software can deal with that scenario for critical data, but who knows what they did.  I'm hoping it's the /RESET that stops everything, since that is being driven by the power supply and it certainly knows when power is going out, but your scope capture implies otherwise.

I will look at the timing diagram.

It must be the power supply because I'm probing on the connector, before DS1210. I need to make sure I don't reset the memory before the power supply resets the processor.
« Last Edit: January 26, 2025, 03:45:41 am by Miti »
Fear does not stop death, it stops life.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #62 on: January 26, 2025, 04:08:24 am »
The timing looks like it would work for the FRAM, but I'm not sure you need to go through all the trouble for extra delays on /LB, /UB, and /WE.

I think you're right about the WE, maybe it doesn't need a delay, I'll reevaluate. However, without delay on LB, UB and A17, I risk that LB, UB or the address changes right before or in the same time with LxW or LUSERRAMx.

Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

They are, U8 takes care of that. They are both low when LxWs are either low or hi, and only one is low when a byte write happens.

Maybe try this:  You have the following control signals coming into the board: LUSERRAM0, LUSERRAM1, LOE, LLW LUW.  The FRAM inputs are /CE, /UB, /LB, /WE, /OE.  Write the logic equations for the FRAM inputs in terms of the incoming signals.  Or sometimes it's clearer to write out all the combinations in a truth table, in this case 32 rows, with inputs on the left and the desired outputs on the right.  Then it might be easier to see if any gate delays, one-shots, or any other signal massaging is necessary.

EDIT: And another FRAM input to include, if you do equations or a table, is A17.

I honestly don't have time for that, I've put enough time in this project. I'll grow a Greybeard soon... :-DD
« Last Edit: January 26, 2025, 04:42:11 am by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #63 on: January 26, 2025, 06:25:23 pm »
Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

They are, U8 takes care of that. They are both low when LxWs are either low or hi, and only one is low when a byte write happens.
My mistake - sorry.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #64 on: January 26, 2025, 10:48:39 pm »
I drew the time diagrams for writing without any delay and with delay on A17, LB, UB only, no flip flops. The one without delay is worrisome, I see troubles.
The one with delays on A17, LB, UB looks ok.
Noooow, I also drew the reading cycle aaand it does not look good. Or it may be ok, depends where the data is strobed.
The strobe interval is only about 30ns before LUSERRAMx goes high because that line is part of the address and the address to data valid is 110ns.
HM628128 allows about 50ns more data valid.
Can you guess at what point in my scope captures the read data is latched in the processor?
An exercise of imagination...? I may have to go to two chips only to eliminate the LUSERRAMx from the address and keep the LB, UB scheme.

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

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #65 on: January 27, 2025, 01:35:12 am »
Going with two FRAM chips might preserve your sanity, but I still think it's doable with one.

The CPU strobing control is implemented with gates and not inside a PAL, thankfully, so read and write timing can be determined.  The gates are in the processor schematic block B "Address Decoding".

I'll save you some time and say that data is latched into the CPU on the rising edge of LOE.  LOE is derived from LAS (address strobe) and the R/LW signal.  Perhaps the name is misleading, but the rising edge of LAS is when the incoming data is latched.

LAS also goes to PAL U114 where it is combined which a bunch of address lines to create strobes for specific address ranges, two of which are LUSERRAM0 and LUSERRAM1.  So, LUSERRAMx will coincide with LOE.  But I would base timing off LOE since it does not go through a PAL black box.

You have a couple of examples showing LOE and RAM0 (LUSERRAMx) coinciding: DS1Z_QuickPrint1.png and DS1Z_QuickPrint12.png.

In terms of using LUSERRAMx as an address input and /CE, that is ok as long as the FRAM address inputs [A17:A0] change before or exactly when /CE goes low.  This is because tAS (address setup time) is specified as 0ns.  And if you meet this requirement, the access time is tCE (55ns).  If you don't, access time is tAA (110ns).  This seems a little odd when you compare to regular SRAM, but the datasheet acknowledges that is the way it works (but unfortunately doesn't give any further explanation which I'd be interested in hearing why).

EDIT: The timing diagram is from here (pg 5-3), plus all the detail you'd ever want to know: https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf
« Last Edit: January 27, 2025, 01:42:18 am by MarkL »
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #66 on: January 27, 2025, 03:37:06 am »
Going with two FRAM chips might preserve your sanity, but I still think it's doable with one.

The CPU strobing control is implemented with gates and not inside a PAL, thankfully, so read and write timing can be determined.  The gates are in the processor schematic block B "Address Decoding".

I'll save you some time and say that data is latched into the CPU on the rising edge of LOE.  LOE is derived from LAS (address strobe) and the R/LW signal.  Perhaps the name is misleading, but the rising edge of LAS is when the incoming data is latched.

Phew  :phew: thanks Mark! That means I'm safe with one FRAM.

In terms of using LUSERRAMx as an address input and /CE, that is ok as long as the FRAM address inputs [A17:A0] change before or exactly when /CE goes low.  This is because tAS (address setup time) is specified as 0ns.  And if you meet this requirement, the access time is tCE (55ns).  If you don't, access time is tAA (110ns).  This seems a little odd when you compare to regular SRAM, but the datasheet acknowledges that is the way it works (but unfortunately doesn't give any further explanation which I'd be interested in hearing why).

In this case I should delay CE just enough so it comes after A17 is stable. Regardless, LB and UB need delay otherwise they may change before WE rising edge.
Fear does not stop death, it stops life.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #67 on: January 27, 2025, 12:09:06 pm »
Me like this with delay on CE and LB, UB. I think this is it. And it will give me 55ns to data valid for reading as well.
What do you think Mark?
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #68 on: January 27, 2025, 04:45:13 pm »
That looks pretty good.

LUSERRAM0 can go directly to A17.  /CE is derived from LUSERRAM0 and LUSERRAM1, requiring additional gates, so you're automatically going to get your delay there.

I think you're right you may need to delay /UB and /LB a little.  /CE could beat them going high at the end of the cycle instead of /WE, which should also work.

It would be nice if the datasheet provided more detail on /UB and /LB internal operation.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #69 on: January 28, 2025, 03:35:00 am »
Thanks Mark!
Here's the final schematic, I hope, and a preliminary to final layout. It was surprisingly easy to layout.
I've added an option for another inverter, in case I need more delay on /CE which is unlikely.

Cheers,
Miti
Fear does not stop death, it stops life.
 
The following users thanked this post: bingo600

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #70 on: January 28, 2025, 07:15:25 pm »
Looks good.  I think this is what we discussed.

The only minor comment I have is that the 2-4 decoder and six inverters could be simplified to be a pair of AND gates, /LB=LLW*LOE /UB=LUW*LOE, but the logic works as drawn.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #71 on: January 28, 2025, 07:47:40 pm »
FWIW, I set up a quick test on my 8595E to look at the DS1210 behavior vs. the power supply HPWRUP (--> processor reset) to see who wins the race on power off.

By monitoring LUSERRAMx input and LUSERRAMBx output, it's possible to tell when the DS1210 cuts out due to low voltage.

It's close, but the power supply triggers the /RESET first at 4.70V.  This value is above the DS1210 typical spec of 4.62V, but still overlaps with the DS1210 max spec of 4.74V.  So, the weird scenario of a half-word write could happen, but there's too many pre-requisites to be worried about it.  Probably HP should have selected the lower voltage threshold for the DS1210 of 4.37V typ (4.49V max) to have a better margin.

Below is a scope capture of the power off event.  Channel 4, which is monitoring the 5V power supply, was calibrated using a DMM, so I am confident of the voltage value shown on the screen.  You can see the LRAM0 input with the LRAMB0 output continuing to be repeated through the DS1210 right up until the reset stopped the processor.

A test of the other DS1210 on LUSERRAM1 and LUSERRAMB1 showed the same result.

Doesn't affect anything in your design, but I was curious to know.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #72 on: January 29, 2025, 03:22:23 am »
Looks good.  I think this is what we discussed.

The only minor comment I have is that the 2-4 decoder and six inverters could be simplified to be a pair of AND gates, /LB=LLW*LOE /UB=LUW*LOE, but the logic works as drawn.

Yes, you're right, I didn't think to use the LOE line. However, one AND gate would not give me the necessary delay, so I still need to use a series of buffers.
Also, the cost of two gates is about the same as one decoder and I don't have to route another line so I'll keep it as is for now.
Fear does not stop death, it stops life.
 

Offline Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #73 on: January 29, 2025, 03:28:47 am »
FWIW, I set up a quick test on my 8595E to look at the DS1210 behavior vs. the power supply HPWRUP (--> processor reset) to see who wins the race on power off.

By monitoring LUSERRAMx input and LUSERRAMBx output, it's possible to tell when the DS1210 cuts out due to low voltage.

It's close, but the power supply triggers the /RESET first at 4.70V.  This value is above the DS1210 typical spec of 4.62V, but still overlaps with the DS1210 max spec of 4.74V.  So, the weird scenario of a half-word write could happen, but there's too many pre-requisites to be worried about it.  Probably HP should have selected the lower voltage threshold for the DS1210 of 4.37V typ (4.49V max) to have a better margin.

Below is a scope capture of the power off event.  Channel 4, which is monitoring the 5V power supply, was calibrated using a DMM, so I am confident of the voltage value shown on the screen.  You can see the LRAM0 input with the LRAMB0 output continuing to be repeated through the DS1210 right up until the reset stopped the processor.

A test of the other DS1210 on LUSERRAM1 and LUSERRAMB1 showed the same result.

Doesn't affect anything in your design, but I was curious to know.

Interesting test and ...woow, NICE SCOPE!!!
I selected a supervisor with a threshold voltage of 4.63V but I may need to go down to 4.38V to avoid any issues.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #74 on: January 29, 2025, 03:58:57 am »
...
Interesting test and ...woow, NICE SCOPE!!!
Thanks - It's an R&S MXO4 4-ch 12-bit 1.5GHz.  I'm still learning to be proficient with it and I really like the screen.  Unfortunately it's not ready to be my daily driver as it's still a bit green.  I submitted six bugs on it today, and there's a seventh that I'm having trouble re-creating.  But that's a topic for another thread.  I used it on this test because I wanted the extra precision for the single-shot capture.

Quote
I selected a supervisor with a threshold voltage of 4.63V but I may need to go down to 4.38V to avoid any issues.
I think the reset you have is going to be fine.  The likelihood of the weird case happening is extremely small, and it's no worse than the old SRAM module.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf