Tomin Posted February 20, 2015 Report Share Posted February 20, 2015 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. Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted February 20, 2015 Report Share Posted February 20, 2015 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. Quote Link to comment Share on other sites More sharing options...
Tomin Posted February 20, 2015 Author Report Share Posted February 20, 2015 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.pngIt 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. Quote Link to comment Share on other sites More sharing options...
Skip Posted January 12, 2017 Report Share Posted January 12, 2017 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 Quote Link to comment Share on other sites More sharing options...
Skip Posted January 12, 2017 Report Share Posted January 12, 2017 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 Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 12, 2017 Report Share Posted January 12, 2017 Please take a look at this guide to use as logic analyzer: http://gadgetfactory.net/learn/2015/07/30/designlab-using-papilio-as-stand-alone-logic-analyzer/ Jack. Quote Link to comment Share on other sites More sharing options...
Skip Posted January 12, 2017 Report Share Posted January 12, 2017 Thanks Jack for link, I'll give it a try! Skip Quote Link to comment Share on other sites More sharing options...
Skip Posted January 13, 2017 Report Share Posted January 13, 2017 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 Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 13, 2017 Report Share Posted January 13, 2017 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. Quote Link to comment Share on other sites More sharing options...
Skip Posted January 15, 2017 Report Share Posted January 15, 2017 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 Quote Link to comment Share on other sites More sharing options...
Skip Posted January 16, 2017 Report Share Posted January 16, 2017 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 Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 16, 2017 Report Share Posted January 16, 2017 Skip, No need to use the OLS client included with DesignLab, it is just for convenience. Not sure what is wrong with RLE, I keep meaning to take a look to see what the problem is but its hard to find time right now... Jack. Quote Link to comment Share on other sites More sharing options...
Skip Posted January 16, 2017 Report Share Posted January 16, 2017 @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 Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 17, 2017 Report Share Posted January 17, 2017 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. Quote Link to comment Share on other sites More sharing options...
mkarlsson Posted January 18, 2017 Report Share Posted January 18, 2017 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 Quote Link to comment Share on other sites More sharing options...
Skip Posted January 18, 2017 Report Share Posted January 18, 2017 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 Quote Link to comment Share on other sites More sharing options...
Skip Posted January 18, 2017 Report Share Posted January 18, 2017 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 Quote Link to comment Share on other sites More sharing options...
Skip Posted January 18, 2017 Report Share Posted January 18, 2017 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 ... Quote Link to comment Share on other sites More sharing options...
Skip Posted January 18, 2017 Report Share Posted January 18, 2017 Hi @Jack Gassett, Opps... hold off on pulling the changes I just found a problem. I had replaced DesignLab-1.0.8/examples with the DesignLab_Example git repository. I just discovered that there's no example/libraries subdirectory in the release. Sorry about that! Skip Quote Link to comment Share on other sites More sharing options...
Skip Posted January 19, 2017 Report Share Posted January 19, 2017 Hi @Jack Gassett, I think I finally got it right. Give it a look and let me know what you think. Skip Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 20, 2017 Report Share Posted January 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 20, 2017 Report Share Posted January 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
Skip Posted January 20, 2017 Report Share Posted January 20, 2017 Thanks Jack !! That fixed all of my build issues. Sorry for all of the noise and confusion! I've learned a lot in the last couple of weeks. Skip Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 21, 2017 Report Share Posted January 21, 2017 Excellent! Glad you are enjoying the journey so far. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.