Presentation is loading. Please wait.

Presentation is loading. Please wait.

Versus JEDEC STAPL Comparison Toolkit Frank Toth February 20, 2000.

Similar presentations


Presentation on theme: "Versus JEDEC STAPL Comparison Toolkit Frank Toth February 20, 2000."— Presentation transcript:

1 versus JEDEC STAPL Comparison Toolkit Frank Toth February 20, 2000

2 ® www.xilinx.com Agenda  The latest on JEDEC STAPL  JavaScan versus JEDEC STAPL  Frequently Asked Questions  Appendix  Java API for Boundary-Scan  JEDEC STAPL  Lattice ispVM

3 ® www.xilinx.com Utilizes existing JTAG infrastructures and standards Wide variety of devices now include JTAG chain: CPUs, embedded processors, DSPs, bus logic, and Flash memory Write Once Run Anywhere- One file, multiple platforms Web “friendly”: Facilitates networked based download and debug Rich development tool suite Combines the BEST Attributes of IEEE-JTAG & JAVA IEEE1149.1 JTAG

4 ® www.xilinx.com The latest on JEDEC STAPL  JEDEC voted STAPL in as a specification  JAM name has been changed to STAPL because of copyright, conflicts of interest with Altera “chairing the JEDEC committee”, and other marketing advantage  JEDEC JAM (STAPL)(2.1) is not compatible with original JAM (1.1) : All current users will need to be change to newer versions of STAPL  JEDEC STAPL STILL has limited compression & large memory requirements (cannot be used with smaller embedded processors)  JEDEC STAPL does not work with larger file sizes used in PROMs and FPGAs, needs to be updated but… —Bryon Moyer of Altera dissolved the JEDEC committee for now

5 ® www.xilinx.com JavaScan versus JEDEC STAPL Platform Independence Write Once, Run Anywhere: One file, multiple platforms, one standard Network & Internet “friendly” Proven Virtual Machines Exist for Nearly Every Platform Small Footprint Fast & Efficient Tightly written code-10K bytes easily fits on any 8 bit processor Easily Integrated into Existing System Extensible to Embedded & Personal Java: User picks features Infrastructure & Support Road Tested and proven reliability Fully supported 850 + engineers at Sun: Long term commitment Scalable & Flexible: Optimize compression, data & I/O interfaces Training & Tool support from Multiple Vendors: Compilers, Code Coverage, Test & Development Systems Vendor and platform dependent Favors Altera specific Programming & Data Formats Customized for each different revision of Altera devices STAPL Player is not platform independent Large (5X) Footprint 50KBytes required- Will not fit in an 8 bit processor Code must be decompressed during run time, must store compressed and decompressed code Major users (Teradyne) and PLD vendors (Lattice/Vantis) have complained about large code requirements for their PLDs and platforms No Infrastructure & Support: You are on your own! No tool support: Test & Development systems do not exist No updates & bug fixes except from individual PLD vendor

6 ® www.xilinx.com Frequently Asked Questions  Where can I get a quick comparison of Java versus JEDEC STAPL?  The latest competitive alert is at:http://www.partner.xilinx.com/common/cpld/cpldcomp_info/alterajam.pdf  What is JEDEC STAPL and how does it compare to Altera’s Jam?  JEDEC STAPL (Rev 2.1) does not look anything like the original (1997) JAM (Rev 1.1). Several large changes have been made to the software and changes and updates are continuing. Customers will need to make sure they have the latest revision running on their systems and embedded processors.  Where do I get a copy of the reference implementation of the Java API for Boundary-Scan and its accompanying documentation?  Follow this link http://www.xilinx.com/products/software/sx/sxpresso.html#Java API and then select the link titled "Java API for Boundary-Scan - Reference Implementation” (ftp://ftp.xilinx.com/pub/utilities/epld/jscan.zip). Download and unzip the file. You will find all the source code, descriptive HTML documentation and javadoc generated collateral information to help you understand the entire API.  How do I interface the Java API for Boundary-Scan to any arbitrary hardware?  Follow this link http://www.xilinx.com/products/software/sx/sxpresso.html#Java API and then select the link titled "Java API forBoundary-Scan - Reference Implementation" (ftp://ftp.xilinx.com/pub/utilities/epld/jscan.zip). Download and unzip the file. will see a document entitled "Java Native Interface Specification". This document describes the hardware interface calls and behavior. Download the Java Developers Kit from the Java web site (http://java.sun.com/products/jdk/1.2/index.html ). Read the accompanying documentation about building and using Java Native Interface (JNI) methods. Then simply code, compile and install a DLL or SO file that implements this interface and you are ready to go.

7 ® Appendix Details on Competitors: JEDEC STAPL & Lattice/Vantis ispVM

8 ® www.xilinx.com Algorithmic Control- Flow Language Java Compiler Byte Codes Java Virtual Machine Platform: Workstation/PC/Embedded Java API for Boundary-Scan provides a complete solution Platform Independence Small Footprint (10Kbytes) Scalable from JavaCard to Enterprise Java Java is proven technology Road-Tested & Proven Reliability Full suite of development tools & reference material

9 ® www.xilinx.com Algorithmic Control- Flow Language (Under definition by JEDEC) STAPL Proprietary Byte Codes STAPL Virtual Machine (JAM Player) Platform: Workstation/ PC Embedded Proprietary Compiler Customer must supply debug and interpreter Current JEDEC STAPL (JEDEC name for JAM) is 100% incompatible with original Altera JAM Run time memory requirements balloon- Need to store compressed & decompressed code Compression scheme works well only for Altera devices and cannot be altered JEDEC STAPL Provides only part of the solution All must be supplied by the end customer C-Code Compiler

10 ® www.xilinx.com Lattice/Vantis ispVM Only a partial solution... (customer written) Byte Codes Virtual Machine Platform : Workstation/PC/Embedded Compiler Compiler and support tools left up to the customer Customer must supply run time environment No algorithmic control flow language front end Specification, capabilities and features poorly define What Lattice has been saying: “ Consensus for a virtual machine- based standardization effort appears to be building, as demonstrated by Xilinx's Java API proposal”. Lattice Press Release: Sept. 24, 1998 Why not just use JavaScan?


Download ppt "Versus JEDEC STAPL Comparison Toolkit Frank Toth February 20, 2000."

Similar presentations


Ads by Google