According to Wall Street & Technology article, Credit Suisse is using Celoxica to provide hardware accelerated market and trading technology for Credit’s next-gen trading platform.  By “hardware” they obviously mean using FPGA technology.  For years, Celoxica has been trying to make in roads into financial services by offering hardware and software to build FPGA applications.  Unfortunately, the long development times for synthesized hardware doesn’t mesh well with the short lead times of I-banks.  I believe Celoxica has changed their strategy to provide completed “turn-key” like solutions.  This makes a lot of sense.

A few years ago, I attended a “High Performance Wall St” conference where CSFB hosted a small talk with Celoxica on using FPGAs in day to day trading.  Although CSFB wouldn’t even acknowledge they were using Celoxica on their trading floor, it is obvious that a relationship did exist, FPGAs were used all which eventually led up to this deal today.

Next week I’ll be attending the software defined radio conference in Washington D.C. For those of you familiar with Virtual Instrumentation you know at NI we’ve been working for many years on software defined instruments that take advantage of PC based technologies. With a simplistic view of SDRs it isn’t difficult to draw a parallel between virtual instrumentation and SDRs. In the case of SDRs some of the communications system components traditionally implemented in hardware are defined in software (on a PC or embedded devices). With some of NI’s measurement class hardware and an IF transceiver you can develop an SDR and use LabVIEW FPGA to program the FPGA on the IF transceiver.

My goal at the conference is to learn more about the needs of people developing SDRs as they might apply to using LabVIEW and LabVIEW FPGA and also NI’s FPGA based hardware. If you’re going to be at the SDR conference next week and would like to get together with ideas on how to apply LabVIEW to SDR development or how to make use of FPGA based COTS solutions from NI for SDRs let me know. You can find me on twitter @kamrans or just e-mail me directly at kamran dot shah at ni dot com

I finished the programmer for the on-board Intel StrataFlash on my FPGA development board today. It was much more of a hassle than I thought it was going to be. Digilent, maunfacturer my FPGA board, had done a fantastic job on their user manuals on every topic except for the memory resources, which was disappointing. I had to dig my way through a couple datasheets before I got all the information I needed to operate the Flash device.

At first, I had thought that all I would need is a stand-alone device to program the Flash, but the protocols ended up being complex enough that I used Test CPU 1. I modeled the system after my LCD controller. There are four main components: Test CPU 1, ROM for the data to be stored, a counter that’s used to generate the addresses for the Flash, and a little component that adds an offset to the counter’s output so the system can be easily configured to place data anywhere in the Flash array.

Because it takes over 260 us for the Flash to write data into the array, the chip has a status signal that can be monitored to detect when it’s done programming the Flash. Now, the Test CPU 1 didn’t have input capabilities when I started, but I did add them in. Luckily, it was rather easy. I just added another opcode to the control block, a register between the inputs and the rest of the processor, and four new pins that act as individual inputs. The instruction takes four fields: the opcode, if it’s testing for a ‘1′ or ‘0′, the pin number, and an address to jump to should the condition be fulfilled. For example, if the instruction is testing pin 2 to be ‘1′, it will jump to the address specified if pin 2 is ‘1′.

While perusing the datasheets, manual for my development board, and schematics of my development board, I got confused in several places. First of all, there are two inputs to the StrataFlash that I don’t have access to on my development board. Second, the StrataFlash is automatically configured for two-byte word writing (as opposed to byte-sized), so there were several signals omitted because of that. Of those signals, address bit 0 was tied to ground. This confounded me because the manual told me that it had a 24-bit address bus, when I really only have access to 23 bits!

The other major thing that tripped me up was the protocol for reading and writing data. I have access to four signals that are used to place the StrataFlash in a variety of bus modes (the data bus is bidirectional). The signals are: write enable, output enable, chip enable, and reset/power down. The fourth is a signal used to place the chip in a low power state, or configure it for power down. But, because the StrataFlash has an on-board CPU,  it needs a command sent to it before every write to tell it what to do. The steps to write two bytes to the Flash array as follows:

1. Set up signals: WE = ‘0′, OE = ‘1′, CE = ‘0′, RP = ‘1′
2. Send write command (0×40): address bus is address of data to be written, data bus is ox40, toggle WE
3. Send data and address, toggle WE
4. Wait for the status signal to return to ‘1′

Because I’m running Test CPU 1 at 1 MHz for this application, I didn’t need to worry about timing much because the StrataFlash is actually running faster than the CPU in this case. The data ROM holds the write command alternately with the data to be written. Another thing to note is that, because Test CPU 1 doesn’t have any data outputs, I had to cheat a bit and directly output the contents of register 1 to address the data ROM. Because I’m using register 1 to address the data ROM, I couldn’t use it to address the Flash because it changes addresses for both the command and data writes, while the Flash requires that they stay the same for both writes. That’s why I have a separate counter handle the Flash’s address, which is controlled by a couple of the CPU’s outputs.

Here’s a component-level schematic of the system:

I have a few design concerns with the OZ-3 regarding this Flash memory. First and foremost: its data bus is sixteen bits wide, but my instructions are thirty-two bits wide. Fetching the instructions in two cycles isn’t a big deal in terms of actually doing it, but it is a big deal in terms of the OZ-3’s potential CPI. It’s close to one if the instructions are fetched in one cycle, but rises to two if they’re fetched in two cycles, because the other stages of the processor can’t do anything while the second half of the instruction is being fetched. That halves the amount of work the processor can do in a second, which I simply won’t accept.

There are a few solutions that I’ve come up with to solve this problem: get another flash chip somehow, expand the instruction fetch stage to two stages and clock them twice as fast, or completely re-do my ISA to fit into sixteen bits.

The first solution is ideal for performance. Digilent does make a peripheral device that is another Flash chip, but it’s a serial flash and isn’t Intel StrataFlash. Conceivably, I could make my own peripheral connector using a 40-pin expansion port on my development board so that I can still have a parallel interface with Intel StrataFlash. This may be too time-consuming, but it would let me do the most with the OZ-3.

The second solution is probably going to be the one I go with, because it would be easiest and still let me clock the OZ-3 pretty fast, while still keeping a close-to-one CPI. The StrataFlash chip that is on the board supports 110-ns reads, so if you double that, that would be how fast I can clock the OZ-3 overall. 220 ns per cycle translates to 4.5 MHz, which is reasonable.

The last solution is one that I simply do not want to do. Needless to say, stuffing the ISA into sixteen bits would change everything. Microarchitecture, capabilities, address width. I would essentially have a whole new processor, which I don’t want.

With the Flash programmer complete, I’m going to continue with the OZ-3. The next step is sorting out the instruction fetch stage(s).

Ben Oztalay

It’s hard to believe we missed this one from a couple of years back but we’re thankful that reader [Christian] tipped us off about it. This a Nintendo DS with two tablet pc screens being used as an external display. He’s using an FPGA but not to emulate the processor. It is translating the video data from the DS board into usable signal for the larger LCD screens. In the video after the break you can see that pen input has been implemented, with the FPGA sending location data back to the DS.

[Neal], the creator, priced the project out at around $580. It’s worth a lot more considering the know-how needed to get the video scaling and pen input right using the FPGA. It won’t fit in your pocket, but it doesn’t have a case either so it’s not going anywhere anytime soon.

Altera’s latest version of Quartus II now enables users to implement the economy version of the Nios II processor without charge. That’s a great way for Altera to bring new customers to the Nios.  Let users learn and implement a design, then when (or if) they need added performance for a design they will likely just shell out the license fee. From then, it would be doubtful that they ever went back to the lower performing brother of the Nios family.

When you step back though, you realize that the standard and fast versions are serious RISC implementations while the economy version is not much better than processors we made in digital design courses in undergrad. (Of course, we didn’t have free compilers and debug tools to accompany them!)  Without hardware multiply (or divide) and 0.15 DMIPs per MHz, it seems unlikely that the economy processor would be used by anyone doing anything more than orchestrating the components on the Avalon bus. However, with Altera leaving support for custom instructions intact, this announcement may leave dangerous room for people looking to save money in these cost-conscious times.

Si trabajas en el mundo de la banca, y te enseñan un pantallazo como este…

… seguramente no te dirá nada, por curiosidad te diré que lo que tienes ahí es una cosimulación de un modelo realizado con Simulink (MathWorks) y un simulador de código VHDL, comparando los resultados obtenidos con objeto de verificar la bondad de nuestro código. Una vez que los ingenieros comprueban que todo funciona correctamente reescriben ese código en un microprocesador de propósito espécifico llamado FPGA capaz de ejecutar instrucciones de código mucho más rápido que un micro convencional. Lo normal, es que este código se utilice en sistemas de visión artificial, radares, telecomunicaciones,…  Esto se podía ver el pasado Jueves 19 de Noviembre en el X-fext  en Madrid, una feria que organiza cada dos años Xilinx uno de los principales fabricantes de estos microprocesadores FPGA.

Recientemente publicamos un post sobre Algoritmic Tading en el que comentábamos que la ventaja entre unos traders y otros venía dada por microsegundos,  jústamente eso, lo que hace que una FPGA sea más rápido que un micro convencional, unos microsegundos y que se traducen en millones de Libras Esterlinas al final de un año y eso es precisamente lo que los más listos de la clase están haciendo ya en la City. Cogen sus modelos y los reescriben en código VHDL (código específico para FPGA’s), como si fuese código C, y de ahí lo reescriben en las FPGA’s y en lugar de ser el micro de un PC o servidor el que lanza las órdenes de compra/venta es una FPGA de Xilinx o Altera  la que se encarga de esto, mucho más rápido que su pariente lejano de Intel.

Una pena que ya no puedas pasarte por ahí, al final; como si de un mercadillo de barrio se tratara, terminaron recogiendo su tecnología y llevándose su conocimiento a otra parte. Una verdadera lástima, porque aquí más de uno te habría contado cómo hacerlo.  Quizás el tipo este de la foto sepa algo…

Development of the open source logic analyzer, first discussed here, has progressed rapidly in the forum.

We’ve looked at cost estimates, Uwe made some excellent block diagrams, and Jack has already added a basic layout to his SVN.

Read our goals and specs after the break.

Our goals, as summarized by Jack:

Primary goals:
1) Logic Analyzer for $30-40 US dollars
2) 70Mhz+ speeds
3) 16-32 channels

Secondary goals:
1) Add a Voltage Buffer
2) Make it as DIY as possible.
3) Make it as Open Source as possible.

According to an interview on HPCwire with Mitrionics Chief Science Officer, Mitrionics will start work on a new experimental compiler that will take code and target FPGA and multi-core CPUs and,  maybe someday, GPUs. In my book this is too little too late.

I don’t think there is much future for FPGAs.  Mitrioncs has developed their own C language extensions, Mitrionic C.  Its not a bad language but its like writing device drivers so it knocks out a lot of general application developers.  Also, the compiler is quite expensive.   Now, the generated code: it  does not directly run on FPGA chips, it run on some virtual OS that sits on top of the FPGA.  What does this matter?  According to the numbers I heard from sales reps at SC’08, it costs tens of thousands of dollar per year to run the virtual OS.   Unless your customer is the CIA, I don’t think most customers like to spend huge amounts of cash on compilers, boards and annual licenses to run your programs.

The real problem is this.  All people have computers with multi-core processors.  As the years go by, the number of cores grows.  Most developers deal with companies like Microsoft and Intel.  They provide tools that are quite good for languages that most developers are familiar with.  BTW, Intel probably doesn’t make that much money on the tools as they exist to drive chip sales.  Also, companies who design  chips – like Intel or AMD – will probably promote technologies, like Thread Building Block, that will address multi-core without costing an arm and a leg.

Now, GPU companies have it easy.  Almost everyone has a GPU.  If you don’t have one you can buy one for $100 on Newegg.   For free, developers can work on OpenCL, Brook++ or CUDA.  These languages are backed by much larger companies – Apple, AMD, NVIDIA – compared to Mitrionics.  These technologies will be around for years.

Mitrionics has to enter this competitive market and say, “I can deliver a better compiler that understands your products, CPU and GPU, better than you. I will also provide these tools at a reasonable price and disseminate knowledge on our technology effectively as to increase adoption.”  Good luck!

[Jack] wrote in to let us know about a project that creates a virtual microprocessor core based on the ATmega103 by using a Field-Programmable Gate Array. Great, we thought. Here’s another rather esoteric project like the NES on a FPGA, but what’s the motivation behind it? We asked [Jack] and he provided several scenarios where this is quite useful.

Implementing the AVR core allows code already written for the chips to be easily ported to an FPGA without a code rewrite. This way, if your needs outpaced the capabilities of the microcontroller long after the project has started, you can keep the code and move forward from that point with the added capabilities of the gate array. Having the core already implemented, you then only need to work with HDL for the parts of the project the AVR was unable to handle. He also makes the point that having an open source AVR core implementation provides a great tool for people already familiar with AVR to study when learning VHDL.

With products like the Butterfly that this project is based around, or the Maple we’ve seen in the past, programmable logic for the recreational hacker is starting to get a little easier.

We’re really excited to be joined by Jack Gassett, developer of the Butterfly FPGA platform, to prototype an open source, high-speed, low-cost logic analyzer. This effort grew out of a bunch of great comments on a post about open source logic analyzer clients.

Share your ideas for the logic analyzer in the new ‘SUMP PUMP’ logic analyzer development form. Jack has already posted a power estimate for the FPGA, and Ian has some thoughts on interface design. Maybe someone can suggest a name?

Arrow and Altera have teamed up to deliver a cleverly-easy-to-use low-cost dev board. Just plug it into your USB port and the built-in programmer for the Cyclone III FPGA allows you instantly begin prototyping your designs.

This seems like a great idea, hopefully this is well executed. We will have to wait to see the spec sheets, but the 80-pin PCB edge connector seems like an excellent way to provide the user with expansion capabilities while minimizing bulk, cost, and trace lengths.

Lattice Enhances FPGA Design Tool Suite

Lattice Semiconductor has announced Version 8.0 of its ISPLever FPGA design tool suite. This latest version includes enhancements for the design of high-speed double data rate (DDR) interfaces for the LatticeECP3 FPGA range. These enhancements include automatic interface code generation to increase design productivity and reduce coding errors, as well as enhanced timing analysis that provides more transparency to circuit timing details. The IPexpress tool now can generate the HDL for the most appropriate generic DDR interface based on user requirements such as direction, speed and bus width.

This HDL has been specifically designed and validated for high-performance, robust operation. For the ECP3 range, certain DDR interfaces can now be implemented with higher pin layout flexibility. Since an important part of robust DDR interface operation is a clean transfer between the IO and fabric clock domains, the Trace static timing analysis report has been enhanced to include a Timing Rule Check section that specifically analyses these clock domain transfers. This is done automatically and does not require users to define additional timing constraints.

The IPexpress tool can now also optionally generate the complete I/O-specific circuitry for proprietary DDR memory interfaces, allowing designers to focus solely on the controller logic of their DDR1 and DDR2 DRAM interfaces. ISPLever 8.0 software is able to complete large, congested designs 30 per cent faster than with the previous ISPLever 7.2 SP2 release. Lattice continues to enhance and expand support for the open source 32-bit RISC Latticemico32 ecosystem. The GNU compiler (GCC) has been upgraded to Version 4.3.0, which enables higher system performance and more flexible code deployment options.

The Tri-speed MAC IP can now be interconnected to higher throughput configurations. The component library includes a dual-port on-chip memory to enable high-speed information passing between Wishbone bus masters, while an enhanced SPI Flash controller allows both read and write access. The ISPLever design tool suite provides a complete set of tools for all design tasks, including project management, IP integration, design planning, place and route, in-system logic analysis and more. Version 8.0 of the ISPLever software adds support for Red Hat Enterprise Linux 5.3. Synopsys’ Synplify Pro advanced FPGA synthesis is included for all operating systems supported and Aldec’s Active-HDL Lattice Edition simulator is included for Windows.

The ISPLever 8.0 software also comes bundled with the Latticemico32 system and ISPLever Classic, as well as with the PAC Designer tools that target mixed signal design. The ISPLever tool suite is provided on DVD for Windows, Unix or Linux platforms. In addition to the tool support for Lattice devices provided by the OEM versions of Synplify Pro and Active-HDL, which are included in the ISPLever tool suite, Lattice devices are also supported by the full versions of Synopsys Synplify Pro and Aldec Active-HDL. Mentor Graphics Modelsim SE and Precision RTL synthesis also support the latest Lattice devices, such as the LatticeECP3 range. The ISPLever 8.0 tool suite for Windows, Linux and Unix users is available immediately without charge for customers with active design tool maintenance contracts.

One of the challenges faced in networking research and education is the difficulty of accurately recreating a network environment. Production routers are implemented as hardware devices, but designing and fabricating a new hardware design for research or teaching is very expensive. Modular software routers like Click enable research and education on routing in software, but don’t allow experimentation with hardware and physical-layer issues.

NetFPGA aims to rectify this, by providing an easy-programmable hardware platform for network devices (NICs, switches, routers, etc.). Users interact with NetFPGA remotely, uploading programs that configure FPGAs on the device appropriately, and then observing the results. The initial version of NetFPGA didn’t have a CPU: instead, software to control the device runs on another computer, and accesses hardware registers remotely (using special Ethernet packets that are decoded by the NetFPGA board). The second version of NetFPGA has an optional hardware CPU.

Discussion

This seems like a pretty incontrovertible “good idea.” One potential question is how the performance of an FPGA-based router compares to that of realistic production hardware — I’d suspect that NetFPGA-routers occupy a middle ground between software-only routers (easy to develop, poor performance) and production routers (difficult to program and expensive to fabricate, but good performance).

In the past year there has been an increased level of skepticism regarding FPGAs as computing devices. Large amounts of ink of been spilled regarding the emergence of GPUs as general-purpose computing platforms. NVIDIA’s Tesla is racking up high benchmark scores in domains that include computational finance, scientific computing, geophysics and many others.

Nonetheless, there are certain domains in which FPGAs are clear winners over GPUs, particularly when power consumption is factored into the results. Two of these domains are crypto-analysis (code cracking) and bioinformatics.

The CHREC group at the University of Florida, and Pico Computing of Seattle, have both recently announced benchmark results for DNA sequencing algorithms. Both groups used FPGA clusters to perform massively parallel computations and to accelerate the comparing and scoring of DNA base pairs by orders of magnitude.

The Florida group, led by Dr. Alan George, implemented a Smith-Waterman sequencing algorithm on a cluster of 96 Altera high-capacity FPGA devices, using PCI Express FPGA cards supplied by GiDEL.

The Novo-G cluster used for this project consists of 16 Linux servers, each housing a quad-FPGA accelerator board from GiDEL. According to the CHREC team, Novo-G’s performance was compared with an optimized software implementation executed on a single 64-bit, 2.4GHz AMD Opteron core. A speedup of 40,849X was observed. The implication is that a bioinformatics calculation that would take days to run on a single desktop workstation or server would require just seconds to complete using the Novo-G FPGA cluster.

In Seattle, Pico Computing implemented a similar algorithm that performs sequence analysis and scoring to create a 2-dimensional figure called a dot plot. The Pico team reported that they had achieved greater than 5000X acceleration of their algorithm, using a cluster of 112 Xilinx Spartan-3 FPGA devices. The Pico cluster consumed less than 300 Watts of power, with all FPGAs fitting comfortably into a single 4U server chassis.

Perhaps more interesting about the Pico Computing project was how it was developed. Greg Edvenson of Pico used a single FPGA device during initial algorithm development. The FPGA was encapsulated in a Pico Computing E-17 card attached directly to Greg’s laptop computer via an ExpressCard interface. After the algorithm was tested and working as a single hardware process, Edvenson then scaled up and replicated the algorithm for deployment on the FPGA cluster. Greg used C-to-FPGA tools provided by Impulse Accelerated Technologies during the development of the algorithms, reducing the need to write low-level HDL code.

In summary, bioinformatics is one application domain in which FPGA acceleration offers clear and compelling benefits. And as well, there are multiple FPGA cluster approaches that can be taken to meet the needs of the application, and to meet the constraints of budget and power consumption.

So you are thinking about designing a new product from scratch.   For a first of type product of relatively high complexity, this can be a daunting thing to start.   Typically first of type complex products can take anywhere from 3 – 5 years + to go from back of a napkin idea, to a successful, reasonably bug-free product out in the market place.  Follow on upgrade versions can take over a year frequently.

It all starts with requirements — what does the thing absolutely have to do to succeed in the market for for the mission at hand.   Gathering and validating the requirements can be a lengthy process of 12-18 months+ for a first of kind system in a regulated industry.   Requirements are often so key that specialized tools are used to gather and keep track of requirements and to ensure that everything is checked off  as work progresses.  Often times a rapid prototype is done in parallel with the requirements to validate key concepts and ideas.
During this time also key design tools and design software is identified and the contracts for their purchase and use are negotiated. Large organizations may have much of this already done in-house

Next comes the Detailed Design — once the requirements are captured, validated, and gone over with the design team, the detailed design can proceed quite rapidly.  Often this may take less than a year.  (The many specialists in the FPGA/CPLD Design Group, and the Mixed Signal Electronics / PCB Design Groups often perform these type tasks for their companies)

In a regulated industry, next comes qualification testing — proof that the design meets the requirements and applicable regulations — given a skilled and experienced design team this can still take more than a year for a complex system.   This can be done by teams of systems engineers as well as test specialists and design team members)

(This can involve FDA/ FAA, or other regulatory personnel as well)

Qualification testing can include standards like:
Mil-Std-810
DO-160
FCC
CE
UL
and others

Once qualification testing is done field testing is often many more months of work by many specialists.  (This can involve FDA/ FAA, or other regulatory personnel as well)

Field test and service history is often used for qualification of re-use of existing older design components.

This is often followed by production ramp-up, and full rate production.  Manufacturing Engineers and other production personnel prepare the factory and build the product.

A lengthy and challenging process, but product creation has its rewards and job satisfaction once things are all working –

Não tenho tanta experiência e conhecimento em VHDL quanto o Marcelo Barros ou o Francisco de Souza, leitor do Blog. No entanto, eu já estava preparando esse texto há um tempinho e complementei com algumas idéias desse outro texto do supracitado Marcelo.

Inclusive, a leitura desse outro texto é altamente recomendada!

Vamos ao meu humilde post:

Meu primeiro contato com VHDL foi há mais de um ano, mas só comecei a fazer projetos com ele há 3 meses, o que não é quase nada. Se alguém leu um dos primeiros posts desse blog, vai perceber que eu dizia que não é possível atribuir valor a um signal em mais de um local do código e isso é algo facilmente resolvido com as máquinas de estado.

Você pode tranquilamente fazer alguns circuitos em VHDL só usando IF e ELSE, mas, com o tempo, isso acaba atrapalhando quando você precisa configurar um sinal, fazer uma ou várias ações e, por fim, configurá-lo novamente.

Com o CASE, é possível criar estados e esses estados podem, cada um na sua vez, configurar o valor de um mesmo sinal.

Veja o exemplo abaixo:

Esse seria o modelo de um programa fictício que começa no estado A e fica nele até um sinal X receber o valor 1 (como se alguém clicasse num botão para disparar o mecanismo) depois ele passaria pelos estados B, C, E, F, retornando ao B e seguindo o loop até que um certo sinal Y receba o valor 1, então o sistema entra no estado D e por fim volta ao estado A para aguardar novamente o sinal X.

Para implementar essa máquina de estados, pode-se usar flip-flops do tipo D ( D é a entrada e Q é a saída), um para cada estado. A saída Q de cada Flip-flop é o controle para um certo circuito que atua quando o estado está ativo.

Traduzir isso para código VHDL é simplesmente seguir as setas e colocar o que acontece em cada estado.

O sinal “estado” pode ser definido como:

signal estado: natural range 0 to 5:= 0;

Além disso, o “when others” serve para prevenir possíveis erros no valor do estado. Nesse caso não vai ter problema, mas é uma boa prática de programação usá-lo.

Com esse exemplo, dá pra ver que em qualquer um dos estados B, C, E ou F o valor do sinal Y poderia ser modificado sem problemas. Além disso, fica mais fácil de entender para que o código serve se uma outra pessoa quiser ler.

No texto do Marcelo Barros, vocês vão notar que ele usa os estados com nomes. Isso também é uma boa prática de programação, mas como estou só mostrando o conceito, acho que fica mais simples de entender. Isso não é complicado de fazer:

Usando o “type”, você configura os possíveis nomes dos estados, como abaixo. Use sempre nomes que descrevam bem o que irá ser feito no estado.

type estados is (aguardando, setup, modulo, soma, iteracao, multiplicacao);

Para acabar, a parte do conteúdo do estado, que mostra o que ele realmente faz pode ser escrita num novo CASE dentro de um “process (estado)”. Serve para deixar o código mais limpo.

Bem, por hoje é só. Se estiver algo errado no código ou no desenho, avisem.

I wrote this really long rant on the Quant Net site about different emerging technologies used in computational finance. It focuses on the differences between developing on Nvidia video cards, Field Programmable Gate Arrays (FPGAs) and IBM’s Cell processor. Please take a look.

Se você quer entrar no mundo das FPGAs e aprender descrever Hardware em VHDL, eu aconselho a leitura de um texto curto e bem explicado sobre esse assunto no blog do Ricardo Bittencourt (Brain Dump): http://www.ricbit.com/2009/11/ataque-cilonio.html

Somente um pouco mais avançado que um Hello World da programação de Hardware, ele ensina a fazer leds acenderem em sequência. Tudo numa linguagem simples e com muitas imagens.

Altera Corp. has introduced the Cyclone IV FPGAs, thereby expanding the success of the low-cost Cyclone series.

The Cyclone IV GX is said to be the lowest cost, lowest power FPGAs with transceivers, and the Cyclone IV E has helped it extend the lead in combining low cost, low power, and high functionality. Simultaneously, Altera also extended its transceiver portfolio leadership.

The Cyclone IV FPGA family offers two variants. Cyclone IV GX devices have up to 150K logic elements (LEs), up to 6.5-Mbits of RAM, up to 360 multipliers, and up to eight integrated 3.125-Gbps transceivers supporting mainstream protocols including Gigabit Ethernet (GbE), SDI, CPRI, V-by-One and Cyclone IV GX has hard IP for PCI Express (PCIe).

According to Jennifer Lo, Senior Marketing Manager, Altera, the company is pushing bandwidth limits in cost-sensitive markets and products — specifically, smartphones, wireless communications, industrial Ethernet, broadcast and 3D displays.

There is said to be a huge demand from Latin America, Asia, etc., specifically in wireless. Altera is providing a low cost, low power solution. Next, the trend is also moving from 2D to 3D displays. In broadcast it is moving to high bandwidth, in order to support HD video.

Easier for designers to debug FPGA designs
With the new Cyclone IV, will it become easier for designers to debug FPGA designs, especially when looking at the hardware and software aspects? Lo said that ease of use has always been a focus for low-end products for Altera.

“To that end, with Cyclone IV FPGA’s, like other Cyclone series, we strive to provide reference designs, design examples, development boards to customers to jump-start their design. With respect to debugging, we don’t see any particular differences between Cyclone IV and previous Cyclone generations.

“However, with more training, both fundamental trainings offered free on-line and more in-depth instructor-led trainings are available to help customers get accustomed with the Altera design methodology and use of our Industry-leading development software,” she added.

Altera had introduced the Cyclone III LS FPGA development kit, as well as shipments of industry’s first FPGAs with integrated 11.3-Gbps transceivers. How are all of these going to help Altera overall, given that Q3 saw a 3 percent increase; and help boost FPGA sales?

Lo added: “FPGAs usually have a longer design cycle (at least a few months before prototyping and another few months till mass production. With the recent few product additions, Altera is in a technology leadership position that we are all very proud of and confident that we will be able to reap the results of in the near future.”

Product goals to address market requirements
Commenting on the product features, the Cyclone IV FPGA family supports mainstream transceiver protocols and has the core functionality to address targeted applications.

The new FPGA family also facilitates probably the lowest system cost — in terms of lowest device cost, reduced board and BOM cost, and fastest time to volume production. Also, it meets the most strict power budgets with increased functionality.

Focusing on Altera’s transceiver portfolio leadership, the company is said to be the only supplier shipping FPGAs with 11.3Gbps transceivers. The Altera Cyclone IV GX has 3.125Gbps transceivers.

The Arria II GX, shipping now, features 3.75 Gbps transceivers, while the HardCopy IV GX and Stratix IV GX feature 8.5Gbps transceivers. The Stratix IV GT features 11.3Gbps transceivers. Lo added that the company needs to make sure that the products supports all latest transceiver protocols.

Cyclone IV FPGAs
Altera’s Cyclone IV FPGAs are currently said to be the lowest cost, lowest power, integrated transceivers.

Lowest system cost
* Smallest density FPGA with transceivers
* Integrated hard IP
– PCIe x1, x2, x4
– Transceivers built from ground up for low cost
* Requires only two power supplies
* Wirebond packages

Lowest power
* 60nm low-power process
* PCIe to GbE bridge for <1.5W

High functionality
* Up to 150K logic elements (LEs)
* Up to 6.5-Mbit RAM and 360 multipliers for DSP-intensive applications
* Up to eight integrated 3.125-Gbps transceivers

As an example, when used in consumer video displays, the new family will meet high video-quality requirements fast and cost effectively. When used in a broadcast video capture card, it helps save over 30 percent system cost.

ASSP replacement
Cyclone IV FPGAs provide a cost that rivals ASSPs. It also offers unmatched flexibility to support multiple protocols. Besides, being obsolescence proof, it reduces cost as well.

It can also replace simple bridge ASSPs — for example, PCI to PCIe, PCIe to GbE, etc. The FPGA family can also replace industrial Ethernet ASICs/ASSPs.

“By preserving critical timing during late design changes, Rapid Recompile can also significant reduce the timing closure workload on designers,” she added.

As I mentioned in my previous post, the next step that I wanted to take after designing the OZ-3 in simulation was to design and implement a simple CPU in an FPGA, just to get used to complex systems. Ironically, a couple days before I made that post, I had finished that CPU. It’s called Test CPU 1.

I said “simple CPU,” and by that, I mean a single-cycle, 16-bit RISC. The instruction set is ten instructions total; only the essentials. It doesn’t have any input capabilities, and all output capabilities are in 32 individual output pins, so data transfers would be rather difficult. Also, there are eight 16-bit registers. It can address 256 bytes of dRAM, and programs are limited to 4 MB, organized as 2Mbits x 16bits. The ALU is capable of addition and subtraction only, and it can only branch on zero. Here’s the full instruction set:

1. add
2. subtract
3. add immediate
4. subtract immediate
5. compare
6. branch on zero
7. jump
8. set/reset output pin
9. store
10. load

All of the immediates specified in add/subtract immediate are limited to five bits, so that makes loading 16-bit registers with values rather painstaking. Compare is simply subtraction without the register file being told to load the value on the ALU result bus.

I won’t really go into the microarchitecture, but one of the bigger problems I ran into while coding this processor involved synchronizing units with the clock and making sure nothing ended up being a two-stage process when everything was supposed to be single-cycle. I originally placed the program counter outside of the control unit/instruction decoder. This was a mistake, because I was clocking the control unit, as it was handling the Z-flag, which required a register to hold the value for use in the next instruction. I tried solving this by separating the Z-flag control area and the regular control area. This way, the Z-flag logic was the only part of the control unit that was clocked. I ended up running into undetermined problems with this, though.

To solve these problems, I put the program counter in the control unit and made sure that the control unit, register file, and dRAM were the only clocked pieces of the processor. By the way, during the first half of a cycle, all of the data is being interpreted/processed, and during the second half, the data is written. At last, after long hours of simulation, I was able to get it to work!

In actual synthesis, I ended up just getting rid of the data RAM all together. I wasn’t able to use the RAM resources on my FPGA development board because learning the interface wasn’t really worth it for this project. None of the programs I wanted to test used it, either. Eight registers were enough for my purposes. This drastically reduced the time it took to synthesize, map, translate, and place and route. From there, generating the programming file doesn’t take too long. It also cut down the amount of warnings given by ISE 11 by about 3,000.

I ran the CPU at 1 MHz, dividing down from the 50 MHz clock supplied on the board. The first program I got to work was one that counted to 0xFFFF, then lit an LED and waited indefinitely. The second program, my personal favorite, was one that controlled a 2×16 LCD display on a peripheral module, displaying the message “It works! ” Working out the timing for this program was especially difficult. I had to switch jump and branch address so many times that I ended up mixing them up and causing errors in the program that way. Despite this, it was quite rewarding when I clicked “Program Chain” then waited a couple seconds and saw “It works! ” on the screen, instead of a blank screen or flashing cursor. It’s still a  bit touchy; I have yet to find out why. But, this is where this project ends. I’ve begun coding components of the OZ-3, and hope to have a functional FPGA implementation by the end of November, or this year at the latest.

Ben Oztalay

Because I’m starting this blog so late in this processor’s development, I figured I would give a summary of what it is and what stage of design it’s in.

It official terms, the OZ-3 is a 32-bit, 5-stage RISC (reduced instruction set computer). This means that it can operate on 32-bit values, it has a small instruction set of basic instructions, can address four gigabytes of memory, and instructions move through five stages within the processor. It also has 32 registers, with r0 hardwired to 0. The stages are as follows:

• Instruction Fetch (IF)
• Instruction Decode (ID)
• Execute (EX)
• Memory and Input/Output (MEMIO)
• Writeback (WB)

Values from any of the last three stages can be forwarded to ID if a subsequent instruction needs to use the result of an operation. The way I’ve organized which stage a forwarded value comes from is first based on the result register of the instruction currently in any stage. That’s a bit of a mouthful, so here’s an example: say you send an instruction through thats “add r1, r2, r3.” Now, if you want to use its result in r1 in the next instruction, the instruction decoder looks to see if the instruction in EX has r1 as its destination. If so, the value at EX’s output (r2 + r3) is taken instead of the value coming from the register file. What if there’s an instruction in MEMIO that has r1 as its destination as well? Well, the most recent instructions get priority, so EX’s value would still be taken. Value forwarding allows a more streamlined program. Without it, there would have to be three no-op instructions between “add r1, r2, r3″ and “add r3, r2, r1″ because you’d have to wait for the result of “add r1, r2, r3″ to be written into the register file, all the way in WB.

The ALU can perform addition, subtraction, logical AND, OR, XOR, rotate right, rotate left, shift right, and shift left operations. The shift operations fill in blank spaces with 0, and both they and the rotate operations can only shift one bit at a time.

Its I/O capabilities include:

• 16 individual input pins
• 16 individual output pins
• 1 32-bit input port
• 1 32-bit output port

I’ve done the interface with the input pins by creating a branch on pin instruction that will branch if a specified input pin is 1. You have to check the input pin first to get its value into the condition register, though. Another note, the OZ-3 has no branch prediction and also has separate data and instruction memory.

It has three addressing modes: register, immediate, and displacement. Register-mode instructions take three registers: destination, source 1, and source 2. Immediate-mode instructions take: destination, source 1, 16-bit immediate value. Finally, displacement-mode instructions take: source 1, 21-bit displacement. Register- and immediate-mode instructions are for ALU, data memory, and input/output port instructions. Displacement-mode instructions are used for program control instructions such as jumps and branches. Instructions are 32 bits long.

Here’s the full instruction set:

1. add (register)
2. subtract (register)
3. AND (register)
4. OR (register)
5. XOR (register)
6. compare (register)*
7. shift left (register)
8. shift right (register)
9. rotate left (register)
10. rotate right (register)
11. add (immediate)
12. subtract (immediate)
13. AND (immediate)
14. OR (immediate)
15. XOR (immediate)
16. compare (immediate)*
17. load (immediate)
18. store (immediate)
19. load port (immediate)
20. store port (immediate)
21. output pin to 1 (immediate)
22. output pin to 0 (immediate)
23. input pin check (immediate)
24. branch on carry (displacement)
25. branch great than (displacement)
26. branch equal (displacement)
27. branch less than (displacement)
28. branch on pin (displacement)
29. jump (displacement)
30. no operation

*Compare instructions don’t have a destination. They subtract one value from another to see if they’re zero.

That would be about it for the description of the OZ-3. So far, I have simulated it at gate-level using a fantastic digital logic simulator called Logisim, by Carl Burch. Here’s a link to a video of it in action in said simulator: http://www.youtube.com/watch?v=MV-CK4Og2gA. This link is also in my sidebar. Other programs I’ve had this run in simulation include one in which it takes a joystick as the input and outputs a dot on an LED matrix according to the position of the joystick, a division subprogram, and one that displays a few animations one a 7-segment display according to which input pin is 1. The fastest I’ve been able to run the processor in simulation is a blazing 512 Hz.

So, where to next? An FPGA implementation. I’ve been working with an FPGA and VHDL for quite some time, so my coding skills are appropriate. Before I dive headlong into coding a system and complex as a 5-stage CPU, I plan on coding a far simpler processor, appropriately (and unimaginatively) called Test CPU 1. Funny thing is, I’ve already done that, too! I will make a post about it, but I’ve just completed it tonight and plan to move on to coding the OZ-3 sometime very soon.

Ben Oztalay

I found this cool video (below), provided by IEEE Spectrum Online the other day. Josh Romero, it’s narrator, must have experienced the robot revolution at this year’s NIWeek, as much of the video footage is taken from the Day 3 keynote. Here’s the full, extended version of Dr. Bewley’s talk about the work being done at the UCSD Coordinated Robotics Lab.

This small treaded robot can climb stairs with ease and balance itself on a point.

Josh brings up a good point in his video: automatic feedback control can be the difference between simple, ordinary robots and incredibly sophisticated dynamic systems. Take Switchblade, for example. The robot performs low-level control on a dedicated, embedded processor (in this case, a 2M gate FPGA on a SingleBoardRIO) to automatically balance itself on a point. There is an additional, real-time processor that performs additional tasks like maneuvering up a flight of stairs. With it being so small and having such a wide spectrum of mobility, it puts search-and-rescue robots like the PackBot to shame. See you at the top of the stairs, PackBot!

Ok, I take that back. Let’s avoid “shaming” PackBot. Please don’t shoot me, PackBot.

Stay tuned for a closer look at how Switchblade works in a future post.