Difference between revisions of "Fpgalafw"
Line 12: | Line 12: | ||
* 2010 - [http://www.bastli.ethz.ch/index.php?page=BitHoundEn BitHound] (Derived from SUMP but with Ethernet interface) | * 2010 - [http://www.bastli.ethz.ch/index.php?page=BitHoundEn BitHound] (Derived from SUMP but with Ethernet interface) | ||
* 2011 - [http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer OpenBench Logic Sniffer] (Derived from SUMP, ported to Verilog) | * 2011 - [http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer OpenBench Logic Sniffer] (Derived from SUMP, ported to Verilog) | ||
** [http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2FVerilog_Core%2F Demon Core Verilog Source Code SVN] | |||
== Benefits == | == Benefits == |
Revision as of 17:29, 19 April 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.
Previous Projects
There are various pre-existing open source firmware projects that can be drawn upon:
- 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)
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.
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
|
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, it's 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, 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).