I know being over-careful is good practice especially for presentation to the management but factual issues should not be distorted for that sake.
What I mean if an FPGA low level functionality (registers, luts, blocks, and successful timing) doesn't work as expected for each and every clock edge then we ought to give up or we add mitigation logic of some type.
(Check out if you need this basic understanding of FPGAs: http://www.apogeeweb.net/article/67.html).
To my understanding mitigation is the domain of safety critical applications or aerospace and it requires small sized designs with plenty plenty of work to detect or correct events such as SEU...etc.
But I notice many fpga engineers carry some remnants of mitigation mindset everywhere and it is this that I hate...
The most famous example: if a state machine enters unreachable state and then what?
Is it enough just to add when others ? and does various state coding imply fpga registers could go wrong?
I believe we should then reset the state and then reset all associated signals and reset input module and reset output module and well reset all system and don't worry about your design switching on and off as a result. Else a partial mitigation is pointless.
Another example "if count = n ..." and somebody would review the code and say no sir add if count > n as well to make it more solid just in case.
My answer is that my counter is meant not to be more than n but less and I should not bother about unreachable state of > n. I do not want to mask any potential bugs...
There might be tens of thousands or hundreds of thousands of registers in a design so why just make some more solid and forget others.
so in short we either mitigate faults correctly when the application is critical or assume fpga will work and should be trusted instead of half-baked solutions for non-critical cases.
Here we need to differentiate between fpga primary logic per se and user made functionality out of that logic.
FPGA primary logic should be trusted but user design may not be. Flaky designs are common and mitigation may be considered here but can also mask bugs or patch them up.
For example there might be cases when some logic is locking to some signal and loss of lock may need to be mitigated.
Another example: some designs decide I/Q pairing from a serial I-Q-I-Q stream based on just one single initial check but I would prefer to have self-correcting logic if I am not sure about my simulation cover or not confident about the module that generates the stream of I-Q-I-Q designed by my next door neighbour
This sounds like a design -unfairly- needs to check and correct its inputs which is the responsibility of input module.
Any comments appreciated.
- Customer Support
- ↳ Product Support
- ↳ Oscilloscopes
- ↳ 5 Series MSO Oscilloscopes
- ↳ Windows Based Oscilloscopes
- ↳ Non- Windows Based Oscilloscopes
- ↳ Sampling Scopes and Modules
- ↳ Programming Support
- ↳ Other or Discontinued Oscilloscopes
- ↳ Probes & Probe Accessories
- ↳ Passive/Low Voltage
- ↳ High Voltage
- ↳ Differential
- ↳ Current
- ↳ Other or Discontinued Probes
- ↳ Signal Sources
- ↳ AFG1000/2000/3000 series
- ↳ AWG5000/7000/70000 Series
- ↳ Keithley 3390
- ↳ Older and Obsolete Signal Sources
- ↳ TSG4100A Series
- ↳ Spectrum Analyzers
- ↳ Announcements and FAQs
- ↳ RSA Programming
- ↳ RSA300/RSA500/RSA600 Series
- ↳ RSA5000/6000 Series
- ↳ Older and Obsolete Spectrum Analyzers
- ↳ Vector Network Analyzers
- ↳ Announcements and FAQs
- ↳ Programming with VectorVu-PC (E.g., Automated Test)
- ↳ TTR500 Series VNAs
- ↳ Source Measurement Units (SMU)
- ↳ 2600 Series SourceMeter
- ↳ 2651A High Current SourceMeter
- ↳ 2657A High Voltage SourceMeter
- ↳ 2400 Series SourceMeter
- ↳ 2450/2460 Touchscreen SourceMeter
- ↳ Other Source Measurement Units (SMU)
- ↳ Digital Multi Meters (DMM)
- ↳ Series DMM7510 Graphical Sampling DMM’s
- ↳ Series 2000 and Series 2100 DMM's
- ↳ Series 2015 & 2016 THD/Audio Analyzers
- ↳ Other DMM's
- ↳ Data Acquisition Systems and Switch Systems
- ↳ Series 3700 Switch System/Multimeter and Plug-In Cards
- ↳ 7000 Series Switch
- ↳ 700 Series Switch
- ↳ RF Switch
- ↳ Other Switches
- ↳ Series 2700 Multimeter/Data Aquisition/Switch System
- ↳ Power Supplies
- ↳ Series 2200 Programmable DC Power Supplies
- ↳ Series 2260 Programmable DC Power Supplies
- ↳ Series 2280 Precision Measurement DC Power Supplies
- ↳ Series 2300
- ↳ Other Power Supplies
- ↳ Power Analyzers
- ↳ Semiconductor Test Products
- ↳ S530 Parametric Test Systems
- ↳ 4200-SCS Semiconductor Parameter Analyzer
- ↳ ACS Software Products
- ↳ Low Level Measurement & Sourcing
- ↳ Nanovoltmeters
- ↳ Electrometers
- ↳ Curent Amplifiers
- ↳ PicoAmmeters
- ↳ Current Sources
- ↳ Older & Obsolete Instruments
- ↳ Bit Error Rate Testers
- ↳ Logic Analyzers
- ↳ Video Test
- ↳ Other Instruments
- ↳ Electronic Loads
- ↳ Frequency Counters
- ↳ Keithley DAQ Data Aquisition Products
- ↳ Other Keithley Instrument Products
- ↳ Other Tektronix Instruments
- ↳ Software
- ↳ TekScope Anywhere
- ↳ SourceXpress
- ↳ SignalVu-PC
- ↳ PWRVIEW
- ↳ KickStart
- ↳ Test Script Builder
- ↳ Drivers and Utility Software
- ↳ LabView Drivers
- ↳ IVI Drivers
- ↳ TekVISA
- ↳ Other and Discontinued Software
- ↳ ExcelLINX
- ↳ IVy
- ↳ Keithley I/O Layer (KIOL)
- ↳ Accessories
- ↳ Test Fixtures
- ↳ Cables and Connectors
- ↳ Instrument Accessories & GPIB
- ↳ Data Acquisition Accessories
- ↳ Picosecond Components and Accessories
- ↳ Remote Instrument Communication (Programming) Examples
- ↳ Application Support
- ↳ Low Current Measurements
- ↳ Low Voltage Measurements
- ↳ Resistivity Measurements
- ↳ Hall Measurements
- ↳ Electrochemistry
- ↳ Solar Cell Measurements
- ↳ Nanotechnology Measurements
- ↳ High Voltage Discretes for Power Switching
- ↳ High Brightness LEDs
- ↳ Memory (Flash, Phase Change, NVM, Resistive)
- ↳ Display Technology (OLED, TFT, Organic Polymer)
- ↳ Organic Device Measurements
- ↳ General Discussion
Who is online
Users browsing this forum: No registered users and 3 guests