Difference between revisions of "Fpgalafw"
(One intermediate revision by one other user not shown) | |||
Line 3: | Line 3: | ||
'''fpgalafw''' is a proposal for a project to implement a universal logic analyser firmware for use as a firmware for commercial logic analysers that we wish to support, on FPGA development boards and for use as an in-circuit, or even in-FPGA debugging tool. | '''fpgalafw''' is a proposal for a project to implement a universal logic analyser firmware for use as a firmware for commercial logic analysers that we wish to support, on FPGA development boards and for use as an in-circuit, or even in-FPGA debugging tool. | ||
== Benefits == | |||
* Would simplify the implementation of libsigrok. | |||
** Reduced repetition. | |||
** Advanced triggering becomes hard when every manufacturer has a different trigger model. We can implement one to cover a variety of devices. | |||
* Unlock previously unsupported device features. If a feature is added to one LA, it is added to all. | |||
* Would enable support for more analysers such as the [[RockyLogic Ant8]], the [[RockyLogic Ant18e]], the [[ChronoVu LA8]] etc. | |||
== Goals == | |||
* 100% open-source Verilog implementation (written from scratch or based off of other open-source projects). | |||
* Portable Verilog implementation that works (as much as possible) in a generic way. | |||
** Should work across all common FPGA/CPLD families from various vendors, including Xilinx, Altera, Microsemi/Actel, Lattice, etc. | |||
** Should work for any suitable FPGA/CPLD based logic analyzer board (existing devices or future ones than can be built specifically for use with this project), and any suitable CPLD/FPGA eval boards. | |||
** This means that the use of vendor-/family-specific constructs are discouraged in the "core" of the code. There might be optional per-device or per-vendor constructs that are not portable, but those should be moved outside the "core" so that as much functionality as possible works for any device. | |||
== Previous Projects == | == Previous Projects == | ||
There are various pre-existing open source firmware projects that can be drawn upon: | There are various pre-existing open source firmware projects that can be drawn upon: | ||
* 2004 - [http://www.freepcb.com/eebit/ eebit] | * 2004 - [http://www.freepcb.com/eebit/ eebit] | ||
* 2006 - [http://www.sump.org/projects/analyzer/ SUMP] (written in VHDL) | * 2006 - [http://www.sump.org/projects/analyzer/ SUMP] (written in VHDL) | ||
Line 15: | Line 33: | ||
** [http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FVerilog_Core%2F Demon Core Verilog Source Code SVN] | ** [http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FVerilog_Core%2F Demon Core Verilog Source Code SVN] | ||
== | == Status == | ||
Some intitial work has been done, but the project is not really started yet. The current best branches are | |||
* | * Joel Holdsworth's work on the demon core: https://github.com/jhol/butterflylogic | ||
* Iztok Jeras's work on the demone core: https://github.com/jeras/butterflylogic | |||
* | |||
== Components == | == Components == | ||
fpgalafw will not work as a monolithic single firmware. Rather it is a library/framework of components that can be assembled together depending on the capabilities of the device, and the mode of operation. | fpgalafw will not work as a monolithic single firmware. Rather it is a library/framework of components that can be assembled together depending on the capabilities of the device, and the mode of operation. | ||
Line 126: | Line 143: | ||
== Project Folder Structure == | == Project Folder Structure == | ||
Proposed project folder structure... | Proposed project folder structure... | ||
* / | * / | ||
** README | ** README | ||
Line 153: | Line 172: | ||
** /sw | ** /sw | ||
*** # Embedded sofware here | *** # Embedded sofware here | ||
== Firmware Packaging == | == Firmware Packaging == | ||
Each device class will be given a firmware package that the driver can load. This package will be ZIP-file containing multiple firmware .bit files for the different permutations of modes and options that can be selected on this device. It is undesirable to have a single universal hardware file for each device, because multiple features will compete for use the limited number of logic units and internal storage. | Each device class will be given a firmware package that the driver can load. This package will be ZIP-file containing multiple firmware .bit files for the different permutations of modes and options that can be selected on this device. It is undesirable to have a single universal hardware file for each device, because multiple features will compete for use the limited number of logic units and internal storage. | ||
The firmware package will contain a text index file that indicates the capabilities of the device, its Bus ID, and a list of the firmware files available. | The firmware package will contain a text index file that indicates the capabilities of the device, its Bus ID, and a list of the firmware files available. | ||
== Firmware Build Environment == | == Firmware Build Environment == | ||
The firmware will be built using a GNU Make driven build environment, which will be compatible with Altera, Xilinx, Lattice tools, and FreeHDL etc. | |||
The firmware will be built using a GNU Make driven build environment, which will be compatible with Altera, Xilinx, Microsemi/Actel, Lattice tools, and FreeHDL etc. | |||
== Protocol == | == Protocol == | ||
We will implement a common command protocol, common among all the host interfaces. (With the possible exception of SUMP if we plan to support that). | We will implement a common command protocol, common among all the host interfaces. (With the possible exception of SUMP if we plan to support that). |
Latest revision as of 10:09, 6 December 2013
This is a preliminary design
fpgalafw is a proposal for a project to implement a universal logic analyser firmware for use as a firmware for commercial logic analysers that we wish to support, on FPGA development boards and for use as an in-circuit, or even in-FPGA debugging tool.
Benefits
- Would simplify the implementation of libsigrok.
- Reduced repetition.
- Advanced triggering becomes hard when every manufacturer has a different trigger model. We can implement one to cover a variety of devices.
- Unlock previously unsupported device features. If a feature is added to one LA, it is added to all.
- Would enable support for more analysers such as the RockyLogic Ant8, the RockyLogic Ant18e, the ChronoVu LA8 etc.
Goals
- 100% open-source Verilog implementation (written from scratch or based off of other open-source projects).
- Portable Verilog implementation that works (as much as possible) in a generic way.
- Should work across all common FPGA/CPLD families from various vendors, including Xilinx, Altera, Microsemi/Actel, Lattice, etc.
- Should work for any suitable FPGA/CPLD based logic analyzer board (existing devices or future ones than can be built specifically for use with this project), and any suitable CPLD/FPGA eval boards.
- This means that the use of vendor-/family-specific constructs are discouraged in the "core" of the code. There might be optional per-device or per-vendor constructs that are not portable, but those should be moved outside the "core" so that as much functionality as possible works for any device.
Previous Projects
There are various pre-existing open source firmware projects that can be drawn upon:
- 2004 - eebit
- 2006 - SUMP (written in VHDL)
- 2008 - openVeriFLA
- 2009 - miniLA
- 2009 - LeKernel's Logic Analyser
- 2010 - BitHound (Derived from SUMP but with Ethernet interface)
- 2011 - OpenBench Logic Sniffer (Derived from SUMP, ported to Verilog)
Status
Some intitial work has been done, but the project is not really started yet. The current best branches are
- Joel Holdsworth's work on the demon core: https://github.com/jhol/butterflylogic
- Iztok Jeras's work on the demone core: https://github.com/jeras/butterflylogic
Components
fpgalafw will not work as a monolithic single firmware. Rather it is a library/framework of components that can be assembled together depending on the capabilities of the device, and the mode of operation.
Host Interface
|
Storage
|
Data Packer
|
Indicator LEDs
|
Operating Modes
|
Triggering
|
Project Folder Structure
Proposed project folder structure...
- /
- README
- NEWS
- Makefile
- /boards
- /openbench-logic-sniffer
- /nexys2
- /papilio ...
- /rtl
- /verilog
- /host-interface
- /cypress-fx2
- /software
- /firmware
- /sump
- /firmware
- ....
- /cypress-fx2
- /storage
- /ddr2
- /firmware
- /bram
- /firmware
- /ddr2
- /host-interface
- /verilog
- /tools
- # Scripts etc in here
- /sw
- # Embedded sofware here
Firmware Packaging
Each device class will be given a firmware package that the driver can load. This package will be ZIP-file containing multiple firmware .bit files for the different permutations of modes and options that can be selected on this device. It is undesirable to have a single universal hardware file for each device, because multiple features will compete for use the limited number of logic units and internal storage.
The firmware package will contain a text index file that indicates the capabilities of the device, its Bus ID, and a list of the firmware files available.
Firmware Build Environment
The firmware will be built using a GNU Make driven build environment, which will be compatible with Altera, Xilinx, Microsemi/Actel, Lattice tools, and FreeHDL etc.
Protocol
We will implement a common command protocol, common among all the host interfaces. (With the possible exception of SUMP if we plan to support that).