mjoergen / hyperram

Portable HyperRAM controller

HyperRAM

This repository contains a portable OpenSource HyperRAM controller for FPGAs written in VHDL. I'm writing my own implementation because I've looked at several other implementations, and they all seemed lacking in various regards (features, stability, portability, etc.)

The HyperRAM controller in this repository is a complete rewrite from scratch, and is provided with a MIT license.

Learn more by reading the documentation in this repository or by browsing the companion website: https://mjoergen.github.io/HyperRAM/

Features

This implementation has support for:

• Maximum HyperRAM clock speed of 100 MHz.
• Variable latency.
• Configuration registers read and write
• Identification registers read
• Automatic configuration of latency mode upon reset.
• 16-bit Avalon Memory Map interface including burst mode.
• Written for VHDL-2008

All the source files for the HyperRAM controller are in the src/hyperram directory, and all files needed for simulation are in the simulation directory.

Porting to another platform may require hand-tuning of some clock parameters, see the section on porting.

Example Design

I'm testing this HyperRAM controller on the MEGA65 hardware platform (revision 3). It contains the 8 MB HyperRAM chip (link to datasheet) from ISSI (Integrated Silicon Solution Inc.). Specifically, the part number of the HyperRAM device on the MEGA65 is IS66WVH8M8BLL-100B1LI, which indicates a 64 Mbit, 100 MHz version with 3.0 V supply and a single-ended clock.

I've written a complete Example Design to test the HyperRAM controller on this MEGA65 platform. The additional source files needed for this are placed in the src/Example_Design directory.

Getting started

The HyperRAM controller has just two interfaces, one for the external HyperRAM device and one for the client (user) of the HyperRAM. For the client interface I've chosen the Avalon Memory Map protocol. This is an industry standard and is easy to use. The interface width is 16 bits corresponding to one word of the HyperRAM. The addressing is in units of words, not bytes.

The Avalon interface supports burst mode, where you can read or write multiple words in a single HyperRAM transaction. Section 3.5.5 in the Avalon Memory Map specification describes burst mode in detail.

To see an example of how to use the HyperRAM controller and how to connect it to the internal FPGA logic and to the external HyperRAM device, have a look at the Example_Design, specifically at the top level file and the trafic generator.

Make sure that you are aware of the necessity of Tri-State-Buffering. It is good design practice to infer the tri-state buffers from the top-level file.

The HyperRAM configuration and identification registers can be accessed through the same Avalon Memory Map interface via the following addresses:

• 0x80000000 : Identification Register 0 (Read-only)
• 0x80000001 : Identification Register 1 (Read-only)
• 0x80000800 : Configuration Register 0 (Read-write)
• 0x80000801 : Configuration Register 1 (Read-write)

Avalon Memory Map interface

Here is a brief summary of the signals involved in the Avalon Memory Map interface. For full details, refer to Section 3 of the specification. The HyperRAM controller uses "Pipelined Read Transfer with Variable Latency", see section 3.5.4 and Figure 12, and supports burst mode, see section 3.5.5. It does not use the "waitrequestAllowance" property.

Signal	Description
write	Asserted by client for one clock cycle when writing data to the HyperRAM
read	Asserted by client for one clock cycle when reading data from the HyperRAM
address	Address (in units of 16-bit words)
writedata	Data to write
byteenable	1-bit for each byte of writedata to the HyperRAM
burstcount	Number of words to transfer
readdata	Data received from the HyperRAM
readdatavalid	Asserted when data from the HyperRAM is valid
waitrequest	Asserted by the device when it is busy

Further reading

The following links provide additional information:

• Example Design
• Porting guideline
• Detailed design description
• Simulation

hyperram's Issues

csn not latching in IOB

on my workstation with own toplevel I see warning that CSN is not registered in IOB (the other signals are).

I am using not this code from here, but the code from MEGA65 fork...

p_fsm : process (clk_i)
begin
if rising_edge(clk_i) then
hb_csn_o <= '0'; -- added by Antti
hb_rstn_o <= '1';

when I add the above line then CSN registers in IOB and design still works!
not sure if that is proper fix or not.

VUnit support

Vunit simulator support.

Instead of a dedicated VHDL module that generates traffic use Vunit modules that handle Avalon (or any other CPU bus) based transactions + add randomization for address and data.

Because testbench contains one Verilog file, GHDL can't be used. For local tests Free Modelsim versions were used.

32 bit wide DATA

Any plans to support 32 bit wide avalon data bus? It would make the use much easier!

ISSI die rev D errata

there is a errata (you need request the document from ISSI) for ISSI revision D dies, in short it says that all writes must be at least two clocks long, that is you need to write always 4 bytes (using RWDS to mask unused bytes).

Does this core support this errata? I a guessing the core does short writes and always would hit this ISSI errata?

Memory corruption during burst write

Short description

This bug only happens when writing with burstcount > 1, i.e. when issuing writes of more than 2 bytes. Basically, the controller ignores the byteenable input on all but the first clock cycle. This bug was observed in the ILA while investigating issue #2.

To reproduce

Start a write with burstcount = 2 and write the following:

1. cycle: data = X"BBAA" with byteenable = "11"
2. cycle: data = X"DDCC" with byteenable = "01"

Expected behavior

The memory is updated with the three bytes X"AA", X"BB", and X"CC".

Observed behavior

Four bytes are written to memory, i.e. the fourth byte X"DD" gets written as well, thus corrupting one byte of memory.

Controller locks up on some boards.

This is observed when connecting a PicoLemon HyperRAM module to the PMODs of a QMTech Wukong board.

I suspect the problem is due to the increased latency through the board traces and PMODs.

Make clock phase delay dynamically programmable

The following waveform shows the expected behavior