@DavidBoyd wrote:
I'll preface the below comments by saying first, that I have no experience whatsoever with LabVIEW targetted to FPGA.
But I have a feeling that this is close to a hopeless cause, if the goal is to actually perform some sort of memory integrity test. There are a number of things which stand in your way:
- compilers are very smart, they will optimize away almost any attempts you make at writing and reading back variables in memory, expecting something different
- you really may not know where your variables are in the target anyway, so it's a anybody's guess what's getting "exercised"
- without knowing the details of how physical memory is laid out in a device, the notion that you're walking a "one" across a bunch of parallel address lines otherwise at "zero", looking for "stuck-ats", is quaint
Writing useful memory/logic tests is generally something I think of as done either at the assembly language level, or at least in C with a VERY clear understanding of compiler optimization control. And it must go hand in hand with knowing how memory chips are addressed, how the upper address lines are demuxed, etc.
Best regards,
Dave
Dave, your concerns are valid and in some ways very true. Saying I could even write the first sentence on a paper with regards to compilers would be far too generous. So, there is the distinct possiblity that what I say in this post doesn't hold water.
Your points are definitely noted. To point 1, I am not sure what abilities the compiler has to optmize something like this between the FPGA side and the RT side of things. Because the data is "simulated" on the FPGA, then stuck in a FIFO to the RT, I am not sure whether the compiler of the FPGA can look at the two and notice it could optimize.
I believe you may be right in the fact that you can't know where your variables are in terms of memory locations on the board, therefore you can't determine what memory has gone bad, if it will be bad every time, etc. Truthfully, I am not sure if the FPGA, after compiled, will always use the same memory each time the bitfile is loaded. Maybe someone with more in depth knowledge of the lower workings can comment on this.
This test, however, serves two purposes. One is, as you described, checking the memory which may be a mute point. The other is to simulate a line change event happening every ms, and to ensure we capture and log each one. This is a requirement. By having this test, we can simulate DI lines changing, and test our software processing without having any external DI lines actually wired up to the FPGA.
Thanks for your points, they are all well taken and will be discussed with my coworkers/customer. I would definitely be interested if you or anyone else has additional thoughts on this.
