Has anyone replaced HP8591(E) SRAM by FRAM?

[Miti]

I've ordered a FM22L16 to see if I can discover the reality.  I can use an STM32H7 nucleo board that I have laying around as a pattern generator which will allow me to independently control each FRAM control signal with 2.5ns granularity.  With software it will be easy to put things in any arbitrary order.  Do you have a scope capture when the FRAM board is not working (e.g., without the delay)?

No, I don’t have. I only started saving screenshots after the programmer, and the SA, started working.
I’m curious what you find out with your experiment.

It's even more interesting that your analyzer booted at all.  I pulled the SRAM from mine and it doesn't boot.  So, in the non-delay case, the FRAM module is *partially* working or marginal.

My guess is because the 16bit was working. It’s only the 8bits that wasn’t working.

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.  There are also silicon delay lines (e.g., DS1100L-xx series), but not cheap.

I’ll take a look at the monostable. I can’t use delay line, the delay must happen only on the falling edge, rising edge must be fast.

Edit: Yes, I could use an AND gate  but at $12 they are expensive.

[Miti]

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.

Do you have a schematic? I can't figure out how to do this.

Edit: Looking at the application data sheet, I don’t think I can get a delay below about 80nS with 74LVC123.

[MarkL]

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.

Do you have a schematic? I can't figure out how to do this.

Edit: Looking at the application data sheet, I don’t think I can get a delay below about 80nS with 74LVC123.

Yes, it looks like the LVC can't get below that.  There are some other series that are a little faster, but still probably not what you want.  I can draw it if you're still curious how it could be used to delay a leading edge.

A plain RC delay can do 1's or 10's of nanosecond speeds.  See below.  Any kind of delay element or circuit, like a series of slow gates or the silicon delay line, can take the place of the RC.   An 8 channel bus driver with the gates daisy-chained is another way to get a pile of gate delays.

There's a somewhat oddball and dated part that's cheaper than a silicon delay line: 74LS31 ($1.27  at Mouser).  It's a collection of elements with different delays.  The elements are controlled to specific tolerances in manufacture and they are in the delay range you want.

[MarkL]

Eh, the 74LS31 is not so great after looking deeper into the datasheet at min/max delay bounds over extreme temperature and Vcc.  Probably remove that from consideration.

[Miti]

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.  There are also silicon delay lines (e.g., DS1100L-xx series), but not cheap.

Actually, I simulated the circuit that you posted and it is not as predictable as one may think. If the repetition rate is high the delay is one, after a long high level, it is different. To be honest I never liked timing circuits that depend on RC circuits. At least with the oscillator I clearly know that the delay is between a bit over one period and a bit under two periods, and that interval is very well defined.

I have the new layout for one chip and two chips boards, but I will hold for awhile pending the results from your experiment.

Cheers,
Miti

[MarkL]

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.  There are also silicon delay lines (e.g., DS1100L-xx series), but not cheap.

Actually, I simulated the circuit that you posted and it is not as predictable as one may think. If the repetition rate is high the delay is one, after a long high level, it is different. To be honest I never liked timing circuits that depend on RC circuits. At least with the oscillator I clearly know that the delay is between a bit over one period and a bit under two periods, and that interval is very well defined.

I have the new layout for one chip and two chips boards, but I will hold for awhile pending the results from your experiment.

Cheers,
Miti

With the RC delay it's also possible to add some steering diodes: one to limit the peak voltage on the capacitor, and another to discharge it more quickly.  Something like below.  But point taken it may still not be as predictable as desired.

The xx123 is more predictable since internally it's using comparators.  The fastest one I can find is about 40ns.  It's also possible to build a one-shot out of a pair of high speed comparators to get into the 10ns range, but again those comparators don't come cheap.

The pile of gates for delay may not be so bad.

Have you tried clocking your delay flip-flops with a function generator?  Is there any delay range where the analyzer stops working?


I'm working through some issues with the board support package for this STM32H7 Nucleo board that I have.  I can get get it working the way I want for this test, but cite the 53 page thread "Is ST Cube IDE a piece of buggy crap?"  The answer is "yes".

  https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/

[Miti]

Have you tried clocking your delay flip-flops with a function generator?  Is there any delay range where the analyzer stops working?

No, I have not but the good part about the oscillator is that I can calculate its frequency exactly, based on where I want my /WE pulse to land.

Edit: I looked again at the /WE spread scope shot and realized it gives me a lot of info. I think the timing is acceptable as is, proof is that the SA works well for many hours. The minimum /WE pulse is 16nS, the shot shows about 20nS. To make it even better, I could move it to the left about 6-7 nS (change the oscillator from 25MHz to 30MHz), and that should also shorten the spread by 13.34nS.

[Miti]

Hi Mark,

Did you have any success with the FRAM and the Nucleo?

Miti

[MarkL]

Hi Miti,

I've resolved the SW issues with the Nucleo board, and have the FRAM and a break-out board in-house.  I need to assemble it and write the test SW.  Still a bit more to do.  I have some other activities getting in the way at the moment, and I apologize for the delay.

I know you want to get your board done.  You have a working solution, and I won't be insulted if you decide to proceed.

The general plan is to be able to read/write the FRAM under SW control via GPIO bit-bang for initialization and read-back with known data, and then use the FMC (memory controller) peripheral to stream control pin changes clocked at 200MHz to the FRAM control inputs.  The data I/O pins from the FMC will drive the control inputs on the FRAM, so any arbitrary sequence of control ordering can be created, and at any timing, by crafting the data out pattern.  After streaming some high-speed test writes using this method, all locations will be read back at slower speed and checked for valid writes in the expected locations, and invalid data or writes to a wrong location.

Previously, I thought I could achieve 2.5ns granularity, but there is a "CLK+1" in the FMC timing specifications, so I will get 5ns granularity with a 400MHz processor clock (that's the max).  I verified the 5ns FMC timing with a scope on the Nucleo board, so I am confident this approach will work.  5ns should be sufficient for our purposes, but if something is really close, there's always physical coax delays that can be introduced. 

I kind-a wish I hadn't sold my 300MHz 24-channel Agilent 16720A pattern generator several years ago.  I never used it, but it would have been perfect for this.

I will post updates.

[Miti]

Insulted? No, I don’t think there’s reason to feel insulted. There’s a more selfish reason behind this waiting. I want to see if there is an eureka moment that allows me to simplify the board. Now I hope this confession doesn’t insult you. 

[Miti]

What do you think about this circuit instead of the flip-flop or RC delay. Three 74HC buffers give me a delay of a bit under 20nS, six should delay by almost 40nS. No clock, no RC. I should give it a try.

[MarkL]

I like the gate delay approach.  That diagram works.

If you're still in the experimenting frame of mind, you could use non-inverting buffers (e.g., xx244, xx365, xx367) and zero-ohm SMD links between the gates.  Then you could experiment with delay between 0 and 8/6 gates.


On the test setup, I had some time to build the FRAM breakout board.  Next step is to get it wired up to the Nucleo board.  I'll probably need to use some tiny coax runs + series termination for the control pins because of the edge speed.  The header pins stick out the bottom about 0.4" so it's convenient to do the Nucleo connections all on one side, and probing on the other.

[Miti]

If you're still in the experimenting frame of mind, you could use non-inverting buffers (e.g., xx244, xx365, xx367) and zero-ohm SMD links between the gates.  Then you could experiment with delay between 0 and 8/6 gates.

 No, I'm not, so I will do this. Options on the final board.

[Miti]

Hi, I'm back.
I have finalized three version of this FRAM boards. Single FRAM chip with flip flop delay on /WE, single chip with buffer delay, and dual chip. I decided to order only the last two, not only because of the boards cost, but because the shipping for two boards was $2.15 CAD, while for 3 boards it jumped to over $ 15.
I received the boards yesterday and to my surprise one has the mounting holes plated and one un-plated. Whyyyyyy? 
The boards are copy -> paste -> modify so why are they different? 3D view in Kicad shows un-plated and so does the JLCPCB 3D view.

Miti

[Miti]

Ok, so the answer to the question "Has anyone replaced HP8591(E) SRAM by FRAM?" is yes, I have.
Here is the version with single FRAM chip and the /WE control signal is delayed with 74HC14 inverters only, no flip-flops and oscillator. I've made the HC bold because is important for the correct delay. Not LVC, not AHC, but HC. For D1, or D2, pick one, whichever you prefer, they should be both low reverse current and low forward voltage drop so they should work, I have not tested long term though. I also have the boards for a dual FRAM version, the glue logic is simpler but the main cost is the FRAM so it doesn't make sense to spend more if the single chip works so well. I have the parts, I may populate and test one board just for fun one rainy day.

If anybody is interested in this project, likes it, and wants to make a small contribution to my effort, please PM me and I'll send you my Paypal.

Cheers,
Miti

[Miti]

The programmer:

Here is an adapter board that helps with the transfer of content from the original HP8590 RAM to the FRAM using a memory programmer.
Tested with Xeltek SP5000 and TL 866II Plus. Xeltek works very well, TL 866 needs external 5V on the pins 16 and 32 of the pin header, otherwise it will not supply the voltage to release the reset line. I have used a programmable power supply set to 5V, 100mA. Calibration constants are there, personalities, settings, you just need to set the date and time. Make sure you remove the jumper while reading the original RAM to avoid any risk of altering the content, and install it to write into the FRAM. Also save it somewhere.
 
Enjoy!

[MarkL]

Great - glad everything is working with the HC delay!

I've been traveling for the last several weeks but will get back to finishing the FRAM characterization, if only for informational purposes at this point.  Will post here when done.