Announcing JOLT - Yet Another Xilinx Programming Tool

John Williams wrote:

>>> I hate to say this but you probably could have better spent your time 
>>> developing a SVF file interpreter [...]
>>
>> You may well be right. I did have a lot of fun in the process though, 
>> so no regrets :-)
> 
> You probably learned a lot as well, and that's more valuable than just 
> about anything.

I sure did. I hadn't hooked up FPGA's before this. You see, I'm a 
software, not a hardware, guy by training so I really expected the whole 
excercise to end in smoke and, well, tears.

It did not, so I now know that I can easily tie together a couple of 
development boards using the user I/O pins if the need arises. Second, I 
know understand enough of JTAG to be able to use it as intended, instead 
of swapping parallel cables all the time.

> One thing about proprietary tools and data formats is that they inspire 
> all sorts of "just because" exploratory hacking.

Certainly. it is a chilling thought that even the kind of simple reverse 
engineering (analyzing what IMPACT puts on the parallel port) is getting 
increasingly difficult from a legal standpoint. I am not sure if I would 
have posted this openly to a Usenet group if I were a US citizen - a 
strict reading of the DMCA probably outlaws even this completely 
innocent stuff that is for the good of everybody (including Xilinx).

> Witness the fascination people seem to have with the bitstream encoding. 
>  Even if it were published, there's not much that most mortals could do 
> with it anyway.  However, because it's Top Secret, it tantalises the 
> reverse engineer in us all..

I guess we're all still kids, taking apart stuff to see how it works :-)

Regards, Sidney

In article <cg0l1u$jp22@cliff.xsj.xilinx.com>,
Neil Glenn Jacobson  <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote:
>To clear the record, Jungo does not charge a per-seat fee and was not 
>the reason that a Linux-based WebPack was absent.  The specific issue 
>was the per-seat license fee associated with Xilinx's GUI development 
>tool kit.
>
>You may now return to your soapbox...
>

Ok, it's the MainWin porting tool that requires the per-seat license.  
That's pretty much what keep Xilinx from having a set of free tools for 
Linux, correct?

BTW: I'm a customer.  Just trying to help you guys out ;-)

Phil

In article <cg0pjd$jov3@cliff.xsj.xilinx.com>,
Neil Glenn Jacobson  <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote:
>The short answer that avoids almost all the specific issues you raise is 
>that we are moving away from a GUI toolkit that is encumbered with a 
>per-seat license fee.
>

That works too!

Good to hear.  Any idea about when we might see the fruits of these 
efforts?

Thanks

Phil

In article <cg0ldg$jp01@cliff.xsj.xilinx.com>,
Neil Glenn Jacobson  <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote:
>I hate to say this but you probably could have better spent your time 
>developing a SVF file interpreter that runs on Linux that way you could 
>use the SVF files generated from iMPACT which already contain a full 
>implementation of the configuration algorithm and as updated as the 
>algorithms improve.  Alternatively, you could take the JDrive [open and 
>free] source code (http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf) 
>and compile it on Linux (as some already have) to also have an 
>up-to-date, all device configuration solution.
>

Not having been in the FPGA world for several years (but getting back in 
as a hobbyist)...  What's an SVF file?  Even if we had an interpreter for 
SVF files, how would that help us get the bits into the FPGA?  Seems like 
we still need something like JOLT (the physical layer) to actually get the 
bits there.

Phil

Phil Tomson wrote:
> In article <cg0l1u$jp22@cliff.xsj.xilinx.com>,
> Neil Glenn Jacobson  <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote:
> 
>>To clear the record, Jungo does not charge a per-seat fee and was not 
>>the reason that a Linux-based WebPack was absent.  The specific issue 
>>was the per-seat license fee associated with Xilinx's GUI development 
>>tool kit.
>>
>>You may now return to your soapbox...
>>
> 
> 
> Ok, it's the MainWin porting tool that requires the per-seat license.  
> That's pretty much what keep Xilinx from having a set of free tools for 
> Linux, correct?
> 
Well, we don't use MainWin but, yes, that is correct.


> BTW: I'm a customer.  Just trying to help you guys out ;-)
> 
> Phil


-- 

     You've *read the email* - now *buy the book*

SVF is "Serial Vector Format" and is the de facto standard that 
describes that data transmitted to and received from the boundary-scan 
(1149.1, JTAG) Test Access Port (TAP).  It was developed by TI and 
Teradyne but is now administered by Asset Intertech.  More details are 
available on their web site 
(http://www.asset-intertech.com/support/svf.pdf).  You can think of the 
SVF file as assembly language for TAP transactions.  It already includes 
the data to shifted into the device and the necessary TAP transitions.


An alternative approach is based on IEEE Std 1532 which requires BSDL 
files and programming data files (which therefore separate data from 
algorithm).  The free and open source code for this is called JDrive and 
is available from Xilinx's web site as XAPP 500 
(http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf) and its associated 
files.

Phil Tomson wrote:

> In article <cg0ldg$jp01@cliff.xsj.xilinx.com>,
> Neil Glenn Jacobson  <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote:
> 
>>I hate to say this but you probably could have better spent your time 
>>developing a SVF file interpreter that runs on Linux that way you could 
>>use the SVF files generated from iMPACT which already contain a full 
>>implementation of the configuration algorithm and as updated as the 
>>algorithms improve.  Alternatively, you could take the JDrive [open and 
>>free] source code (http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf) 
>>and compile it on Linux (as some already have) to also have an 
>>up-to-date, all device configuration solution.
>>
> 
> 
> Not having been in the FPGA world for several years (but getting back in 
> as a hobbyist)...  What's an SVF file?  Even if we had an interpreter for 
> SVF files, how would that help us get the bits into the FPGA?  Seems like 
> we still need something like JOLT (the physical layer) to actually get the 
> bits there.
> 
> Phil


-- 

     You've *read the email* - now *buy the book*

On Wed, 18 Aug 2004 16:43:35 -0700, Neil Glenn Jacobson wrote:

> The short answer that avoids almost all the specific issues you raise is 
> that we are moving away from a GUI toolkit that is encumbered with a 
> per-seat license fee.

This is good news, hopefully the new GUI tool kit will be X windows
friendly. The current toolkit is awful, FPGA Editor (which is the only GUI
tool I ever use) is unusable over a network. Cadence and Mentor tools
both work seemlessly over a network, there is hardly any performance
difference between running them on a your workstation and running them
on your server. The Cadence and Mentor tools are also distribution
agnostic, I've had no problem running them on any platform even an
Athlon64 running the 64 bit version of Mandrake 10.0. The Xilinx GUI tools
won't run on Mandrake 10.0 in either the 32 bit or 64 bit incarnations. I
have to keep my workstation at 9.2 so I have something that can run
FPGAeditor. The basic tools, xst, map, par, etc, all work fine of course
because they are CLI based and have no library dependencies. In 7.1 Xilinx
should statically link every thing so that these stupid dependencies go
away.

On Thu, 19 Aug 2004 17:39:55 -0400, "B. Joshua Rosen"
<bjrosen@polybus.com> wrote:

>On Wed, 18 Aug 2004 16:43:35 -0700, Neil Glenn Jacobson wrote:
>
>> The short answer that avoids almost all the specific issues you raise is 
>> that we are moving away from a GUI toolkit that is encumbered with a 
>> per-seat license fee.
>
>This is good news, hopefully the new GUI tool kit will be X windows
>friendly. The current toolkit is awful, FPGA Editor (which is the only GUI
>tool I ever use) is unusable over a network.

FPGA Editor is also the only GUI tool I use.  
I use it over a network quite successfully, using TightVNC, since my
desktop machine is too small and slow to run FPGA Editor itself.
What makes you say it's unusable?

Regards,
Allan.

B. Joshua Rosen wrote:
> 
> This is good news, hopefully the new GUI tool kit will be X windows
> friendly. The current toolkit is awful, FPGA Editor (which is the only GUI
> tool I ever use) is unusable over a network...

I don't run FPGA Editor over a network. But as a performance data point, 
I often having seti running in the background reniced to the lowest 
priority. If I run fpga_editor while seti is running, performance is 
terrible; in fact unusable. If I stop seti, then performance is quite 
acceptable; I would even say pretty good.

-- 
My real email is akamail.com@dclark (or something like that).

On Fri, 20 Aug 2004 13:02:54 +1000, Allan Herriman wrote:

> On Thu, 19 Aug 2004 17:39:55 -0400, "B. Joshua Rosen"
> <bjrosen@polybus.com> wrote:
> 
>>On Wed, 18 Aug 2004 16:43:35 -0700, Neil Glenn Jacobson wrote:
>>
>>> The short answer that avoids almost all the specific issues you raise is 
>>> that we are moving away from a GUI toolkit that is encumbered with a 
>>> per-seat license fee.
>>
>>This is good news, hopefully the new GUI tool kit will be X windows
>>friendly. The current toolkit is awful, FPGA Editor (which is the only GUI
>>tool I ever use) is unusable over a network.
> 
> FPGA Editor is also the only GUI tool I use.  
> I use it over a network quite successfully, using TightVNC, since my
> desktop machine is too small and slow to run FPGA Editor itself.
> What makes you say it's unusable?
> 
> Regards,
> Allan.

I'm running it over X not VNC (I don't want a desktop just the
application), it takes minutes to draw a screen. VNC is a Windows way of
doing things, it moves pixels which is horribly ineffecient compared to X
which moves commands. However since FPGAeditor is a Windows application I
can see where VNC might do a much better job because it's pixel oriented.
However all of my servers are running Mandrake 10.0 now so I can't run
FPGAEditor on them anyway, at least until 7.1 comes out.