MAx 10, External SRAM

--- Quote Start ---

You could create a Platform Designer (aka Qsys) system design and use the tri-state components (generic tri-state controller, tri-state conduit bridge) to do this instead of creating your own logic.

--- Quote End ---

Hi SStrel, in first thank for prompt answer, I am far from LAB to apply a test now.

Here attached the code I wrote and TCL script for QSYS. Compared to UNIVERSITY program (seen later on seeking your suggestion), seems very close, U.P. is written in Verilog I prefer VHDL.

On "Generic Tristate Controller" you suggested there is a device close to mine, IDT71V416, using this block device is forever 32 bit.

If I select that device then edit all parameters adapting to device, it appear as tristate driver more than an SRAM controller. I suppose some other block need be attached and it is not clear to me now how to use these blocks.

Doing this, portability across family and vendors broke and here is why I prefer wrote my code.

I'm also stuck at quartus version 15.1, new version report error if pin near clock get used and offer no way to override compiling a previous working design.

Best regards

Roberto

The tristate controller is a driver. You then need a master in your system that connects to the Avalon slave interface of the tristate controller to issue read and write commands to the SRAM. It's old, but see this user guide:

https://www.altera.com/en_us/pdfs/literature/ug/ug_avalon_tc.pdf

Hi SStrel, tank a lot for assistance, that document was the first I found by googling around, at this moment I am not able to use this controller due it refuse reduce to 16 bit bus, I try more later.

About my code why

SRAM_Data <= avalon_slave_writedata when avalon_slave_write='1' else

(others => 'Z');

refuse to input/output data?

I am using similar code to read write an external bus (unrelated to SRAM) and it work fine, on RAM forever read 0 and seems not writing data to.

Next week I can collect some spare time and I test it Thorougly again to try isolate the problem from design. Using internal FPGA RAM work(final board with 10M50SC), using external DRAM (test board) it work, SRAM controller seems faulty. Again I cannot use nor NIOS nor JTAG debugger, when inserted on design refuse to compile with an error relative to Config flash, no way at this moment to inspect from internal bus, I arrange some test from external Logic Analyzer pod.

Best regards

Roberto

--- Quote Start ---

Hi SStrel, tank a lot for assistance, that document was the first I found by googling around, at this moment I am not able to use this controller due it refuse reduce to 16 bit bus, I try more later.

About my code why

SRAM_Data <= avalon_slave_writedata when avalon_slave_write='1' else

(others => 'Z');

refuse to input/output data?

I am using similar code to read write an external bus (unrelated to SRAM) and it work fine, on RAM forever read 0 and seems not writing data to.

Next week I can collect some spare time and I test it Thorougly again to try isolate the problem from design. Using internal FPGA RAM work(final board with 10M50SC), using external DRAM (test board) it work, SRAM controller seems faulty. Again I cannot use nor NIOS nor JTAG debugger, when inserted on design refuse to compile with an error relative to Config flash, no way at this moment to inspect from internal bus, I arrange some test from external Logic Analyzer pod.

Best regards

Roberto

--- Quote End ---

Again thank for hints and moral support too, sometimes things behave differently than HDL seems be...

About this problem where where found how trouble come from.

Component generated from QSYS fabric, on TOP were redirected to local signals before pin, all work fine with input or output pin leaving space to test them and sample with an external connector not for tristate.

To test Input and output from tristate pin, tristate driver need to be replicated at TOP then sample in and out not from pin but from readdata and writedata. If read from INOUT it doesn't work at all:

- INOUT pins are no more connected the right way

- it generate bad code stuck to something not sure ('0' '1' or data)

- tristate function is lost to INOUT pins.

Removed this threat, then all core behave same way, my core, university core, also tristate controller; ( I solved about parameters reading another tons of docs). Every controller now read a strange "400A" pattern all across the RAM and also everywhere there is nothing on Avalon.

This I fear need a huge hardware debug and connection of LA to external bus, Actually I don't own a dev board with SRAM on it so I plan build an adapter to fit on some dev kit 40 pin connector and study what happen from there. I own micro grabber for LA bought long time ago, they perfect fit on .5mm but my eyes are no more the same.

The best way for next chip can be to have some internal SRam and or SDRam to avoid external fit with all these troubles and reducing pin count too.

Best regards

Roberto