Nios II to SRAM via Tri-State Bridge

[Altera_Forum]

Let's see how long it takes to get a 'good' answer to this question: :D 

 Ok, I have a Nios II system (32-bit data width) connected to a single 16-bit SRAM through an Avalon Tri-State Bridge (the one they have a module for in SOPC v8.1: IDT71V416).   Now, there are no configuration options in SOPC for the Bridge data width and I was expecting the bridge to handle the translation from 16 to 32 and vice-versa but apparently it doesn't since the .ptf file shows all data to be 32-bits and more imporantly since my system doesn't work. :eek:  Question: Is there a way to configure the Avalon Tri-State Bridge to handle the translation from 32 to 16 bits? Can the Avalon Tri-State Bridge even do this?  My backup plan is to write some VHDL to handle the translation but before I do the work, I wanted to know if it was already possible.  Thanks!

[Altera_Forum]

Are you using the SoPC builder component "IDT71V416"? If so, your problem is that the component is only for a 32-bit wide interface. That component was used specifically for 4 development boards that used two of the IC's in parallel. What you need to do is create a custom tri-state component with a 16-bit wide data bus. No you don't need to write any VHDL. You just need to let SoPC builder know that your component is 16 bits wide. 

 Jake

[Altera_Forum]

Jake is rigth, all you need to do is 

 open your sopc builder project chose menue FILE -> New component change to TAB Signals Button "Add Signal" rename the new Signal clk change its Interface to clock sink add more new signals like adr, data, nrd nwr... choose interface avalo_tristate_slave if your component has negative logik choose read_n otherwise read as signal type.  if you add your data interface, choose width to 16 and direction to bidir. you should now have a minimum of clock, data,adr,nrd,nwr,ncs don't worry about the direction, it is from the components view so read is input (output from fpga) change Signal Type to clk change to Tab Interface Button ADD INTERFACE Change default type to "Avalon Memory Mapped Tristate Slave" Setup your Timing according to your device datasheet, you can enter nSec as SOPC will take care about that. now finish your component and feel free to use it  be aware of that you should check your avalon tristate bridge after adding this component about the shared signals  creating such a component is quit easy and done within a couple of minutes including reading datasheet ....

[Altera_Forum]

and don't forget to shift the address bus so a0 of the NIOS is unsed, a1 of NIOS connects to a0 of SRAM and so on...

[Altera_Forum]

Ok... now I have this issue where bit8 of my 16bit databus is always set HI. Before I turn on the SignalTap or solder wires to my board for the Logic Analyzer, has anyone see something like this before; related to the SPOC build paramaters? 

 I have tried a 2nd board and it exhibits the same problem.  Starting to debug now but if anyone has any suggestions, i'm more than happy to hear them. :-)

[Altera_Forum]

Nope. Typically the cause is that it's not connected on the board and is floating high. 

 Jake

[Altera_Forum]

So, The problem is internal to the FPGA. 

 I swapped the FPGA pins for bit8 (the one that is stuck high) and bit9 and the stuck bit followed to bit9.   Something is fishy inside the FPGA (i'm thinking the SOPC but i'm about to hook up signal tap to find out for sure).  More to come...

[Altera_Forum]

Hi, I too faced a similar issue initially which i solved using a custom 16 bit interface. But still when i try to download my application to the SRAM it shows error while verification. what could be the possible reason..:confused:

[Altera_Forum]

Hi, I had a quite similar problem in the following configuration. 

- 16 bits SRAM on the board - Custom SRAM component in SOPC builder - cs, ws, oe, add, 16 bits data controlled by custom component - beh, bel stuck to 0 in VHDL - mapping of a0 => a1 in VHDL  All was functional when I was using "run configuration as" but the NIOS didn't boot in stand alone mode (boot copying from FLASH to SRAM). I saw with Signal Tap that all accesses to SRAM during the boot were in 8 bits mode instead of 16 bits.  The solution was to add the control of beh and bel by the SRAM custom component, because it was not able to recognize a 16 bits SRAM with the 16 bits data bus specification !  Hope this helps.