mtsukanov@gmail.com wrote:
> 
> it does surely sound like a powerup issue. BUT - if I knew what
> happens to the i/o of the CPLD on a 'blank check' I could put it into
> code so the CPLD can perform the same function once it is up and
> running.

That depends on the exact nature of the powerup issue - some aspects of
power cycling,  you cannot 'put into code'.
'blank check' (or verify, or any JTAG read ), will cycle the JTAG state
engine, and exit in a known way, and do so with full Vcc on the devices.

So you may have a sequecing problem.

Don't Xilinx have app notes for using their CPLDs to load FPGAs ?
Try their code ?

-jg

On Mar 1, 2:49 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> <mtsuka...@gmail.com> wrote in message
>
> news:1172776617.906745.77140@31g2000cwt.googlegroups.com...
>
>
>
> > it does surely sound like a powerup issue. BUT - if I knew what
> > happens to the i/o of the CPLD on a 'blank check' I could put it into
> > code so the CPLD can perform the same function once it is up and
> > running.
>
> This approach - mimic the blank check - may set you up for failure.  While
> it appears that you operate properly every time you perform the blank check,
> you're not looking at all the possible silicon and operating conditions,
> just what you have in front of you.
>
> Read up on how to power-up or reset the prom properly.
> Read up on how the CPLD I/Os behave on power up.
> Read up on how to properly program the FPGA.
>
> Implement a system which - by design, not by experiment - is guaranteed to
> work.
>
> If you insist on engineering by enecdote, please at least take a scope probe
> to the CPLD pins and watch what the specific signals do during that blank
> check operation.


I completely agree with you. Unfortunately, I didn't design this
'custom' board, so I have to work with what I got, which means almost
all BGA parts: can't probe any line I please - no access to the pin/
trace. But yes it looks like I need to do more 'investigative' work
for sure.

<mtsukanov@gmail.com> wrote in message 
news:1172776617.906745.77140@31g2000cwt.googlegroups.com...
>
> it does surely sound like a powerup issue. BUT - if I knew what
> happens to the i/o of the CPLD on a 'blank check' I could put it into
> code so the CPLD can perform the same function once it is up and
> running.

This approach - mimic the blank check - may set you up for failure.  While 
it appears that you operate properly every time you perform the blank check, 
you're not looking at all the possible silicon and operating conditions, 
just what you have in front of you.

Read up on how to power-up or reset the prom properly.
Read up on how the CPLD I/Os behave on power up.
Read up on how to properly program the FPGA.

Implement a system which - by design, not by experiment - is guaranteed to 
work.

If you insist on engineering by enecdote, please at least take a scope probe 
to the CPLD pins and watch what the specific signals do during that blank 
check operation. 

On Mar 1, 12:45 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> <mtsuka...@gmail.com> wrote in message
>
> news:1172763684.644449.311760@n33g2000cwc.googlegroups.com...
>
>
>
>
>
> > Hmm... I'm not completely sure I understand what u said, but let me
> > clarify a little more on what's happening:
>
> > The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> > CPLD is doing is connecting the signals going from the PROM to the
> > FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> > CPLD, it works right away, and the FPGA gets programmed from the PROM.
> > If I turn off the POWER to the whole system, turn it back on - nothing
> > happens. The FPGA does'nt get programmed from the PROM. *IF at that
> > point I right click on the CPLD in Impact, and select 'blank check',
> > the CPLD starts 'working' and the FPGA gets programmed. The V4 is
> > working in 'master' mode, and I checked the CCLK and it runs just fine
> > after board powerup, thought the d_in has garbage on it. The d_in
> > turns good when i do the 'blank check' on the CPLD or when I reprogram
> > the CPLD. That's why I'm wondering if the 'blank check' drives the
> > CPLD's pins to 0 or 1 during the 'blank check' operation, something
> > funky like that
>
> > thanks again, any help is much appreciated
>
> You have just described a system and symptom completely unrelated to the
> typical questions devined by the "what happens when I do this" question.
>
> You have a CPLD that doesn't just connect two parts.  You have a CPLD that
> powers up between two parts that power up.
>
> Chances are the prom and FPGA are not both happy.  The blank check for the
> CPLD might do something that functionally changes the I/O.  Typically a
> blank check isn't used to ponder whether an operating device is blank so a
> "destructive" check is reasonable where outputs can tristate or change state
> while the device is interrogated.
>
> Use a logic analyzer or similar device to look at the power-up behavior of
> the PROM control signals as well as the FPGA program control pins.  You
> probably have a misbehavior in the initialization because the CPLD isn't on
> at the right time - or correct power-on polarity - for the attached devices.
>
> Your cure may be as simple as added pull-up/pull-down resistors or a little
> intelligence to make sure both devices around the CPLD are in reset.
>
> The problem isn't around the "blank check" as implied by your initial
> superficial question (no depth) but in the CPLD's behavior in your FPGA
> initialization.


it does surely sound like a powerup issue. BUT - if I knew what
happens to the i/o of the CPLD on a 'blank check' I could put it into
code so the CPLD can perform the same function once it is up and
running.

<mtsukanov@gmail.com> wrote in message 
news:1172763684.644449.311760@n33g2000cwc.googlegroups.com...
>
> Hmm... I'm not completely sure I understand what u said, but let me
> clarify a little more on what's happening:
>
> The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> CPLD is doing is connecting the signals going from the PROM to the
> FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> CPLD, it works right away, and the FPGA gets programmed from the PROM.
> If I turn off the POWER to the whole system, turn it back on - nothing
> happens. The FPGA does'nt get programmed from the PROM. *IF at that
> point I right click on the CPLD in Impact, and select 'blank check',
> the CPLD starts 'working' and the FPGA gets programmed. The V4 is
> working in 'master' mode, and I checked the CCLK and it runs just fine
> after board powerup, thought the d_in has garbage on it. The d_in
> turns good when i do the 'blank check' on the CPLD or when I reprogram
> the CPLD. That's why I'm wondering if the 'blank check' drives the
> CPLD's pins to 0 or 1 during the 'blank check' operation, something
> funky like that
>
> thanks again, any help is much appreciated


You have just described a system and symptom completely unrelated to the 
typical questions devined by the "what happens when I do this" question.

You have a CPLD that doesn't just connect two parts.  You have a CPLD that 
powers up between two parts that power up.

Chances are the prom and FPGA are not both happy.  The blank check for the 
CPLD might do something that functionally changes the I/O.  Typically a 
blank check isn't used to ponder whether an operating device is blank so a 
"destructive" check is reasonable where outputs can tristate or change state 
while the device is interrogated.

Use a logic analyzer or similar device to look at the power-up behavior of 
the PROM control signals as well as the FPGA program control pins.  You 
probably have a misbehavior in the initialization because the CPLD isn't on 
at the right time - or correct power-on polarity - for the attached devices.

Your cure may be as simple as added pull-up/pull-down resistors or a little 
intelligence to make sure both devices around the CPLD are in reset.

The problem isn't around the "blank check" as implied by your initial 
superficial question (no depth) but in the CPLD's behavior in your FPGA 
initialization. 

mtsukanov@gmail.com wrote:

> Yea I actually tried doing 'id code' read, it didn't do anything,
> didn't produce the same results as doing a 'blank check' or
> reprogramming.

check that you have the correct pullups/pulldowns on the JTAG pins.

On Mar 1, 10:56 am, cs_post...@hotmail.com wrote:
> On Mar 1, 10:41 am, mtsuka...@gmail.com wrote:
>
> > The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> > CPLD is doing is connecting the signals going from the PROM to the
> > FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> > CPLD, it works right away, and the FPGA gets programmed from the PROM.
> > If I turn off the POWER to the whole system, turn it back on - nothing
> > happens. The FPGA does'nt get programmed from the PROM. *IF at that
> > point I right click on the CPLD in Impact, and select 'blank check',
> > the CPLD starts 'working' and the FPGA gets programmed.
>
> Try some other non-destructive operations - the most trivial would be
> read idcode
>
> It may be that the CPLD's jtag stage machine is waking up in a state
> that keeps the CPLD from running; executing one of these operations
> probably finished by putting it back into operational state.
>
> As a guess, when it's in programming state, the ordinary I/O's would
> all be high-Z.  Depending on pullup resistors, it's possible that
> exiting from programming state to operating state could be producing a
> clock edge necessary to start the process of loading your FPGA...


Yea I actually tried doing 'id code' read, it didn't do anything,
didn't produce the same results as doing a 'blank check' or
reprogramming.

On Mar 1, 10:41 am, mtsuka...@gmail.com wrote:

> The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
> CPLD is doing is connecting the signals going from the PROM to the
> FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
> CPLD, it works right away, and the FPGA gets programmed from the PROM.
> If I turn off the POWER to the whole system, turn it back on - nothing
> happens. The FPGA does'nt get programmed from the PROM. *IF at that
> point I right click on the CPLD in Impact, and select 'blank check',
> the CPLD starts 'working' and the FPGA gets programmed.

Try some other non-destructive operations - the most trivial would be
read idcode

It may be that the CPLD's jtag stage machine is waking up in a state
that keeps the CPLD from running; executing one of these operations
probably finished by putting it back into operational state.

As a guess, when it's in programming state, the ordinary I/O's would
all be high-Z.  Depending on pullup resistors, it's possible that
exiting from programming state to operating state could be producing a
clock edge necessary to start the process of loading your FPGA...

On Mar 1, 9:27 am, John_H <newsgr...@johnhandwork.com> wrote:
> mtsuka...@gmail.com wrote:
> > On Feb 28, 9:14 pm, Tim <t...@nooospam.roockyloogic.com> wrote:
> >> mtsuka...@gmail.com wrote:
> >>> on lets say... a Xilinx CoolRunner 2 CPLD? I had trouble finding
> >>> information on this. Using Impact.
> >> It reads back the program from the device and checks that the device is
> >> blank. That used to mean checking that all the bits were set to '1'. No
> >> doubt devices are more complicated now.
>
> > I guess what I'm particularly asking is, on a 'blank check' do the
> > signals and/or pins in the CPLD get set to 0 or 1? or what?
>
> > I'm trying to find out because the particular design i'm working on,
> > 'works' if I do a 'blank check' on the CPLD.
>
> You should have the option to "erase part."  If you do that, then
> program the device without the "blank check" your design will still work.
>
> If the check box is the difference between working and not working, then
> the software apparently notices the previously programmed device *isn't*
> blank and performs the erasure, setting all bits to the same polarity
> through the bulk erase process, allowing the programmed bits - and only
> the programmed bits - to be the opposite polarity.
>
> If you're programming a bunch of new parts, it's convenient to skip the
> check for a blank device to save time.  If parts were never in the
> erased state, the device would always be erased first and there would be
> no need for that check box.


Hmm... I'm not completely sure I understand what u said, but let me
clarify a little more on what's happening:

The CPLD is connected to a xcf32 PROM and to a Xilinx V4 FPGA. All the
CPLD is doing is connecting the signals going from the PROM to the
FPGA - primarily the 'done' and 'd_in' pins. So, when I program the
CPLD, it works right away, and the FPGA gets programmed from the PROM.
If I turn off the POWER to the whole system, turn it back on - nothing
happens. The FPGA does'nt get programmed from the PROM. *IF at that
point I right click on the CPLD in Impact, and select 'blank check',
the CPLD starts 'working' and the FPGA gets programmed. The V4 is
working in 'master' mode, and I checked the CCLK and it runs just fine
after board powerup, thought the d_in has garbage on it. The d_in
turns good when i do the 'blank check' on the CPLD or when I reprogram
the CPLD. That's why I'm wondering if the 'blank check' drives the
CPLD's pins to 0 or 1 during the 'blank check' operation, something
funky like that

thanks again, any help is much appreciated

mtsukanov@gmail.com wrote:
> On Feb 28, 9:14 pm, Tim <t...@nooospam.roockyloogic.com> wrote:
>> mtsuka...@gmail.com wrote:
>>> on lets say... a Xilinx CoolRunner 2 CPLD? I had trouble finding
>>> information on this. Using Impact.
>> It reads back the program from the device and checks that the device is
>> blank. That used to mean checking that all the bits were set to '1'. No
>> doubt devices are more complicated now.
> 
> 
> I guess what I'm particularly asking is, on a 'blank check' do the
> signals and/or pins in the CPLD get set to 0 or 1? or what?
> 
> I'm trying to find out because the particular design i'm working on,
> 'works' if I do a 'blank check' on the CPLD.

You should have the option to "erase part."  If you do that, then 
program the device without the "blank check" your design will still work.

If the check box is the difference between working and not working, then 
the software apparently notices the previously programmed device *isn't* 
blank and performs the erasure, setting all bits to the same polarity 
through the bulk erase process, allowing the programmed bits - and only 
the programmed bits - to be the opposite polarity.

If you're programming a bunch of new parts, it's convenient to skip the 
check for a blank device to save time.  If parts were never in the 
erased state, the device would always be erased first and there would be 
no need for that check box.