These goals all look very good. Regarding the test suite, one thing I've been thinking of that could help a lot with designing test benches is to invest in some code (or blocks) for the tedious boiler plate that is often needed for this work. One extremely useful function would automatically extract sync in and sync out signals and then break out the associated frames of input and output data for comparison with expected results. Similarly, a test input generator that would take a frame of data and create an appropriately demultiplexed array and a sync signal to feed into a block using "from workspace" or the like. The basic goal is to make it easier to check the input/output relationship of a block without having to deal with things that don't matter like demux factor and overall latency.
Glenn On Mon, Oct 17, 2011 at 6:03 AM, Andrew Martens <[email protected]>wrote: > Hi all > > Various working groups were formed at the 2011 CASPER workshop. One of > these were for the toolflow, > libraries, software etc. Various decisions and actions were decided. This > is a list. > > 1. Test Suite > > The current library test suite is to be updated. The current bit-for-bit > tests will continue to > be used where appropriate and new tests developed to test data quality for > other, especially high-level, blocks. Examples for these test types would > be accumulators for bit-for-bit > tests and FFTs for performance tests. Each block added to the library would > need to have associated > to allow proof of correct operation and any bug fix should include a test > that would expose this bug in > future which might be added to existing tests. Any changes/fixes to library > blocks will require that the > appropriate tests be run and correct operation proved before changes are > made to the main repository. > > 2. Github > > The main CASPER library repository will be moved to github. > > 3. More frequent mailing list updates on library work > > Work on the libraries and toolflow will be communicated more often to the > CASPER community via > the mailing list. Information on bugfixes or large improvements/changes > will be sent out immediately. > A list of smaller changes will be sent out once the list is long or after a > month or so has elapsed. > > 4. Move to more recent Xilinx/Matlab distribution > > The recommended Xilinx/Matlab distributions will be updated in the next few > months. > > 5. BORPH > > A memory mapped interface will replace BORPH in tcpborphserver. This should > improve performance > when using katcp. BORPH will continue to run for those running code > natively on the PowerPC. This > change should not be noticeable (besides higher performance). > > 6. xBlocks > > There is a large ongoing effort in moving the DSP libraries to xBlocks. > Included in this are significant optimisations > in terms of resource usage. Development in mlib_devel will be frozen and, > once sufficient testing is > performed using the new test suite, the mlib_devel library will be > deprecated in favour of the xBlocks based > library. > > 7. git FAQ > > A git FAQ wiki page is to be set up, serving library developers especially > > 8. Error coverage > > Parameter type and range checking is to be more intensively implemented. > > 9. Deprecated libraries/blocks > > The gavrt library and other blocks are to be deprecated and useful blocks > extracted to the xBlocks library. > > 10. New toolflow > > As an initial move to a new toolflow, a library of primitives is to be > created in verilog. This will be > used as the basis in the future toolflow. > > Regards > Andrew > > > > > >
