cpu/avalon bug ?

Altera_Forum · ‎08-17-2006

Hi all,

i wrote a custom peripheral (called 'simple_registers'), designed as an avalon slave. My peripheral is byte access based and uses the following Avalon signals:

entity simple_registers is

port(

clk : in std_logic;

reset_n : in std_logic;

chipselect : in std_logic;

address : in std_logic_vector (7 downto 0);

write : in std_logic;

writedata : in std_logic_vector (7 downto 0);

readdata : out std_logic_vector (7 downto 0);

irq : out std_logic;

read : in std_logic

);

I wanted to verify avalon transactions during read and write accesses, so I looked at the avalon signals using SignalTap II logic analyzer.

Here is my problem :

When I write a byte (stb instruction in my sample code below) , everything is fine : chipselect is asserted for 1 clock period and all other signals are correct.

*addr_test=0x55;

0x04001fd0 <main+52>: ldw r3,-32632(gp)

0x04001fd4 <main+56>: movi r2,85

0x04001fd8 <main+60>: stb r2,0(r3)

But when I read a byte (ldbu instruction in my sample code below) , avalon transaction is not as I expected : chipselect and read signals are asserted for 4 clock periods , I was expecting only one clock period (as for the stb instruction). It seems that the CPU perform a word access (adress are incremented 4 times) . Nevertheless all other signals are corrects.

temp= *addr_test;

0x04001fdc <main+64>: ldw r2,-32632(gp)

0x04001fe0 <main+68>: ldbu r2,0(r2)

0x04001fe4 <main+72>: stb r2,-32628(gp)

I should also mention that addr_test address pointer is set to bypass the cache (bit 31 set to '1').

Also in SOPC component editor , I selected 'memory (use dynamic bus sizing)' in the avalon slave setting. My CPU is a NIOS2/S with 512 bytes instr cache.

Where Am I wrong ? Can anybody help me ?

Sheers.

Altera_Forum · ‎08-18-2006

Hi bigboss25,

this behavioral is absolutly correct.

if you read the avalon documentation you will notice that a read from nios is always 32bit regardless if the software does a byte (8bit) word (16bit) or long (32bit) access. the "unwanted" bits are not used.

this is so. you have to live with that and maybe need some workarounds.

i had these problems too in the past but nowadays all sopc modules are fully 32bit as nios is a 32bit core.

try to change your module to 32bit and use the information that is inside the byteenables as they also show which 8bit are accessed like they do on write cycles. this workwaround works fine with quartus 6.0sp1 but i am not shure if it will in the future. but this works only with io commands like ldbio.

i had to "modify" my thoughts to design 32bit sopc modules even if the design inside is 8 bit. even all avalon masters are 32bit now and i do the 32-8bit conversion inside the module.

but this behavioral of reading more than selected by software is realy a pain if you try to attach an 8bit external device to a tristate bridge.

hope this helps you.

Michael Schmitt

Altera_Forum · ‎08-18-2006

You're right , I was wrong and I did not read the spec enough http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/rolleyes.gif

Thx a lot !