Difference between revisions of "Fpgalafw"
Line 16: | Line 16: | ||
** Advanced triggering becomes hard when every manufacturer has a different trigger model. We can implement one to cover a variety of devices. | ** 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. | * Unlock previously unsupported device features. If a feature is added to one LA, it is added to all. | ||
* Would enable support for more more analyzers such as the [[RockyLogic Ant8]], the [[RockyLogic Ant18e]], the [[ChronoVu LA8]] etc. | |||
== Components == | == Components == |
Revision as of 13:38, 19 April 2013
This is a preliminary design
fpgalafw is a proposal for a project to implement a universal logic analyzer 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
- 2008 - openVeriFLA
- 2009 - miniLA
- 2010 - BitHound (Derrived from SUMP but with Ethernet interface)
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 more analyzers such as the RockyLogic Ant8, the RockyLogic Ant18e, the ChronoVu LA8 etc.
Components
fpgalafw will not work as a monilithic 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 permutation of different modes and options that can be enabled or disabled in 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.