post edit --- got it working for a de2-115
@wass and others With a fresh head i had another go and matched some of the unknown parameters with the Terasic TCL. I have now created a successful tristate controller and bridge to allow the nios to run on SRAM.
note the original problem is obviously the terasic part. i have a feeling because it may use the old sopc tri-state set up and hence the problems with qsys. i'm guessing though. how to get it working I have attached a zip file with the images you'll need, showing the settings and connections.
you'll see the timing is actually more conservative than the sram datasheet says. i imagine that it could be improved and its possible that my set up isn't using one of the tighter running modes of the ram; but it works. - Make a "Generic Tri-state controller". Match all the settings to the screen shots in the attached zip.
- Insert a "tri-state conduit bridge".
- Connect the two together.
- Connect the Avalon MM slave of the controller to you CPU data and instruction masters.
- Connect clocks and resets.
- Set you Nios in QSys to use the Tri controller for reset and exception vectors.
- In Nios EDS, edit your BSP settings on the linker page to use the tristate controller.
- Connect the top level signals as per the code quote below. Note that i swizzled the Byte enable bits together. i assume this is correct, but maybe not since it appears their use is optional? (this works)
- There ya have it, my dodgy SRAM.
// SRAM - Using Tristate Bridge
.sram_tcm_address_out (SRAM_ADDR), // sram.tcm_address_out
.sram_tcm_outputenable_n_out (SRAM_OE_N), // .tcm_outputenable_n_out
.sram_tcm_byteenable_n_out ({SRAM_UB_N,SRAM_LB_N}), // .tcm_byteenable_n_out
.sram_tcm_read_n_out (), // .tcm_read_n_out
.sram_tcm_write_n_out (SRAM_WE_N), // .tcm_write_n_out
.sram_tcm_data_out (SRAM_DQ), // .tcm_data_out
.sram_tcm_chipselect_n_out (SRAM_CE_N), // .tcm_chipselect_n_out
Thanks to Socrates and BadOmen for their advice.
Onto the next challenge for me.