Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
Discussion Groups | FPGA-CPU | issue #13: XSOC problems on XS40 v1.4+ boards (with 128 KB ram)
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
issue #13: XSOC problems on XS40 v1.4+ boards (with 128 KB ram) - Jan Gray, Gray Research LLC - Mar 18 0:50:00 2000
|
Issue reported, understood, fixed, but fix not yet verified nor dropped to web site. Effect of fix is 1) new version of XSOC.sch, 2) new flavors of UCF files and 3) new flavors of .bit files. I also need to update the Guide to reflect these changes. The fix will appear in beta 0.92 later this weekend. Jan Gray, Gray Research LLC. Issue: 13 defect xsoc XSOC did not run on a v1.4+ board Opened: 03/17/00 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 It may have something to do with which version of XSTOOLS you are running. Resolv: 03/17/00 fixed 0.92 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 |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )