ISE WebPack 6.1 Impact problem

Hi all:

I was using a Digilent 2DE + DIO1 (Spartan2E) with the Free ISE WebPack 5.2, with no problems.

I have just downloaded the new WebPack 6.1 and everything runs well until iMPACT tries to automatically configure the BoundaryScan chain. The Digilent D2E is programmed thru a parallel cable connected to LPT1: and worked OK under WebPack 5.2

Comparing 5.2 with 6.1, we have found that 5.2 said

--------------------------------------------------- Connecting to cable (Parallel Port - LPT1). Checking cable driver. Driver windrvr.sys version = 5.0.5.1. LPT base address = 0378h. ...

---------------------------------------------------

but 6.1 says

--------------------------------------------------- LPT base address = 0B78h.

---------------------------------------------------

and finally says "communications with the cable could not be stablished. Check cable and power"

Has anybody found the same problem and any workaround?

Thanks in advance

-javier

Reply to
Javier Fernández Baldomero
Loading thread data ...

Javier,

Do you use NT? Xilinx dropped NT support with ISE version 5.1i, but it still ran. With 6.1i Impact won't even start up. Neither will the Core Generator. YMMV.

Marc

Javier Fernández Baldomero wrote:

Reply to
Marc Guardiani

Marc Guardiani escribió:

Sorry I forgot to mention: we use Windows XP

Thanks for the info. Our iMPACT does start, and from the log messages, it seems it confuses LPT1=0378 with LPT1=0B78. I have tried to look for "edit options" to change that, but can't find anything either in the menus or in the PDF handbook. In any case... why does 6.1 uses 0B78 instead of the previous 0378?

Confused... :-)

-javier

Reply to
Javier Fernández Baldomero

Could be a typing error, I already found one. In ECS 6.1i (the schematic editor), if you put the USELOWSKEWLINES=TRUE attribute on a signal, the resulting .vhf file contains a spelling error that keeps the design from synthesizing (SIGNAL is spelled "SIGANL").

As far as Impact goes, I can't even get it to run.

Javier Fernández Baldomero wrote:

Reply to
Marc Guardiani

Interesting. I wonder how that one got past testing. I'll bet it gets tested now/tomorrow.

Many years ago, a friend described a neat trick for testing software. The idea was to make sure the each line of code was at least exerecised in order to find the gross bugs. He started with a clean listing. Install breakpoints. When you get there, mark that line and the rest of the block, that is until the next branch, skip, return or such. Eventually, you have marked off all the easy stuff and now you have to generate test cases to tickle the hard/obscure ones.

This is just the software version of making sure your test bench wiggles all the signals at least once.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

If software testing would be that easy. Actually there are tools (code coverage tools) that are there for this very purpose: measure the percentage of blocks (lines) that were executed during a test.

However it's not that easy at all to reach 100% coverage. You might need fault injection and other techniques, and even with that some SW constructs cannot be covered 100% (think about testing a SW for *all possible* out-of-memory conditions or for *all possible* floating-point exceptions).

And in many cases the problem is not the branches that are there (and thus can be tested by code-coverage) but the ones that are missing: unchecked special conditions, return values, etc.

Anyway, I'm sure you all know all this...

This bug should have been found though.

Regards, Andras Tantos

Reply to
Andras Tantos

Hi all, again,

Neil from Xilinx assisted us offline to better diagnose this problem, and in the process of answering his questions it came out that another, identical PC in our department was able to run the software perfectly. Identical since they were bought at once, same store, same model, same date. Basically identical SiSoft SANDRA listings.

So, whatever the problem is, it's a problem with that particular PC, be it hardware, BIOS, XP configuration... In short: we have found a PC with such a subtle configuration or hardware failure that it fools iMPACT 6.1 making it believe that LPT1: is at 0B78 (I love reproducible errors :-)

We'll try to interchange that computer with somebody else's and upgrade to 6.1 then.

Thanks to all again

-javier

Reply to
Javier Fernández Baldomero

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.