Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

IORD 11.0 vs IORD 9.1

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?

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thank you for the answers.

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