Random Ramblings on LabVIEW Design

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

LabVIEW Life Lessons #5 - KISS, KISS and KISSER

Active Participant swatts Active Participant
Active Participant
‎10-21-2016 11:09 AM
‎10-21-2016 11:09 AM

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 Knight of NI
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.

Active Participant swatts Active Participant
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 MattP
Active Participant

simple as possible....and no simpler

Member Terry_ALE
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)?

Active Participant swatts Active Participant
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 Christian_L
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.

Active Participant swatts Active Participant
Active Participant

Beautifully put. 100% agree