what does a 'blank check' do exactly

on lets say... a Xilinx CoolRunner 2 CPLD? I had trouble finding information on this. Using Impact.

thanks!

Reply to
mtsukanov
Loading thread data ...

A blank check gives me carte blanche?

Most programmable, non-volatile memories are one-way programmable; that is - when erased - all bits are one polarity and programming involved programming only the bits that are the opposite polarity.

This means that some meory can simply be "added to" but almost all of the time a new program involves changing some of the programmed polarities back to erased polarities. Erasure can only occure on a block or device level for most of these devices.

The blank check tells you the reprogram *can* be successful because there are no unerased bits left that will need the erased status. It's easier to check for the entire erasure than for just the bad bit polarities.

- John_H

Reply to
John_H

'blank check' means it checks the device is erased, ready to be programmed.

Normally used in a re-cycle situation, when you want to program new code into the CPLD, you go along this chain of operations :

Erase/BlankCheck/Program/Verifty/Secure/VectorTest

Commonly devices are shipped blank, so the first 2 are optional on a new device, but required on a already programmed device.

-jg

Reply to
Jim Granville

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.

Reply to
Tim

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.

Reply to
mtsukanov

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.

Reply to
John_H

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

Reply to
mtsukanov

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

Reply to
cs_posting

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.

Reply to
mtsukanov

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

Reply to
Tim

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.

Reply to
John_H

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.

Reply to
mtsukanov

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.

Reply to
John_H

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.

Reply to
mtsukanov

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

Reply to
Jim Granville

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.