Survey ResultsThanks to everyone for filling out the survey. 43 valid responses were received over the course of a month which is not so bad for a small engineering forum, and enough to sample some reasonable data with a fair bit of confidence. For those interested, the results are publicly published here, besides the comments field for user privacy:
https://docs.google.com/spreadsheets/d/1yqCfIa8lzXFmDxayfT2XsBuWI-NDyL6ssCdF4YwLubI/edit?usp=sharingSome surprising conclusions from the survey. It seems that users on here are roughly evenly divided between software engineering and hardware engineering, and about 20% report other fields. I had actually expected to see more FPGA/RTL engineers (none reported that as their profession) but perhaps this is a limitation of the single selection, as at least in the case of my career and present employment I am both a hardware engineer and a FPGA systems engineer.
It seems the majority of users on here are experienced in their field with more than 12 years' of professional experience. I had originally intended the distribution of options to be somewhat logarithmic but perhaps I should have included a 20+ years option to further divide this category. Nonetheless I think it is fair to say that the majority of people interested in this project are professional and experienced engineers. That means the product must be professional too, of course! Over 85% of individuals said that they would consider the purchase of a FOSHW instrument, which is good news.
On pricing, the data was a pleasant surprise as I was worried about the need to cost-optimise even further. Some were willing to pay over $1000 USD for such an instrument. Weighting the prices by assuming that any option is taken as half-way in the range (with the upper and lower bound options set at their respective minimums and maximums) this gives a price target of USD $713 for the instrument. That should be achievable, depending upon the final specification and what modules, if any, need to be included in that configuration (I expect the price to include a 4 channel AFE.)
It seems most people would be accepting of a touchscreen based user interface, though there were some who said that it would not be acceptable. I would be in favour of a limited degree of physical controls, but a complex control assembly would be expensive to tool up and could increase the bill of materials considerably; it also limits the flexibility (e.g. channel knobs that don't make sense when you have an LA module installed, for instance.) Some consideration of overall device form factor needs to be made here.
The "please rank the importance" data were also very useful and helps steer this project somewhat:-
Modularity ranked highly (average score 4.0/5), with the majority split between 4 and 5 points suggesting this to be essential to most users. I intend for the instrument to be modular but it was good to have confirmation of this.
Portability was mostly unimportant to those surveyed (average score 2.1/5), with the majority suggesting 'not at all' useful.
Configurable digital filters scored a rather midfield 3.3/5, with most people selecting option 3, 'somewhat important'. There however were a substantial number both regarding this as essential, and another group similarly as not essential. More research and discussion is needed on this point I suspect, to determine the performance level that is required by those who desire such a function.
There was more majority support for an
MSO function, but the average score was similar to digital filters at 3.6/5. However, it seems this score is weighted more by those that regard it to be essential. One user commentated that state analysis would be essential for such a function, and I agree. This means the memory capture and trigger path needs to support modes synchronous to analog channels and asynchronous too. That is a lot more difficult than supporting only one route, but it should be at least practical to support state-only analysis (with analog channels off), it gets a bit more difficult to try to synchronise this with the analog data.
Wi-Fi connectivity was not seen as that important, with an average score of 2.0/5. That is fine - it can be supplied by an external USB stick if required. It does not appear there is sufficient interest at this point to justify internal integration, with all the complications from an RF and EMC design perspective. The correlation between this and portability, however, was not that great, at 0.23, indicating a loose agreement between the answers, though the size of the survey may make drawing a better result more difficult here.
Stronger interest was heard for the
DDS function, with an average score of about 3.0/5, although much like the configurable digital filters option this seems like an option that has mostly 'average' support, with few people regarding it as essential. That was somewhat surprising to me and pushes the DDS function more towards an external module card, if it is implemented. It should be relatively trivial to implement it using the FPGA's spare resources, requiring only a few SERDES blocks, but will require a board with external filters, offset, gain control and output amplifiers. A suggestion of an isolated DDS was made by one respondent. This would likely have to be a separate module (I personally don't think it is worth including as a 'standard' option due to the cost), but with high speed digital isolators available from Analog Devices and others, plus a DC-DC module to bridge the isolation gap, it's eminently practical to do so. But this would likely add a fair bit to the cost of any such module.
The
10MHz reference function was well-supported, with the majority of interest around 4/5, for an average score of 3.5/5. This seems like a no-brainer as it is pretty inexpensive to add and comes at relatively little cost. The reference signal could be routed via the FPGA fabric as a combinational logic block, although this might add jitter, so external multiplexers may be preferred. In any case, it's reasonably trivial to feed in a 10MHz reference to the PLL, or to export the PLL's reference signal, with some multiplexer ICs or the FPGA fabric.
And the
50 ohm input termination was also well-supported, with the majority of responses also around 4/5. Very few people regarded it as not important at all. The average score was 3.8/5. I intend to investigate adding a fast relay turn-off circuit to any 50 ohm input, using a simple latch, to allow the terminator to be protected if the input is grossly overloaded. Of course, it will not save your ass if you connect it to 240V mains, but it might stop you damaging the terminator if it is hooked to 24V instead of 5Vpk max. (For simplicity, it would turn off all terminators if input voltage is exceeded, if the 50 ohm mode is enabled for that channel.)
The next stepsThe existing hardware architecture was a great proof of concept but I believe to continue this project it will be essential to develop a second-generation PCB. I see two possible routes forward for this project. The lack of portability as a serious requirement unlocks options that would be more power-hungry than a battery powered solution might otherwise support (for 8+ hour runtimes.)
Option A. Use PCI Express with a Pi Compute Module 4, replacing the reverse engineered CSI bus, connected to a similar Zynq 7000 (PCI-Express variant so likely Zynq 7015.) The UltraScale is a very nice platform but the biggest disadvantage here is that it restricts you to a Xilinx Linux distribution (and Xilinx are not too good with keeping this up to date, nor do I want to go down the rabbit hole of having to build a custom kernel.) For all of its faults, the Pi has a open and supported kernel, with limited proprietary software with at least good regular support. The CM4 is also a 'beast' in terms of processing offering in a modest configuration 4GB of application memory, gigabit Ethernet and a USB2.0 controller. (There is some pain in supporting USB3.0 and PCI-e at the same time; a bridge IC may be necessary, and I'm not sure of the kernel or driver complexities there. However, the CM4 does have internal gigabit Ethernet.) However, the limitation of using the 32-bit Zynq is addressable memory will be limited to 1GB, so sample memory would be limited to max 900Mpts or so, fixed to the board in a dual DDR3 arrangement. Sample rates would also top out around 2-2.5GSa/s on 1 channel or 1.2GSa/s on a pair of channels. Yes, a MIG configuration is also an option to add say an additional memory bus, but for prior stated reasons I am not a supporter of that route forward. However I am relatively confident a price of
US$750 can be achieved here with a touchscreen UI and a few controls. My past experience with Zynq suggests that a passive heatsink will be sufficient as a cooling solution; the Pi 4 may end up being the ultimate thermal bottleneck and require some careful thermal engineering to allow the Pi 4 to run at near-100% CPU load for sustained periods of time.
Option B. Zynq UltraScale+ architecture with the ZU2EG or ZU3EG variant in use. No Compute Module. Linux application runs on the Zynq UltraScale with direct memory access to waveform data, and Mali-400 GPU helps with any 2D GPU tasks that can be offloaded, though waveform rendering still likely to be software or FPGA based. Large memory space available: should be able to support at least 8GB and probably 16GB in a user-accessible DDR4 SODIMM, granting long acquisition buffers. The biggest disadvantage here is that the cost is considerable - the UltraScale is not a cheap device. The Linux headaches as above are also noteworthy and may slow development if the available supported kernel is stuck in the dark ages. I estimate that this solution would push the product more past the
US$900 price point which may limit the market for it. However, it is likely that with the fast UltraScale fabric, the higher memory bandwidth (more internal AXI fabric, faster FPGA fabric, etc.) that the system could exceed 5GSa/s in a single channel configuration with the right engineering efforts, although probably not from day one. Power consumption of the UltraScale may also require a heatsink and, while I would intend to avoid it as I have a genuine dislike of the things in test equipment, a fan may also become necessary.
Other options have been discussed on here, including going to a plain FPGA to CM4 interface over PCI Express. However, there are really serious advantages to having the Zynq ARM (in either configuration) closely coupled to the FPGA fabric, that would be difficult and resource-expensive to implement on a soft-core CPU. Something like a Kintex with a MicroBlaze has been considered, but the disadvantage is the performance from a soft processor is limited without having to dedicate a large amount of fabric to it. The Zynq SoCs aren't much more than their comparable FPGA-only brethren, but deal with a lot of the headaches for you already. Improving how 'accessible' this platform is to hardware and software hackers is critical to me.
I do appreciate the continued discussion here so please let me know your thoughts, positive or negative.
Tom
Edited to fix omission with Wi-Fi results.
Home
Help
Search
Login
Register
