f



Digilent USB support from Xilinx Impact (Programmer cable SDK for Impact)

I've created a patch for Impact so it supoorts Digilent USB. This patch
could be modified to become some kind of SDK for different programmer
cable which are not supported by Impact.

So here is my survey. What kind of programmer cables would you like to
use with Impact?

Regards,

Zoltan

0
8/24/2006 10:22:00 PM
comp.arch.fpga 18587 articles. 2 followers. Post Follow

22 Replies
1456 Views

Similar Articles

[PageSpeed] 1

zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> I've created a patch for Impact so it supoorts Digilent USB. This patch
> could be modified to become some kind of SDK for different programmer
> cable which are not supported by Impact.

> So here is my survey. What kind of programmer cables would you like to
> use with Impact?

For me, the biggest problem (with impact on linux) is the use of the
windriver. It needs a recompile for every kernel update, it doesn't play
nice with with other users of the parallel port (the normal lp module), it
creates a security hole as big as a barn door, it taints the kernel and is
usefull as a P.I.T.A. as ppdev/libusb could deliver the needed functionality 
for free.

Otherwise, the MPSSE mode of the FT2232 would be welcome.

B.t.w, I'll try to get MPSSE running for xilprog a.s.a.p.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
0
Uwe
8/24/2006 10:47:03 PM
My version works only on Win32 :(
I do a lot of embedded Linux stuff, but I prefer my Windows desktop :)

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > I've created a patch for Impact so it supoorts Digilent USB. This patch
> > could be modified to become some kind of SDK for different programmer
> > cable which are not supported by Impact.
>
> > So here is my survey. What kind of programmer cables would you like to
> > use with Impact?
>
> For me, the biggest problem (with impact on linux) is the use of the
> windriver. It needs a recompile for every kernel update, it doesn't play
> nice with with other users of the parallel port (the normal lp module), it
> creates a security hole as big as a barn door, it taints the kernel and is
> usefull as a P.I.T.A. as ppdev/libusb could deliver the needed functionality
> for free.
>
> Otherwise, the MPSSE mode of the FT2232 would be welcome.
>
> B.t.w, I'll try to get MPSSE running for xilprog a.s.a.p.
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

0
zcsizmadia
8/24/2006 10:56:20 PM
zcsizmadia@gmail.com wrote:

> My version works only on Win32 :(
> I do a lot of embedded Linux stuff, but I prefer my Windows desktop :)

How'd you patch it?
It should be possible to port your change over to Linux (perhaps using a
different technique but the mechanics of your patch should still apply)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
0
Daniel
8/25/2006 1:58:33 AM
I inject a dll into the impact.exe, and hook DeviceIoControl and some
other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT
I/O port using windriver6 driver. Instead of calling original windrvr
DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits  to
Digilent USB (or any other programmer cable).

On linux the easiest could be to create a brand new windrvr emulator
driver where we implement all the IOCTLs used by impact. BTW, I have no
clue why they are using the windriver as a device driver, because all
the features they do with the Jungo driver ius really simple and
generic(eg: user mode I/O access, USB acces to device, etc.)

Zoltan

0
zcsizmadia
8/25/2006 3:47:53 AM
zcsizmadia@gmail.com wrote:
> I've created a patch for Impact so it supoorts Digilent USB. This patch
> could be modified to become some kind of SDK for different programmer
> cable which are not supported by Impact.
> 
> So here is my survey. What kind of programmer cables would you like to
> use with Impact?
> 
> Regards,
> 
> Zoltan
> 

Actually the question I have is what kinds of programmer cables can
I use with linux. Impact -- I'd just as soon not use it. I prefer open
source command line utilities. In fact I want everything to be a
command line utility -- get rid of the IDE's. I use my own editor
and "make" and I'm happy.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
0
David
8/25/2006 4:59:36 AM
zcsizmadia@gmail.com schrieb:

> I've created a patch for Impact so it supoorts Digilent USB. This patch
> could be modified to become some kind of SDK for different programmer
> cable which are not supported by Impact.
>
> So here is my survey. What kind of programmer cables would you like to
> use with Impact?
>
> Regards,
>
> Zoltan

Zoltan,

here is the survey ==> and and all.

if you do want todo some work on the topic, it makes WAY more sense to
"discover" the Impact CableServer protocol, in that way you dont need
to patch anything, you can support both win and linux and you can be
either adding 3rdr party programmer support to impact by using 3rd
party "cableserver" or you can add support for impact supported cables
to 3rd party hardware.

the protocol is easy to figure out, start cableserver with debug
logging, then etherreal and run impact and make some notices, then
start your own cableserver and monitor  difference in the comms.

I have done preliminary work for this, but unfortunatly I have not
enought time right now for this task.If you are interested I can give
all the info and programs I have (partial cableserver emu). If you need
some Xilinx board I could have some overleft to 'sponsor' the project.

Antti
XSIM => MicroBlaze+uClinux Simulator (open plugin SDK)
http://xilant.com

0
Antti
8/25/2006 7:05:34 AM
zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> I inject a dll into the impact.exe, and hook DeviceIoControl and some
> other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT
> I/O port using windriver6 driver. Instead of calling original windrvr
> DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits  to
> Digilent USB (or any other programmer cable).

Do you do this without the windriver header file?

> On linux the easiest could be to create a brand new windrvr emulator
> driver where we implement all the IOCTLs used by impact. BTW, I have no
> clue why they are using the windriver as a device driver, because all
> the features they do with the Jungo driver ius really simple and
> generic(eg: user mode I/O access, USB acces to device, etc.)



-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
0
Uwe
8/25/2006 7:53:36 AM
David Ashley <dash@nowhere.net.dont.email.me> writes:

> Actually the question I have is what kinds of programmer cables can
> I use with linux. Impact -- I'd just as soon not use it. I prefer open
> source command line utilities. In fact I want everything to be a
> command line utility -- get rid of the IDE's. I use my own editor
> and "make" and I'm happy.
> 

I've done just this in Linux with a bit of makefile like this:

prog: work/$(TOP).bit
        @echo "setPreference -pref StartupCLock:AUTO_CORRECTION" > work/impact.c
md
        @echo "setMode -bs" >> work/impact.cmd
        @echo "setCable -port auto" >> work/impact.cmd
        @echo "Identify" >> work/impact.cmd
        @echo "setAttribute -position 1 -attr configFileName -value
$(TOP).bit" >> work/impact.cmd
        @echo "Program -p 1 " >> work/impact.cmd
        @echo "quit" >> work/impact.cmd
        cd work && impact -batch impact.cmd

make prog then does the work...

Of course, ideally, ditching Impact would be good ;-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   
0
Martin
8/25/2006 8:50:43 AM
zcsizmadia@gmail.com wrote:
> I've created a patch for Impact so it supoorts Digilent USB. This patch
> could be modified to become some kind of SDK for different programmer
> cable which are not supported by Impact.
> 
> So here is my survey. What kind of programmer cables would you like to
> use with Impact?
> 
> Regards,
> 
> Zoltan
> 

The support of Amontec JTAGkey would be very nice (based on FTDI FT2232 
- FT2232L to be green). The Amontec JTAGkey is one of the only USB JTAG 
POD with very large io voltage range (all IOs can drive at 24mA) !

goto http://www.amontec.com/jtagkey.shtml

Note:
We are working on a new version cheaper but without ESD-EMI overvoltage 
.... protection and for 5V to 2.8V only. Coming in the next two weeks.
We are working on our own .dll for controlling the JTAGkey integrating 
JTAG layer.

Let me know if you want to receive one Amontec JTAGkey as sample (we 
will ship to you without any charge for you), this can be help for your 
integration.

If interested, send me an email to laurent DOT gauch @ amontec DOT com

Regards,
Laurent
www.amontec.com
0
Amontec
8/25/2006 1:32:11 PM
Antii,

The cableserver methos sounds much better. In that case the full
Digilent USB could be
utilized.
Next week I'll look into it.


Uwe,

Yes and no. I use the windrvr.h to check which IOCTL is important to
overwrite. The actual LPT I/O communication is very simple. You can see
the location of port and data in the packets.

BTW I use strace to log low level API activity by impact.
http://www.bindview.com/Services/RAZOR/Utilities/Windows/strace_readme.cfm

Zoltan

0
zcsizmadia
8/25/2006 2:02:48 PM
I still use 6.3,and it doesn't exist there :(
Afetr installing 8.2 I could make CableServer work (with a lot of
impact and CableServer crashes :)

Here is what I think. I can easily hook the WSOCK32 functions in
CableServer and see what parameters they have in accept, connect, recv,
send, ioctlsocket, etc. In that case it would be much easier to
reverse engineer the communication and reproduce the whole
communication in a new CableServer.

Your idea will work on both Linux and Win32 for sure, so next week I
start working on a new CableServer.

First I think I will implement the Paralell III support, that will be a
good start to test and debug, and later implement other LPT based
cables, and then implement Digilent USB, which I think should be easy.

I hate to pick names for projects. Any ideas? :)

Zoltan

0
zcsizmadia
8/25/2006 4:21:42 PM
zcsizmadia@gmail.com schrieb:

> I still use 6.3,and it doesn't exist there :(
> Afetr installing 8.2 I could make CableServer work (with a lot of
> impact and CableServer crashes :)
>
> Here is what I think. I can easily hook the WSOCK32 functions in
> CableServer and see what parameters they have in accept, connect, recv,
> send, ioctlsocket, etc. In that case it would be much easier to
> reverse engineer the communication and reproduce the whole
> communication in a new CableServer.
>
> Your idea will work on both Linux and Win32 for sure, so next week I
> start working on a new CableServer.
>
> First I think I will implement the Paralell III support, that will be a
> good start to test and debug, and later implement other LPT based
> cables, and then implement Digilent USB, which I think should be easy.
>
> I hate to pick names for projects. Any ideas? :)
>
> Zoltan

eeesy! names are easy. dont worry yet.

it makes sense to make a "DummY"
cableserver first, then add cable drivers as loadable plugins to it.
or use the cable server as another brigge, like forwarding impact
requests to altera jtagserver :)

or the cableserver could recognize both altera and impact protocols

Antti
attached is VERY RAW something that was at least responding
to some impact tcp packets. maybe its for older version and
its all changed, anyway all the protocol is clearly visible and
lots of info comes from cableserver commandline log, this
is good source to look at , there are as example commands
to set and clear single bits in parallel port, ..



----------
procedure TForm1.serverAccept(Sender: TObject; ClientSocket:
TCustomIpClient);
var
  a : array[0..100] of byte;
  slen,i,j,l : integer;
  pNumber, Speed: integer;
  pName, cName,
  s : string;

begin
  l := ClientSocket.ReceiveBuf(a, 100);
//  memo1.Lines.Add('ACCEPT '+inttostr(l));

  case a[0] of
    $00: begin
      memo1.Lines.Add('X 00');
      ClientSocket.Sendln(#$01, '');
    end;

    $01: begin
      memo1.Lines.Add('LOCK');

      ClientSocket.Sendln(#$01, '');
      repeat
        l := ClientSocket.ReceiveBuf(a, 100);
        if l>0 then
        begin
          ClientSocket.Sendln(#$01, '');
          memo1.Lines.Add('cmd'+inttostr(l));
        end;
      until (a[0] = 1) or (l<=0);
    end;

    $03: begin
///      memo1.Lines.Add('SET CABLE'+inttostr(l));

      if l = 2 then
      begin
//        ClientSocket.Sendln(#$01, '');
//        server.WaitForData;

        l := ClientSocket.ReceiveBuf(a, 100);
        l := ClientSocket.Sendln(#$01, '');
      end else
      begin
        ClientSocket.Sendln(#$01, '');
      end;
    end;
    $04: begin
      memo1.Lines.Add('Close Cable');
      ClientSocket.Sendln(#$01, '');
    end;

    $05: begin
///      memo1.Lines.Add('GET INFO');
      ClientSocket.Sendln(#$01, '');
      //

///      memo1.Lines.Add('GET INFO2');


      ClientSocket.Sendln(
      #$03#$00#$00#$00+
      'LPT'+
      #$00#$00#$00#$00+
      #$40#$0D#$03#$00+
      #$0C#$00#$00#$00+
      'Parallel III'+
      #$00#$00#$00#$00
      , '');
///      memo1.Lines.Add('GET INFO3');

    (*
      ClientSocket.Sendln(
      #$04#$00#$00#$00+
      'NONE'+
      #$FF#$FF#$FF#$FF+
      #$00#$00#$00#$00+
      #$00#$00#$00#$00+
      #$00#$00#$00#$00
      , '');
*)
    end;
    $11: begin
      memo1.Lines.Add('X 11');
      ClientSocket.Sendln(#$01, '');
    end;

    $70: begin
      //
      memo1.Lines.Add('Check Server');
      ClientSocket.Sendln(#$01, '');
    end else
    begin
      for i:=0 to l-1 do memo1.lines.add('REC:' +
inttohex(ord(a[i]),2));

      ClientSocket.Sendln(#$01, '');
    end;
  end;
end;

0
Antti
8/25/2006 4:29:22 PM
Martin Thompson wrote:
> Of course, ideally, ditching Impact would be good ;-)

Well impact is now out of the picture with the spartan-3e
starter board, using the xup
http://inisyn.org/src/xup/

So I've got all I need.
vhdl -> ghdl -> gtkwave for simulation
vhdl -> xilinx webpack tools -> bitfile for synthesis
xup -> spartan3e for test

Net cost? $149 for spartan-3e starter board, plus
some determination not to do this all under windows.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
0
David
8/25/2006 4:38:19 PM
David Ashley schrieb:

> Martin Thompson wrote:
> > Of course, ideally, ditching Impact would be good ;-)
>
> Well impact is now out of the picture with the spartan-3e
> starter board, using the xup
> http://inisyn.org/src/xup/
>
> So I've got all I need.
> vhdl -> ghdl -> gtkwave for simulation
> vhdl -> xilinx webpack tools -> bitfile for synthesis
> xup -> spartan3e for test
>
> Net cost? $149 for spartan-3e starter board, plus
> some determination not to do this all under windows.
>
> -Dave
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

without determination it all works brillantly without fuzz in winXP ;)

Antti

0
Antti
8/25/2006 4:44:11 PM
Antti wrote:
> without determination it all works brillantly without fuzz in winXP ;)

Sure, and soldiers desert from wars and go over to the enemy
side all the time. But they'll have to live with themselves
for the rest of their lives...:^).

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
0
David
8/25/2006 5:29:44 PM
I've already hooked all the tcp/ip API in Cableserver, and dump all the
recv, send buffers to the screen, so now if I run Cable server in debug
mode, I can see the communication for all the messages between Impact
and CableServer.  The protocoll seems very simple especially in debug
mode I can see what  is the message, and what are the parameters.

Unfortunately this weekend i'm going for a short vacation :) But I'll
jump on this when I get back.

Zoltan

PS:
Here are couple of dumps for sampling:

Main ->  GET INFO pName=LPT, pNumber=0, speed = 200000, cName=Parallel
III.
send
01
send
03 00 00 00
send
4C 50 54
send
00 00 00 00
send
40 0D 03 00
send
0C 00 00 00
send
50 61 72 61 6C 6C 65 6C 20 49 49 49
send
00 00 00 00

send
01
WSARecv
21
WSARecv
80 00 00 00 00 00
WSARecv
00
WSARecv
00 00 00 00 00
WSARecv
00
BScn ->  WRITE mode=128, writeLength=0, readLength=0.

send
01
WSARecv
26
WSARecv
0C 00 00 00 05 00 00 00
BScn ->  PULSE PIN 12 count=5.

0
zcsizmadia
8/25/2006 5:33:01 PM
I've already hooked all the tcp/ip API in Cableserver, and dump all the
recv, send buffers to the screen, so now if I run Cable server in debug
mode, I can see the communication for all the messages between Impact
and CableServer.  The protocoll seems very simple especially in debug
mode I can see what  is the message, and what are the parameters.

Unfortunately this weekend i'm going for a short vacation :) But I'll
jump on this when I get back.

Zoltan

PS:
Here are couple of dumps for sampling:

Main ->  GET INFO pName=LPT, pNumber=0, speed = 200000, cName=Parallel
III.
send
01
send
03 00 00 00
send
4C 50 54
send
00 00 00 00
send
40 0D 03 00
send
0C 00 00 00
send
50 61 72 61 6C 6C 65 6C 20 49 49 49
send
00 00 00 00

send
01
WSARecv
21
WSARecv
80 00 00 00 00 00
WSARecv
00
WSARecv
00 00 00 00 00
WSARecv
00
BScn ->  WRITE mode=128, writeLength=0, readLength=0.

send
01
WSARecv
26
WSARecv
0C 00 00 00 05 00 00 00
BScn ->  PULSE PIN 12 count=5.

0
zcsizmadia
8/25/2006 5:33:46 PM
BTW I'm a hardcore Windows guys so this soldiers/enemy example wasnt't
funny at all :))

David Ashley wrote:
> Antti wrote:
> > without determination it all works brillantly without fuzz in winXP ;)
>
> Sure, and soldiers desert from wars and go over to the enemy
> side all the time. But they'll have to live with themselves
> for the rest of their lives...:^).
>
> -Dave
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

0
zcsizmadia
8/25/2006 5:36:02 PM
zcsizmadia@gmail.com wrote:
> BTW I'm a hardcore Windows guys so this soldiers/enemy example wasnt't
> funny at all :))

You're also a top poster sometimes :^). But anyway it's not
directed at you, if I were to sell out and move to windows I'd
be betraying the cause. You and most of the world are
perfectly free to be in the windows camp. More power to you.

I use windows when I have to but I'm just so much more
effective when I can use linux.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
0
David
8/25/2006 8:07:24 PM
David Ashley schrieb:

> zcsizmadia@gmail.com wrote:
> > BTW I'm a hardcore Windows guys so this soldiers/enemy example wasnt't
> > funny at all :))
>
> You're also a top poster sometimes :^). But anyway it's not
> directed at you, if I were to sell out and move to windows I'd
> be betraying the cause. You and most of the world are
> perfectly free to be in the windows camp. More power to you.
>
> I use windows when I have to but I'm just so much more
> effective when I can use linux.
>
> -Dave
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

there are different excuses, reasons for everything, as example I use
WinXP, while:

1) it is capable to start multiply instances of "norton commander" !!!
well sure yet not very good at it, but manageable.

yes I have looked at midnight commander too, but I still stick
to my old tools, eg the original NC (or actually its clone FAR)

Antti

0
Antti
8/25/2006 8:19:20 PM
zcsizmadia@gmail.com wrote:

> I inject a dll into the impact.exe, and hook DeviceIoControl and some
> other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT
> I/O port using windriver6 driver. Instead of calling original windrvr
> DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits  to
> Digilent USB (or any other programmer cable).

Easy enough to do that with LD_PRELOAD in Linux. (.so injection)
Interesting idea!

> On linux the easiest could be to create a brand new windrvr emulator
> driver where we implement all the IOCTLs used by impact. BTW, I have no
> clue why they are using the windriver as a device driver, because all
> the features they do with the Jungo driver ius really simple and
> generic(eg: user mode I/O access, USB acces to device, etc.)

Assuming you can get the windrv header file, although I think you can
probably reverse engineer it anyway.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
0
Daniel
8/26/2006 8:29:57 AM
Go to windriver website and download the evaluation version. It
includes the header files.

Zoltan

0
zcsizmadia
8/26/2006 2:53:39 PM
Reply: