News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0890 HyperRAM burst example

Started by pramber, September 04, 2020, 01:08:27 PM

Previous topic - Next topic

pramber

I am using the open source IP to access the HyperRAM:
https://github.com/blackmesalabs/hyperram

This includes a very simple test design, where every 32 clocks a write and read test occurs.
Has somebody an example on how to access the HyperRAM over the IP core as fast as possible (burst mode)?
As I can interpret the Verilog code only bursts of 2 words or rather 2 dwords are supported. But my Verilog expertise is very limited and maybe it is not a big deal to perform long bursts.

JH

Hi,
please check:
https://forum.trenz-electronic.de/index.php/topic,1320.0/topicseen.html
there are links to different HypeRAM  IP solutions (free and commercial versions).

or maybe Joris on the other post can help you,  he try to implement his own IP.

br
John

Joris van Rantwijk

Hi Pramber,

I have not used the BlackMesaLabs core so I'm not really sure how it works in detail.

Indeed I designed my own HyperRAM controller for the TE0890 in VHDL. It supports arbitrary burst length.
Unfortunately my tests sometimes detect bit errors. This happens extremely rarely (once every few days), but I'm very unhappy about it.

My code is available here:
https://github.com/jorisvr/te0890-utils/tree/master/hyperram_test

It would be great if you could test my controller on your TE0890 module. So far I developed and tested this on just one TE0890, and it gives these errors, and I have no idea whether my HyperRAM chip is just broken or if there is still a bug in my code.

If you decide to try my code, please let me know how it works for you.
To be clear: I do of course understand if you don't have time to try this or you prefer to choose another HyperRAM core. No pressure.  8)

Joris.

pramber

Hi Joris,

thanks for your reply and that you provide your HyperRAM controller for the community.
I will make a stab at your IP core. I am very excited on the results because we are using a custom board very similar to the TE0890 (Spartan 7 and HyperRAM part). But there are some fine differences, for example our supply voltage is 1.8V instead of 3.0V, so theoretically we could run the clock with 166 MHz.
As soon as I have results I will inform you.

Kind regards,
Bernhard

pramber

I had to adapt some odds and ends but your controller is running so far.

RS232 output works as well:

R=0003 F=00000000
P=0000 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=ff00 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=aa55 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=cc33 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=f00f B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
R=0004 F=00000000
P=0000 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=ff00 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=aa55 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=cc33 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=f00f B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000


I keep you up to date.

Joris van Rantwijk

Hi Bernhard,

Great that you got the controller running. It would be nice if you can use it for your project.
The test sequence is pretty thorough in my opinion, so this result is already a strong indication that the interface is working correctly.

As I mentioned, on the TE0890 I see unexplained error burst approximately once per day which are driving me crazy.
Let me know if you see something similar, but let's hope not.

Are you running at 100 MHz?
I have some doubts whether 166 MHz is feasible with the method I used to capture read results.

pramber

Yes, the clock frequency is 100 MHz. This should be fast enough for our application.
It is still running without any errors (round 221). I will test it over night and hopefully the error counter stays at zero.

pramber

Unfortunately, after approximately 26 hours the first error appeared. One single bit fell over.
R=0589 F=00000000
P=0000 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=ff00 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=aa55 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=cc33 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000000
P=f00f B=001 B=002 E=0-15d001-3-f00f-f00b B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
R=058a F=00000001
P=0000 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=ff00 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=aa55 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=cc33 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=f00f B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
R=058b F=00000001

I will continue with the test and report any further errors.

JH

Hi pramper,
can you tell me which FPGA you use on your custom board? --> exact name with package and speed grade.
which Hyperram did you use on your custom carrier (part name of the hyperram)?
Which Vivado version did you use? this can also make difference on optimization and place and route of the design.

You use 3.3V instead of 1.8V. With max 166MHz your running on ~60 of the max speed.
@Joris: How long does your core works on TE0890 when you run it with max 60MHz?
We still need to know which FPGA Pramper has exactly to compare better but that would be a good starting point to isolate the cause of the issue

br
John

Joris van Rantwijk

Quote from: pramber on September 10, 2020, 03:04:40 PM
Unfortunately, after approximately 26 hours the first error appeared. One single bit fell over.

Ouch. Interesting that it is just a single-bit flip. When I hit an error with my TE0890, it is usually a burst of hundreds of errors and often multiple flipped bits per word. So perhaps we are seeing different error mechanisms, however the time between errors seems to be in the same ball park (approximately once per day).

Still I would expect an interface like this to be 100% reliable if correctly implemented. I have been scratching my head over possible causes but I just can't figure it out.

Quote from: JH on September 11, 2020, 09:47:42 AM
@Joris: How long does your core works on TE0890 when you run it with max 60MHz?

I tested once at 50 MHz and got an error after 120 hours.
At 80 MHz, I got an error after about 24 hours.
At 100 MHz, I typically see the first error after 24 hours.
Recent tests at 100 MHz show the first error typically after 48 hours after I cleaned up my 5 V supply (separate PSU instead of USB, extra capacitor, common-mode ferrites on cables).

It should be noted that these numbers are statistically weak because some tests were done only once and others just a few times.
Due to the low error rate, it would take weeks to reliably determine the error rate for a given set of conditions.

For example, it looks like my error rate dropped after cleaning up the 5 V supply, but I really doubt whether that difference is statistically significant. Even the 120 hour survival at 50 MHz does not look so extreme once you take into account that the number of memory transactions in that test is equivalent to just 60 hours at 100 MHz.

I should also note that changing the clock frequency also requires adjusting the timing of the read data path. This is because I use CK as the read capture clock, not RWDS. The BlackMesaLabs core also uses this method by the way.

pramber

We are using the Spartan 7 XC7S25-2CSGA225I and the HyperRAM IS66WVH8M8ALL-166B1LI with a supply voltage of 1.8V.
Therefore our clock is differential connected between the FPGA and the RAM (Cmos levels).

The software is the Vivado v2019.2 (64-bit).

I stopped the test after 36 hours and no further errors occurred.
R=0773 F=00000001
P=0000 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=ff00 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=aa55 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=cc33 B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=f00f B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
P=rrrr B=001 B=002 B=003 B=004 B=005 B=010 B=03f B=200 F=00000001
R=0774 F=00000001

JH

Hi,
TE0890 use XC7S25-1FTGB196C with IS66WVH8M8BLL-100B1LI @3.3V (sorry I mixed power supply on the last post ), so your custom board FPGA has has better speed grade.

This makes it significantly better in terms of performance than TE0890. This makes it harder to compare, I will think about it.

Did you changed something between this 36h test and the last one which failed after 26h?

br
John

pramber

I didn't change anything. It was just one long test over 36 hours where one error occurred after 26 hours.

AcM

Hi pramber,

I'm tring to use the controller with a 1.8V hyper ram @100MHz without success.
After just 8 reads it starts with errors and after a while stop making request.
What did you changed to the controller?
Regards

AcM

Sorry, my mistake, a day to find it out... the controller works great.