Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - DavidFrancis

1
Client software / Re: RLE channel groups
Quote
I recall from my own tests with a 100MHz source that it wasn't necessary to multiply the count value by 2... I'll verify it again this

It is not valid to test the 200MHz mode with a 100MHz clock as the counts are not used.
To test correctly a much lower frequency should be used and this will show that the 2 times multiplication  is required.
2
Client software / Re: RLE channel groups
I have just found time to check out the latest GIT.
I have found the reasons for problems with 200MHz capture.

Lines 215/6 The second word does not use msb as flag but is used as data so the second rleCountMask is not required.
Also the count value should be doubled as it is based on 100MHz capture rate.

Lines 221 to 230 it is valid and essential to have a count if the previous value is zero.


I suggest :-
Code: [Select]
        if ( ( normalizedSampleValue & this.rleCountValue ) != 0 )
        {
          final int count;
          if ( ddrMode && ( i < ( samples - 1 ) ) )
          {
            // In case of "double data rate", the RLE-counts are encoded as 16-
            // resp. 32-bit values, so we need to take two samples for each
            // count (as they are 8- or 16-bits in DDR mode).
            // This should also solve issue #31...
            // The second word does not have msb set so second word does not need mask
            count = (( ( normalizedSampleValue & this.rleCountMask ) << shiftBits )
            | ( normalizeSampleValue( this.buffer[++i] ) )) * 2;
          }
          else
          {
            count = ( normalizedSampleValue & this.rleCountMask );
          }
//          if ( oldSample > 0 ) // XXX
//          {
            time += count;
//          }
//          else
//          {
//             LOG.warning( "Ignoring RLE count without preceeding sample value: " + Integer.toHexString( count ) );
//          }
        }
I also noticed that in Lines 846 and 856 you have substituted  <<2 for *8.
As << has a lower precedence it give an incorrect result.

A better way would be :-
Code: [Select]
    if ( this.config.isDoubleDataRateEnabled() )
    {
      // 0x7fff8 = 511Kb = the maximum size supported by the original SUMP
      // device when using the demultiplexer...
      final int maxSize = 0x7fff8;
      size = ( ( stopCounter & maxSize ) << 13 ) | ( ( ( readCounter & maxSize ) >> 3 ) - 1 );
      // A better approximation of "(readCounter - stopCounter) - 2". This also
      // solves issue #31...
      this.trigcount = ( ( ( size & 0xffff )  - ( ( ( size >> 16 ) & 0xffff )) )<< 3  );
    }
    else
    {
      // 0x3fffc = 255Kb = the maximum size supported by the original SUMP
      // device...
      final int maxSize = 0x3fffc;
      size = ( ( stopCounter & maxSize ) << 14 ) | ( ( ( readCounter & maxSize ) >> 2 ) - 1 );
      // A better approximation of "(readCounter - stopCounter) - 2". This also
      // solves issue #31...
      this.trigcount = (  (( size & 0xffff )   - ( ( ( size >> 16 ) & 0xffff ))) << 2  );
    }
I also found that the upper two groups must be deselected when using DDR mode.
I hope this helps

edit: added code blocks for better readability...
3
Open Bench Logic Sniffer / Re: Trigger problem under Demon Core
A quick way to simulate pre trigger capture is to use the complex basic trigger and set stage one to trigger on the required channel but with a delay set to the pre trigger count value  and set the second stage to trigger on the required channel. If edge triggering is require a third stage can be used.
5
Client software / Re: 200Mhz RLE mode
The idea of  200MHz is to store two 16 bit samples in each 32 bit sample, the second 16 bits taken at 5ns later than the first. The Sump client was set to request half the number of required sample but at 32 bit  and read each  as two  16 bit samples. As it  did not handle RLE for 200MHz. there was no requirement for counts. Version 6 still treats 16 bit 200MHz samples as 32 bits and hence outputs 32 bit counts. The count value needs to be build from two of the 16 bit samples. An alternative would be to treat 200MHz as 32bit and divide the data into two in the decode routine. This would need to be done for both RLE and non RLE and would require a lot of changes to existing code. 8 bit samples at 200MHz are treated as 16 bit samples in a similar way.
6
Client software / 200Mhz RLE mode
I have been looking at the 200 MHz capture problems and have found answers to most.
I attach a modified LogicSnifferDevice.java file which is based on a version from the Git on 14 th Feb. I was unable to get the latest version to run with all the drop boxes working.
The attached file is a bit messy as some of the changes would possibly better handled in the config settings.
It will now allow 200Mhz captures  in 8 or 16 bit normal or 7 and 15 bit with RLE on. The 8/7 bit captures can  be either group of the lower two.

I have also modified the trigger point to work with the verlog6 bitstream. This is one place where there may be differences with other bitstreams. This could be improved once other bitstreams are identified.

One thing is frequency measurement in 200MHz is hit or miss due to the noise problem.
Generally  frequency measurement is more accurate with the higher clock to signal ratio which for lower frequencies are better provided by RLE. 

I hope you find this useful.
7
Client software / Re: 200MHz sampling rate
I made a mistake in my last message I had the trigger set on the clock and not the data so it was triggering  early before the buffer had filled giving the wrong impression.
sorry for that.
8
Client software / Re: 200MHz sampling rate
I just did a quick check and it seems sampling rate before the trigger is different to that before. I seems to be 100MHz before trigger regardless of what is selected.
9
Client software / Re: Virtual "GND"
I agree that a method to turn off channels from the display would be useful, it is not a substitute for earthing unused inputs. Floating inputs especially when probe cables are attached will add extra events which will reduce the recording time when RLE is used.
Unused channels need to be disconnected int the FPGA to give full benefit.

I have found that when I have used the probe cable I had connect all unused channels to a piece of earthed bare wire before I was able to capture all the signals I was looking at.
10
Client software / Re: RLE and Verilog core
ols_verilog_mata5 Looks OK now. Tested it with firmware 2.6 and Jawi's client 0.9.3.1.
Just one question what memory depth does 24 bit use 6k or 8k?
11
Client software / Re: RLE and Verilog core
I tested ols_verilog_mets4 and it gives correct results with Jawi's latest 0.9.3 client.
I also tested it with the OLS 2.06 client which also gives correct results.

One small point 24 bit captures still have the most significant byte as zero.
12
Client software / Re: RLE and Verilog core
To Dogsbody as I pointed out earlier I have not found any client including Jawi's which requires inclusive counts (mode 0).
Some of the earlier Jawi's clients had bugs in the rle decoder which just may have given better results with inclusive counts but that was a fluke and even then the results were not accurate.

Jawi's latest client ols-0.9.3 specifically selects mode 1 but will work with modes 2 0r 3 if a selection method is provided.

To make the verilog bitstream compatible with all previous clients both mode 0 and mode 1 should provide exclusive count.
13
Client software / Re: RLE and Verilog core
I have now tested 3 alternative bitstreams which are :-
1 2.12 Dynamic
2 Rasmus newrle_0.0.7
3 Dogbody's verilogv5 (RLE mode 1)

I used a test program which dumps the raw data and is set to send the rle mode 1 bits for all tests.
The results in the attached spread sheet show that all three behave in the same way. Slight differences in the 10MHz values are from jitter on the input as the signal I was using had a slow rise time (10us). A further test  with the program set to rle mode 0 resulted in the count for 10MHz clock of 100018. (verilog only)
All previous clients I have tested give good results with the first two bitstreams but show counts too high using verilog version.

I therefor think that making RLE mode 1 the default is the best option. New clients can then use meta data to customize its operation to match the newer bitstreams if necessary.

One area where I have found slight differences is in the trigger point indicator. This is done by using the counts which are sent to ols divided by 4. It depends if the data at the calculated trigger position is a count or data.
With rle data a difference of one can mean many clock periods (to the next or previous change in data).
14
Client software / Re: Jawi's Logic Sniffer client software - releases and requ
I agree using mode 2 would be better normal use as it does show static levels provided memory depth is set above 256. Now that a stop command is provided it is not so important to have these smaller memory depths.

All my tests indicate that RLE mode 1 is compatible with earlier bitstreams. Counts are lost when using mode 0 with earlier clients.
15
Client software / Re: Jawi's Logic Sniffer client software - releases and requ
Just tested 0.9.3-b7 with dogbody's latest bitstream and have 3 minor mods I suggest.
1) to change initialization of oldSample line 195 from 0 to -1 this will ensure first sample is output
2) to remove  -1 from line 219 'i>= this.trigCount -1'  the trig position was out by 1 sample
3) to change initialization of FLAG_RLE line 345 from 0x00004100 to 0x0000C100 this will set it to  use rle mode 3

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01432445992session_write_close ( )...(null):0
20.01462577584ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01462578360Database_MySQL->query( ).../DatabaseHandler.php:119
40.05682717096Database_MySQL->error( ).../Db-mysql.class.php:273