A.L.S.E the FPGA Experts

High-Speed JPEG Video Encoder

2024-12-31T10:46:55Z

This is a “dual-core” version of our standard JPEG encoder.
It is still compact enough and efficient to fit in a very small low cost FPGA while allowing real time compression at higher resolutions than Full-HD at 60fps.
It has an option to generate a video stream optimized for GPU decoding ! This is a unique feature on the market, now tested and used on high-end commercial products.
This IP does not require any processor nor any external memory.

Purpose

This “Dual-Core” High-Speed Baseline JPEG Encoder (Compression) core is capable of encoding video on-the-fly while producing standard JPEG compressed format. Its “Dual-core” architecture doubles the compression speed as compared to our standard baseline JPEG Encoder. The use of JPEG compression allows using very small FPGAs without external memory, leading to very economical systems, and our dual-core architecture allows high resolution and frame rates compression on low cost FPGAs.

Architecture

ALSE HighSpeed (dual-core) JPEG Encoder

Easy to use

Our core is compact and implements standard interfaces, so it can be used easily either as a standalone block, or as part of a Platform Designer system (or equivalent).

Again : it does not require any embedded processor nor external memory. It is small and efficient enough to fit easily in low cost and small FPGAs, like in the Altera Cyclone and Agilex 3 families, or the Lattice FPGA families (eg ECP3, ECP5, Certus-NX, CertusPro-NX, Crosslink-NX, Mach-XO5 etc) or the Microchip FPGAs (Igloo 2 or Polarfire).

It fits (indeed) very well in higher-end families (Altera Agilex 5 or Agilex 7, Lattice Avant-X and Avant-G etc), thus offering the capability to support high resolutions and frame rates. Our simulation environment can be helpful to develop and the application that includes the JPEG encoder.

Main Technical characteristics

Speed and Area-Optimized encoder (dual-core) engine
Suitable for both still image and real-time video compression.
8 bits (byte) Streaming output interface with Backpressure. Easy to connect to the ALSE Ethernet communication engine for example. Output format is 8x8 YUV Blocks (4:2:2).
Option to generate a video stream optimized for multi-thread GPU decoding !
Supports any image resolution up to 64k x 64k.
Standard Huffman table.
Dynamically configurable Quantization tables (up to 8 tables) for multiple levels of compression and quality.
Dynamic choice of compression level (can be adjusted automatically).
Can be easily integrated in a complete video system using the ALSE “Block to Raster” module, a Memory Frame Buffer and a Video Output Controller (RGB outputs for VGA, LCD; YUV BT656, etc … )
Versatile. This IP can be used in all FPGA devices (internal memory blocks must indeed be available).
Compact.
Fast : excellent Fmax on all FPGA families.
First-class Technical Support (E-mail and Telephone, extended CET hours).
Customization to specific needs is possible.
Verification Environment with advanced test benches.

Best in class

Some ALSE IPs also exist in the competition, JPEG Codec is in this case. However, our IP offers unique characteristics and advantages.

More compact.
More efficient than the competition.
Faster (better Fmax).
Dual-engine version.
Optimized for multi-thread decoding (GPU) -encoder option-.

Demos available

We have many demos created for many FPGA boards.

JESD204

2024-01-20T23:57:38Z

JESD204 is the Data Converter Serial Interface standard that was created through the JEDEC committee, with the participation of all the industrial providers of high-speed ADC and DACs (including Ti, Analog Devices etc).

If you want to use High Speed ADCs or DACs in your project, you need an FPGA with transceivers and a JESD204 IP !

And ALSE has JESD204 IPs available for many FPGA families and vendors.

See our Reference Design documentation below.

Purpose

The first purpose of JESD204 is to provide the ability to transfer reliably Data at very high speeds, using as few wires as possible. Obviously, these requirements lead to using HSSLs (High Speed Synchronous Serial Links) i.e. Transceivers (SERDESes) and pairs of wires for low voltage differential signalling.

Beyond Data transfer, JESD204 provides services allowing an extremely precise knowledge of the samples position in absolute time (synchronization and time stamping in particular) which is compulsory and very critical when signals are acquired through multiple ADCs or formed using multiple DACs.

Principle

A JESD204B Interface involves Transceivers to transmit serially at very high speed parallel Data on one or several lanes. This is the PHY layer. It is based on the Transceivers of the FPGA you have selected.

The Link layer is the protocol (scrambling, encoding, character and lanes alignments, assembling…)

The transport layer deals with frames of data.

And in practice, a control & status registers interface will be available to monitor and control the IP.

Versions

The first standard widely adopted was JESD204B in 2011 (based on 8/10 encoding, offering deterministic latency)
To date, it is still the most used version.
JESD204C (based on 64/66 encoding) is becoming common for the latest converters.
And JESD204D is under way.

Multiple Challenges

You may think that finding a working IP is the main challenge. While it may not be very simple to make the right choice, you would be wrong if you don't anticipate the many other complex aspects of the task.

The JESD204B DACs, ADCs and support chips (like JESD204B Compliant PLLs) are extremely complex to parameterize and use. Just take a look at the LMK0482 PLL datasheet (128 pages) or the DAC38RF 147 pages.

Synchonization and dealing with latency can be challenging too.

For very high speed DACs & ADCs, there is another difficulty inside the FPGA to handle and process the extreme streams of data, often with multiple samples per beat.

If you have to deal with hardware and board design, with links up ti 12.5 Gb/s, there will be no room for the smallest error.

Dealing with transceivers is never trivial.

If you start struggling with your project involving JESD204B (or C), don't hesitate to contact ALSE.

ChipBridge (Chip-To-Chip)

2024-01-02T16:21:14Z

This IP is ideal to control a lot of peripherals from a centralized high-end (Master) FPGA (or ASIC) ! Connecting and controlling peripherals from the Master directly is typically difficult and inefficient : lack of support for 3.3V I/Os, level translators and ESD protections required, difficulty to modify the main FPGA to adapt to changes in the peripherals, Electrical and Safety concerns, PCB routing, and real estate issues…

Using a single transceiver and two pairs of signals, ChipBridge allows to extend the AXI4 mapping to an external FPGA while maintaining good access performance (latency) and bandwidth. The Slave FPGA can be low cost, low power, and robust.

ChipBridge is a “Chip-To-Chip” AXI4 connectivity solution allowing to displace peripherals to an external FPGA. This allows a Master System On Chip FPGA (or ASIC), typically with embedded processor(s), to transparently access peripherals connected to a Slave FPGA. In other words, ChipBridge can extend the AXI4 interconnect outside the main chip.

The first ChipBridge IP Core was developed on Lattice CertusPro-NX FPGAs using a high-speed (10G) transceiver through an ALSE Aurora Light 64B/66B IP for the physical interconnect. However, other physical streaming links (like LVDS) can be used.

Likewise this IP core targets mainly Lattice FPGAs but is compatible with most other FPGAs including Altera-Intel, AMD-Xilinx, Microchip and Efinix.

Note however that ChipBridge is not interoperable with AMD-Xilinx Chip-to-Chip IP.

The Datasheet is below.

Don't hesitate to contact us if you want more information on this IP.

Aurora 64B/66B IP Core

2019-11-10T14:39:46Z

Aurora 64B/66B is a lightweight and open protocol suitable for chip-to-chip, board-to-board and backplane applications using very high speed transceivers.

The ALSE Aurora 64B/66B IP core is a very compact and optimized but exhaustive implementation of this protocol, also developed and verified to ensure full compatibility with the Xilinx IP core (interoperability has been tested and demonstrated).

This IP is available on all the high-end Altera/Intel FPGAs (from Stratix V and Cyclone10gx to Agilex 3/5/7/9), but also for all other FPGA vendors including Lattice, Microchip and Efinix.

Last but not least, we have developed and delivered an ASIC version of our Aurora 64B/66B IP !

Compared to the 8B/10B version of the Aurora protocol, the 64B/66B flavor does address the highest lanes speeds (when 8B/10B typically stops at 6 GBs per lane).
It also offers an effective bandwidth of up to 97%, instead of 80% for 8B/10B.

Our Aurora64B/66B IP therefore provides an efficient way to interconnect Altera/Intel, AMD/Xilinx, Lattice, Microsemi/Microchip and Efinix FPGAs, or any other chip (ASIC, ASSP, etc …) using the public Aurora 64B/66B protocol.

Typical application

our IP supports all the Aurora-Protocol Features including :

Full implementation of Aurora protocol
Up to 16 lanes
Full-Duplex, Simplex Tx and Simplex Rx modes.
64-bits user datapath
Framing and Streaming interfaces
Up to 16 transceiver lanes per Aurora instance
User K-block interface
Native Flow Control
User Flow Control
Additional CRC for PDU frames
Clock compensation
Complete Interoperability with Xilinx Aurora 64 core
Per lane polarity inversion and skew compensation.
AXI and Avalon-ST Streaming compatible.
and much more…

Architecture

Aurora64 Architecture

Examples of Reference Designs platforms

Altera :

Agilex 7 kits
Agilex 5 Arrow Eagle kit
Agilex 5 Altera kit
Cyclone 10 GX dev kit
Arria10 Attila (ReflexCES)
Arria10 Achilles (ReflexCES)
Stratix10 GX Dev Kit
Cyclone V Clovis/AVDB
Cyclone V Clovis/AVDB
and many other boards…

Lattice :

Avant-G & Avant-X Versa boards
CertusPro Nx Evaluation board
CertusPro-NX Versa Board

Efinix :

Efinix Titanium development kit

Microchip :

Microchip Polarfire MPF300T development kit

and more …

Agilex 5 <-> Ultrascale+ 50G Demo

This demo is built using our Aurora 64B/66B Reference Design. Here is the architecture :

Demo Architecture

Note : if you don't have a Xilinx kit, you can run the demo on the Agilex5 kit with a QSFP+ loopback module.

The Guide to run the demo is here :

ALSE Aurora64 Agilex5 Demo User Guide

You can see the video here.

The programming (and probing) files are available here :

Demo_Agi5_devkit_2026

Agilex 5 kit programming and probing files

Examples of tested Aurora configurations - (not exhaustive !)

The table below shows tested configurations connecting a Xilinx-AMD FPGA and IP to an Altera FPGA through the ALSE Aurora IP. This demonstrates the interoperability between the IPs and FPGAs.

The table below shows some examples of ALSE Aurora 64 IP on Microchip FPGAs connected to Xilinx-AMD FPGAs.

Examples of ALSE Aurora 64 IP on Microchip FPGAs

The table below shows some examples of ALSE Aurora 64 IP on Lattice FPGAs connected to Xilinx-AMD FPGAs.

Examples of ALSE Aurora 64 IP on Lattice FPGAs

We have a similar tables for Efinix (Titanium) FPGAs.

HyperRam Memory Controller

2017-11-28T07:29:40Z

The HyperRAM memories, based on low-power PSRAM technology and using the recent HyperBus interface, are a very welcome addition to the traditional RAM memories portfolio : they have been optimized for Mobile and Automotive applications and are an excellent fit for many projects.

They provide good Bandwidth performance
The interface, known as “HyperBus”, offers a low signal count (Address, Command and Data using only eight DQ pins)
They offer Low Power consumption
Typical power consumption during burst read is about 60 mA only.
Efficient protocol, with Hidden Refresh mode, and various burst modes.
Most devices are available for Automotive Temperature range…

But… by the experience of many users, these memories are actually surprisingly complex to use reliably and efficiently with most existing controllers.

ALSE has designed an extremely efficient and versatile HyperRam Memory Controller providing high performance (up to 333 MBytes/s, which is 1.5 x times faster than a 16 bits PSRAM running at 108 MHz).
It is also extremely reliable while being compact. Our customers have compared and reported our controller as a clear winner.

Main Technical Features

High-Performance HyperRam Controller supporting Burst Mode for Read/Write transfers, to get optimized bandwidth and minimal switch fabric overhead.
Memory Operating Frequency typically up to 166 MHz or more, depending on FPGA and Memory speed grades, and (more marginally) on the customer PCB. This delivers a bandwidth up to 333 MBytes/s or more, with only 12 x IO pins (CS, Clk/Clk_n, DQS, DQ[7:0])
16 bits Slave Data Interface with Burst (and wrap) support. Typically, the Controller will serve a Master that can be a Nios II, Nios V, RiscV, Xilinx MicroBlaze, or another CPU, with or without caches, with or without Bursting.
Other hardware masters (like DMA engines) are of course also possible (e.g : Video streaming DMAs, Scatter-Gather DMAs, Frame buffers etc…)
16 bits Slave Register Interface to access HyperRAM memory registers (for configuring Output Drive Strength, Burst Wrap, etc…)
Burst Wrap mode support (for efficient transfer with caches).
Very low FPGA resource usage (Logic Cells and Memory Blocks)
Versatile : this IP can be used in most existing FPGA devices that have internal memory blocks.
Intel Platform Designer compliant, with an advanced configuration panel.
Highly configurable. A lot of options and settings are available to parameterize and optimize the controller.
Provided with sophisticated SDC Timing Constraints.
Comes with advanced Hardware Tester Reference Designs in source code. Allows to test and qualify custom boards . The testers are ready to use for several FPGA Design Kits :
Tested on the Xilinx Artix7 Trenz TE0725 kit
Tested on the Cyclone 10 LP FPGA Evaluation Kit
Transparent supports for dual-die HyperRam chips !
AXI4 support for Xilinx

Typical waveforms

Here is above a typical waveform of a Write access, with initial Latency.

hyper write

Here is above a typical waveform of a Read accesses, with initial Latency.

hyper read

Examples of supported Memories

ISSI IS66/67WVH8M8ALL/BLL - 64Mb
Cypress S27KL/S0641 - 64Mb
Cypress S70KL/S1281 - 128Mb
etc …

Aurora 8B/10B IP Core

2017-10-31T12:18:05Z

Aurora 8B/10B is an open, lightweight, high-speed, and low latency serial protocol suitable for chip-to-chip, board-to-board and backplane applications using Transceivers.
For AMD/Xilinx users, Aurora 8B/10B is available through the Xilinx Logicore IP for some FPGA families, but not all (in which case we can help) !
The ALSE Aurora 8B/10B IP Core makes Aurora 8B/10B available to all FPGAs (and potentially ASICs), including all Altera FPGAs with transceivers (Cyclone, Arria, Stratix, Agilex 3/5/7/9), Lattice FPGAs (CertusPro Nx, Avant-X, Avant-G), Microchip FPGAs (PolarFire, RTG4) and Efinix (Titanium).
Therefore, this IP provides an efficient way to interconnect an AMD/Xilinx FPGA (for example) with an FPGA from another vendor. Complete interoperability with the Xilinx IP is guaranteed.
It can also be used to interconnect two FPGAs from the same vendor together, in replacement of other proprietary or complex High-Speed Serial protocols (like Serial Lite IV or PCIExpress).
Or indeed two FPGAs from any vendor!
The Figure below shows a typical application of the ALSE AUrora 8B/10B IP linking an FPGA with an AMD FPGA:

Aurora Typical Application

All Aurora 8B/10B Protocol Features are supported including :

Full-Duplex, Simplex Tx and Simplex Rx Operation supported
Currently demonstrated at up to 6.6 Gbps (Gigabits per seconds) per Transceiver lane.
Higher bitrates are possible, depending on the Device Transceiver characteristics (max 8b/10b Encoder/Decoder Bitrate).
Up to 16 Transceiver lanes.
Framing and Streaming interface.
Payload Data User Frames (PDU)
User Flow Control (UFC).
Native Flow Control (NFC), in immediate and completion mode.
Additional CRC for PDU Frames
8b/10b Encoding / Decoding.
Clock Compensation sequence generation.
Per lane polarity inversion and skew compensation.
User datapath depending on number of lanes and 16bits/32bits mode per Transceiver lane. Examples :
-> in a x1 /32bits configuration, the user datapath is 32bits.
-> in a x4 /16bits configuration, the user datapath is 64bits.
-> in a x4 /32bits configuration, the user datapath is 128bits.

Note : we have also an Aurora 64B/66B IP core available for higher speeds !

Other Technical Features

All Altera FPGAs (with transceivers) are supported. _We support also other FPGA vendors (including Lattice, Microsemi/Microchip and Efinix).
AXI streaming / Avalon-ST compatible for User interfaces (PDU, NFC, UFC)
Very low FPGA resource usage : typically less than 1000 ALMs / 2 Memory Blocks for a Full IP in a x1 (1 lane) configuration
Provided with SDC Timing Constraints and QIP file for easy integration in Platform Designer.
Hardware Tester Reference Designs

Examples of existing Hardware Tester Reference Designs

Altera (Intel) :

Agilex 7 kits
Agilex 5 Eagle kit
Cyclone 10 GX dev kit
Arria10 Attila (ReflexCES)
Arria10 Achilles (ReflexCES)
Stratix10 GX Dev Kit
Cyclone V Clovis/AVDB
Cyclone V Clovis/AVDB

Lattice :

Avant G & Avant-X Versa boards
CertusPro Nx Evaluation board
CertusPro-NX Versa Board See our article and its Application Note.

Efinix :

Efinix Titanium development kit

Microchip :

Microchip Polarfire MPF300T development kit

and more …

PowerLink

2016-11-08T06:34:56Z

Introduction

After accumulating some experience with other Industrial Networks on FPGA, we converged on retaining only POWERLINK as well as our own Ultra-Low Latency Gigabit ring.

POWERLINK is a fast real-time field bus based on standard Ethernet. openPOWERLINK is an open-source implementation of this protocol, and comes with example designs targeting Intel (previously Altera) FPGAs.

Experience

Our experience with POWERLINK was very successful :

We quickly mastered the POWERLINK Slave Development Kit
We were able to build fully working slaves on very low cost FPGA boards (including the $25 BeMicroMax10 !)
The interaction with the openPOWERLINK maintainers was easy and productive.
B&R offers a serious support for Powerlink adopters.

Take a look at this presentation to find out more details about the systems we implemented.

Synchronous SRAM (SSRAM) Controller

2016-11-07T14:28:21Z

Low Latency is often very important in many fields such as cache-based products, broadcast, networking and communications applications, video streaming / video games, etc …
Synchronous SRAM memories are very good candidates for such latency-sensitive applications, thanks to their (very) low latency (typically one clock cycle), high performance.
Interfacing such memories to an FPGA is easy using the optimized ALSE controller. Thanks to its very small FPGA footprint and low resource usage, this controller fits in the smallest FPGAs, which makes it also perfect for the Automotive and Consumer Markets.

Main Technical Features

High-Performance Controller supporting Burst Mode for Read/Write transfers, to get optimized transfer speed and minimal switch fabric overhead.
Memory Operating Frequency typically up to 133 MHz, depending on FPGA and Memory speed grades, and (more marginally) on the customer PCB characteristics.
32bits Slave Interface (Avalon-MM based) with Burst support. Typically, the Controller will serve a Master that can be an Altera Nios II CPU (32bits), with or without caches, with or without Burst mode. A hardware master (DMA) is of course also possible (e.g : Video streaming DMAs, etc …)
Specific version of the controller for No Bus Latency memories, also called Zero Wait States memories (such as ISSI IS61NLF204836B / IS61NLF409618B, or Cypress CY7C1471BV33 / CY7C1473BV33), for 100% bandwidth utilization (no dead cycles)
Very low FPGA resource usage : less than 200 Logic Cells, and two memory blocks
Versatile : This IP can be used in all FPGA devices (Intel / Altera, Xilinx, Lattice, MicroSemi / Actel) having internal memory blocks.
Provided with sophisticated SDC Timing Constraints, Hardware Tester Reference Designs, etc…

Typical waveforms

SSRAM no bus latency waveform

Here is above a typical waveform of consecutive Read/Write accesses, with/without bursts, with Zero Wait state (no bus latency) and thus 100% bandwidth utilization. The clock can be up to 133 MHz here.

Examples of supported Memories

ISSI IS61LPS25632B
ISSI IS61NLF204836B/IS61NLF409618B
Cypress CY7C1471BV33 / CY7C1473BV33
etc …

Ultra Low Latency Network

2016-10-04T17:24:21Z

Introduction

Gigabit Ethernet over copper twisted pairs (1000BASE-T) is an ubiquitous, easy, and extremely reliable Physical Medium.
ALSE has developed a lot of experience around this technology, like the very innovative GEDEK communication kit (processor-less hardware stack) and allowed achieving reliably unprecedented data throughput. This technology has been used in hundreds of systems all over the world.

One of our clients expressed the need to build an architecture with up to more than 20 regulation and control boards interconnected together, and with a requirement that all boards should be updated with the regulation data from ALL OTHER boards during the first half of a single PWM cycle (targeted at 20 kHz). In other words, all the boards should see all the other board's data in no more than 25 micro-seconds.

Another requirement was the ability to implement redundancy.

Quite naturally Gigabit Ethernet comes to mind to implement the inter-boards communication.
However, even under underestimated conditions (20 slaves, 20 kHz, no redundancy), 40 Ethernet frames must circulate in much less than 25 µs. This simple calculation shows that a standard (store-forward) architecture, even with a near zero delay (like GEDEK) would be outperformed by a ratio greater than four !

Are existing solutions available ?

We conducted a careful pre-study and reached the conclusion that NO SOLUTION existed in the market that reached only a fraction of the performance required !

The table below, extracted from a very interesting article about Industrial Ethernet shows the state of the art.

[table]

Industrial Ethernet standards Cycle Time

Our solution

We use completely standard IEEE 802.3-2008 Ethernet frames.

We implement a “circular” bi-directional (dual) ring. Two frames circulate in opposite directions for a full turn, thus already implementing a first redundancy.

We use the Cut-Through Forwarding technology in our own optimized switch to reach an absolute minimal latency.

We use the Summation Frame method (each node adds it's own data in a slot of the circulating frame).

We use a fully Hardware implementation, thus removing any software interaction or limitation to the performance. In Hardware, decisions can be taken in less than 10 nanoseconds (ie practically at each incoming byte in the GbE link), with no jitter.

We re-used (and customized) our optimized and well proven Gigabit-only MAC (Media Access Control).

Note : We have implemented several clever optimizations to further reduce our cut-through switch latency. The details are only available after signing an NDA.

Network Topology

The figure below shows 9 boards connected together, one of which being the Master.

Network (ring) Topology

Test System

We have used 9 DE2-115 FPGA kits attached together mechanically to form a “tower”. See picture below. The DE2-115 (used in some Training courses) was available and it comes with two GBE interfaces (Marvell 88E1111 PHY).

This setup allows to practically measure with great precision the achieved latency in realistic conditions (including the delays in the Marvell Gigabit PHYs). The results were extremely close to our simulations.

Tower of DE2-115

Complementary tools

We have developed an “Embedded Sniffer” : a special version of the Master forwards all (or some) circulating frames to another (3^rd) Ethernet port for analysis with a PC using Wireshark, without disturbing the Ring network.

Conclusion

Our technology (based on an optimized ultra-low latency Gigabit Ethernet cut-through switch) can enable a new range of industrial applications that were not feasible so far.

If your system consists of several boards that need to communicate with each other and exchange data with very small delays and latency, our technology may help you. Do not hesitate to Contact us

Quad SPI Controller

2016-09-27T15:06:28Z

For an FPGA-based project, replacing bulky, pin-consuming, and complex Parallel Flash Memories by modern Quad-SPI Flash devices is very exciting in many respects.
It drastically reduces the FPGA pin count and thus enables smaller (and cheaper) packages. It also reduces the power consumption, minimizes the PCB area & complexity, reduces the BOM, while providing good transfer speed, etc…

The major issue against Quad SPI memories is that Parallel Flash Memories are usually much simpler to interface with, and may even not require any specific controller (though this is less and less true).

At A.L.S.E, we have taken into account this growing demand and we have developed an extremely efficient and compact (yet affordable) Quad-SPI Controller, which has already been adopted by many customers, especially in the very demanding and competitive field of Automotive Equipment Manufacturers.

Main Technical Features

High-Performance Controller !
In some applications, we have seen boot time reduction by a factor of more than 20x !
Supports Burst Mode transfers for optimized transfer speed and minimal switch fabric overhead.
Takes fully advantage of the multi-lanes (x4) capability.
Transfer speed up to 52MBytes/s (Quad SPI clock up to 104 MHz) or more, depending on FPGA and QSPI Memory type and speed grades.
Quad IO Programming (x4) is also supported

Versatile

This IP can be used in all FPGA Altera devices (including MAX / MAXII families, since no memory blocks are needed in some configurations). For other FPGA vendors (Xilinx, Lattice, MicroSemi/Actel), please contact ALSE.
We support most Flash Vendors & types (Winbond, Spansion, Numonyx, Micron…).
Support the latest densities, like 256MBits/512MBits/1Gbits (4 bytes-address mode)
Includes Clock Domain Crossing Management for best area and transfer speed results.
Special “Direct Command Mode” available to access Quad SPI low-levels commands directly from the Avalon Master interface, allowing memory specific operations as Lock/Unlock, Read of Status Registers, Flash ID, Software Reset, etc …
Support of the additional QSPI Hardware Reset pin for Flash supporting it
Multi-chip management. An option allows to parallel two QSPI Flash devices (with an extra CS signal) to double the storage space. Ask ALSE for this.
Modular: Embedded programming can be activated or deactivated, for security reason or for area minimization purpose. FIFO depths can be easily adapted regarding customer FPGA constraints.

Simple Interface

32bits Slave Interface (Avalon-MM) with Burst support.
Typically, the Controller will serve a Master that can be an Altera Nios II CPU (32bits), with or without Caches, with or without Burst mode.

A hardware master is of course also possible so this controller can also be used without an embedded processor.

Compact !

The area can be trimmed down to less than 600-700 Logic Elements, and even 0 (zero) internal memory block.
Partial Transparent CFI Flash Emulation (a very special feature developed by ALSE), designed and optimized to be compliant with Altera nios2-flash-programmer. This option greatly facilitates the adoption of the Quad-SPI as a replacement of standard CFI Parallel Flash memories (programming is essentially the same as for Parallel Flash devices).
Easy integration in Altera Qsys or manually (no processor in system)
Delivered with sophisticated SDC Timing Constraints, and Hardware/Software Reference Designs, etc…

Device Support

Examples of supported Quad-SPI Memories :

Spansion / Cypress S25FL129P, S25FL512, etc …
Micron M25Q256 etc…
Macronix 25L256 etc…
Winbond W25Q80, W25Q16, W25Q32, etc …
Numonyx N25Q256, N25Q512, etc …
etc …

Even if your specific Flash is not supported (to be verified), ALSE could easily add it to the list.