Logic Analyzer with Papilio Duo


Tomin

Recommended Posts

Hi

 

I got my Papilio Duo last week. I wanted to try the Logic Analyzer with Papilio Duo but I can't seem to make it work. I uploaded the Circuit and the code but it didn't work. I looked into the directory and to me it seemed like only older boards are supported. It this true? If so, when Papilio Duo will be supported? Thank you. The logic analyzer would be very helpful with the project I'm currently working on. If it matters I'm using Arch Linux and Fedora 20.

Link to comment
Share on other sites

Yes, I tried to burn and upload that into the Papilio. For some reason Tools / Logic Analyzer doesn't do anything but if I start it from terminal (DesignLab/tools/Logic_Analyzer.sh) that opens the Analyzer. Earlier I tried to select Capture / Begin Capture / Show device metadata and I thought it didn't work because it disabled Capture button. This time I just clicked Capture and it actually gave me some output. Apparently it works. Thanks. :)

 

Edit: I'm not quite sure what I'm doing wrong now. I always get this kind of output no matter what I do: https://dl.dropboxusercontent.com/u/4305182/Scrot/2015-02-20-23-26-49.png

It has always those same waveforms even if I try to ground some of the inputs. I tried to wire some of the A wing pins to ground (e.g. pins labeled 7 and 0) but it still looks the same if I recapture it. Is the AVR doing something funny or what?

 

Edit 2: I guess I shouldn't have uploaded that code or something because that's what made it to do something else than needed it to do. :D 

Link to comment
Share on other sites

  • 1 year later...
On 2/20/2015 at 11:22 AM, Jack Gassett said:

Hello Tomin,

 

If you download DesignLab you will see a project in the table of contents that has an 8 channel Logic Analyzer for the Papilio DUO.

 

Jack.

Hi @Jack Gassett,

Are the sources for the DUO version available?  I'm interested in using 8/16/32 bits with my DUO and the I/O buffer wings.

Skip

 

Link to comment
Share on other sites

Hi @Jack Gassett,

I've flashed the 8 channel Logic Analyzer for the Papilio DUO bit file I found in ./build/shared/tools/logicanalyzers/DUO_LX9/papilio_duo_lx9.bit successfully.  I've unplugged the Papilio and plugged it back in again, but it's only enumerating as the JTAG device, I don't see the serial port.  Do I assume correct that I should be plugging in the USB FPGA connector?  The green LED is flashing at about a 1 Hz rate.

I'm running Ubuntu 16.04.1 LTS 64 bit.  lsusb shows:

Quote

skip@xenial:~/Papilio/DesignLab$ lsusb
Bus 002 Device 004: ID 0403:7bc0 Future Technology Devices International, Ltd
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 18e3:9106 Fitipower Integrated Technology Inc
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 004: ID 04ca:0027 Lite-On Technology Corp.
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
skip@xenial:~/Papilio/DesignLab$ sudo lsusb -v -d 0403:7bc0

Bus 002 Device 004: ID 0403:7bc0 Future Technology Devices International, Ltd
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x7bc0
  bcdDevice            7.00
  iManufacturer           1 Gadget Factory
  iProduct                2 Papilio DUO
  iSerial                 3 100000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           55
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 Papilio DUO
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 Papilio DUO
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
skip@xenial:~/Papilio/DesignLab$

 

Skip

Link to comment
Share on other sites

Hi @Jack Gassett,

I've installed DesignLab-1.0.8 and I was able to successfully run the Papilio_DUO_QuickStart example (BTW: Way cool, no installation issues at all on Ubuntu 64 bit).

When I click the logic analyzer icon the bit file is downloaded successfully, but the logic analyzer never starts.  No messages are displayed after the bit file is programmed.  If I say "No" to "Would you like to load a Logic Analyzer..." dialog no messages are displayed either.

I had installed ols-0.9.7.2 that I downloaded from http://ols.lxtreme.nl prior to installing DesignLab so I tried it and it ran (sort of).  I see a 100Mhz clock on channel 1, but I can't find any configuration screens to select clocking, capture width, etc.

Does the bit file loaded by DesignLab need to used with the DesignLab OLS client?

This is the coolest thing I've played with in YEARS!  I've already run CP/M and Pacman on the board, I can't wait to get the logic analyzer running!

Skip

Link to comment
Share on other sites

On 1/13/2017 at 9:55 AM, Jack Gassett said:

If I remember correctly it should be running the Logic_Analyzer.sh script in the DesignLab-1.0.8/tools folder. Can you see if you can manually run that script? Maybe there is an issue with Java on your path?

Jack.

Hi Jack,

I ran the script manually and the problem appears to be a missing dependency (missing requirement [10.0] osgi.wiring.package).  A full log of the run is attached.  This is a pretty virgin install of Ubuntu 16.04.1 LTS, I've installed it from scratch when I got my DUO and I've only been installing Papilio related tools on it.

Skip

Logic_Analyzer.log

Link to comment
Share on other sites

Hi @Jack Gassett,

After I copied ols.profile-papilio-duo.cfg from the DesignLab tree into the ols plugins directory I had some success using the ols-0.9.7.2 client from http://ols.lxtreme.nl as long as I leave Run Length Encoding disabled.  I guess my primary question at this point is if there is any reason I need to use the ols version bundled with DesignLab?

Enabling RLE corrupts the data badly.  I'm using a bus I2C bus as a test, with RLE disabled the clock is a very nice and stable 350Khz.  When I enable RLE it looks completely different.

Skip

Link to comment
Share on other sites

@Jack Gassett,

I just succeeded in rebuilding the Benchy_Sump_LogicAnalyzer_Standalone example, but I did run into some issues.  Some issues were related to running on Linux (file system case sensitivity), some were related to references to "../../../DesignLab/build/windows/work/examples/", and some were related to an apparent reorganization of the tree structure.

I forked DesignLab_Examples on github and committed my changes to the fork.  I'm going to take a look at the RLE stuff and see if I can contribute a fix.  Don't expect to much, I'm just learning VHDL.

Skip

 

Link to comment
Share on other sites

FYI, I had a discussion a couple of years ago with Jan Willem Janssen (JaWi, the author of the ols client software) regarding bugs in the RLE code.  The problem I found was that RLE processing in demux mode (i.e. 200 MHz sampling mode) was completely broken.  This is what I wrote him back then:

The reason I think demux mode is a hack is that only the input sampling module and the trigger module knows about demux mode, the rest of the pipeline is tricked into processing two 16-bit values as one 32-bit value.  This works fine as long as the client receiving the data is processing it as a sequence of 16-bit values, but when you add RLE encoding to the mix then it starts to fall apart since the RLE encoder knows nothing about demux mode.  For example, 32-bit RLE mode is using bit 31 as a flag (if set it indicates a repeat count) so you only have 31 channels in this mode and the most significant channel is always 0.  This means that in demux mode the sample stored in bits 16-31 will have it's top channel value zeroed out bit not the value stored in bits 0 - 15.  This could be fixed if the RLE module knows about demux mode. 

A more significant side-effect of processing two 16-bit values as one 32-bit value in the RLE encoder is that you are really RLE-encoding pairs of 16-bit values.  If the stream of 16-bit values look like this: 0x5000, 0x5100, 0x5000, 0x5100, 0x5000, 0x5100 then the RLE encoder will process this as the value 0x51005000 repeated three times.   To process this correctly the RLE decoder in the client must first create the original sequence of 32-bit values based on the RLE flag and RLE count, and then process them as a sequence 16-bit sample values.  In other words, the process order in the client must be the reverse of the process order in the RTL code and must operate in the same context as the RTL code (first do RLE as 32-bit values, then the sample values as 16-bit values).  However, looking at your code (in RleDecoder.java) I believe this is not how it's done in your client, it's trying to do both at the same time.  If I read your code correctly it looks like you are processing the data as a single16-bit value and if the RLE flag is set and in demux mode then you try to modify the repeat-count for this 16-bit value somehow by using the next 16-bit value and then multiplying the result it by 2, rather than processing it as repeated pairs of 16-bit values.  It also looks like you are applying the 32-bit rleCountValue and rleCountMask to the 16-bit sample value in 16-bit demux mode?


In other words, RLE in 200 MHz mode (a.k.a. demux mode) does not work in the client software.  I don't think this has been fixed by JaWi.

Magnus

Link to comment
Share on other sites

Hi @mkarlsson!

I'm very new to this ... but I've been doing a LOT of reading of old posts, etc.  I happy you are still around, most of the treads I've been reading here there and everywhere seem to have gone quiet a couple of year ago.  I'm very impressed with all of the work everyone has put into OLS and related projects!

I hadn't mentioned it, but I get garbage at 200 Mhz even without RLE.  I get good data at 100 Mhz and 20 Mhz w/o RLE which are the only other clock rates I've tried so far.  The Papilio DUO is the only hardware I have right now so I can't really tell if I have a client problem or a target problem.

I'm going to try to port the Verilog implementation to my DUO and see how it compares.

I  tried using pulseview briefly, but it doesn't seem to recognize my Papilio.

Skip

Link to comment
Share on other sites

2 hours ago, Jack Gassett said:

Thanks Skip, if you can send a pull request when you are ready I will merge it in.

Do you have the fixes for the path issues too? I thought I had fixed them with the 1.0.8 release but maybe not.

Thanks,
Jack.

Hi @Jack Gassett,

I fixed all of the issues with the Benchy_Sump_LogicAnalyzer_Standalone example for the DUO ONLY.  I'll fix the other targets and then send you a pull request.

I suspect other examples will have similar problems.  I'm going to try to do some global search and replaces to fix the issues on all of the .xise files in the examples and then test a few.  I would probably take days for my pokey machne to build all examples and targets!

One of the biggest issues on Linux was that there was a .../examples/libraries/clocks AND a .../examples/libraries/Clocks.  I moved all of the files from ../examples/libraries/clocks into ../examples/libraries/Clocks and then deleted ../examples/libraries/clocks.  Any projects with references to the lower case clocks will now be broken on Linux, of course Windows won't care.

Skip

Link to comment
Share on other sites

Hi @Jack Gassett,

I finished fixing all Benchy_Sump_LogicAnalyzer_Standalone targets and I've sent you a pull request.  I've tested the DUO bit file built from a fresh tree with the changes.  I haven't tested the other targets since I don't have hardware.

For a while I didn't think the Papilio_One_500K target working because it appeared hang while routing, however it was just REALLY slow.

I can understand if a smaller part takes more time to route than a larger part because it is fuller, but the 250K part routed MUCH faster!

Any idea of what's happening here?  Is this typical?

Skip

Quote

Papilio_One_500K: 
... 
All signals are completely routed. 
Total REAL time to PAR completion: 1 hrs 6 mins 46 secs 
Total CPU time to PAR completion: 1 hrs 6 mins 39 secs Peak Memory Usage: 632 MB
Peak Memory Usage:  632 MB
...

Papilio_One_250K:
...
All signals are completely routed.
Total REAL time to PAR completion: 13 mins 39 secs 
Total CPU time to PAR completion: 13 mins 37 secs 
Peak Memory Usage:  612 MB
...
 

 

Link to comment
Share on other sites

Hey Skip,

Thank you very much for the pull request, it looks like there are too many auto-generated files that are included though... It makes it hard to determine where the real changes that need to be made reside...

I think the best thing at this point is for me to try and re-create what you are seeing. Can you describe the error you get and what you do to get it?

Thanks,
Jack.

Link to comment
Share on other sites

Hello Skip, 

I think the root of the problems you are seeing may be from a misunderstanding about how DesignLab works. I suspect that you are going into the circuit directory and opening the *.xise files directly. That is not going to work, it is important that you open up the Xilinx ISE using the "Load Circuit" icon within DesignLab. DesignLab modifies the xise files and puts all of the correct paths in place when you click the "Load Circuit" icon. If you try to bypass DesignLab and open the xise files directly then you are going to have all types of problems with wrong paths because you are never giving DesignLab the chance to setup the environment...

Jack.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.