Parallella Community

Epiphany Architecture Reference, Rev. 14.03.11

Pages 135/136: The AUTOxDMA1 register is a copy/paste of the AUTOxDMA0 register.

Theres an error in: parallella_manual.pdf

In figure 5 the dimension is wrong should be 3.4" but you have it as 3.275". Also if you going to correct this may I say the figure isn't very clear. I think it would be better to have all the dimensions coming off the bottom left corner. Also the centre of the connectors should be included.

Bren

This thread would be a lot more maintainable if it were split into separate threads for each document (e.g. Epiphany Architecture Reference in one, Epiphany SDK Reference in another, etc.) and if each document thread were split into separate threads for each revision.

This said, my post concerns the Epiphany Architecture Reference, rev 14.03.11, page 136. Table 38 is a copy of table 37 on the preceding page, whereas it was meant to describe the DMAxAUTO1 Register (which holds the upper 32-bits of the DMA slave mode receiver register pair).

Epiphany Architecture Reference, rev 14.03.11, page 136. Table 39, bit [1] reads:
"Sets up DMA channel to work in master made"
but should read:
"Sets up DMA channel to work in master mode"

Epiphany Architecture Reference, rev 14.03.11, page 138, DMAxCOUNT reads:
"The upper 16 bits specify the outer loop of the DMA transfer and the and lower 16 bits of the register specify the number of inner loops."
but should read:
"The upper 16 bits specify the outer loop of the DMA transfer and the lower 16 bits of the register specify the number of inner loops."

Epiphany Architecture Reference, rev 14.03.11, page 139, DMAxSRCADDR reads:
"The updated address is equal to the old source address added with the value in the destination field in the stride register."
but should read:
"The updated address is equal to the old source address added with the value in the source field of the stride register."
DMAxDSTADDR should also change "field in the stride register" into "field of the stride register".

Epiphany Architecture Reference, rev 14.03.11, page 140, DMAxSTATUS, bit [3:0] reads:
"while the DMA is not in in an IDLE state"
but should be:
"while the DMA is not in an IDLE state"

Epiphany Architecture Reference, rev 14.03.11, page 141, DEBUGCMD reads:
"A write only alias register used to place control the debug state of the Epiphany core from an external agent."
but should be:
"A write-only alias register used to control the debug state of the Epiphany core from an external agent."

Epiphany Architecture Reference, rev 14.03.11, page 144, Table 51 (IMASK register) bits [9:0] reads:
"ILAT Latched interrupts waiting to enter CPU"
which is identical to the bits [9:0] line of Table 48 (ILAT register), page 142. I strongly suspect that Table 51 is incorrect, at least in its labelling.

Epiphany Architecture Reference, rev 14.03.11, page 147, page 58 (MEMSTATUS) reads:
"WRITE_BREACH Read from external agent attempted with DIS_EXT_WR==1"
but should be:
"WRITE_BREACH Write from external agent attempted with DIS_EXT_WR==1"
or maybe:
"WRITE_BREACH Read from external agent attempted with (DIS_EXT_WR_MMR || DIS_EXT_WR_MEM)==1"
because there is no DIS_EXT_WR bit.
In the same table, we read:
"XWRITE_BREACH Write to on-chip cores attempted with DIS_CORE_XWR=1"
which should be:
"XWRITE_BREACH Write to off-chip attempted by a core with DIS_CORE_XWR=1"

I also presume that if a core has write-protected its local memory with MEMPROTECT's PAGE0 through PAGE7 bits, another core's attempt to write there would cause a MEMSTATUS MEM_FAULT of the target core? What is the exception raised on the writing core in this scenario?

Epiphany Architecture Reference, rev 14.03.11, page 148, table 59 (MESHCONFIG), bit [7:4] reads:
"The even monitored can be programmed as an input to CTIMER0 or CTIMER1."
but should be:
"The event monitored can be programmed as an input to CTIMER0 or CTIMER1."

Epiphany Architecture Reference, rev 14.03.11, pages 150-151, unnumbered table (RMESHROUTE), bit [5:3] reads:
"EAST_CONFIG 0xx: normal routing
100: block northbound transactions
101: send northbound transactions south
110: send northbound transactions west
111: send northbound transactions north"
but should be:
"EAST_CONFIG 0xx: normal routing
100: block eastbound transactions
101: send eastbound transactions south
110: send eastbound transactions west
111: send eastbound transactions north"

bit [8:6] reads:
"SOUTH_CONFIG 0xx: normal routing
100: block northbound transactions
101: send northbound transactions west
110: send northbound transactions north
111: send northbound transactions east"
but should be:
"SOUTH_CONFIG 0xx: normal routing
100: block southbound transactions
101: send southbound transactions west
110: send southbound transactions north
111: send southbound transactions east"

bit [11:9] reads:
"WEST_CONFIG 0xx: normal routing
100: block northbound transactions
101: send northbound transactions north
110: send northbound transactions east
111: send northbound transactions south"
but should be:
"WEST_CONFIG 0xx: normal routing
100: block westbound transactions
101: send westbound transactions north
110: send westbound transactions east
111: send westbound transactions south"

The table needs to be numbered too, of course.

Epiphany Architecture Reference, rev 14.03.11, page 152 reads:
"The STATUS register can be written using the MOVTS instruction or [...]"
but should be:
"The STATUS register can be written to using the MOVTS instruction or [...]"

"Status bits [2:0] are ready only bits controlled by the operational state of the CPU, but can be written forcibly through the FSTATUS alias."
I suspect should rather be:
"Status bits [2:0] are bits controlled by the operational state of the CPU, but can be written forcibly through the FSTATUS alias."

Epiphany Architecture Reference, rev 14.03.11, pages 153, table 64 (XMESHROUTE) has the same problems as unnumbered table RMESHROUTE, pages 150-151.

Epiphany Architecture Reference, rev 14.03.11, pages 130, table 32 (CMESHROUTE) has the same problems as unnumbered table RMESHROUTE, pages 150-151.

Epiphany Architecture Reference, rev 14.03.11, page 156, table 67 reads:
"0111=fpu excpetion"
but should be:
"0111=fpu exception"
In the same table:
"RDMESHROUTE"
should be
"RMESHROUTE"

Epiphany Architecture Reference, rev 14.03.11, page 157, table 68, revision 3.13.9.29 reads:
"Fixed lots of typos (an probably added some more..)"
but should be:
"Fixed lots of typos (and probably added some more...)"

I submitted a pull request for the SUB OV/AV flag here:
https://github.com/adapteva/epiphany-docs/pull/2

Please double check that I didn't make a mistake.

The documentation states that TESTSETD (double word testset) is supported:
https://github.com/adapteva/epiphany-do ... md#testset

I would try testing it, but binutils doesn't support it:
https://github.com/adapteva/epiphany-bi ... .cpu#L1611

Short of twiddling bits in the assembled binary, can anyone confirm which way is supposed to be correct? Does Epiphany-III hardware support TESTSETD with a 32-bit address and 64-bit payload? Should binutils be updated?