DMA and PCI in SoPC Builder

Hi All,

I have some problems using SoPC builder (5.1) with DMA and PCI (Altera PCI compiler 4.1.0). I have system with PCI with 4 BARs, 4 user interfaces (three of them are actually memories, but implemented outside of the system) and DMA controller.

The PCI has this configuration: BAR0 1MByte, prefetchable - user memory BAR1 32kBytes, nonprefetchable - control io BAR2 4kBytes, nonprefetchable - control memory1 BAR3 1kByte, nonprefetchable - control memory2

"control io" is is connected to control port on DMA, CRA registers on PCI and some registers outside of the system

"user memory" is main memory of the system.

the DMA controller has connected its read port to PCI access, write port to the "user memory". it is configured to use burst transfers of

128 bytes, uses only words (because the PCI is 32bit), and it has 20bit length register.

The first problem The DMA has 20bit length register. But when I write to the Length register anything that is longer than 10 bits, the DMA stops responding and does nothing. The way to produce is write 0x8C to the Control register (GO, Words only, Length=0 stop), zeroing the Status register and then write to the Length register. With lengths smaller than 0x400 it works fine.

And the second one I haven't found how to use IRQ of the DMA - is it functional? Maybe it is problem of PCI megacore... I want to create a PCI interrupt after end of DMA operation to let the control driver know that the operation is finished. I have enabled interrupts from Avalon (bit 7 of register

0x14 in PCI CRA), then I have set the I_EN bit in DMA Control register (bit 4), but the interrupt does not happen. It is also weird, that I dont see any IRQs in the SoPC builder, but the PCI should support IRQ...

Do you anyone know, where could be the problem?

Any help appreciated,

Martin

Reply to
Martin
Loading thread data ...

Martin,

You may want to post this on "

formatting link
" as well. You'll probably get a better/faster response from that Forum.

Regards,

- Brendan

Reply to
brendan.rankin

The DMA interrupt is definitely functional, although I've only connected it to the NIOS, and not the PCI core.

Regards, Mark

Reply to
Mark McDougall

I've not worked with interrupts in SoPC builder, but I suppose tha the interrupt should be visible. I've seen somewhere in examples/documentation that a column named IRQ appears in SoPC builder, but I don't have anything like this in my system configuration... I suppose that there should be some possibility to assign IRQ number to a device that can raise interrupt, am I right?

Martin

Reply to
Martin

Martin,

The PCI Compiler does not provide a way to handle interrupts in Avalon/SOPC Builder. Your options are to instantiate a small Nios II core, design your own IRQ management master.....or wait for the next release of the PCI Compiler core, which should certainly address this.

- Brendan

Reply to
brendan.rankin

Brendan,

it really does not? It is mentioned in the PCI compiler user guide, that it can generate PCI interrupts...

Martin

Reply to
Martin

Martin,

While it is true that the PCI Compiler can generate PCI interrupts, it cannot manage Avalon (SOPC Builder) interrupts. So, while the PCI Compiler can generate PCI interrupts, I don't believe there is a way to associate this to Avalon/SOPC Builder IRQs. I think that you can generate PCI interrupts on other Avalon/SOPC Builder "events", just not interrupts.

It's a simple oversight, with a pretty simple workaround. If you need help with it, please contact me directly (via e-mail).

What do you plan to connect via PCI? Just curious.

Cheers,

- Brendan

Reply to
brendan.rankin

Page 7-74 of PCI IP 4.1.0 user-guide:

"The following events ca cause a PCI interrupt

- Avalon asserts the IRQ signal

- Avalon writes to one of the mailbox registers

- An error condition is detected"

"The Avalon IRQ input causes a bit to be set in the PCI interrupt status register. When you need to assert a PCI interrupt, this bit can be enabled."

That's why I wonder, that the interrupt does not work.

Martin

Reply to
Martin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.