Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

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

Discussion Groups

Discussion Groups | FPGA-CPU | Java JTAG API

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).

Java JTAG API - Kolja Sulimma - Jan 12 13:14:00 2005


I found the Java JTAG API that I was talking about.
It is called JavaScan and has been withdrawn.
http://www.jcp.org/en/jsr/detail?id=2
(inkludes example source code to program a XC9500)

There is a HAL that allows to efficiently send large blocks of data via JTAG
http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm

Kolja




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Java JTAG API - Eric Smith - Jan 12 13:57:00 2005

Kolja wrote:
> I found the Java JTAG API that I was talking about.
> It is called JavaScan and has been withdrawn.
> http://www.jcp.org/en/jsr/detail?id=2
> (inkludes example source code to program a XC9500)

That's the awful bit-at-a-time one. Just as well that it was
withdrawn.

> There is a HAL that allows to efficiently send large blocks of data via
> JTAG
> http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm

That's a much better interface, since you can supply an arbitrary amount
of data in one call. I'm willing to write C code providing the underlying
transport for that, but someone else will have to deal with wrapping it
in JNI.

Eric




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Java JTAG API - Kolja Sulimma - Jan 13 5:35:00 2005

Eric Smith wrote:

>Kolja wrote: >>I found the Java JTAG API that I was talking about.
>>It is called JavaScan and has been withdrawn.
>>http://www.jcp.org/en/jsr/detail?id=2
>>(inkludes example source code to program a XC9500)
>>
>>
>
>That's the awful bit-at-a-time one. Just as well that it was
>withdrawn.
>
>>There is a HAL that allows to efficiently send large blocks of data via
>>JTAG
>>http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm
>>
>>
>
>That's a much better interface, since you can supply an arbitrary amount
>of data in one call. I'm willing to write C code providing the underlying
>transport for that, but someone else will have to deal with wrapping it
>in JNI. Unfortunately there are no API documents on that page. But the HAL is
designed for the API, so there must be
API suport for transferring large blocks of data, even if Xilinx doesn't
use it in the example.

Kolja Sulimma


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Java JTAG API - Eric Smith - Jan 13 11:49:00 2005

Kolja wrote:
> There is a HAL that allows to efficiently send large blocks of data via
> JTAG
> http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm

I wrote:
> That's a much better interface, since you can supply an arbitrary amount
> of data in one call.

Kolja wrote:
> Unfortunately there are no API documents on that page. But the HAL is
> designed for the API, so there must be
> API suport for transferring large blocks of data, even if Xilinx doesn't
> use it in the example.

Huh? Most of that page *is* API documentation. I was specifically
referring to the interface:

public native byte OperateTAP( int bitCount, byte[] TCKbits,
byte[] TMSbits, byte[] TDIbits, byte[] TDObits );

which is described in considerable detail.

The rest of the API is not too different than the other bit-at-a-time
one, but that one OperateTAP call makes it possible to do reasonably
efficient remote JTAG for some things.

It may still be insufficient, though, because for some devices it may
not be possible to blindly send large blocks of data without examining
the feedback until the entire block completes.

For instance, if you want to program a parallel flash memory device
attached to pins that can be controlled by a JTAG scan chain, you
want much more of the smarts to be near the device, because you have
to shift the entire scan chain every time you change any signal.

Eric




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Java JTAG API - Kolja Sulimma - Jan 13 12:06:00 2005


On Thu, 2005-01-13 at 17:49, Eric Smith wrote:
> Kolja wrote:
> > There is a HAL that allows to efficiently send large blocks of data via
> > JTAG
> > http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm
>
> I wrote:
> > That's a much better interface, since you can supply an arbitrary amount
> > of data in one call.
>
> Kolja wrote:
> > Unfortunately there are no API documents on that page. But the HAL is
> > designed for the API, so there must be
> > API suport for transferring large blocks of data, even if Xilinx doesn't
> > use it in the example.
>
> Huh? Most of that page *is* API documentation. I was specifically
> referring to the interface:
>
> public native byte OperateTAP( int bitCount, byte[] TCKbits,
> byte[] TMSbits, byte[] TDIbits, byte[] TDObits );
>
> which is described in considerable detail.
>
> The rest of the API is not too different than the other bit-at-a-time
> one, but that one OperateTAP call makes it possible to do reasonably
> efficient remote JTAG for some things.

That's a misunderstanding because the nomenclature is not clear.
The first link I posted refers to a standardization approach for a Java
JTAG API, that's what I refered to as API.
The second link is a hardware abstraction layer (HAL) for the very same
API. Of course this a an API, too, but to differentiate I refered to it
as HAL.

What I ment is, from the HAL you can infer that the original Java API
also had a method to send long strings od bits.

> It may still be insufficient, though, because for some devices it may
> not be possible to blindly send large blocks of data without examining
> the feedback until the entire block completes.
> For instance, if you want to program a parallel flash memory device
> attached to pins that can be controlled by a JTAG scan chain, you
> want much more of the smarts to be near the device, because you have
> to shift the entire scan chain every time you change any signal.

I agree.

Kolja




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Java JTAG API - Peter C. Wallace - Jan 13 12:19:00 2005

On Thu, 13 Jan 2005, Eric Smith wrote: > Kolja wrote:
> > There is a HAL that allows to efficiently send large blocks of data via
> > JTAG
> > http://www-ee.eng.hawaii.edu/~linbai/Java_API/java_native_interface.htm
>
> I wrote:
> > That's a much better interface, since you can supply an arbitrary amount
> > of data in one call.
>
> Kolja wrote:
> > Unfortunately there are no API documents on that page. But the HAL is
> > designed for the API, so there must be
> > API suport for transferring large blocks of data, even if Xilinx doesn't
> > use it in the example.
>
> Huh? Most of that page *is* API documentation. I was specifically
> referring to the interface:
>
> public native byte OperateTAP( int bitCount, byte[] TCKbits,
> byte[] TMSbits, byte[] TDIbits, byte[] TDObits );
>
> which is described in considerable detail.
>
> The rest of the API is not too different than the other bit-at-a-time
> one, but that one OperateTAP call makes it possible to do reasonably
> efficient remote JTAG for some things.
>
> It may still be insufficient, though, because for some devices it may
> not be possible to blindly send large blocks of data without examining
> the feedback until the entire block completes.
>
> For instance, if you want to program a parallel flash memory device
> attached to pins that can be controlled by a JTAG scan chain, you
> want much more of the smarts to be near the device, because you have
> to shift the entire scan chain every time you change any signal. If the hardware designer is nice and brings out the CS, OE, and WE pins, you
can save quite a few scan chain shifts. The SVF file format supports
messing with IO bits to do this. > Eric >
> To post a message, send it to:
> To unsubscribe, send a blank message to:
> Yahoo! Groups Links Peter Wallace
Mesa Electronics



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )