URL
https://opencores.org/ocsvn/pavr/pavr/trunk
Subversion Repositories pavr
[/] [pavr/] [trunk/] [doc/] [html/] [group__pavr__test__bugs.html] - Rev 6
Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> <title>Bugs</title> <link href="doxygen.css" rel="stylesheet" type="text/css"> </head><body> <!-- Generated by Doxygen 1.2.16 --> <center> <a class="qindex" href="main.html">Main Page</a> <a class="qindex" href="modules.html">Modules</a> <a class="qindex" href="pages.html">Related Pages</a> </center> <hr><h1>Bugs<br> <small> [<a class="el" href="group__pavr__test.html">Testing</a>]</small> </h1><table border=0 cellpadding=0 cellspacing=0> </table> <dl compact><dt><b> Errata to Atmel's AVR documentation:</b><dd> The corrected versions of some paragraphs from Atmel's documentation are shown below. <br> Original, wrong, terms are strikelined, while corrected terms are bolded: <br> <ul> <li>The following text can be found throughout the references. <br> <br> <font color=gray> "... <br> <strong> RAMPD </strong> <br> <br> Register concatenated with the <s> Z register </s> <strong> instruction word </strong> enabling direct addressing of the whole data space on MCUs with more than 64K bytes data space. <br> <br> <strong> EIND </strong> <br> <br> Register concatenated with the <s> instruction word </s> <strong> Z register </strong> enabling indirect jump and call to the whole program space on MCUs with more than 64K <s> bytes </s> <strong> words </strong> program space. <br> ..." <br> <font color=black> <br> <li>In the `AVR Instruction Set' document, page 60: <br> <font color=gray> "... <br> <strong> V: </strong> Rd7 * <s> /Rd7 </s> <strong> /Rr7 </strong> * /R7 + /Rd7 * Rr7 * R7 <br> ..." <font color=black> <br> </ul> </dl><hr><dl compact><dt><b> Atmel's AVRStudio simulator bugs</b><dd> <ul> <li>bug001<ul> <li><b>symptom</b>: NEG instruction computes the H flag via other formula than that given in the AVR Instruction Set (H=R3+Rd3). <br> Where is the bug, in the simulator or in the document, it's up to be seen. <br> Versions 3.53 and 4.04 of AVRStudio behave the same (weird) way. <br> Example: initially having SREG=0x01 and R10=0xD9, NEG R10 sets SREG to 0x01 instead of 0x21. <br> The AVRStudio formula for H seems to be R3*(not Rd3) rather than R3+Rd3.</ul> <li>bug002<ul> <li><b>symptom</b>: when trying to set/reset port A pins, there is a 1 clock delay between the moment PORTA receives the bits and the moment PINA gets updated. Those events should have been simultaneous (of course, port A direction was considered already configured as output, by setting DDRA(i)=1).</ul> </ul> </dl><hr> <p> <b>pAVR</b> <b>bugs</b> <b>history</b> <dl compact><dt><b> 28-31 July 2002</b><dd> <ul> <li>The Program Memory and Program Counter are handled in different places, even though they share much functionality. Moreover, the Program Counter doesn't have associated an explicit manager. This makes PM and PC quite difficult to maintain. <br> Reorganized PM and PC handling. Now they are handled by a common manager, the PM manager. <br> <li>Every test runs smoothly so far.</ul> </dl><dl compact><dt><b> 27 July 2002</b><dd> <ul> <li>The Stall and Flush Unit and Shadow Manager are difficult to maintain because of too many rules and exceptions. <br> Reorganized the SFU so that its behavior follows only one rule, the so-called `SFU rule': older hardware resource requests have priority over younger ones. <br> Reorganized the Shadow Manager so that its behavior accurately implements the shadow protocol. However, a few exceptions still exist (such as LPM Program Memory handling or CPSE RF handling).<li>*** Modelsim 5.3 behaves strange again. <br> It asserts hardware managers warnings, but when the the local conditions are investigated, the situation is perfectly legal. It seems that at a moment when a signal has a 0-1 transition and another one has a 1-0 transition, there is a `small' (theoretically 0) amount of time that both signals are considered 1, and that transient triggers the warning. That shouldn't happen, it seems to be a Modelsim bug. <br> However, trying to reproduce that behavior was unsuccessfull. It only appears sometimes; the apparition rule is well hidden. <br> For now, it's best to ignore these warnings during simulation. However, it means that those assertions don't fullfill their purpose.</ul> </dl><dl compact><dt><b> 25 July 2002</b><dd> <ul> <li>bug023<ul> <li><b>symptom</b>: IJMP and EIJMP don't jump were they are supposed to, if the instruction before them modifies the Z pointer.<li><b>remedy</b>: IJMP and EIJMP actually jump before even the BPU gets updated by the previous instruction. As they use the Register File mapped Z pointer for finding target address, they need to be calmed down for a clock (Z pointer is modified in stage s5). <br> Just request a nop in pipe stage s4. Now IJMP and EIJMP take 4 clocks (RJMP and JMP still take 3).<li><b>status</b>: corrected</ul> <li>bug024<ul> <li><b>symptom</b>: loads don't work any more (!). They (sometimes) get garbage.<li><b>remedy</b>: when correcting bug 021, the shadow protocol was applied for all devices that could use it. It was wrong. The Data Address Calculation Unit must not use the shadow protocol, because it gets RF/IOF/DM exclusivity by means of stalling, and it must be granted access to these resources, even during stalls. <br> When trying to read from Unified Memory, loads got data from shadow registers, not directly from the RF/IOF/DM 's data out.<li><b>status</b>: corrected DACU</ul> <li>bug025<ul> <li><b>symptom</b>: JMP gets corrupted if the previous instruction is a load.<li><b>remedy</b>: JMP is a 32 bit instruction. The second word (a 16 bit constant) can get flushed by a previous instruction stall s5. <br> Flush s2 requested in s3 and s4 are more delicate than other flushes. They can interfere with stalls requested by older instructions. They must be stallable because older instructions might want that. If stall s2 requested in s3 or s4, then if older instructions require stall, don't blindly flush s2, but rather do nothing and wait for the stall to end. Only after that acknowledge the flush. <br> <li><b>status</b>: corrected</ul> <li>bug026<ul> <li><b>symptom</b>: CPSE doesn't skip the following instruction, when it should.<li><b>remedy</b>: the skip condition was picked as `not zero flag', instead of `zero flag'.<li><b>status</b>: corrected</ul> <li>bug027<ul> <li><b>symptom</b>: SBIC and SBIS don't do their job.<li><b>remedy</b>: IOF read access was simply not requestd.<li><b>status</b>: corrected the Instruction Decoder by placing an IOF request in pipe stage s5, for SBIC and SBIS</ul> <li>bug028<ul> <li><b>symptom</b>: RCALL doesn't work.<li><b>remedy</b>:<ul> <li>the 12 bit relative offset wasn't initialized in the Instruction Decoder. Just do that (cut&paste the corresponding code line from RJMP, as the relative jump address is placed in the same bits in the instruction code).<li>the return address was correct for CALL but bigger with one than needed for RCALL. Actually, CALL and RCALL need <b>different</b> return addresses, as CALL has 32 bits and RCALL only 16. <br> Modification: now, the current instruction's PC is <b>conditionally</b> incremented in pipe stage s4. A new set of wires and registers were introduced so that CALL can request to increment its return address. RCALL doesn't need to do that.</ul> <li><b>status</b>: corrected the Instruction Decoder, so that CALL requires to increment its return address.</ul> <li>note: all instructions seem to work.</ul> </dl><dl compact><dt><b> 24 July 2002</b><dd> <ul> <li>bug020<ul> <li><b>symptom</b>: garbage got by loads placed immediately after stores that modify their pointer.<li><b>remedy</b>: loads and stores can modify their data pointer. However, the Bypass Unit must also be updated, because the pointer registers are placed in the Register File. The BPU wasn't updated.<li><b>status</b>: corrected<li><b>note</b>: the modularity of the design (separate hardware managers, small set of conventions regarding signal naming, grouping similar-function code) payed off. This bug required an intervention spread out over half megabyte of code. The Data Address Calculation Unit, Bypass Unit were modifed, new wires and registers were defined, some of them were renamed.</ul> <li>bug021<ul> <li><b>symptom</b>: stores that modify their pointer make the following instruction unable to update the Bypass Unit. Moreover, the BPU is written with garbage.<li><b>remedy</b>: Stores and the instruction after them can require to simultaneousely write the BPU. That's because these stores make intensive use of BPU and eat all its write resources. They write 3 bytes: 2 of them in s5 (the modified pointer) and 1 in s6 (the data to be written into the Register File). The one written in s6 can be simultaneous with following instruction's s5 write BPU request. <br> To correct this bug, there are 2 options: <ul> <li> 1. add a stall in pipe stage s5 for all stores. That is, stores will take 3 clocks. <li> 2. increase BPU width from 2 chains to 3 chains and modify the way stores make use of Bypass Unit (write all what has to be written - 3 bytes - in the same pipe stage, s5). This is more attractive because stores still need only 2 clocks. However, the Bypass Unit continues to grow (from initial depth/width of 2/2 to the present 4/3). </ul> Option 2 was chosen. <br> The Unified Memory architecture favorized this bug. Stores must be able to write the Register File and, consequently, write their data into BPU along with the pointer they have modified.<li><b>status</b>: corrected</ul> <li>bug022<ul> <li><b>symptom</b>: LPM always returns 0.<li><b>remedy</b>: multiple bug:<ul> <li>The LPM stalled s2, then read s2 status. Seeing it `busy', gives up from reading what it needed and maintains pavr_pm_addr_int at its present value. The Program Memory Manager needs to be instructed to forcedly grant access to LPM instructions to s2, even if it is stalled. Also, the shadow protocol must be bypassed.<li>LPM didn't update BPU.<li>pointer registers were used directly in a few hardware managers, not via BPU. This enables subtle read before write hazards (they escaped until now).</ul> <li><b>status</b>: corrected</ul> <li>note: <br> LD Rd, -X; LD Rd, X; LD Rd, X+; <br> LD Rd, -Y; LD Rd, Y; LD Rd, Y+; LDD Rd, Y+q; <br> LD Rd, -Z; LD Rd, Z; LD Rd, Z+; LDD Rd, Z+q; <br> ST -X, Rr; ST X, Rr; ST X+, Rr; <br> ST -Y, Rr; ST Y, Rr; ST Y+, Rr; STD Y+q, Rr; <br> ST -Z, Rr; ST Z, Rr; ST Z+, Rr; STD Z+q, Rr; <br> LPM; LPM Rd, Z; LPM Rd, Z+ <br> seem to work.</ul> </dl><dl compact><dt><b> 23 July 2002</b><dd> <ul> <li>bug016<ul> <li><b>symptom</b>: read before write data hazards<li><b>remedy</b>: BLD instruction didn't update BPU.<li><b>status</b>: corrected</ul> <li>bug017<ul> <li><b>symptom</b>: BLD doesn't modify the target register.<li><b>remedy</b>: while processing pavr_s5_iof_rq IOF request, the IOF Manager set IOF bit address to zero instead of pavr_s5_iof_bitaddr. Correct that.<li><b>status</b>: corrected</ul> <li>bug018<ul> <li><b>symptom</b>: Even though they work fine separately, POP, PUSH and MOVW one after another (in various combinations) don't.<li><b>remedy</b>: This is a triple (!) bug: <ul> <li> MOVW requires a stall in s6 while POP requires a stall in s5. The two stalls are simultaneous. <br> The Stall and Flush Unit doesn't handle properly multiple stalls. <br> Modify SFU so that the oldest stall doesn't kill the younger one(s), but only delays it (them). <li> The SP was incremented during a stall, and the DACU received after the stall a wrong pointer (the new SP). <br> All hardware resources must be stallable. Presently they are not. <li> The instruction after MOVW, PUSH is skipped. The PM data out shadow register doesn't do its job. <br> The shadow registers are updated every clock. That's not right. <br> Update them only if they don't already hold meaningful data (check the corresponding `shadow_active' flag). Otherwise, during successive stalls they get corrupted. </ul> This was a tough one.<li><b>status</b>: corrected</ul> <li>bug019<ul> <li><b>symptom</b>: the sequence <br> LDI R17, 0xC3 <br> ST Z+, R17 <br> results in storing garbage into memory.<li><b>remedy</b>: the nop requests (placed by ST) increase the needed BPU depth with one. Thus, BPU depth must be increased from 3 to 4.<li><b>status</b>: corrected</ul> <li>note:<ul> <li>CBI, SBI, BST, BLD, MOVW, IN, OUT, PUSH, POP, LDS, STS seem to work.</ul> </ul> </dl><dl compact><dt><b> 22 July 2002</b><dd> <ul> <li>bug011<ul> <li><b>symptom</b>: DEC does in fact INC<li><b>remedy</b>: ALU operand 2 is selected as -1 in pipe stage s5, and then, the DEC-related code does out=op1-op2, which results in out=op1+1. <br> Just make the ALU treat INC and DEC the same way (that is, out=op1+op2).<li><b>status</b>: corrected</ul> <li>bug012<ul> <li><b>symptom</b>: BPU doesn't do its job.<li><b>remedy</b>: stupid and time costly bug, generated by a (too) quick cut and paste in the BPU code.<li><b>status</b>: corrected<li><b>note</b>: Modelsim PE/Plus 5.3a_p1 has a cache problem. After correcting this bug, the same results came after recompiling and restarting the simultation. It was enough to close Modelsim and open the project again for things to go fine. It's not the first time Modelsim behaves this way.</ul> <li>bug013<ul> <li><b>symptom</b>: Z flag is computed wrongly for ALU opcodes that need 8 bit substraction with carry.<li><b>remedy</b>: Z=Z*oldZ<li><b>status</b>: corrected</ul> <li>bug014<ul> <li><b>symptom</b>: Z flag is computed wrongly for all ALU opcodes (!).<li><b>remedy</b>: instead of and-ing the negated bits of output, Z output was computed by and-ing output's bits.<li><b>status</b>: corrected</ul> <li>bug15<ul> <li><b>symptom</b>: read before write data hazards related to IN instruction<li><b>remedy</b>: IN doesn't write the Bypass Unit. Do that. Nasty one, requiring new wires and registers.<li><b>status</b>: corrected<li><b>note</b>: the shadow manager was completed. Pretty much code, hopefully with no new bugs.</ul> <li>notes:<ul> <li>MOV, INC, DEC, AND, AND, OR, ORI, EOR, COM, NEG, CP, CPC, CPI, SWAP, LSR, ROR, ASR, multiplications (timing-only), BCLR, BSET seem to work.</ul> </ul> </dl><dl compact><dt><b> 21 July 2002</b><dd> <ul> <li>bug008<ul> <li><b>symptom</b>: read before write data hazards.<li><b>remedy</b>: the Bypass depth was increased from 2 to 3. Design bug.<br> To update the documentation!<li><b>status</b>: corrected.</ul> <li>bug009<ul> <li><b>symptom</b>: the 16 bit arithmetic instructions write only the lower byte of the result in the Register File if the next few instructions aren't nops.<li><b>remedy</b>: 16 bit arithmetic instructions stalled s6. During stalling s6, the Bypass flushed a value that was needed later. A signal was needed that can stall the BPU. Now, the stall s6 requests also stall the BPU.<br> Pretty triky design bug.<br> To update the documentation!<br> <li><b>status</b>: corrected.</ul> <li>bug010<ul> <li><b>symptom</b>: stalls needed by 16 bit arithmetic instructions induce the replacement of the instruction placed 4 clocks later by a nop<li><b>remedy</b>: shadow registers were assigned, but never used. PM data out, (and consequently, the instruction register) read a nop instead the correct data that was read during the stall. Now the pipeline uses shadow registers related by PM data out.<br> The other shadow registers (related to DM, RF, IOF and DACU data out) are still unused!<br> To update the documentation with shadow-related issues!<li><b>status</b>: corrected.<br> </ul> <li>note:<ul> <li>ADD, ADC, ADIW, SUB, SUBI, SBC, SBIW seem to work.</ul> </ul> </dl><dl compact><dt><b> 15 July 2002</b><dd> <ul> <li>bug004<ul> <li><b>remedy</b>: reporting this bug was a bug. The Register File works fine. This bug report was generated by modifying X register (RF addr 27:26) and expecting that RF bulk data (RF addr 0...25) to be modified, which won't happen.<li><b>status</b>: ok.</ul> <li>bug005<ul> <li><b>remedy</b>: DACU data out was duplicated, with 2 different names: pavr_dacu_do and pavr_s6_dacudo. pavr_dacu_do was only writen, and pavr_s6_dacudo was only read. When RET tried to read the return address from DACU, it got garbage, because it read DACU data out from pavr_s6_dacudo, that was not assigned any value.<br> Cut out pavr_s6_dacudo. DACU data out is now unique, for both read an write (that is, pavr_dacu_do). Also, the documentation was updated.<li><b>status</b>: corrected.</ul> <li>bug006<ul> <li><b>symptom</b>: CALL doesn't work.<li><b>remedy</b>: in the SP Manager, pavr_s5_calldec_spwr_rq was writen twice, and pavr_s52_calldec_spwr_rq wasn't writen at all, because of a less careful cut-and-paste. As a result, during CALL, PC's lsByte was not stored.<li><b>status</b>: corrected</ul> <li>bug007<ul> <li><b>symptom</b>: ALU flags are not defined.<li><b>remedy</b>: ALU flags in was not connected to SREG (zero-level assignment)<li><b>status</b>: corrected</ul> <li>notes:<ul> <li>RET, CALL seem to work.<li>pAVR runs its first complete program (12 instructions).</ul> </ul> </dl><dl compact><dt><b> 13 July 2002</b><dd> <ul> <li>bug003<ul> <li><b>symptom</b>: RET is a mess<li><b>remedy</b>: during nop requests, stall must have higher priority that flush in s2. The Stall Manager (the nop request-related lines) must take care of that.<li><b>status</b>: corrected</ul> <li>bug004<ul> <li><b>symptom</b>: RF seems to be unable to write other registers than pointer registers.<li><b>status</b>: NOT corrected!</ul> <li>bug005<ul> <li><b>symptom</b>: RET is still a mess.<li><b>status</b>: NOT corrected!</ul> <li>bugs pool: 004, 005</ul> </dl><dl compact><dt><b> 27 June 2002</b><dd> <ul> <li>bug001<ul> <li><b>symptom</b>: read before write data hazards. Hmm, this kind of bugs shouldn't have occured.<li><b>remedy</b>: LDI didn't update BPU0. Just do that.<li><b>status</b>: corrected.</ul> <li>bug002<ul> <li><b>symptom</b>: while reading the code, something was smelling bad.<li><b>remedy</b>: the code that computes the branch/skip conditions was not writen at all.<li><b>status</b>: corrected.</ul> <li>notes:<ul> <li>The controller has successfully executed its first instruction (a RJMP)! However, it was the only...<br> <li>The kernel seems to be easy to debug thanks to its regular structure.<li>RJMP, LDI, NOP seem to work.</ul> </ul> </dl><br> <hr><address align="right"><small>Generated on Tue Dec 31 20:26:31 2002 for Pipelined AVR microcontroller by <a href="http://www.doxygen.org/index.html"> <img src="doxygen.png" alt="doxygen" align="middle" border=0 width=110 height=53></a>1.2.16 </small></address> </body> </html>