Now that people are receiving their OLS boards it is time to get serious about updates. Some people have posted bugs at the project page: http://www.gadgetfactory.net/gf/project ... c/tracker/ (http://www.gadgetfactory.net/gf/project/butterflylogic/tracker/). We will try to address the bugs as we make improvements.
To start I was thinking the goal would be to work towards a single bitstream. Currently there are 6 different bitstreams depending on what numbering scheme you want to use and what sample depth/how many channels you want. We should be able to add new modes to the vhdl core that are controlled by the Java application for these options. This will allow us to get down to one bitstream which will be much more convenient.
So here are the list of tasks I'm going to start with:
-Get the java client checked into svn so we can start making/tracking changes. (Easy)
-Add an option to allow the numbering scheme to be selected.
-Requires a new mode in the vhdl core. (Easy)
-Requires a new item in the options page of the Java Client. (Easy)
-Requires visual feedback on the bottom bar letting you know which numbering scheme is selected. (Not sure? probably Easy)
-Consolidate all memory options into one bitstream.
-Requires a complete rework of the vhdl core. It should be similar to what is done for the 200Mhz mode but in the opposite direction. (needs more study of vhdl code. most likely Moderate-Hard)
-Java client needs to send a configuration string to the core when channel groups are deslected. It should also update available sample depths based on how many channel groups are selected.
-Java client needs to give visual feedback of which mode is selected. (Easy-Moderate)
-We also need to take into consideration the 200Mhz sampling mode and RLE for each sample depth. I haven't studied the RLE code much yet but my first thought is that we might be able to move the RLE data to the parity bits of the BRAMs. (Moderate)
Jack.
Once, there is a VHDL code for all bit-depths, the "numbering scheme" could be SW thing only (swapping bytes as they come from usb). This would simplyfy the vhdl model and improve latency by not adding another (de)mux.
I just checked in some changes and a tar file that contains a test release with the first changes.
Changes:
-Adds Number Scheme dropdown box to the Sump Java Client
-Adds Test Mode under Number Scheme dropdown box. Connect a ribbon cable between the 2 ribbon cables to test all channels.
-Adds two new flags to the VHDL core for Test Mode and Alt Number Scheme
I haven't done a lot of testing yet but thought I would put it out there if anyone wants to check it out.
http://gadgetforge.gadgetfactory.net/gf ... r&view=log (http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2FTestReleases%2F2.01TestRelease.tar&view=log)