Open-source CableServer for Impact on sourceforge.net

Hi All,

Here is a open-source CableServer replacement,ent for Impact. Currently
Parallel III and Alter ByteBlaster are supported, but any 3rd party can
be implemented easily and can be used from Impact.

I've tested only Impact 8.2, if anybody has any problem with 7.1,
please let me know!

Impact and Xilinx CableServer communication are very pooly written.
There is no error recovery at all. If server stops, Impact GUI will
crash. To avoid this you must disconnect server from GUI using
Output/Cavble disconnect menu.

http://sourceforge.net/projects/xilprg
http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209

Regards,

Zoltan

zcsizmadia@gmail.com schrieb:

> Hi All,
>
> Here is a open-source CableServer replacement,ent for Impact. Currently
> Parallel III and Alter ByteBlaster are supported, but any 3rd party can
> be implemented easily and can be used from Impact.
>
> I've tested only Impact 8.2, if anybody has any problem with 7.1,
> please let me know!
>
> Impact and Xilinx CableServer communication are very pooly written.
> There is no error recovery at all. If server stops, Impact GUI will
> crash. To avoid this you must disconnect server from GUI using
> Output/Cavble disconnect menu.
>
> http://sourceforge.net/projects/xilprg
> http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209
>
> Regards,
>
> Zoltan

Great !! it really works!

so now you can use Impact to connect to ByteBlaster,
or any other custom cable or cable not supported by impact!

Antti

zcsizmadia@gmail.com wrote:
> Hi All,
> 
> Here is a open-source CableServer replacement,ent for Impact. Currently
> Parallel III and Alter ByteBlaster are supported, but any 3rd party can
> be implemented easily and can be used from Impact.
> 
> I've tested only Impact 8.2, if anybody has any problem with 7.1,
> please let me know!
> 
> Impact and Xilinx CableServer communication are very pooly written.
> There is no error recovery at all. If server stops, Impact GUI will
> crash. To avoid this you must disconnect server from GUI using
> Output/Cavble disconnect menu.
> 
> http://sourceforge.net/projects/xilprg
> http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209
> 
> Regards,
> 
> Zoltan
> 

Dear All,

This is good news. About time to get some open software to program FPGA's!.

The problem I still have is that we and many others are using the USB 
Parallel IV cable (DLC7).  Who has ideas or works on an interface to 
drive the DLC7 cable? It seems to me that it now should be possible to
build an USB interface to communicate with the DLC7. First someone needs 
   to 'investigate' the functions of the Cypress firmware and then with 
the knowledge of the Impact protocol ....

Regards,

Rene.

Rene van Leuken schrieb:

> zcsizmadia@gmail.com wrote:
> > Hi All,
> >
> > Here is a open-source CableServer replacement,ent for Impact. Currently
> > Parallel III and Alter ByteBlaster are supported, but any 3rd party can
> > be implemented easily and can be used from Impact.
> >
> > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > please let me know!
> >
> > Impact and Xilinx CableServer communication are very pooly written.
> > There is no error recovery at all. If server stops, Impact GUI will
> > crash. To avoid this you must disconnect server from GUI using
> > Output/Cavble disconnect menu.
> >
> > http://sourceforge.net/projects/xilprg
> > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209
> >
> > Regards,
> >
> > Zoltan
> >
>
> Dear All,
>
> This is good news. About time to get some open software to program FPGA's!.
>
> The problem I still have is that we and many others are using the USB
> Parallel IV cable (DLC7).  Who has ideas or works on an interface to
> drive the DLC7 cable? It seems to me that it now should be possible to
> build an USB interface to communicate with the DLC7. First someone needs
>    to 'investigate' the functions of the Cypress firmware and then with
> the knowledge of the Impact protocol ....
>
> Regards,
>
> Rene.

not exactly, you are messing some things.
Parallel Cable IV = DLC7, does not work on USB dongle
Platform USB Cable = DLC9

if you need to communicate with DLC9 then you use the original
xilinx cable server and use the ip protocol to talk to it.
no need to know anything internal to the DLC9.

if you want to make impact to communicate with some USB cable
other than DLC9 then you have to add support for it to the opensource
cable server. This could also be a special USB2LPT type of thing that
is later connected to DLC7 but that doesnt make much sense.

Antti

Rene van Leuken <rene@cas.et.tudelft.nl> wrote:
...

> The problem I still have is that we and many others are using the USB 
> Parallel IV cable (DLC7).  Who has ideas or works on an interface to 
> drive the DLC7 cable? It seems to me that it now should be possible to
> build an USB interface to communicate with the DLC7. First someone needs 
>    to 'investigate' the functions of the Cypress firmware and then with 
> the knowledge of the Impact protocol ....

Have a look at http://inisyn.org/src/xup/

It states:
"The standalone Xilinx Platform Cable USB is unsupported and untested. Since
its hardware is presumably very similar, it may be usable as-is or with some
minor hacking. "

So well worth a try.

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

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

I think later on it would be nice to support all Xilinx programmer
cables natively from cblsrv (Platform USB, Parallel IV, etc.):

1. Jungo driver could be eliminated on both Linux and Win32
2. A open-source "cblhost" could be easily written and bundled with
cblsrv supporting standard Xilinx cables + 3rd party cables

Zoltan

Antti wrote:
> Rene van Leuken schrieb:
>
> > zcsizmadia@gmail.com wrote:
> > > Hi All,
> > >
> > > Here is a open-source CableServer replacement,ent for Impact. Currently
> > > Parallel III and Alter ByteBlaster are supported, but any 3rd party can
> > > be implemented easily and can be used from Impact.
> > >
> > > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > > please let me know!
> > >
> > > Impact and Xilinx CableServer communication are very pooly written.
> > > There is no error recovery at all. If server stops, Impact GUI will
> > > crash. To avoid this you must disconnect server from GUI using
> > > Output/Cavble disconnect menu.
> > >
> > > http://sourceforge.net/projects/xilprg
> > > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209
> > >
> > > Regards,
> > >
> > > Zoltan
> > >
> >
> > Dear All,
> >
> > This is good news. About time to get some open software to program FPGA's!.
> >
> > The problem I still have is that we and many others are using the USB
> > Parallel IV cable (DLC7).  Who has ideas or works on an interface to
> > drive the DLC7 cable? It seems to me that it now should be possible to
> > build an USB interface to communicate with the DLC7. First someone needs
> >    to 'investigate' the functions of the Cypress firmware and then with
> > the knowledge of the Impact protocol ....
> >
> > Regards,
> >
> > Rene.
>
> not exactly, you are messing some things.
> Parallel Cable IV = DLC7, does not work on USB dongle
> Platform USB Cable = DLC9
>
> if you need to communicate with DLC9 then you use the original
> xilinx cable server and use the ip protocol to talk to it.
> no need to know anything internal to the DLC9.
>
> if you want to make impact to communicate with some USB cable
> other than DLC9 then you have to add support for it to the opensource
> cable server. This could also be a special USB2LPT type of thing that
> is later connected to DLC7 but that doesnt make much sense.
> 
> Antti

zcsizmadia@gmail.com schrieb:

> I think later on it would be nice to support all Xilinx programmer
> cables natively from cblsrv (Platform USB, Parallel IV, etc.):
>
> 1. Jungo driver could be eliminated on both Linux and Win32
> 2. A open-source "cblhost" could be easily written and bundled with
> cblsrv supporting standard Xilinx cables + 3rd party cables
>
> Zoltan
>
its not that easy. specially if you want to use unmodified cable IV and
usb cable. for usb cable it is possible to use replacement firmware and
pld file, but it want be any more xilinx platform usb cable then.

similarly the pld in Cable IV can be read out and reprogrammed.

if you are interest to support Cable IV in Cable IV high speed mode I
can give jedec2vhdl converter that can create VHDL code from the jedec
file read back from Cable IV, it should be enough to reverse the Cable
IV low level protocol I think.

I tried to revers Cable IV by creating an PCI IP Core that emulated the
cable and logged the transactions, but that way didnt leed to success,
ok I did not have time to have proper ECP emulation that was the reason
why I didnt succeed with that attempt.

Antti

Probably I miss something here.

Why not just hook LPT or Jungo driver in windows, and see what is sent
to the cable? Or it is downloading the firmware at the very beginning
and it's a copyright issue to include the original firmware in your
open-source application?
The same way using a USB sniffer the communication can be reverse
engineered (unless the data is not crypted)

Do you have any  Par IV or Platform USB cable I could borrow to see if
it could be reverse engineered?

Zoltan

Antti wrote:
> zcsizmadia@gmail.com schrieb:
>
> > I think later on it would be nice to support all Xilinx programmer
> > cables natively from cblsrv (Platform USB, Parallel IV, etc.):
> >
> > 1. Jungo driver could be eliminated on both Linux and Win32
> > 2. A open-source "cblhost" could be easily written and bundled with
> > cblsrv supporting standard Xilinx cables + 3rd party cables
> >
> > Zoltan
> >
> its not that easy. specially if you want to use unmodified cable IV and
> usb cable. for usb cable it is possible to use replacement firmware and
> pld file, but it want be any more xilinx platform usb cable then.
>
> similarly the pld in Cable IV can be read out and reprogrammed.
>
> if you are interest to support Cable IV in Cable IV high speed mode I
> can give jedec2vhdl converter that can create VHDL code from the jedec
> file read back from Cable IV, it should be enough to reverse the Cable
> IV low level protocol I think.
>
> I tried to revers Cable IV by creating an PCI IP Core that emulated the
> cable and logged the transactions, but that way didnt leed to success,
> ok I did not have time to have proper ECP emulation that was the reason
> why I didnt succeed with that attempt.
> 
> Antti

On 2006-09-06, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> "The standalone Xilinx Platform Cable USB is unsupported and untested. Since
> its hardware is presumably very similar, it may be usable as-is or with some
> minor hacking. "

I have tested it and it doesn't work. One problem is that the CPLD on the
platform cable does not get a supply voltage at all if the xup firmware is
downloaded to the FX2 chip. 

/Andreas

zcsizmadia@gmail.com schrieb:

> Probably I miss something here.
>
> Why not just hook LPT or Jungo driver in windows, and see what is sent
> to the cable? Or it is downloading the firmware at the very beginning
> and it's a copyright issue to include the original firmware in your
> open-source application?
> The same way using a USB sniffer the communication can be reverse
> engineered (unless the data is not crypted)
>
> Do you have any  Par IV or Platform USB cable I could borrow to see if
> it could be reverse engineered?
>
> Zoltan
>
Zoltan,

snooping the USB cable does not make much sense as it is always
downloading the actual firmware, those any new release of ISE may have
different firmware and completly new USB protocol. It could of course
be possible to write an emulator for the USB chip and use the actual
firmware, by emulating it in fake driver, but that is all too
time consuming.

now as of Cable IV, well I havent done windows kernel debugging for
ages. I used todo it. But as of today I dont have debug tools that can
put breakpoints on io access in running winXP system. Sure it can be
done when windows is installed in qemu, etc, but its all
pretty much pain.

Or another way is to reverse engineer some xilinx DLL, what defenetly
violates the licensing, and is boring anyway.

So third option is to look at the jedec readback from Cable IV, sure
after conversion to VHDL.

Antti