aJile Technology

• How do aJile microprocessors execute JVM bytecodes?
   

   

  aJile microprocessors are 32-bit stack machines designed to efficiently implement the JVM via direct execution. Therefore, JVM bytecodes form the native base instruction set along with extended bytecodes (see below) for explicit memory access and real-time threading primitives. All JVM bytecodes are microcoded and atomic with the exception of block operations which are interruptible. Executing JVM bytecodes directly eliminates the need for any interpreters or translators thereby providing improved execution performance and smaller memory footprints.
• The JVM instruction set doesn't support explicit memory addressing. How do aJile microprocessors accomplish this for embedded applications?
   

   

  aJile microprocessors utilize the JVM impdep2 trap mechanism to define additional instructions (i.e. 16-bit extended bytecodes). These additional instructions (e.g., ipeek, ipoke) are represented as methods at the Java source level allowing programmers to use standard Java constructs and tools. During an application build (linking process), each occurrence of the corresponding method invoke bytecode is replaced with the extended bytecode (e.g., replacing invokes to the "ipeek" method with the corresponding extended bytecode).
• How are custom instructions implemented?
   

   

  aJile microprocessors allocate a portion of the on-board SRAM for custom instruction microcode. Custom instructions are defined via the extend bytecode mechanism as previously described. aJile provides a service to develop custom instruction microcode from a functional specification.
• How do aJile microprocessors support the Java threading model?
   

   

  aJile microprocessors directly implement real-time Java threading primitives (e.g., java.lang.Thread.yield, java.lang.Object.notify.all) and data structures resulting in extremely fast atomic threading operations (including true Java synchronization), fast interrupt response and deterministic scheduling. The usual resident RTOS is no longer required.
• How are applications developed for aJile microprocessors?
   

   

  Standard Java class files from applications developed with commercial Java IDEs are statically resolved and compacted (e.g., unused methods and fields are removed) to build executables using optimizing linking tools. In addition to bytecode optimizations, the static linker technology performs several embedded application build functions including generating object initialization sequences, memory and JVM configurations, and interrupt and trap handler assignments.
• How do aJile microprocessors support interrupts?
   

   

  aJile microprocessors implement vector tables for interrupt handling. (The static linker allows any method to be assigned to a specific interrupt in the interrupt vector table during an application build.) Upon interrupt recognition, the processor automatically suspends the current thread and saves its state. The processor resolves the pending interrupt through the on-chip interrupt controller and invokes the corresponding handler from the interrupt vector table.
• What is the multiple JVM feature?
   

   

  The multiple JVM feature allows multiple independent Java applications to execute in a deterministic, time-sliced schedule with full memory protection. Within its bounded execution interval and memory space, each JVM environment can employ its own multi-threading and memory utilization policies without threat of intervention by faulty or malicious applications.
• How do aJile microprocessors perform garbage collection (GC)?
   

   

  aJile provides 3 separate GC algorithms (mark & sweep, generational, and train) which will be configurable during application builds (linking process). It is also possible to build applications without GC (i.e. never deallocate memory). Utilizing the multiple JVM feature, each application can select the GC algorithm that best suits its execution profile without interfering with other applications.
• What is the runtime system for aJile microprocessors?
   

   

  aJile's realtime Java runtime systems are built upon Java ME CLDC 1.1 and CDC 1.1 foundation profile. The runtime systems include drivers for on-chip peripherals and various external peripherals including various RS232 / RS485 controllers, ethernet controllers, USB controllers, LCD controllers, touch screen controllers, audio codecs, RTCs, MMC controllers, and CF controllers.
• What is the operating system for aJile microprocessors?
   

   

  aJile processors have a microprogrammed real-time kernel that is internal to the processor. The microprogrammed kernel performs the traditional operating system functions (scheduling, context switching, interrupt preprocessing, error preprocessing, object synchronization). Java threads are native threads on the aJile processor. In addition, extended bytecodes are used to implement Java threading primitives such as sleep, wait, notify, notifyall, yield, monitor enter, monitor exit, and interrupt to provide extremely fast and atomic (non-interruptible) executive operations. These primitives are incorporated in the aJile Java runtime system such that the traditional operating system layer is not required.

aJ-100

• What is the typical power consumption of the aJ-100?
   

   

  Here is a break down of the power consumption of the aJ-100 running at 100Mhz:

  Mode	Power Consumption
  Sleep (1)	< 500 uW @ 3.3V
  Idle (2)	< 13 mW @ 2.5V
  Operation(3)	175.0 mW @ 2.5V (Core) 82.5 mW @ 3.3V (I/O) 257.0 mW (Total)

  Operating modes:

  1. All inputs and I/Os are static HIGH at VDDIO (3.3V). Internal PLL is OFF with oscillator pins (XIN,XOUT) running at 10 MHz.
  2. All inputs and I/Os are static HIGH at VDDIO (3.3V). Internal PLL is running at 100 MHz, aJ-100 is awake with zero I/O activity.
  3. System active running a typical application. "Core" includes all peripherals, PLL, RAM, and the JEM core.
• What are the electrical characteristics of the aJ-100's pins?
   

   

   All outputs are 8mA drivers except IOA[7:0], which are 24mA drivers.
  Typical Iol @ Vol=0.4V for 8mA driver : 14mA, for 24mA driver : 35mA
  Typical Ioh @ Vol=2.4V for 8mA driver : 21mA, for 24mA driver : 51mA

  
  Read more...
• How does the aJ-100 know the memory width (8, 16 or 32-bit) at the bootup time?
   

   

  The initialization data for the aJ-100 processor is completely setup and configured during the build process under the control of JEM Builder. The user can select the configuration options including the width of memory for each of the chip selects with JEM Builder (open the tree under Project and then under Chip Selects) and the appropriate initialization data is integrated in the load image.
  Within the load image, the width of the boot memory is placed in the low two bits at location 0x0000_0000. Upon reset, the aJ-100 first reads location 0x0000_0000 and extracts the low two bits and places them in the width field of the CS0 configuration register. With the boot memory width properly configured the aJ-100 will read the initialization data to configure the remaining values for the chip selects, I/O, and PLL configuration registers as part of the first steps in the boot process.
• What are the known bugs with regards to aJ-100 hardware?
   

   

  Here is the current errata list for the aJ-100 processor:
  

  • The UART receive time-out is much too quick. This issue is masked with aJile's implementation of javax.comm.SerialPort
  • The IrDA decoder does not meet the minimum pulse width requirements of IrDA. Because of this an external IrDA encoder/decoder is required to communicate with most IrDA devices (including the Palm)
  • The power-down control for individual peripherals via the Peripheral Power Down Control register is not implemented.
  • To generate a pulse of constant width using the general purpose timer/counter requires the FIFO to be filled with the constant pulse width value. This can be accomplished by writing the constant value 32 times to the FIFO.
  • The Timer/Counter enable bits in the GPTC global mode register (GPTC_GMR) are connected incorrectly in the aJ-100. Bit 6 of the GPTC_GMR enables T/C0 and bit 7 enables T/C1. Unfortunately the interrupt from T/C2 may not be enabled. The GPIO interrupt logic may be configured to detect most interrupt conditions of T/C2.
  • The general purpose timer/counter sample interrupt is enabled with bit 16 of the general purpose timer/counter mode register (GPTCx_MR) instead of bit 17. This causes both the reload interrupt and the sample interrupt to be enabled with the same bit in GPTCx_MR.
  • The general purpose timer/counter trigger register will not be set unless the corresponding timer is enabled.
• Are there any precautions with using aJ-100 chip selects?
   

   

  There is an aJ-100 logic flaw in the decoding of memory mapped internal peripherals such that CS4 must be configured for a 32-bit data bus width. Likewise, the 16KB internal RAM must also use a chip select setup for 32-bit data bus width. However, the internal RAM is address remappable such that we can use the data width configuration from either CS0, CS1, CS2 or CS3. The address mapping is specified in a JEM Builder configuration file such that the default is to utilize CS3. Hence, CS3 needs to be configured for 32-bit data bus width.

• Can aJ-100 be interfaced to 16-bit and 8-bit devices?
   

   

  The aJ-100 is designed to work with 32-bit, 16-bit, and 8-bit memories to simplify designs. However, the aJ-100 is a 32-bit architecture such that all memory accesses are 32 bits regardless of the memory data widths. For example, if a 16-bit memory is used, a read operation will actually access two consecutive 16-bit memory locations to build a 32-bit word internally. Likewise for 8-bit memory, four consecutive 8-bit memory locations are read to build a 32-bit word internally. Write operations to 16-bit and 8-bit memory have the same property of writing 32-bits at a time. Hence, two consecutive locations are written in 16-bit memory and four consecutive locations are written for 8-bit memories.
  
  Many/most times it is better to specify 8-bit and 16-bit peripheral devices as using the 32-bit operation. For a chip select that is specified as 8-bits, the aJ-100 will perform 4 bus accesses in order to retrieve the 32bits of data. To retrieve the 32-bits of data at address X the aJ-100 will automatically read address X, address X+1, address, X+2, and address X+3. A similar issue is for writes. When chip select is specified as 16-bits the aJ-100 will access address X and X+2. All four transactions will occcur in order for the CPU to access 32-bits of information. This is ideal for memory type devices allowing 32-bits to be automatically retrieved from memory systems that are less than 32-bits wide. However, in general the automatic transfers will cause problems with peripheral devices. That is why it is generally better to specify the peripheral as a 32-bit device. As a 32-bit device the A0 and A1 address will be low for all accesses to that device. Therefore the peripheral should not connect to the aJ-100s A0 and A1 pins.
  
  With the aJ-100 use of A0 and A1 on peripherals should be avoided unless. The exception to this is for devices that can tolerate the automatic bus transactions when the chip select is specified as 8-bits or 16-bits. Most peripheral devices can not take advantage of this operation. Some LCD controllers can take advantage of this operation when accessing the controllers frame buffer.
  
  Caution needs to be exercised interfacing to 16-bit and 8-bit peripherals since reading or writing multiple locations is usually not desired. Single location accesses can be achieved via connecting the address lines right shifted once (for 16-bit peripherals) or twice (for 8-bit peripherals) and using a chip select configured for 32-bit data with. Hence, software drivers must mask out the upper 16 or 24 bits of data for reads since these upper bits are undefined. Likewise, data must be right aligned for write operations.
  

• Can the aJ-100 access more than 32MBytes of address space?
   

   

  The aJ-100 address, A[27:0], supports a total address space of 256MBytes. A27=1 is reserved for internal use leaving 128MBytes for external use. The aJ-100 decodes A[24:22] for the chip select outputs, CS7-CS0, which are also qualified with A[27:25]=000.

  The 8 chip selects therefore each decode 4MBytes of address space and cover a total address space of 32MBytes. Each chip select configuration register defines the timing used for a transaction in the address space for which that chip select applies. For addresses above the low 32MB, the timing is repeated in each 32MB block. That is, the timing select mechanism uses the A[24:22] decode but ignores A[27:25].

  If the following issues seem too troublesome, one simple alternative is to use only 12MB of one or both types of memory freeing up one or two chip selects for peripherals.

  
  Read more...

JNIB

• What is the feature set of JNIB?
   

   

  • aJ-100 Processor
  • 16 MB PSRAM with battery backup
  • 16 MB NAND Flash
  • 10/100 base-T Ethernet port
  • Dual serial channels supporting either RS-232 or RS-485 operation
  • USB 2.0 host port
  • Dual Compact Flash type-II card slots
  • Expansion bus
    • Slave interface
    • 16-bit data bus
    • 8-bit GPIO port
    • SPI and I2C
    • Power and ground
  • Real-time clock with battery backup
  • Status LEDs
  • Alphanumeric LCD display with 16x2 character layout
  • (8) User defineable push buttons
  • (10) Configuration switches for boot source selection and serial channel mode selection
  • Audible Buzzer
• What the power requirement of JNIB?
   

   

  The JNIB is shipped with a 5VDC/2A power transformer. The JNIB  power requirements vary depending on the use of the LCD display back light and the power draw from USB peripherals.
• What are the physical dimensions of the JNIB?
   

   

  130mm (w) x 135mm (d) x 32mm (h)
• What regulatory agency approvals does the JNIB have?
   

   

  Emmissions and Immunity

  • FCC part B
  • ICES-0003
  • EMC
  • VCCI

  Safety

  • US 60950
  • CSA
  • EN609050
  • IEC 60950-1
• What is the main difference between JNIB and JNIB_L?
   

   

  JNIB_L does not have the LCD display and does not have the keypad/LED daughter board. It uses a lightpipe to show the LEDs on the main board. Otherwise it is identical to the JNIB