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)
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.
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 Sunday, February 11, 2024 at 12:08:16 AM UTC-5, bitrex wrote: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
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
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 Sunday, February 11, 2024 at 12:08:16 AM UTC-5, bitrex wrote: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
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
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 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 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/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..
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 91:53:12 |
Calls: | 8,690 |
Calls today: | 5 |
Files: | 13,250 |
Messages: | 5,946,882 |