Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Life Lessons #5 - KISS, KISS and KISSER

Active Participant

Hello World Wide Wire Wranglers,

You may well have heard be going on about KISS and it's really an acronym that I can buy into. For those of you who have never heard it, it stands for.

KISS.png

And this applies to everything we try and do, but what about Realtime systems I hear you ask (you know who you are, you scallywag)

RT

Well as RT has a subset of LabVIEWs capabilities we then apply

KISSer.png

Yes, but surely FPGA has different rules? actually it does.

FPGA

KISSest.png

One time this doesn't apply is when you're electing a president .......

Much Love

Steve

Comments
Knight of NI

I live by KISS.  I have a few stories of people overcomplicating things and then I make them simplify and then things finally work.

Though, I would say my FPGAs lately have been a little more complicated than RT.  My RT have just been a pass through between PC and FPGA.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

That's interesting matey, we tend to get out of FPGA as quick as poss, although I would say our use cases tend towards simpler FPGA requirements.

I think the beauty of KISS is it pushes you to think about simplicity as an important design consideration. It should have an AS POSSIBLE at the end of it too though.

Active Participant

simple as possible....and no simpler

Cheers,

Matt Pollock
National Instruments
Member

Do you mean that if a customer wants it 'all on the FPGA' you triage the functionality in an attempt to find what is really needed on the FPGA and then move things off of it to RT or to the main host (Win/Linux)?


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
Active Participant

If the customer wants it all on the FPGA it's a sign of a slightly unhealthy relationship, our customers don't tend to make explicit constraints like that. 99% of the time they just have a problem that needs solving or are not familiar with NI hardware.

A current observation (desire) is that we move away from FPGA as soon as possible in a project. If you are tinkering in FPGA near the end of the project it might be an indication that you're in trouble. <-- this is just a feeling at the mo' I haven't got anything but my own observations to base this on.

So in short we aim to push complexity up through to the host as soon as we can.

Active Participant

I would agree with this statement, from the perspective that the FPGA (and related I/O) should be treated as a custom piece of hardware, and not software. You'll want to define, implement, and validate your custom hardware early on in the project, before you are close to finishing your software development in RT or on the host.

I don't advocate moving all functionality from FPGA to RT, as the FPGA does provide specific benefits over RT or the host for run-time execution.

swatts wrote:


                       

A current observation (desire) is that we move away from FPGA as soon as possible in a project. If you are tinkering in FPGA near the end of the project it might be an indication that you're in trouble. <-- this is just a feeling at the mo' I haven't got anything but my own observations to base this on.

authored by
Christian L, CLA
Principal Systems Engineer - Partner and Ecosystem Development - National Instruments
  
Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for
use in hazardous environments. You assume all risks for use of the Code, and use of the Code is subject to the Sample Code License.

Active Participant

Beautifully put. 100% agree