what does a 'blank check' do exactly

<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. 

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