A
alb
Guest
Hi John,
John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
There are two fundamental aspects that make a difference between the two
worlds:
1. ease to change
2. complexity
Re-programming and FPGA is rather a PITA compared to just running
'make' and this very simple aspect has a huge impact on the way
development is carried out. That is also why, for space applications,
the development flow tends to limit the possibility to wildly change the
code base, increasing the risk to break everything.
Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.
Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.
[]
We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.
This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?
Al
John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).
It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.
There are two fundamental aspects that make a difference between the two
worlds:
1. ease to change
2. complexity
Re-programming and FPGA is rather a PITA compared to just running
'make' and this very simple aspect has a huge impact on the way
development is carried out. That is also why, for space applications,
the development flow tends to limit the possibility to wildly change the
code base, increasing the risk to break everything.
Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.
Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.
[]
If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.
But how do I choose the PWM frequency?
Al
The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.
We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.
You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.
This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?
Al