Saanlima Forums

Support for products from Saanlima Electronics
It is currently Sat Dec 16, 2017 3:44 am

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Apr 30, 2014 1:15 pm 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
I just wanted to let you know I have been working on adding support for Pipistrello OLS in sigrok and pulseview.
Sigrok and the gui frontend PulseView is a very actively developed open-source interface for all kinds of logic analyzers, scopes, multimeters etc.
See: http://www.sigrok.org

sigrok-cli is the command-line version and pulseview is a Qt-based GUI frontend. Pulseview still has a way to go to be complete (it still misses trigger setup) but the drawing part is amazingly good and very fast (it handles 16 Meg 32-bit samples flawless). It's developed on linux but you can cross-complie for windows.

If you want to give it a try on windows here is how to get it installed. The tricky part is that you need to change the USB driver for the board to libusb-win32. I admit this is somewhat scary but it worked for me using the filter driver and I can still access the board via the FTD2xx driver for other use (like fpgaprog) etc., but you do this on your own risk. For more info in this see: http://www.sigrok.org/wiki/Windows

Steps (this assumes you have the fifo-version of the OLS code loaded on Pipistrello and the board is set to use FTDI fifo mode):

1) Download and run the pulseview installer from here: http://www.saanlima.com/download/pulseview-0.2.0-installer.exe
2) Connect the Pipistrello board to the computer
3) Go to c:\Program Files (x86)\sigrok\PulseView and run zadig.exe
4) In the Zadig GUI select "Options -> List All Devices
5) Select "Pipistrello LX45 (Interface 1) " as the device. You should see USB ID as 0403:6010:01
6) Change the new driver from WinUSB to "libusb-win32"
7) Next to the "Replace Driver" button there is a pulldown menu marked by an arrow. Pull it down and select "Install filter driver"
8) Click on "Replace Driver". There is a warning popping up, select OK.
9) Run Pulseview from the start button. It should come up with demo device selected. Change device to Pipistrello OLS.
10) Next to the device pulldown button there is now a new button marked with a screwdriver and wrench. Click on it and select "External" as the pattern.
11) Change the sample rate to 100 MHz and click on the Run button. After about a second you should see the traces show up with the test pattern on ch 16 - 31.

For Linux you have to compile from sources. See http://sigrok.org/wiki/Linux for info on building it on Linux.
My source code for libsigrok with Pipistrello OLS support is available at github:
https://github.com/magnuskarlsson/libsigrok

My verilog source for the Pipistrello OLS is also available at github:
https://github.com/magnuskarlsson/Pipistrello_ols_verilog

Bit files (and a complete Xilinx ISE project) can be found here:
http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M_fifo_05282014.zip
See the README file in the zip archive for more info.

Magnus


Last edited by magnus on Wed Jun 25, 2014 7:15 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Mon Jun 23, 2014 12:28 pm 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
Here is a screen snapshot of PulseView:

Image


Top
 Profile  
 
PostPosted: Wed Jun 25, 2014 8:24 am 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
The latest update to the Pipistrello OLS project also extends the triggering to support edge triggers in JaWi's SUMP client. You can get it here:
http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M_fifo_05282014.zip
See the README file in the zip archive for more info.

Below is a screen shot that shows the edge trigger setup in the modified version of JaWi's SUMP client (included in the zip archive).
If the edge bit is set then the value bit means rising/falling edge, else it means high/low level. You can mix and match edge and level triggers.

Image

Magnus


Top
 Profile  
 
PostPosted: Wed Jul 16, 2014 6:59 pm 
Offline

Joined: Wed Oct 16, 2013 4:18 pm
Posts: 8
magnus wrote:
The latest update to the Pipistrello OLS project also extends the triggering to support edge triggers in JaWi's SUMP client. You can get it here:
http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M_fifo_05282014.zip
See the README file in the zip archive for more info.


Hi Magnus, just gave it a try, much more convenient that having a complex trigger for edge stuff. Only problem I have found is there appears to pretrigger corruption in the buffer, the attached image shows a capture. The previous capture was at 100MHz, the next capture was at 50MHz (of the same periodic signal). The pretrigger data appears to be from the previous capture? Something strange going on here anyway. I am using the files from Pipistrello_OLS_64M_fifo_05282014.zip.

Cheers, Ian.


Attachments:
wierd.png
wierd.png [ 64.49 KiB | Viewed 8194 times ]
Top
 Profile  
 
PostPosted: Wed Jul 16, 2014 9:15 pm 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
Hi Ian,

I guess you can call it a bug but this is the way this thing works going all the way back to the original SUMP vhdl project, including the Open Bench Logic Sniffer.

From the SUMP vhdl project documentation (http://www.sump.org/projects/analyzer/fpga/):

Controller

Controls the capturing & read back operation.

If no other operation has been activated, the controller samples data into the memory. When the run signal is received, it continues to do so for fwd * 4 samples and then sends bwd * 4 samples to the transmitter. This allows to capture data from before the trigger match which is a nice feature.

Note: Data read back from before the 'run' signal might be invalid if the controller configuration was changed recently and not enough data was gathered before the signal was set.


For example, if you use a 1 Msample buffer and set the trigger point to 25% then it will sample 750 Ksamples after the trigger is detected and then send back 1 Msamples from the buffer. However, if it did not sample 250 Ksamples before the trigger was detected (say it only sampled 10 Ksamples) then it will read back stale data once it reaches 750 + 10 Ksamples.

One way to fix this would be to add another counter such that it would not arm the trigger until it has sampled at least the pre-trigger amount of samples (250 Ksamples in the example above) so that it will always read back valid samples.

Magnus


Top
 Profile  
 
PostPosted: Wed Jul 16, 2014 9:48 pm 
Offline

Joined: Wed Oct 16, 2013 4:18 pm
Posts: 8
Hi Magnus, okay I get that and it makes sense. I only changed the configuration to make it more apparent.

I have done it again, but this time selected "repeat capture with current device settings" button. I also used a smaller buffer (5.24ms) to make sure it fills quickly. Again I am capturing the same periodic signal, but get the following glitch before before and after the trigger (picture attached).

Cheers,
Ian.


Attachments:
wierd2.png
wierd2.png [ 65.99 KiB | Viewed 8191 times ]
Top
 Profile  
 
PostPosted: Wed Jul 16, 2014 11:57 pm 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
Ian, this is exactly what I expect to see with the signal used.

Since the trigger edge happens every millisecond it will trigger sometimes between 0 ms and 1 ms after the capture starts. When you read back the data, the stale data will then start somewhere between -0 ms and -1 ms. It's will absolutely be stale past -1.0 ms.

In your waveform it's clear that there are stale data at about -0.35 ms which is consistent with the above statement.

I think the statement in the SUMP documentation is somewhat misleading. You don't have to change configurations etc. to see this, the data will always be stale if you read back data from before the capture start point. The hardware is reset when the capture starts and if the trigger happens after say 0.5 ms after the capture start then you will only get valid data going back -0.5 ms from the trigger point. This has nothing to do with the size of the buffer, i.e. using a small 5.24 ms buffer will not help, you can only read back up to the capture start point.

Maybe I should add that the buffer memory acts as a LIFO memory (last-in-first-out), i.e. the data is read back from the end in reverse order. If you capture 750 Ksamples after the trigger point and use a 1 Msample buffer then 1 Msamples are read back from the end in reverse order. In the example above, if the trigger happens after 10 Ksamples then the stale data will start when you have read back 760 Ksamples from the end.

Hope that explains it more.

Magnus


Top
 Profile  
 
PostPosted: Thu Jul 17, 2014 12:16 am 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
One way to get around this problem is to use a multi-stage trigger. The first stage trigger will be an edge trigger with a delay counter of say 20 ms worth of samples. Next stage will also be an edge trigger but without a delay and set to start the capture. You will then have at least 20 ms worth of data before the trigger point.

Magnus


Top
 Profile  
 
PostPosted: Mon Jul 21, 2014 1:59 pm 
Offline

Joined: Wed Oct 16, 2013 4:18 pm
Posts: 8
Hi Magnus,

I couldn't believe this, but you are right! I went back to my Open Bench Logic Sniffer and performed the same test and it too produced the same results. I could have sworn it worked differently.

In my mind it defeats the whole point of being able to configure the before/after capture ratio. I thought the whole point of that was to be able to see what happened before the trigger - but now my understanding is all this data is not valid. What's the purpose of that option, or is it supported on other sump hardware?

I don't fully understand why it can't work as I would like it to? I thought it was like a ring buffer capturing all the time, and when the trigger happens it merely counts on the after buffer ratio. Then the whole buffer can be read out and it would all be valid.

I guess the last point comes down to me not understanding the structure, but I'm fine with that and I understand your suggested work around and will use that in the future. I still wouldn't mind hearing your comments on my second paragraph though.

Kind regards,
Ian.


Top
 Profile  
 
PostPosted: Fri Jul 25, 2014 3:58 am 
Offline

Joined: Thu Aug 29, 2013 5:48 pm
Posts: 225
>> I don't fully understand why it can't work as I would like it to? I thought it was like a ring buffer capturing all the time, and when the trigger happens it merely counts on the after buffer ratio. Then the whole buffer can be read out and it would all be valid.

Yes, it's using a ring buffer but it's not capturing data until you kick off a capture. If the trigger then happens after say 1 ms then you can only go back 1 ms in the ring buffer since it's only stored data for that long.

>> In my mind it defeats the whole point of being able to configure the before/after capture ratio. I thought the whole point of that was to be able to see what happened before the trigger - but now my understanding is all this data is not valid. What's the purpose of that option, or is it supported on other sump hardware?

The data in the ring buffer is only valid going back to the time you started the capture. It's like this on all sump hardware. I think the problem is that your system is repeatedly creating the trigger condition and you are starting the capture as it's running so you have no control of when the trigger happens. A better way is to set up the system so that it's not producing the trigger condition, then starting the capture which will start filling data in the ring buffer, then making the system create the trigger condition. This way the sump hardware has captured data long before the trigger happens and all data in the buffer is valid. Hope this makes sense.

Magnus


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group