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?

On 2/10/2024 10:08 PM, bitrex wrote:
> 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)?

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

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)

On 2/11/2024 2:10 AM, Don Y wrote:
> On 2/10/2024 10:08 PM, bitrex wrote:
>> 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)?
>
>> 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.
>
> 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)

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.

On 2/11/2024 9:34 PM, bitrex wrote:
> 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?

On 2/12/2024 12:24 PM, Fred Bloggs wrote:
> On Sunday, February 11, 2024 at 12:08:16 AM UTC-5, bitrex wrote:
>> 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?
>
> 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.

On 2/12/2024 1:51 AM, Don Y wrote:

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

On 2/12/2024 5:37 PM, bitrex wrote:
> On 2/12/2024 1:51 AM, Don Y wrote:
>
>>> 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.

On 2/12/2024 12:24 PM, Fred Bloggs wrote:
> On Sunday, February 11, 2024 at 12:08:16 AM UTC-5, bitrex wrote:
>> 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?
>
> 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

On 2/12/2024 3:37 PM, bitrex wrote:
> On 2/12/2024 1:51 AM, Don Y wrote:
>
>>> 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..

On 2/12/2024 3:44 PM, bitrex wrote:
> On 2/12/2024 12:24 PM, Fred Bloggs wrote:
>> On Sunday, February 11, 2024 at 12:08:16 AM UTC-5, bitrex wrote:
>>> 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?
>>
>> 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")

On Monday, February 12, 2024 at 4:38:45 PM UTC-8, Don Y wrote:
> On 2/12/2024 3:37 PM, bitrex wrote:
> > On 2/12/2024 1:51 AM, Don Y wrote:
> >
> >>> 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.

On 2/14/2024 3:02 PM, whit3rd wrote:
> On Monday, February 12, 2024 at 4:38:45 PM UTC-8, Don Y wrote:
>> On 2/12/2024 3:37 PM, bitrex wrote:
>>> On 2/12/2024 1:51 AM, Don Y wrote:
>>>
>>>>> 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.

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

On 2024-02-12, bitrex <user@example.net> wrote:
> On 2/12/2024 1:51 AM, Don Y wrote:
>
>>> 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

--
Jasen.
🇺🇦 Слава Україні