Alpha Data ADM-XRC-5T2-ADV Manual de usuario descargar pdf (Pagina 14)

12 FPGA and CPLD Solutions Resource Catalog 2010

by Rob Evans, Altium

Design abstraction – tyranny or triumph?

Decades ago when Microsoft unleashed Windows on the

world, a colleague disparagingly dubbed the new operating

environment as ‘DOS in a clown suit’. He had a point. For

all the fanfare generated by Microsoft at the time, Win-

dows was simply a GUI and application layer imposed over

plain old DOS.

Yet as a front-end that abstracted the DOS operating

system to a more accessible interface, Windows was a

success. It removed the need to deal with the low-level

complexity of the DOS command line and allowed users

to work at a higher, graphical level that was more in tune

with what they actually wanted to do.

Windows has now progressed, some might say painfully,

to a point of sophistication that bears little resemblance

to its genesis as a specialized interface to the ‘real’ oper-

ating system. As an evolutionary example of interface

abstraction, it demonstrates the path from ‘clown suit’ (or

more charitably, ‘graphical suit’) to an accessible working

environment that connects into a broad world of applica-

tions and systems.

It also indicates that successfully abstracting a process is

much more than just adding an interface layer that wraps

around it or is imposed on top. Because a process rarely

exists in isolation, an applied abstraction system needs to

connect and respond to the system that surrounds it. Only

then can its full potential be realized.

High Level Design

The abstraction systems used in electronics and software

design are also familiar. In fact, so familiar they’re con-

sidered the normal, rather than abstracted ways to work.

Historically, the move to integrated circuits from discrete

components is a hardware example of designing at higher

abstraction. ICs allowed engineers to adopt a higher-level

‘black box’ approach to design where they didn’t need to

know (or care) what was inside the chips. By assuming

the boxes would work within specification, they could be

simply connected together as functional blocks and tested

on some form of hardware development board.

Software design has progressed through a long path of

programming languages and systems that all serve to free

developers from the horrors of assembly language. Using

the familiar implementations of programming interfaces,

code syntax and compilers, software development har-

nesses high level abstraction via a huge range of languages

– from Pascal through to object-orientated languages

and C++. Embedded application software, the lean, mean

cousin of PC application software shares much of the same

principles and systems.

Significantly, the upstart and relative newcomer to the elec-

tronics development process, programmable hardware, is

in the early days of its design abstraction evolution. Hard-

ware description languages (HDLs) are used to describe the

design at a register (RTL) level, which is ultimately syn-

thesized to a gate level for implementation in the selected

device – traditionally an ASIC, but now more commonly

an FPGA. However the arcane nature of HDLs, often com-

pared in complexity to assembly language, can make the

task of developing embedded hardware daunting.

As a result, a range of design abstraction systems have

been developed in an attempt to ease the pain. These vary

widely in methodology, but are commonly schematic-based

systems, graphical flow chart approaches or variants and

extensions of the C language. As with the other design

domains (hardware and application software), the recog-

nizable tactic of implementing high level design systems

to reduce complexity has been applied.

But there’s a lurking problem – the development of pro-

grammable hardware has a unique set of characteristics

that restrict the advantages of a high level approach.

Interdependent Design, but Separate Processes

One of the defining characteristics of programmable hard-

ware is that it is intimately bound to both the physical

hardware that hosts it in a design (say, an FPGA device),

and any application software that runs on it. It’s the meat

in the sandwich, in effect, and binds the all three parts of

the design together.

This in turn means that FPGA development cannot be

isolated from the rest of what’s now a homogenous, inter-

dependent design process. Yet conventional development

tools, regardless of what abstraction layer is imposed

on them, are generally separate, disconnected design

domains.

The isolation of the design processes mean that crucial

decisions such as hardware-software partitioning must be

decided and locked in early in the design process – there’s

1 2 ... 9 10 11 12 13 14 15 16 17 18 19 ... 43 44

Comentarios a estos manuales

Sin comentarios

Alpha Data ADM-XRC-5T2-ADV Manual de usuario Pagina 14

Comentarios a estos manuales