What hardware and software for unit testing/SPLD device verification?

[bitrex]

Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.

I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.

Right now I'm just using the advanced development platform:

<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>

And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.

These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.

Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

[Don Y]

Not sure exactly what kind of widgets I need for this task, so any advice would
be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some kind of
unit testing framework, where I could write the validation suite on a PC using
some high level or scripting language, and have the interface automatically
apply test signals and probe the device response.

How "dirty" do you want to get your hands? How sure do you want to be
of the extent of your fault coverage?

What do the tools you are using to define the device internals give you
(by way of test vectors AND assurances as to how your design will actually
be compiled onto the hardware)?

<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and using the
Arduino implementation of the Aunit unit testing suite to write the tests,
manipulating pins and then the unit test software reads back output pin states,
this mostly works OK but it's not very elegant.

Likely cheaper than a piece of ATE!

These devices can have both analog and digital outputs but assume I need only
digital unit testing for now.

Are you just looking for functional testing? Or, do you also want to check
dynamic properties (propagation delays, setup/hold times, etc.)? Any
bidir signals whose turn-around time (etc) would be of concern?

Would some kind of logic analyzer be the right tool to accomplish this task?

A logic analyzer *watches* your circuit (and your stimulus can be monitored
if you probe accordingly). But, you still need something to twiddle the
inputs.

The device programmer has the ability to twiddle signals!

Some programmers can apply (and verify) test vectors supplied by the user.
Have a look at how ABEL and CUPL addressed this (aeons ago)

Obviously I need multiple channels but I don't need 50-100 like I'm debugging a
TTL mainframe or something. Open to older hardware but I don't really want to
use GP-IB so USB or at least Ethernet would be ideal for real-time
measurements. What software could then be used on the PC side to code the tests?

The bigger problem you will have is determining if your set of test vectors
"covers" all of the possible (likely) faults that the design can experience.

E.g., for a simple AND gate -- C = A*B -- if the 'A' input is stuck at 1
inside the chip, you can only tell this by driving the A *input* (outside
the chip) to 0 while driving B to 1... and EXPECTING 0 for the output
(if C == 1, then obviously A is not 0 inside the device).

With just an AND/OR array, you can likely create full coverage for each
term by hand (any state would have to have been "set up" by your earlier
vectors)

[bitrex]

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using
some kind of unit testing framework, where I could write the
validation suite on a PC using some high level or scripting language,
and have the interface automatically apply test signals and probe the
device response.

How "dirty" do you want to get your hands?  How sure do you want to be
of the extent of your fault coverage?
What do the tools you are using to define the device internals give you
(by way of test vectors AND assurances as to how your design will actually
be compiled onto the hardware)?

Post by bitrex
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software
reads back output pin states, this mostly works OK but it's not very
elegant.

Likely cheaper than a piece of ATE!

Post by bitrex
These devices can have both analog and digital outputs but assume I
need only digital unit testing for now.

Are you just looking for functional testing?  Or, do you also want to check
dynamic properties (propagation delays, setup/hold times, etc.)?  Any
bidir signals whose turn-around time (etc) would be of concern?

Post by bitrex
Would some kind of logic analyzer be the right tool to accomplish this task?

A logic analyzer *watches* your circuit (and your stimulus can be monitored
if you probe accordingly).  But, you still need something to twiddle the
inputs.
The device programmer has the ability to twiddle signals!
Some programmers can apply (and verify) test vectors supplied by the user.
Have a look at how ABEL and CUPL addressed this (aeons ago)

Thanks for your thorough reply! There are a lot of good points and I
have to think some of it over more, but for the moment I think I mainly
need the ability to verify state machine behavior, the designs aren't
mission-critical enough that I need to drill down to the (unlikely)
hung-gate level in the way you mentioned.

So apply input signals with some "hold time"- the GreenPAK state
machines are asynchronous but YKWIM - and verify appropriate transitions
and ending state.

As you mentioned the ADP/programmer has some integrated hardware for
routing and applying test signals (limited to 5kHz, but for some state
machine testing that's not entirely useless), and while the user
interface for the development board is very intuitive for setting up
simple signal routings and monitoring outputs with LEDs, etc. it's not
very conducive for running more elaborate unit tests. I'm not sure
there's any way to control the dev board strictly from software.

[Don Y]

think some of it over more, but for the moment I think I mainly need the
ability to verify state machine behavior, the designs aren't mission-critical
enough that I need to drill down to the (unlikely) hung-gate level in the way
you mentioned.

Fault coverage can simplify your testing strategy by "ruling out" cases that
for which you won't have to explicitly test. Otherwise, you may have to test
every combination of inputs (where the state variables represent additional
inputs; you can end up with thousands of test vectors "just to be sure" you
have exercised the design in every possible situation that it can encounter.

So apply input signals with some "hold time"- the GreenPAK state machines are
asynchronous but YKWIM - and verify appropriate transitions and ending state.

Ideally, you include a provision that lets you "load" the state (register).
So:
for each state
load state into machine (assumes you can load the state register)
verify state as loaded (assumes you can read back the state register)
for each stimuli
apply stimulus
clock machine
verify intended next state

Because the "intended next state" will likely/often not be the same state
that you were in the process of testing, you have to either: go back and
reload that state so you can test the other possible stimuli as applied
to that state; or, cycle the machine through other states (verifying their
responses to stimuli applied along the way) until you "happen" to return
to that state whereupon you can try an unexplored stimuli.

[I posted a routine that does exactly this, recently, but seem to have
already deleted my post...]

[[The problem with the "serendipitous" approach is that it relies on
your machine having a way back to every state -- eventually -- from
every other state, even if those routes may be circuitous (the beauty
of the algorithm I posted was that it learned the SHORTEST such paths
as it was exploring/exercising the machine). This is not always true
of all machines (though support for a RESET stimulus can make it so!).]]

As you mentioned the ADP/programmer has some integrated hardware for routing
and applying test signals (limited to 5kHz, but for some state machine testing
that's not entirely useless),

Yes, it's just a matter of how long the test will take to execute.
The other problem is often a limit on how MANY vectors it can handle
(each vector specifies an action and expected result; if the fixture
is explicitly designed to exercise clocked logic, then a vector can
*imply* the clock instead of having to explicitly define the "lower
CLOCK; wait N; apply stimulus; wait M; raise clock; wait P; observe
outputs; ..."

and while the user interface for the development
board is very intuitive for setting up simple signal routings and monitoring
outputs with LEDs, etc. it's not very conducive for running more elaborate unit
tests. I'm not sure there's any way to control the dev board strictly from
software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

[bitrex]

Post by Don Y

and while the user interface for the development board is very
intuitive for setting up simple signal routings and monitoring outputs
with LEDs, etc. it's not very conducive for running more elaborate
unit tests. I'm not sure there's any way to control the dev board
strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most
of the ones I use do) that you can use that to read or write to just
about anywhere in the device's configuration matrix and the states of
all relevant inputs and output registers are going to be in there somewhere.

So for testing asynchronous state machine logic it might work to just
use I2C for writing the input state registers and then reading back the
output registers that go to the pins, it's probably OK to assume the
pins work correctly on a working device :)

So an PC -> I2C interface of some type that integrate with e.g. Python
or C++ on PC platform might be OK for some of this. I feel like I might
have an FTDI dongle in my bins somewhere..

[bitrex]

Post by bitrex

Post by Don Y

and while the user interface for the development board is very
intuitive for setting up simple signal routings and monitoring
outputs with LEDs, etc. it's not very conducive for running more
elaborate unit tests. I'm not sure there's any way to control the dev
board strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most
of the ones I use do) that you can use that to read or write to just
about anywhere in the device's configuration matrix and the states of
all relevant inputs and output registers are going to be in there somewhere.
So for testing asynchronous state machine logic it might work to just
use I2C for writing the input state registers and then reading back the
output registers that go to the pins, it's probably OK to assume the
pins work correctly on a working device :)
So an PC -> I2C interface of some type that integrate with e.g. Python
or C++ on PC platform might be OK for some of this. I feel like I might
have an FTDI dongle in my bins somewhere..

Incidentally while these devices are OTP they have both an NVM layer and
a RAM layer, after it's powered up the NVM layer is loaded into RAM but
after that the RAM layer can be re-written via I2C to accomplish various
tasks like e.g. change comparator thresholds or set counters, etc...in
theory rewrite the whole device to have some other function but I
haven't explored that possibility fully.

[Fred Bloggs]

Post by bitrex

Post by bitrex

Post by Don Y

and while the user interface for the development board is very
intuitive for setting up simple signal routings and monitoring
outputs with LEDs, etc. it's not very conducive for running more
elaborate unit tests. I'm not sure there's any way to control the dev
board strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most
of the ones I use do) that you can use that to read or write to just
about anywhere in the device's configuration matrix and the states of
all relevant inputs and output registers are going to be in there somewhere.
So for testing asynchronous state machine logic it might work to just
use I2C for writing the input state registers and then reading back the
output registers that go to the pins, it's probably OK to assume the
pins work correctly on a working device :)
So an PC -> I2C interface of some type that integrate with e.g. Python
or C++ on PC platform might be OK for some of this. I feel like I might
have an FTDI dongle in my bins somewhere..

Incidentally while these devices are OTP they have both an NVM layer and
a RAM layer, after it's powered up the NVM layer is loaded into RAM but
after that the RAM layer can be re-written via I2C to accomplish various
tasks like e.g. change comparator thresholds or set counters, etc...in
theory rewrite the whole device to have some other function but I
haven't explored that possibility fully.

You can check with Renesas, but that feature can be locked out, and the same for reading your configuration data.

[Don Y]

Post by Don Y

and while the user interface for the development board is very intuitive for
setting up simple signal routings and monitoring outputs with LEDs, etc.
it's not very conducive for running more elaborate unit tests. I'm not sure
there's any way to control the dev board strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most of the
ones I use do) that you can use that to read or write to just about anywhere in
the device's configuration matrix and the states of all relevant inputs and
output registers are going to be in there somewhere.

Read CAREFULLY the description of this mechanism. E.g., is it monitoring
the actual pad drivers? Or, the "internal side" of them?

I.e., can you "see" a signal as claiming to be HI but the pin is actually
*not*? (because the pad driver has failed or the bondout wire is broken)

The advantage of testing "at the pins" is that this mirrors how your
circuit actually interacts with the device.

So for testing asynchronous state machine logic it might work to just use I2C
for writing the input state registers and then reading back the output
registers that go to the pins, it's probably OK to assume the pins work
correctly on a working device :)
So an PC -> I2C interface of some type that integrate with e.g. Python or C++
on PC platform might be OK for some of this. I feel like I might have an FTDI
dongle in my bins somewhere..

[whit3rd]

Post by Don Y

and while the user interface for the development board is very intuitive for
setting up simple signal routings and monitoring outputs with LEDs, etc.
it's not very conducive for running more elaborate unit tests. I'm not sure
there's any way to control the dev board strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most of the
ones I use do) that you can use that to read or write to just about anywhere...

while I was thinking that the basic self-test (a POST bit of code for startup)
and an extended self-test (power-on with the RESET button down) might suffice.

The load of testing is then part of the firmware with minimal bench top
hardware required (maybe none).

Read CAREFULLY the description of this mechanism. E.g., is it monitoring
the actual pad drivers? Or, the "internal side" of them?
I.e., can you "see" a signal as claiming to be HI but the pin is actually
*not*? (because the pad driver has failed or the bondout wire is broken)

There's some possibilities there, if you were to (for instance) put a few
summing junctions together into an ADC input. A test vector could
test many different logic states without much hardware at all
(basically, just a few resistor arrays) well enough to find stuck-high
or shorted-low.

[Don Y]

Post by whit3rd

Post by Don Y

and while the user interface for the development board is very intuitive for
setting up simple signal routings and monitoring outputs with LEDs, etc.
it's not very conducive for running more elaborate unit tests. I'm not sure
there's any way to control the dev board strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most of the
ones I use do) that you can use that to read or write to just about anywhere...

while I was thinking that the basic self-test (a POST bit of code for startup)
and an extended self-test (power-on with the RESET button down) might suffice.
The load of testing is then part of the firmware with minimal bench top
hardware required (maybe none).

I was assuming the effort was to validate the *design*.

Some of the older tools (PLDtest, PALASM, CUPL, ABEL, etc.) had the
ability to apply your test vectors to a *simulation* of the logic
(defined in the same file). This would suffice to check your
test vectors against the design -- but, wouldn't ensure 100%
fault coverage *or* that you haven't made the same mistake TWICE
(in the design and in the design of the test vectors!)

For POST, I would assume throwing a known set of stimuli at it and
hashing some set of outputs would suffice to check for gross
failures. In much the same way that memory tests typically only
detect *gross* failures.

E.g., a favorite gross memory test was to fill the region with
(pseudo-)random numbers. Then, reinitialize the RNG and use it
to *verify* the "random" contents. If the period of the RNG is
relatively prime wrt the size of the array (and all decoded
subsets of it), then one or more random values would stumble
upon faults without incurring a more exhaustive/methodical
test.

Post by whit3rd

Read CAREFULLY the description of this mechanism. E.g., is it monitoring
the actual pad drivers? Or, the "internal side" of them?
I.e., can you "see" a signal as claiming to be HI but the pin is actually
*not*? (because the pad driver has failed or the bondout wire is broken)

There's some possibilities there, if you were to (for instance) put a few
summing junctions together into an ADC input. A test vector could
test many different logic states without much hardware at all
(basically, just a few resistor arrays) well enough to find stuck-high
or shorted-low.

The problem with *any* ICT is that it usually means introducing other
hardware/logic to ensure the DUT isn't actively dicking with something
that you don't want dicked with (at this time).

[Jasen Betts]

Post by bitrex

Post by Don Y

and while the user interface for the development board is very
intuitive for setting up simple signal routings and monitoring outputs
with LEDs, etc. it's not very conducive for running more elaborate
unit tests. I'm not sure there's any way to control the dev board
strictly from software.

Can you run the "tester code" (that you write!) *in* the board and just
feed it vectors (or, have it *fetch* vectors) and spit out results?

I realized that for parts that have I2C (which isn't all parts, but most
of the ones I use do) that you can use that to read or write to just
about anywhere in the device's configuration matrix and the states of
all relevant inputs and output registers are going to be in there somewhere.
So for testing asynchronous state machine logic it might work to just
use I2C for writing the input state registers and then reading back the
output registers that go to the pins, it's probably OK to assume the
pins work correctly on a working device :)
So an PC -> I2C interface of some type that integrate with e.g. Python
or C++ on PC platform might be OK for some of this. I feel like I might
have an FTDI dongle in my bins somewhere..

It really sounds like you are describing JTAG boundary scan

[Fred Bloggs]

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.
These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.
Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

Renesas has already done the bit and analog testing of the device at the wafer level before it was even diced up. Any part in hand should work within specification with a confidence level of 5-6 9's or whatever they use these days. So all this stuff about random test vector generation is malarkey. The emulation function along with design rule checking should be totally adequate. The 'testing' function, whatever it is, is a sanity check before putting it onto a board. Enjoy the pretty multi-color displays...

[bitrex]

Post by Fred Bloggs

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.
These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.
Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

Renesas has already done the bit and analog testing of the device at the wafer level before it was even diced up. Any part in hand should work within specification with a confidence level of 5-6 9's or whatever they use these days. So all this stuff about random test vector generation is malarkey. The emulation function along with design rule checking should be totally adequate. The 'testing' function, whatever it is, is a sanity check before putting it onto a board. Enjoy the pretty multi-color displays...

Yeah, setting up simple checkouts using the ADP/emulator and the onboard
stimulus generators is straightforward enough.

More thorough tests on are a PITA, the environment is a GUI like LTSPice
but AFAIK there's no provision to use any kind of list of directives or
scripting language to create and sequence a variety of tests.

[Fred Bloggs]

Post by bitrex

Post by Fred Bloggs

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.
These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.
Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

Renesas has already done the bit and analog testing of the device at the wafer level before it was even diced up. Any part in hand should work within specification with a confidence level of 5-6 9's or whatever they use these days. So all this stuff about random test vector generation is malarkey. The emulation function along with design rule checking should be totally adequate. The 'testing' function, whatever it is, is a sanity check before putting it onto a board. Enjoy the pretty multi-color displays...

Yeah, setting up simple checkouts using the ADP/emulator and the onboard
stimulus generators is straightforward enough.
More thorough tests on are a PITA, the environment is a GUI like LTSPice
but AFAIK there's no provision to use any kind of list of directives or
scripting language to create and sequence a variety of tests.

That kind of gate level testing is a myth for the modern products. To thoroughly test everything at the gate level, the wafer testing has access to many more test nodes, probably uses a lot of serial shifting, and plies the product with an input sequence generated by 1) very expensive test software with a humongous test vector set, and 2) using quite a lot of information about the undocumented internal details that are not accessible to the end user. The product would be unusable if it required that kind of testing by the end user. All you have to do is get it past DRC, and then run whatever through the emulator, which most times is idealized, and then the testing, whatever that is.

[bitrex]

Post by Fred Bloggs

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.
These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.
Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

Renesas has already done the bit and analog testing of the device at the wafer level before it was even diced up. Any part in hand should work within specification with a confidence level of 5-6 9's or whatever they use these days. So all this stuff about random test vector generation is malarkey. The emulation function along with design rule checking should be totally adequate. The 'testing' function, whatever it is, is a sanity check before putting it onto a board. Enjoy the pretty multi-color displays...

Incidentally Dialog used to offer programmed devices in quantities of
hundreds turn-key, I read that now that it's a Renesas product line
there are 5k minimums with lead times of 14 weeks for factory-programmed
devices...thanks guys

[Don Y]

Post by Fred Bloggs

Post by bitrex
Not sure exactly what kind of widgets I need for this task, so any
advice would be appreciated.
I'd like to be able to run unit tests on GreenPAK-type SPLDs using some
kind of unit testing framework, where I could write the validation suite
on a PC using some high level or scripting language, and have the
interface automatically apply test signals and probe the device response.
<https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products/analogpak/slg4dvkadv-greenpak-advanced-development-board>
And connecting this to an AVR/Arduino uP using a breakout cable and
using the Arduino implementation of the Aunit unit testing suite to
write the tests, manipulating pins and then the unit test software reads
back output pin states, this mostly works OK but it's not very elegant.
These devices can have both analog and digital outputs but assume I need
only digital unit testing for now.
Would some kind of logic analyzer be the right tool to accomplish this
task? Obviously I need multiple channels but I don't need 50-100 like
I'm debugging a TTL mainframe or something. Open to older hardware but I
don't really want to use GP-IB so USB or at least Ethernet would be
ideal for real-time measurements. What software could then be used on
the PC side to code the tests?

Renesas has already done the bit and analog testing of the device at the
wafer level before it was even diced up. Any part in hand should work within
specification with a confidence level of 5-6 9's or whatever they use these
days. So all this stuff about random test vector generation is malarkey. The
emulation function along with design rule checking should be totally
adequate. The 'testing' function, whatever it is, is a sanity check before
putting it onto a board. Enjoy the pretty multi-color displays...

Incidentally Dialog used to offer programmed devices in quantities of hundreds
turn-key, I read that now that it's a Renesas product line there are 5k
minimums with lead times of 14 weeks for factory-programmed devices...thanks guys

There's a fair bit of overhead ("setup") to this process to make it
economically viable for small buys. (I.e., YOU could offer such a
service to folks!)

Nowadays, it's really not exceptional for suppliers to think there is
no significant need for that sort of service as "hobbyists" can
likely roll-their-own (their time being "free")