On 7/25/2019 4:39 PM, Dave Daniel
wrote:
Well, I don't have a problem with that, but I'm just a
contributor to the thread.
I have a lot (~43 years) experience with both embedded hardware
(including large FPGA designs) and embedded software, as well as
embedded system architecture, so I'll add my $.02.
Partitioning an architecture into the hardware and software
components is not always easy (in fact, it almost always is not
easy).
Remember that, at 70,000 ft., and ignoring all of the
development methodology issues, an FPGA or other fixed-hardware
portion of a design is different topologically than the part
that the processor handles. For example, the FPGA design is
fixed, topologically and (ignoring re-programming with different
images for different applications) may be designed to be
deterministic in it's behavior. Aside from design faults that
cause timing and metastability issues. A schematic or other
fixed-topological view of the hardware is the only model needed
to depict the hardware (deciphering it is another issue).
The processor-controlled portion of the design necessarily
involves the execution of code, which has no fixed topology at
run-time, and is not necessarily deterministic. A software based
design requires, at a minimum, both a structural model of the
code and a behavioral model (think UML or SysML) to understand.
It is not necessary to have both elements in an embedded
system, but many embedded systems do have both.
My point is that the determination of whether to use an FPGA or
other fixed-hardware design, or a processor-based design, or a
combination of both, is entirely dependent on the requirements
that dictate how the system behaves and what it is supposed to
do. In the commercial world, that determination also must take
into account fixed production costs and maintenance costs of the
system.
Most (?) very small embedded systems designed by "hobbyists"
today use a single SBC such as an Arduino, Raspberry Pi,
BeagleBone, etc.and there is no need for the amount of fixed
hardware that would make a CPLD or FPGA a reasonable design
option, But, as the GPIB-USB discussion shows, sometimes maybe
using both is a good idea.
Hmmm, well, I may have transgressed "simple".? LED controller
(pulse, pwm brightness), timer and trigger for ultrasonic distance
measurement, Neopixel encoder, SPI interface, programmable pins,
FIFO, usart, I2C to parallel decoder (in the works).
also GPIB encoder, replacement for an 8259 keyboard/led driver,
and support circuitry for a DM5010.?
Harvey
DaveD
On 7/25/2019 3:50 PM, saipan59 wrote:
I want to suggest
that the discussion should include the trade-offs of an FPGA
implementation vs an MCU [I have very limited experience with
the former, but a lot with the latter], as it relates to the
applications we're talking about.
Anecdote: When designing the 'Power-On Reset' features for a
product a few years ago, I planned to use a small MCU. When the
Architect found out, he vetoed it, saying "We can't rely on
running code for a critical start-up function". He was fine with
an FPGA or CPLD (at higher cost, more board real estate, less
flexible behaviors, and HUGE complexity in the 'code' that runs
under the covers). My belief is that he was equating an FPGA to
the old bipolar PAL's used in the 70's/80's, where logic
functions were literally burned in, so it was considered
super-reliable.
In the end, I was able to meet the requirements with just a few
little timer (1-shot) chips and a bit of glue logic.
Pete
