Performance Issues

The 150ns of time between reads to your peripheral could be for a lot of reasons depending on the implementation of your custom user logic and the amount of processing you are doing between reads. Maybe you could provide a little more info on what you are trying to do.

If you really need to do high speed transfers, you should consider using the DMA controller.

Two things come to mind that might be the reason for the double reads. The first is whether or not you are running the debugger. The debugger will access the memory. Second, if you are not running the debugger are you looking at the address appropriately? Does the processor have access to 16 bits of data on your SRAM? It may be doing byte reads, first byte in first read and second in second read.

Verify your SRAM setup in SOPC Builder and be sure it matches your part in terms of size and latency.

Good luck.

You should notice that a read is always 32 bit wide.

Regardless of your target.

If for example you have an 8bit slave you will have 4 cycles (4x8=32)

If the slave is 16 bit then ypu will have 2 cycles (2x16=32)

in fact if your software does a char (8bit) read this leads to a 32bit read and the 24bit that are not wanted will be ingnored.

the only difference is a write. a slave with 8 bit will have 1 cycle if the write is 8 bit wide.

one of the avalon documents says that a master must set all byteenables for a read cycle !

This is the reason why it ist currently nearly impossible to connect an existing profibus chip (8bit) to the avalon switch fabric. some registers inside the chip interprete a read even if this access is not intended by the software but done in hardware

have you monitored your custom component with signal tap ?

in the beginning i had readdata as a n-bit wide register. this lead to the problem that the first cycle with chipselect loads this readdata register and the next one is needed to have the output available and so i had to insert 1 waitstate. furthermore check the sopc setting of your custom component.

nowadays the readdata is a wire with a set of combinatorical logic and now each access is only 1 clock cycle long, regardless of read or write.

Michael Schmitt

Thank you everyone for all your information.

MSchmitt, when you stated :-

"nowadays the readdata is a wire with a set of combinatorical logic and now each access is only 1 clock cycle long, regardless of read or write."

what did you mean ?

--- Quote Start ---

originally posted by shmueld@Jul 11 2006, 10:53 AM

thank you everyone for all your information.

mschmitt, when you stated :-

"nowadays the readdata is a wire with a set of combinatorical logic and now each access is only 1 clock cycle long, regardless of read or write."

what did you mean ?

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=16796)

--- quote end ---

--- Quote End ---

With this statement i mean that the oldway i did a avalon slave was :

internal_signal -> DFF -> ReadDatabit

where the internal_signal was combinatorical with the internal signal selected by the address.

Now i have changed that in a way that i have removed the DFF. ReadData is now a wire instead of a reg (in verilog language)

wire [31:0] avs_MyModul_readdata;

assign avs_MyModul_readdata =

( avs_MyModul_address === 6&#39;H00 ) ? { 32&#39;d12345678} :

( avs_MyModul_address === 6&#39;H01 ) ? { 32&#39;d87654321} :

{ 32&#39;d87654321};

Reading from slave address 0 will be 1234567, address 1 will be 87654321 and all others will be 0

this read is only 1 clock cycle long (or short :-) ) no need to assert avs_MyModul_waitrequest

is it now clear to you ?

Michael Schmitt

--- Quote Start ---

originally posted by mschmitt@Jul 11 2006, 04:34 PM

this is the reason why it ist currently nearly impossible to connect an existing profibus chip (8bit) to the avalon switch fabric. some registers inside the chip interprete a read even if this access is not intended by the software but done in hardware

--- Quote End ---

Just for my understanding:

How about setting the address allignment to native mode, implement a 32 bit slave and use only bit 7-0 (bits 31-8 going to nowhere). This should give you the behaviour you need.

Or am I wrong?

Unfortunately you are.

all of these profibuschips have both memory and registers with a single chipselect. the data to and from the profibus is stored inside the chip so this chip-memory area must be a memory inside the nios datamaster that the software can use 8/16/32 Bit access and even memcopy(move) operations without takeing care about that this device is a 8 bit device. (all available softwarestacks need this and we do not want to re-write such an stack an certify it) on the other hand with the same chipselect you gain access to the registers and some of them monitor a read access, so if you want to read a 8 bit register, but executed is 4 read cycles, then you do in real life a read from 3 registers that are not accessed by the software.

the crazy thing is that the byteenables indicate which byte is requested. so the only workaround is to insert a statemachine between avalon and the profibuschip that fetches only these byte that are requested by the software. this works fine here.

so for the software it is neccesary to have a memory modul instead of a register modul to get rid of the gaps in the memory. but no additional (wasted) read cycles.