ISE WebPack 6.1 Impact problem

  • Thread starter Javier Fernández Baldomer
  • Start date
J

Javier Fernández Baldomer

Guest
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
 
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:

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
Click to expand...
 
Marc Guardiani escribió:
Javier,

Do you use NT? Xilinx dropped NT support with ISE version 5.1i, but it
Click to expand...
Sorry I forgot to mention: we use Windows XP


still ran. With 6.1i Impact won't even start up. Neither will the Core
Generator. YMMV.

Marc
Click to expand...
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
 
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:
Marc Guardiani escribió:

Javier,

Do you use NT? Xilinx dropped NT support with ISE version 5.1i, but it


Sorry I forgot to mention: we use Windows XP



still ran. With 6.1i Impact won't even start up. Neither will the Core
Generator. YMMV.

Marc



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
Click to expand...
 
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").
Click to expand...
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.
 
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").

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.
Click to expand...
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
 
Comparing 5.2 with 6.1, we have found that 5.2 said
---------------------------------------------------
LPT base address = 0378h.
---------------------------------------------------

but 6.1 says
---------------------------------------------------
LPT base address = 0B78h.
---------------------------------------------------
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top