Bit or byte swapping in SDRAM?

--- Quote Start ---

Is there any reason the Avalon-ST components would be doing the swapping? Is this an issue with the SDRAM controller? Having some trouble debugging, so any help would be appreciated.

--- Quote End ---

Be careful if you are coding in VHDL if you have code like this;

signal d : std_logic_vector(31 to 0);

signal q : std_logic_vector(0 to 31);

since

q <= d;

will bit-swap. Whereas

process(d)
begin
   for i in 0 to 31 loop
      q(i) <= d(i);
   end loop;
end process;

will retain the same bit index assignments between q and d.

If you have instantiated an IP core with the bus bit order reversed, then you would see this as a bit-reversal in your final design.

Cheers,

Dave

I'm confident that my bit Verilog module is coded correctly and I'm not swapping bits. I found the problem to be in the Avalon-ST component definition. I had switched the "Data Bits per Symbol" parameter to 8 so I wouldn't need an adapter down the line.

So, my ST data bus is defined as "output reg [31:0] st_data" in the top level module. I assumed incorrectly that since my data bus is 32 bits wide, if I chose bits per symbol to be 8 then it would automatically set symbols per beat to 4 and my byte ordering would remain intact.

What am I doing wrong here?

-Jason

--- Quote Start ---

What am I doing wrong here?

--- Quote End ---

Have you written a testbench? If not, you should.

Demonstrate the issue in a testbench and post an image of the Modelsim screen shot, or a PDF, along with the code.

That'll help clarify what you are trying to describe.

Cheers,

Dave

Hi Dave,

I do have a testbench for the module, but haven't yet found an easy way to simulate part of an overall qsys project after Quartus synthesis.

I have isolated the issue to how I create a new component in qsys with my module, so I think I can show what's going on with the attached screenshots.

The Avalon-ST data bus port is defined as above: output reg [31:0] st_data

qsys1 - This shows all of my input and output ports with their interface definitions

qsys2 - The ST source interface - note that I entered 32 "Data bits per symbol" in the parameter box. The data bits are all correctly ordered as [MSB:LSB]

qsys3 - I connect the component to an ST sink (the timing adapter) and feed 2 channels into individual FIFOs

qsys4 - The timing adapter (and all downstream ST components) need to be defined with 32 "data bits per symbol" and 1 "Data Symbols per Beat."

When I program the Nios CPU to read from the FIFOs, the bit ordering is correct. I get signed integers from the ADC and life is good.

The problem is when I change "Data bits per symbol" to 8 in the ST interface definition (qsys2.jpg). I then need to redefine all of my downstream ST components to also have 8 "Data Bits per Symbol" and 4 "Data Symbols per Beat." When the system is built in this way, my data bus is no longer read as [31:0], but rather {[7:0],[15:8],[23:16],[31:24]}.

There's nothing really "wrong" with defining 32 bits per symbol, but I want to make this consistent with other ST components to have byte-wide symbols. That way I can connect my components together directly without changing data formats.

--- Quote Start ---

I do have a testbench for the module, but haven't yet found an easy way to simulate part of an overall qsys project after Quartus synthesis.

--- Quote End ---

I haven't used the Altera-defined Avalon-ST components and their associated component customization.

Here's what I would do if I felt that the components were doing the wrong thing;

1) Simulate; add an Avalon-MM Master BFM component to the SOPC System, and use that to generate read/write transactions. (The BFM uses SystemVerilog, so Modelsim-ASE has to use verilog for the SOPC system).

2) Capture the hardware waveforms using SignalTap. Compare to (1).

3) Try various component settings and repeat (1) and (2).

If things don't appear to be correct, then delete the Altera component and write my own :)

Cheers,

Dave