mjoergen / hyperram

Portable HyperRAM controller

Hi there 👋

hyperram's Issues

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.

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.

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.

Make clock phase delay dynamically programmable

The following waveform shows the expected behavior

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.

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?