Products > Test Equipment

First picture on EEVblog of the new R&S MXO4 series oscilloscope :)

<< < (30/60) > >>

luudee:

--- Quote from: maxwell3e10 on February 11, 2023, 04:25:15 pm ---Somehow people cut much more slack for software than hardware errors. Remember how much bad press Intel got for a division bug in Pentiums. But software and firmware bugs are totally accepted. I wouldn't say that software is intrinsically more complicated than designing and making a big processor. Yet hardware gets more and more powerful while software gets more and more bloated while still having mostly the same functionality.
...

--- End quote ---

Traditionally, a lot more testing and verification has been put in to hardware. I have been doing ASIC design
for over 30 years. I have also done some software development (C/C++).

To manufacture an ASIC, the NRE is anywhere between $1Mil USD, 20 years ago, 180nm node, to about
$10Mil USD, Samsung 8nm node, 4 years ago. Because of the high cost, a lot more effort is being put in to
making HW to be correct the first time. Everything from functional verification, to toggle coverage to various
timing analysis had to be 100%. 

Since FPGAs have taken over a lot of the low-volume market, HW/chip designers have lost the art of making
hardware that works the first time around. We now see "firmware" upgrades that not only include software but
also hardware fixes in FPGA bit streams.

I bet the "freeze" Dave found in the MXO4 is from some FPGA ... the GUI appears to work just fine.

Overall, I believe it has become much less critical to properly verify and test hardware and software, since it
has become so easy to provide and install updates. I still vividly remember the times, when a software update
meant for a vendor to ship two 27xxx EEPROMS which you had to physically replace on a device motherboard.

As such, I believe all equipment we will see in this day and age will suffer from incomplete/faulty HW and SW.
It has become so cheap and convenient to issue a fix at  a later date, that I bet many of these vendors purposely
leave out features and function for a later date. Time-to-Market has become the driving force.

Comparing today's "equipment" to what was manufactured 20 years ago, I believe, the designs were much more
mature, complete and though through 20 years ago that they are today.


luudee

mawyatt:

--- Quote from: luudee on February 11, 2023, 05:07:48 pm ---
--- Quote from: maxwell3e10 on February 11, 2023, 04:25:15 pm ---Somehow people cut much more slack for software than hardware errors. Remember how much bad press Intel got for a division bug in Pentiums. But software and firmware bugs are totally accepted. I wouldn't say that software is intrinsically more complicated than designing and making a big processor. Yet hardware gets more and more powerful while software gets more and more bloated while still having mostly the same functionality.
...

--- End quote ---

Traditionally, a lot more testing and verification has been put in to hardware. I have been doing ASIC design
for over 30 years. I have also done some software development (C/C++).

To manufacture an ASIC, the NRE is anywhere between $1Mil USD, 20 years ago, 180nm node, to about
$10Mil USD, Samsung 8nm node, 4 years ago. Because of the high cost, a lot more effort is being put in to
making HW to be correct the first time. Everything from functional verification, to toggle coverage to various
timing analysis had to be 100%. 

Since FPGAs have taken over a lot of the low-volume market, HW/chip designers have lost the art of making
hardware that works the first time around. We now see "firmware" upgrades that not only include software but
also hardware fixes in FPGA bit streams.

I bet the "freeze" Dave found in the MXO4 is from some FPGA ... the GUI appears to work just fine.

Overall, I believe it has become much less critical to properly verify and test hardware and software, since it
has become so easy to provide and install updates. I still vividly remember the times, when a software update
meant for a vendor to ship two 27xxx EEPROMS which you had to physically replace on a device motherboard.

As such, I believe all equipment we will see in this day and age will suffer from incomplete/faulty HW and SW.
It has become so cheap and convenient to issue a fix at  a later date, that I bet many of these vendors purposely
leave out features and function for a later date. Time-to-Market has become the driving force.

Comparing today's "equipment" to what was manufactured 20 years ago, I believe, the designs were much more
mature, complete and though through 20 years ago that they are today.


luudee

--- End quote ---

That is so true regarding the ASIC NRE, maybe even on the low side. Our over decade old CLASS ASIC for DARPA was ~$50M and worked the first time, with only ~1B transistors (massive Systolic Array). Recall Intel spending $100s of Millions on processor chip development long ago and Apple spent ~$1B on the initial M1 chip set development.

With those kind of numbers and the huge wafer mask set costs for SOTA Digital CMOS processes (reruns), one better get the design right the first time, as errors are quickly career limiting :o

The Digital ASIC design folks have the benefit of some very good (an expensive) CAD tools from Cadence, Synopsis and others. Analog ASIC designs folks, the CAD tools available aren't as refined, and much more emphasis and risk is placed upon the designer.

If you really want to dive into the risk pool of ASIC design, try the merging of Digital and Analog/RF like our first Microwave Systems on Chip dating back to ~2000, which hosted multiple processors, DSP, memory, DACs, ADCs and entire frequency agile Microwave Receiver/Transmitter on a single SOTA SiGe BiCMOS process chip!!

Even today with low cost PCBs available it seems that some hardware designs are just thrown together and get fixed by PCB iteration, and the Firmware/Software is just riddled with numerous bugs.

However, do think generally the "A Grade" TE OEMs do a better job with new equipment introductions, they have the people and financial resources to do a more thorough job before releasing a new product, and the cost shows such!! Some of the better "B Grade" OEMs seem to do a better job before releasing a new product than others, and seem to have found an attractive cost/bug ratio cost*bug product!!

Anyway, old seasoned ASIC designers may have a different perspective on things than folks that have never attempted a complex ASIC :-+

Best, 

EEVblog:

--- Quote from: bozidarms on February 11, 2023, 07:50:41 am ---
--- Quote ---Software is complicated no matter what country it's written in. I'm sure there's horror stories from every single brand.

I'd even believe that the more expensive something is, the more places there are to screw up the design. Cutting edge is cutting edge.

No product manager these days is ever going to say "let's just use it internally for another six months and see if any bugs turn up".
--- End quote ---

I don't quite understand the logic behind that statement, but as long as the potential buyer is willing to accept it, i have no problem with that.
I personally would never do anything like that, or when I buy a great, expensive product (car, TV set...), i expect from the beginning everything to work perfectly (drive easily, perfect picture...).
Don't see any reason why would be different with measuring equipment.

--- End quote ---

Volume, target market, and technical needs are very different between a car and a high end oscilloscope.
But car are not immune, Tesla's for example are (in)famous for software bugs that not only impact the software experience but also extend to hardware functionality.

mawyatt:
One likely reason for the relatively few hardware bugs vs. the typical large number of firmware/software bugs we are accustom too is the hardware bug may require a return and PCB replacement (high OEM cost). Whereas, the firmware/ software bugs are usually rectified by having the user download the prior bug correcting revision (low OEM cost), only to usually introduce new bugs  :o

So the OEM bean counters decide that spending some verification resources on the new product hardware has a better ROI than on firmware/software!!

The mentioned Intel processor computational error vs. Microsoft's bug riddled Windows OS is a great example, and somehow Mr Gates has conditioned us with continual software/firmware revisions loaded with new bugs as acceptable. Can you imagine what additional flack Intel would have gathered if they had introduced the replacement processor with one that had a new bug!!

Best,   

2N3055:

--- Quote from: mawyatt on February 12, 2023, 03:29:58 am ---One likely reason for the relatively few hardware bugs vs. the typical large number of firmware/software bugs we are accustom too is the hardware bug may require a return and PCB replacement (high OEM cost). Whereas, the firmware/ software bugs are usually rectified by having the user download the prior bug correcting revision (low OEM cost), only to usually introduce new bugs  :o

So the OEM bean counters decide that spending some verification resources on the new product hardware has a better ROI than on firmware/software!!

The mentioned Intel processor computational error vs. Microsoft's bug riddled Windows OS is a great example, and somehow Mr Gates has conditioned us with continual software/firmware revisions loaded with new bugs as acceptable. Can you imagine what additional flack Intel would have gathered if they had introduced the replacement processor with one that had a new bug!!

Best,

--- End quote ---

That Intel bug was a reason to introduce formal verification in Intel for verification of designs..
But don't worry, they still make them with bugs even today. It is just they are not as blatant as basic FP instructions..
And all Intel processor for many years, can do actual microcode updates. At boot time, a BIOS loads a a microcode patch into CPU.. So they are sort of software updatable, not much unlike FPGA. They still have to have at least part of instruction set  function properly so the can execute BIOS, but yeah software patches are reality on CPU too..
They can even load nev CPU instructions...

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html

Sad part is that software development could be formally verified and there were great developments on that in 80ies and 90ies but once business side realized they could save money by not doing any of that and by lawyering up and desensitizing users to accept "bugs are normal" philosophy, things went downhill fast...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod