Difference between revisions of "Fpgalafw"
Line 135: | Line 135: | ||
*** /nexys2 | *** /nexys2 | ||
*** /papilio ... | *** /papilio ... | ||
** / | ** /rtl | ||
*** /host-interface | *** /verilog | ||
**** /cypress-fx2 | **** /host-interface | ||
***** /software | ***** /cypress-fx2 | ||
***** /firmware | ****** /software | ||
**** /sump | ****** /firmware | ||
***** /firmware | ***** /sump | ||
***** .... | ****** /firmware | ||
*** /storage | ****** .... | ||
**** /ddr2 | **** /storage | ||
***** /firmware | ***** /ddr2 | ||
**** /bram | ****** /firmware | ||
***** /firmware | ***** /bram | ||
****** /firmware | |||
** /tools | ** /tools | ||
*** # Scripts etc in here | *** # Scripts etc in here | ||
** /sw | |||
*** # 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. |
Revision as of 17:33, 4 May 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:
- 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)
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
|
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, 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).