Host interrupts, driver, etc.

[notzed]

I presume (hope!) this is merely just a "we''re working on it" question, but here goes anyway.

From the examples (and e-hal), there seems to be no way for the ARM to "wait" for epiphany cores to complete without either sleeping "in hope", or presumably a busy wait reading an absolute location. A quick glance through the e-hal code seems to suggest there isn't a device driver as such and the whole chip is just controlled using memory mapped i/o.

I guess my question is: will the epiphany cores eventually be able to raise interrupts on the host device, and have it exposed one way or another via e-hal. i.e. at least a non-busy 'wait', but I guess the FPGA allows for all sorts of possibilities - from a simple interrupt bit to (bi-directional) a hardware mailbox, etc.

I presume the FPGA logic has access to raising interrupts and like other ARM SOCs i've looked at the zynq has a pile available.

Or is this just something which for now will be open for us users to experiment with?

I searched through the forums but all I saw was talk about e-core to e-core communications.

[aolofsson]

We haven't implemented a way yet for the Epiphany core (or other peripheral logic) to interrupt the ARM core, but it was always the plan (I hate polling on so many levels:-)). Here is an article from Jan Gray on implementing interrupts with memory mapped IO on the zynq:

http://fpgacpu.wordpress.com/2013/05/28 ... -part-two/

As it seems Adapteva is eternally running behind schedule with an infinite to-do list, the question is whether there anything we can do to make it easier for people to contribute/help with improvements like these?

Andreas

[timpart]

[tnt]

That just doesn't make sense ...

1) you can't just pick random ranges, depending on which port of the AXI interconnect you're connected to, you have to fit in this or that address range.

2) There would be no such things as "Epiphany side address". The epiphany won't be able to talk to those peripherals directly anyway because the e-link is connected to the HP (high performance) AXI interconnect of the PS which can only talk to the DDR and the OCM.

3) The device tree is exactly there to _avoid_ having any assigned / hardcoded addresses or IRQ. When you assemble your FPGA bitstream, you select the address (or let the tool auto-assign) and IRQ and then you add a node in the device tree saying which device driver to load, where the device is in memory and what IRQ it's wired to.

[mhonman]

Although I've not tried to read and write host-filesystem files from Epiphany code, the neccessary I/O functions are at least present in stdio.h. Perhaps there is a roundabout route in which the Epiphany core writes to a Unix pipe on the host filesystem, which the host process can wait on?

[notzed]

[ysapir]

STDIO should be working when using the e-gdb. It is not so much different then the polling method and external memory shared buffers, but rather than the host (debugger) polling on a shared "mailbox", it polls on the status of the debugged core - waiting for the "TRAP" state.

It does not work in a non-debug session, as there is no host-side server for dealing with this traffic.

[notzed]

[aolofsson]

Tim, Sylvain:

I agree with both of you.

1.) To improve modularity and collaboration we should definitely give more guidance on how to add/customize FPGA logic to play nicely with the Epiphany.

2.) The current FPGA design is really just a first stab at a Parallella system design and it's not optimal. Things will really get interesting when folks start streaming data through the PEC_GPIO interface and I am convince that we will need to redesign the FPGA system at that time. Still lots of open questions regarding what the micro-archtiecture should look like. The Zynq has a lot of cool features that we haven't had time to use yet.

3.) Eventually we hope to have a solid Parallella reference design where folks could easily "put code" here and be up and running with their own optimal custom Parallella loads quickly.

Examples from our "todo" list for FPGA logic:
1.) We currently don't use the cache coherent AXI port. (might be useful for some..)
2.) Interrupt inputs to ARM system from FPGA logic (chapter 7 of Zynq TRM)
3.) How to use the DMA (make e-hal faster). (see chapter 9 of Zynq TRM)
4.) Increase speed of FPGA logic
5.) Full cross bar allowing communication between Epiphany and GPIO directly.
6.) Implement a custom Epiphany DMA engine in PL to avoid eLink read penalty.

Andreas

[TheKr1S]

Are there any plans/progress on the items on the todo list? These items are very wished, especially items 5 an 2.