|
XSOC Known Issues |
|||
|
Home xr16 >> << XSOC Talk News Index 2002 Jan Feb Mar Apr May Jun Jul Aug Sep 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 Apr Aug Sep Oct Nov Dec Links Fpga-cpu List Usenet Posts Site News Papers Teaching Resources Glossary Gray Research GR CPUs XSOC Launch Mail Circuit Cellar LICENSE README XSOC News XSOC Talk Issues xr16 XSOC 2.0 XSOC2 Log CNets CNets Log |
issues -- issues database Copyright (C) 2000, Gray Research LLC. All rights reserved. The contents of this file are subject to the XSOC License Agreement; you may not use this file except in compliance with this Agreement. See the LICENSE file. open issues (12): 2 not-impl lcc-xr16 long integers are not implemented 3 not-impl xr16asm far branch displacements are not implemented 4 not-impl libxr16 most kinds of mul div and mod are not implemented 5 not-impl libxr16 variable bit-count shifts are not implemented 6 defect xsoc VGA only displays 560 pixels/line, not 576 7 wish libxr16 xr16 needs a C runtime library 8 not-impl lcc-xr16 lcc-xr16 needs a test suite 9 not-impl xr16asm xr16 assembler/simulator needs a test suite 11 defect xsoc timespecs do not include async RAM delay offsets 14 wish xsoc XSOC/xr16 refloorplanned for XC4010XL 16 defect doc xspecs.pdf: b<cond> a,-32768 broken 17 defect xr16iss b<cond> a,-32768 broken assigned issues (1): 10 not-impl xr16cpu xr16 cpu needs a test suite resolved issues (1): 20 defect xsoc problems building under Foundation 2.1i. closed issues (6): 1 note doc how to use the issues tracking system 12 wish misc issues tracking should include version number info 13 defect xsoc XSOC did not run on a v1.4+ board 15 defect lcc-xr16 some unsigned hex consts promoted to long 18 defect xr16asm cmpi reg,-32768 broken 19 defect xr16asm cmpi reg,0 broken Issue: 1 note doc how to use the issues tracking system Opened: 02/26/00 jan-@fpgacpu.org See file issues-howto Closed: 02/26/00 jan-@fpgacpu.org Issue: 2 not-impl lcc-xr16 long integers are not implemented Opened: 02/26/00 jan-@fpgacpu.org 1. May need to revise long int pseudo-ops specification in xspecs.pdf. 2. Need to modify lcc-xr16's xr16.md to emit proper long int pseudo-ops. 3. Need to modify xr16asm to implement those pseudo-ops. 4. Need to write long int test suite. Issue: 3 not-impl xr16asm far branch displacements are not implemented Opened: 02/26/00 jan-@fpgacpu.org Repro: lcc-xr16 -o 3.hex -Wl-lst=3.lst 3.c Errors: xr16: branch displacement overflow at 0084 target 'L3' xr16: branch displacement overflow at 01A2 target 'L2' Issue: 4 not-impl libxr16 most kinds of mul div and mod are not implemented Opened: 02/26/00 jan-@fpgacpu.org Currently only unsigned multiply is implemented. Repro: lcc-xr16 -o 4.hex -Wl-lst=4.lst 4.c Errors: xr16: undefined symbol '_muli2' xr16: undefined symbol '_divi2' xr16: undefined symbol '_modi2' xr16: undefined symbol '_divu2' xr16: undefined symbol '_modu2' xr16: undefined symbol '_muli4' xr16: undefined symbol '_divi4' xr16: undefined symbol '_modi4' xr16: undefined symbol '_mulu4' xr16: undefined symbol '_divu4' xr16: undefined symbol '_modu4' Issue: 5 not-impl libxr16 variable bit-count shifts are not implemented Opened: 02/26/00 jan-@fpgacpu.org Repro: lcc-xr16 -o 5.hex -Wl-lst=5.lst 5.c Errors: xr16: undefined symbol '_sllr' xr16: undefined symbol '_slllr' xr16: undefined symbol '_srar' xr16: undefined symbol '_srlr' xr16: undefined symbol '_sralr' xr16: undefined symbol '_srllr' Issue: 6 defect xsoc VGA only displays 560 pixels/line, not 576 Opened: 02/26/00 jan-@fpgacpu.org There's something wrong with horizontal blanking with respect to the video pixel shift pipeline, and so the VGA display does not display the last 16 pixels/line. Issue: 7 wish libxr16 xr16 needs a C runtime library Opened: 02/26/00 jan-@fpgacpu.org This project needs a C runtime library. We need one with full source, that is 16-bit portable, and is compatible with the lcc C compiler. The last time I looked most of the available CRTs depended upon some GCC language extensions... Issue: 8 not-impl lcc-xr16 lcc-xr16 needs a test suite Opened: 02/26/00 jan-@fpgacpu.org There is no lcc-xr16 cross-compiler test suite yet. Surely one could be built using the xr16 simulator. Issue: 9 not-impl xr16asm xr16 assembler/simulator needs a test suite Opened: 02/26/00 jan-@fpgacpu.org There is no xr16 assembler/simulator test suite yet. Issue: 10 not-impl xr16cpu xr16 cpu needs a test suite Opened: 02/26/00 jan-@fpgacpu.org There is no xr16 test suite yet. There should be a minimal one that could be run in the Foundation simulator, and another, built upon the first, that could be run in the actual hardware. Owner: 04/01/00 jan-@fpgacpu.org tests/xr16.s is a start. It runs in the xr16 instruction set sim, and in a Verilog simulator. It still needs a test harness to run in hardware. Issue: 11 defect xsoc timespecs do not include async RAM delay offsets Opened: 02/27/00 jan-@fpgacpu.org The various xsoc-*.ucf constraint files include timespecs which are essential for optimizing placement and routing and for ensuring the resulting design passes static timing analysis. Current the XSOC UCF timespecs are not correct, because they do not include OFFSET timings to account for the delay from the FPGA address and control signals, through the RAMs, and back into the FPGA. Even if trce reports the worst case cycle time is <41 ns, this does not guarantee the design will run at the target cycle time of 80 ns if we do not factor in this external delay through external RAM. Issue: 12 wish misc issues tracking should include version number info Opened: 02/27/00 jan-@fpgacpu.org It would be nice if each resolved or closed issue included the XSOC version number in which the issue was first resolved. Resolv: 03/17/00 fixed 0.92 jan-@fpgacpu.org Done! Closed: 03/17/00 jan-@fpgacpu.org Issue: 13 defect xsoc XSOC did not run on a v1.4+ board Opened: 03/17/00 jan-@fpgacpu.org Someone reports that XSOC (xsoc-10xl-13.bit) doesn't work on his XS40 v1.4+ board. This is troubling because it works on mine. Owner: 03/17/00 jan-@fpgacpu.org It may have something to do with which version of XSTOOLS you are running. Resolv: 03/17/00 fixed 0.92 jan-@fpgacpu.org The problem does indeed have to do with which version of XSTOOLS you are using. In this case, we test XSOC with v1.2, v1.3, and v1.4+ boards, but we had been doing so using a single installation of XSTOOLS, apparently corresponding to a v1.3 board. (Oops.) For v1.4+ boards, the 0.91 design lets XA<15> and XA16 float high via default weak pullups, and this worked because the (v1.3) XSLOAD also let XA<15> and XA16 float high during load of the .hex memory image. The XSOC 0.91 design, which ran out of logical address 0x0000, was actually running out of 'physical address' 0x18000. However, the user was (correctly) using the XSTOOLS for v1.4+ to XSLOAD his v1.4+ board, and this version drives A15/A16 and so correctly uploads the .hex memory image to 'physical address' 0x00000. When the 0.91 configuration was loaded, it once again ran code at 'physical address' 0x18000, which crashes unpredictably. The fix was to modify the XSOC.sch design to tie XA16 to ground, and modify the xsoc*.ucf files to apply pin LOCs (XA<15>=P28, XA16=P16) so as to properly drive the v1.4+ board's 128 KB SRAM address lines A15 and A16. As a bonus, this now provides an almost full 64 KB of RAM (0000-FEFF) on v1.4+ boards. (Recall FFxx is the I/O control register space). Now that XA16=P16 is being driven, the new xsoc-*-14.bit MUST NOT be run on pre-v1.4 XS40 boards, because they also drive P16 with the output of the inverter U3C (see p.17 of XS40-manual-v1_3.pdf). Therefore there will be yet another set of UCF files that drive XA16=P? (v1.2, v1.3) or XA16=P16 (v1.4, v1.4+). (On a v1.4 (not +) board, it should be benign to drive XA<15>=P28 and XA16=P16 even though there these signals do not drive pins on the 32 KB SRAM). UCF File Target -------- ------ xsoc-05xl-13.ucf XS40 v1.2 or v1.3, 4005XL xsoc-10xl-13.ucf XS40 v1.2 or v1.3, 4010XL xsoc-05xl-14.ucf XS40 v1.4 or v1.4+, 4005XL xsoc-10xl-14.ucf XS40 v1.4 or v1.4+, 4010XL We also need new kinds of prebuild xsoc.bit files: Bitstream Target -------- ------ xsoc-05xl-12.bit XS40 v1.2, 4005XL xsoc-10xl-12.bit XS40 v1.2, 4010XL xsoc-05xl-13.bit XS40 v1.3, 4005XL xsoc-10xl-13.bit XS40 v1.3, 4010XL xsoc-05xl-14.bit XS40 v1.4 or v1.4+, 4005XL xsoc-10xl-14.bit XS40 v1.4 or v1.4+, 4010XL Closed: 04/04/00 jan-@fpgacpu.org Issue: 14 wish xsoc XSOC/xr16 refloorplanned for XC4010XL Opened: 03/20/00 jan-@fpgacpu.org XSOC/xr16 is currently floorplanned for a 14x14 CLB XC4005XL. When built on a XC4010XL, it retains the same floorplan, with the result that the datapath is placed on rows 7-14. In an '4010, it would be better if the datapath were placed on rows 13-20. There is no convenient way to do this using schematics, however. Hopefully we can do better with the Verilog version. Issue: 15 defect lcc-xr16 some unsigned hex consts promoted to long Opened: 03/31/00 jan-@fpgacpu.org Repro: lcc-xr16 -S 15.c (and review 15.s) Problem report: From: Jamie R. Chinn (jamiechi-@fultonscrossing.com) Sent: Friday, March 31, 2000 1:42 AM To: fpga-cpu@egroups.com Subject: [fpga-cpu] Constants in LCC-XR16 compiler A constant such as 0x8000 is by default treated as a four byte long. This creates lots of errors. (Such as zexl and leal not found.) To work around this, explicitly cast the constant to unsigned. (unsigned)0x8000 or 0x8000u Shouldn't the default be the two byte int or unsigned int? (I believe the int is defined as 16 bits for the XR16.) Indeed this is an error. The type of 0x8000 should be unsigned int per C standard: Section 3.1.3.2. Integer Constants "The type of an integer constant is the first of the corresponding list in which its value can be represented: ... unsuffixed octal or hexadecimal: int, unsigned int, long int, unsigned long int ..." While 0x8000 (32768) is not representable as an int, it is representable as an unsigned int, but lcc mistakenly promotes it to long. Resolv: 03/31/00 fixed 0.93 jan-@fpgacpu.org Problem lay in function icon in src/lex.c. Quote: static Symbol icon(unsigned long n, int overflow, int base) { ... } else if (overflow || n > longtype->u.sym->u.limits.max.i) tval.type = unsignedlong; else if (n > inttype->u.sym->u.limits.max.i) tval.type = longtype; else if (base != 10 && n > inttype->u.sym->u.limits.max.i) tval.type = unsignedtype; else tval.type = inttype; ... Fix was to change this to static Symbol icon(unsigned long n, int overflow, int base) { ... } else if (overflow || n > longtype->u.sym->u.limits.max.i) tval.type = unsignedlong; #if 1 /* 00/03/31 jan-@fpgacpu.org XSOC issue #15 fix added */ else if (base != 10 && n > inttype->u.sym->u.limits.max.i && n <= unsignedtype->u.sym->u.limits.max.i) tval.type = unsignedtype; #endif else if (n > inttype->u.sym->u.limits.max.i) tval.type = longtype; #if 0 /* 00/03/31 jan-@fpgacpu.org XSOC issue #15 fix deleted */ else if (base != 10 && n > inttype->u.sym->u.limits.max.i) tval.type = unsignedtype; } #endif else tval.type = inttype; ... Closed: 04/04/00 jan-@fpgacpu.org Issue: 16 defect doc xspecs.pdf: b<cond> a,-32768 broken Opened: 04/03/00 jan-@fpgacpu.org The instruction set specification uses comparisons with the negation of the b operand to describe the behavior of all b<cond>s. Example: Format: blt label ... Operation: pre if ((signed)a < (signed)-b) pc += 2*sign_ext(disp8) + 2; ... The problem here is (signed)-b is undefined for b==-32768 (0x8000). Issue: 17 defect xr16iss b<cond> a,-32768 broken Opened: 04/03/00 jan-@fpgacpu.org The ISS works as documented in issue #16, which disagrees with the Verilog model. Issue: 18 defect xr16asm cmpi reg,-32768 broken Opened: 04/03/00 jan-@fpgacpu.org The xr16 assembler turns cmpi reg,imm into addi r0,reg,-imm. This is OK for cmpi/beq and cmpi/bne, but it doesn't work for cmpi/b<other> if imm==-32768, because -imm==32768 is not representable in 16-bit 2's complement. It should use something like: cmpi reg,imm => addi r0,reg,-imm if imm != -32768 => lea r1,-32768 if imm == -32768 cmp reg,r1 => imm 0x8000 addi r1,r0,0 and r0,r0 ; nop sub r0,reg,r1 Resolv: 04/03/00 fixed 0.93 jan-@fpgacpu.org Fixed as above. Closed: 04/04/00 jan-@fpgacpu.org Issue: 19 defect xr16asm cmpi reg,0 broken Opened: 04/03/00 jan-@fpgacpu.org The xr16 assembler turns cmpi reg,0 into addi r0,reg,0. This doesn't set carry-out properly. Contrast lea r2,2 => addi r2,r0,2 cmpi r2,1 addi r0,r2,-1 ; sets carry-out bltu label bltu label ; carry-out set, so branch cond is false with lea r2,2 => addi r2,r0,2 cmpi r2,0 addi r0,r2,0 ; clears carry-out bltu label bltu label ; carry-out clear, so cond is true, WRONG Here the addi of 0 fails to set carry-out, whereas if we generated lea r2,2 => addi r2,r0,2 cmpi r2,0 sub r0,r2,r0 ; => add 0002 + ~0000 + 1, sets carry-out bltu label bltu label ; carry-out set, so cond is false, RIGHT So it's a little tricky, but the fix is to map cmpi reg,0 => sub r0,reg,r0 Resolv: 04/03/00 fixed 0.93 jan-@fpgacpu.org Fixed as above. Closed: 04/04/00 jan-@fpgacpu.org Issue: 20 defect xsoc problems building under Foundation 2.1i. Opened: 04/03/00 jan-@fpgacpu.org Reported by jamiechi-@fultonscrossing.com (Jamie R. Chinn): "Version 2.1i doesn't like the three 'unbonded' outputs that were in the configuration file. I had to assign them to specific pins." Resolv: 04/04/00 fixed 0.93 jan-@fpgacpu.org Fixed. For the v1.2 and v1.3 boards, the UCF files xsoc-05xl-13.ucf and xsoc-05xl-14.ucf now constrain these unused outputs to device pins that drive 8031 I/Os: NET XA<0> LOC = P7; # P1.0 (unused) NET XA<15> LOC = P8; # P1.1 (unused) NET XA16 LOC = P9; # P1.2 (unused) For the v1.4 and v1.4+ boards, the UCF files xsoc-05xl-14.ucf and xsoc-10xl-14.ucf now constrain these unused outputs to device pins that drive 8031 I/Os: NET XA<0> LOC = P7; # P1.0 (unused) This should eliminate all unbonded outputs, and hence the problem F2.1i has with them. |
||
Copyright © 2000-2002, Gray Research LLC. All rights reserved. Last updated: Feb 03 2001 |