Re: IORD 11.0 vs IORD 9.1

Altera_Forum · ‎03-22-2012

Hello,

int main()
{
	int i;
	
	while(1)
	{
		i = IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_BASE);
		printf("PIO EDGE CAP: %d\n", i);
		IOWR_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_BASE, 0x0);
		usleep(1000000);
	}
}

BUTTON is a 4-bit PIO in my SOPC.

If I run this code with Nios II 9.1 I read: PIO EDGE CAP: 0

If I press BUTTON[0] I read: PIO EDGE CAP: 1

..

If I press BUTTON[3] I read: PIO EDGE CAP: 8

Now:

If I run the same code with Nios II 11.0 I read: PIO EDGE CAP: 512

If I press BUTTON[0] I read: PIO EDGE CAP: 513

..

If I press BUTTON[3] I read: PIO EDGE CAP: 520

What does it means?

Altera_Forum · ‎03-22-2012

First thought is that IORD() is a request for a 32bit value, the system will have a 'bus width adapter' that converts the single 32bit read into four 8bit reads - and your avalon slave returns the same value for all 4 bytes.

But that should generate 0x01010101 and 0x08080808.

Perhaps there is some address decode going on.

You are much better off using 32bit slaves.

Altera_Forum · ‎03-22-2012

If I change the width of my PIO to 1 bit I read the value 64 when it captures no edge and 65 when it captures an edge at the input... the strange thing is that with the old version I didn't have this problem.

Altera_Forum · ‎03-22-2012

For a n bit PIO only lower n bits of register are significative.

The upper bits are not supposed to be initialized nor driven and must be treated as don't care.

Then you must mask the valid bit field and test only this part of register output.

In the case of 4bit pio:

i = IORD_ALTERA_AVALON_PIO_EDGE_CAP(BUTTON_BASE) & 0x000F;

So, 513 and 520 become 1 and 8.

The different behaviour of these undriven bits depends on logic synthesis and sometime on previous signal status on those bit lines. So I think what you see it's pretty normal

Altera_Forum · ‎03-22-2012

Thank you for the answers.

I resign myself to this and I'm going to mask the bits. :)