Documentation Errors

Forum for anything not suitable for the other forums.

Re: Documentation Errors

Postby sebraa » Mon Aug 18, 2014 2:53 pm

Epiphany Architecture Reference, Rev. 14.03.11

Pages 135/136: The AUTOxDMA1 register is a copy/paste of the AUTOxDMA0 register.
sebraa
 
Posts: 495
Joined: Mon Jul 21, 2014 7:54 pm

Re: Documentation Errors

Postby Bren » Thu Aug 28, 2014 12:16 pm

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
Bren
 
Posts: 10
Joined: Thu Aug 28, 2014 8:30 am

Re: Documentation Errors

Postby Urhixidur » Thu Feb 26, 2015 5:13 pm

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?
User avatar
Urhixidur
 
Posts: 16
Joined: Mon Jan 19, 2015 7:19 pm
Location: Québec, QC, Canada

Documentation Errors (continued)

Postby Urhixidur » Thu Feb 26, 2015 10:25 pm

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...)"
User avatar
Urhixidur
 
Posts: 16
Joined: Mon Jan 19, 2015 7:19 pm
Location: Québec, QC, Canada

Re: Documentation Errors

Postby snim2 » Sun Jul 19, 2015 11:06 pm

The following are issues with version v14.03.11 of the Epiphany Architecture Reference Manual... I've tried to split this up to make it a litlre more readable...

Issues with the decode table (pp 155)


  • In LD/STR(INDEX)(32) and RM should be RN
  • The BITR instruction has a 5-bit immediate integer, according to the decode table on page 155, but on page 81, the instruction only takes operands from registers.
  • FLOAT, FIX and FABS have some extra bits in the decode table for an RM operand, even though these instructions are unary
  • In the last row of the decode table, the UNIMPL instruction is marked as 16 bit but cannot fit into 16 bits, this should be written as UNIMPL(32)

Issues in Appendix A


  • BCOND example on pp 80 add r1,r1#1 ; some operation should be add r1,r1,#1
  • In description of ADD and SUB (pp 76 and 108) flag OV should be AV
  • In description of JALR (pp 100) LR = PC; should be LR = PC + 2 (16 bit), PC + 4 (32 bit) – i.e. the jump should save the address of the next instruction, to prevent infinite loops
  • The DMA transfer example on pp 72 fails to compile with this error: dma_transfer.s:7: Error: unrecognised instruction `_1d_descr'
  • All ldrs and strs should be ldrh and strh: * The LDR (POSTMODIFY) example on pp 103 fails to compile with the error ldrdpm.s:3: Error: unrecognised form of instruction 'ldrs r31,[r2],#1' * The LDR (DISPLACEMENT-POSTMODIFY) example on pp 105 fails to compile with the error ldrpm.s:3: Error: unrecognised form of instruction 'ldrs r31,[r2],r1' * The STR (POSTMODIFY) example on pp 121 fails to compile with the error str_pm.s:3: Error: unrecognised form of instruction 'strs r31,[r2],r1' * The STR (DISPLACEMENT-POSTMODIFY) example on pp 122 fails to compile with the error str_dpm.s:3: Error: unrecognised form of instruction 'strs r31,[r2],#2'
  • In the SUB instruction on page 118, AC = BORROW should say AC = ~BORROW.
  • In the MOVTS and MOVFS operations, the code the compiler produces swaps rd and rn, which is not mentioned in Appendix A. The code on page 81 says:

    Code: Select all
    MOV R0,%low(x87654321) ;
    MOV R0,%high(x87654321) ;
    BITR R0,R0 ; R0 gets 0x84C2A6B1


    which does not compile, and isn’t correct in any case. This should say:

    Code: Select all
    MOV R0,%low(0x87654321) ;
    MOVT R0,%high(0x87654321) ;
    BITR R0,R0 ; R0 gets 0x84C2A6E1


Ambiguities


  • In the SUB instruction on page 118, the carry flag, AC, is not used in the subtraction. i.e. should the operation be: Rd = Rn - Rm - ~(AC)? The same applies to ADD.
  • In the TRAP instruction on page 124, each system call will produce a return value and an error number, but the manual does not say whether these are saved in registers.
  • In the RTI instruction on page 116, the Operation section says IPEND[i]=0; where i is the current interrupt level being serviced, but it is not clear how the current interrupt level is set.
Typographical mistakes


  • In Appendix A, pp 81 the BITR instruction does not have a section heading (or the heading has the wrong styling), so BITR does not appear in the Table of Contents.
  • pp 109: Too many right parentheses in Operation section.

Would-be-nice-to-have improvements

Instruction descriptions contain pseudo-code for each ISA instruction, but do not deal with incrementing COUNTER0 and COUNTER1. Ideally it would be nice for each instruction in Appendix A to state clearly whether and when counters are updated.
snim2
 
Posts: 53
Joined: Mon Feb 03, 2014 5:02 pm

Error in diagram of Operation of Interrupt Service Routine

Postby dms1guy » Thu Sep 10, 2015 9:16 pm

In Section 7.8.1 of the Epiphany Architecture Reference Manual version v14.03.11 there is an overview of the operation of an interrupt service routine.

Am I correct in noting that you have forgotten to re-enable interrupts at the end of the service routine?

Specifically,
the last software operation specified is to execute an RTI instruction.

The box following the RTI software operation denotes hardware operations, which are:

a) IPEND[N] = 0 (mark the service request as complete)
b) PC = IRET (return from interrupt)


shouldn't there also be a step c)?

c) STATUS[1]=0 (re-enable interrupts)
User avatar
dms1guy
 
Posts: 21
Joined: Thu Sep 10, 2015 9:05 pm
Location: Isle of Man

Re: Documentation Errors

Postby timpart » Tue May 10, 2016 11:49 am

snim2 wrote:Ambiguities

  • In the SUB instruction on page 118, the carry flag, AC, is not used in the subtraction. i.e. should the operation be: Rd = Rn - Rm - ~(AC)? The same applies to ADD.
  • In the TRAP instruction on page 124, each system call will produce a return value and an error number, but the manual does not say whether these are saved in registers.
  • In the RTI instruction on page 116, the Operation section says IPEND[i]=0; where i is the current interrupt level being serviced, but it is not clear how the current interrupt level is set.

Some answers based on my understanding.

Neither ADD nor SUB take the existing value of the carry flag into account. There aren't any equivalent instructions that do. This complicates wider precision calculations.

The TRAP instruction register usage is entirely up to the software that services the resulting processor state. I can't recall which registers are changed offhand for the "standard" ones, which requires support on the ARM host to look for the TRAP state on the chip and then process the request and change registers as needed. If it follows C conventions typically only R0 changes but memory areas pointed to by other registers can change too.

The interrrupt level is implicitly set when whatever causes the interrupt happens; each type of interrupt has a particular bit associated with it in IPEND. The "level" results from treating the bits in IPEND as an array of single bits.

Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: Documentation Errors

Postby jar » Wed Jun 21, 2017 3:12 pm

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.
User avatar
jar
 
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Re: Documentation Errors

Postby jar » Wed Jun 21, 2017 6:09 pm

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?
User avatar
jar
 
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests

cron