Problem with iMpact

[ghelbig]

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG. (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project. One was created last month,
one was created last week. The steps above are repeated EXACTLY for
the two bit files. There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other. With one bit
file, and chip never leaves the DONE state. Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before? I haven't gotten any help from the
factory yet.

Regards,
G.

 

[Gabor]

On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name. In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact. However usually these show up as an error when you go to
verify the .mcs file in SPI flash. When you say "never leaves the
DONE state" do you mean that DONE never goes high? Or does
DONE go high, but the chip never comes out of reset. The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode. Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

 

[ghelbig]

On Jan 24, 12:23 pm, Gabor <ga...@alacron.com> wrote:

On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:





I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case. It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped. The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

 

[Gabor]

On Jan 24, 5:21 pm, ghelbig <ghel...@lycos.com> wrote:

On Jan 24, 12:23 pm, Gabor <ga...@alacron.com> wrote:



On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case.  It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped.  The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

Is there anything in the Verilog code that changes that might affect
the reset? Does your reset depend on PLL or DCM lock? That
can often be affected by seemingly unrelated changes especially
if there is a noisy clock input or insufficient power supply bypass.

-- Gabor

 

[ghelbig]

On Jan 25, 6:13 am, Gabor <ga...@alacron.com> wrote:

On Jan 24, 5:21 pm, ghelbig <ghel...@lycos.com> wrote:





On Jan 24, 12:23 pm, Gabor <ga...@alacron.com> wrote:

On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case.  It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped.  The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

Is there anything in the Verilog code that changes that might affect
the reset?  Does your reset depend on PLL or DCM lock?  That
can often be affected by seemingly unrelated changes especially
if there is a noisy clock input or insufficient power supply bypass.

-- Gabor- Hide quoted text -

- Show quoted text -

I changed the ISERDES from asynch to synch reset. I added and removed
ILA's. Everything else was just bug fixes.

The bit-file works if JTAG-ed into the FPGA. I can Write/Verify/Read
the SPI flash all day long. The bit-file does not work when loading
from SPI.

Thanks for helping! Seriously, there are not bad ideas right now.

G.

 

[ghelbig]

On Jan 25, 12:50 pm, ghelbig <ghel...@lycos.com> wrote:

On Jan 25, 6:13 am, Gabor <ga...@alacron.com> wrote:





On Jan 24, 5:21 pm, ghelbig <ghel...@lycos.com> wrote:

On Jan 24, 12:23 pm, Gabor <ga...@alacron.com> wrote:

On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case.  It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped.  The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

Is there anything in the Verilog code that changes that might affect
the reset?  Does your reset depend on PLL or DCM lock?  That
can often be affected by seemingly unrelated changes especially
if there is a noisy clock input or insufficient power supply bypass.

-- Gabor- Hide quoted text -

- Show quoted text -

I changed the ISERDES from asynch to synch reset.  I added and removed
ILA's.  Everything else was just bug fixes.

The bit-file works if JTAG-ed into the FPGA.  I can Write/Verify/Read
the SPI flash all day long.  The bit-file does not work when loading
from SPI.

Thanks for helping!  Seriously, there are not bad ideas right now.

G.

Follow up:

I get an '_impact4' error message when loading the bit file with
iMPACT version 11.5

Searching the web, the only work-around I have found is: "This issue
is scheduled to be resolved in iMPACT 11.4."

And there is an implication that this only happens with Virtex-6 and
Spartan-6. I'm using a Virtex-5.

Does anyone have a suggestion? My hereditary alopecia is getting some
serious competition.

g.

 

[Gabor]

On Jan 26, 1:20 pm, ghelbig <ghel...@lycos.com> wrote:

On Jan 25, 12:50 pm, ghelbig <ghel...@lycos.com> wrote:



On Jan 25, 6:13 am, Gabor <ga...@alacron.com> wrote:

On Jan 24, 5:21 pm, ghelbig <ghel...@lycos.com> wrote:

On Jan 24, 12:23 pm, Gabor <ga...@alacron.com> wrote:

On Jan 24, 1:50 pm, ghelbig <ghel...@lycos.com> wrote:

I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case.  It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped.  The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

Is there anything in the Verilog code that changes that might affect
the reset?  Does your reset depend on PLL or DCM lock?  That
can often be affected by seemingly unrelated changes especially
if there is a noisy clock input or insufficient power supply bypass.

-- Gabor- Hide quoted text -

- Show quoted text -

I changed the ISERDES from asynch to synch reset.  I added and removed
ILA's.  Everything else was just bug fixes.

The bit-file works if JTAG-ed into the FPGA.  I can Write/Verify/Read
the SPI flash all day long.  The bit-file does not work when loading
from SPI.

Thanks for helping!  Seriously, there are not bad ideas right now.

G.

Follow up:

I get an '_impact4' error message when loading the bit file with
iMPACT version 11.5

Searching the web, the only work-around I have found is: "This issue
is scheduled to be resolved in iMPACT 11.4."

And there is an implication that this only happens with Virtex-6 and
Spartan-6.  I'm using a Virtex-5.

Does anyone have a suggestion?  My hereditary alopecia is getting some
serious competition.

g.

You could always update to the latest Impact. We're mostly using
Impact 21.1 here, and found that it has some better features, at least
for SPI indirect mode programming. Still not bug free, though.

Still I would suggest going through your bitgen options one more time.
Check in particular the startup settings for the correct clock and
also
see if release of "global WE" is possibly set very late or depends on
DCM lock. If you don't have more than one device in the chain, there
is no reason you can't have DONE go high after the other startup
events. Then if DONE goes high but the chip isn't running, there
are non-configuration start-up issues.

-- Gabor