Porting Logic Analyser from One to Pro


Hugo Sereno Ferreira

Recommended Posts

  • Replies 54
  • Created
  • Last Reply

Hey, so I was thinking the path of least resistance to accomplish this is to setup the Sump core as a Wishbone DMA peripheral so it could use the ZPUino's SDRAM controller. I've been talking with Alvie about how to make a DMA Wishbone template example and we are still working out the best way to do this. It is on the top of my task list, along with getting the RGB Matrix Panels working. So hopefully we will have a DMA Wishbone example soon and then making the Sump LA core work with the SDRAM will shortly follow.

 

Jack.

Link to comment
Share on other sites

That's be great Jack. I found the Papilio while looking for a logic analyzer and purposely chose the Papilio Pro for the SDRAM. I didn't know it was not in use in the logic analyzer code. Yet.

 

And BTW, I'm also really excited about using the product to get familiar with FPGA work and love all the things you've provided for use with it. 

 

Doug

Link to comment
Share on other sites

That would be great Jack and I'm surprised it's not been steadily busy given the fact that the Salaea products use a very similar Spartan 6 FPGA and your Papilio Pro with the level shifter wing is close to 1/4-1/3 the price. That's a couple of Benjamins for a few niceties like compact size, nice case, some probes and possibly easy to use SW(guessing as I've not used the OSLA yet).

 

If I get it up and running well enough I will be spinning it around my circles and that's just the LA use case.

 

Doug 

Link to comment
Share on other sites

So I have the Papilio Pro and the Papilio 16 bit I/O Buffer Wing but it only works hanging off the side of port A or Port C. Is there a way to get Port B used?

 

I tried using the DesignLab to compile the sample analyzer sketch but while it would compile with warnings, it would not upload even though papilio_prog is installed and I've used it to load the logic_sniffer.bit file.

 

For a logic analyzer, I'd like to have a case around the bottom and then a top with the wing A and C sockets exposed and then only the pins from the buffer Wing running down the center exposed for clipping on test leads.

 

Doug

Link to comment
Share on other sites

I just found the OLS analyzer source for the Papilio Pro and will go to Xilinx and get their ISE developers kit. I'd like to move the analyzer pins over to Port B and since I know very little yet on all this FPGA stuff if it won't work please chime in and let me know.

 

The reason for using Port B is because when used as a logic analyzer, it would be nice to have an enclosed case yet the Papilio 16bit I/O wing is required to hang out the sides when used on Ports A or C. By using Port B the 16bit I/O wing's 18 pin header( 2 bytes of input, 2 gnd pins ) would be right down the center of the case and this would enable a cover to be made with a clip holding the Wing and exposing Ports A and C along with the Wing input pins. 

 

Thanks

Doug

Link to comment
Share on other sites

Hello Doug,

 

It should be very easy to move the pins and will be a good, practical project to start with. You should be able to open the OLS project, the latest is here, and change the ucf file to match the pins you want. Get the generic Papilio Pro ucf file from here so you can easily see the row B pins.

 

Let us know if you run into problems, we will help you through them.

 

Jack.

Link to comment
Share on other sites

hmm, the source files in that repo are .vhl files while the source package/zip I got from this thread contains lots of .v files.  Is there yet another way to compile the analyzer code?  Is one for DesignLab and one for the Xilinx ISE?

 

I also go the ucf file from this thread with the pullups removed and when I diffed with the file in the package/zip file indeed I saw only the difference in the pullup declarations. 

 

BTW, I already looked at an I2C stream and it was really cool seeing the stream and being able to have the i2c protocol analyzer to really "see" the data. Used a couple of cursors to see the 100K data frequency. Soo much more informative than looking at the pulse train on an analog Oscope. But I will probably have to change my data acquire rate on my i2c controller since I can only capture a single message. I think I have it polling every 5 sec or so. I guess this is where the extra SDRAM memory would help.  Come to think of it, I might be able to look for device IDs and trigger on them so see other device messages. Just talking out loud since this is new for me.

 

Doug

Link to comment
Share on other sites

Hello Doug,

 

It should be very easy to move the pins and will be a good, practical project to start with. You should be able to open the OLS project, the latest is here, and change the ucf file to match the pins you want. Get the generic Papilio Pro ucf file from here so you can easily see the row B pins.

 

Let us know if you run into problems, we will help you through them.

 

Jack.

 

so I finally have Xilinx ISE installed and opened the SUMP BLAZE CORE package but found nothing for Papilio Pro, just 250 and 500 Papilio One. Do I just have to overwrite it's UCF file with the Papilio Pro one I downloaded from this forum?

 

Now that I know the .wise file is the project file, I found the logic_sniffer.wise in the package/zip file posted to this forum. I loaded it into ISE and "implemented Top Module" with no errors. Wing A is now indata[16-31], Wing B is now indata[0-15] and now the clocks and other things on Wing B are now on Wing C.  One problem though, extClockIn does not like being on P118(used to be in P84). I had to add CLOCK_DEDICATED_ROUTE=FALSE to bypass the error.

 

my PapilioPro.ucf file is here if it's of interest: http://pastebin.com/eMYiA4nq

Link to comment
Share on other sites

so I finally have Xilinx ISE installed and opened the SUMP BLAZE CORE package but found nothing for Papilio Pro, just 250 and 500 Papilio One. Do I just have to overwrite it's UCF file with the Papilio Pro one I downloaded from this forum?

 

Now that I know the .wise file is the project file, I found the logic_sniffer.wise in the package/zip file posted to this forum. I loaded it into ISE and "implemented Top Module" with no errors. Wing A is now indata[16-31], Wing B is now indata[0-15] and now the clocks and other things on Wing B are now on Wing C.  One problem though, extClockIn does not like being on P118(used to be in P84). I had to add CLOCK_DEDICATED_ROUTE=FALSE to bypass the error.

 

my PapilioPro.ucf file is here if it's of interest: http://pastebin.com/eMYiA4nq

 

A better way to eliminate the error is to move the extClockIn signal to a G_CLK pin (i.e. a pin that supports an input clock). C8 - C15 are G_CLK pins.

 

Magnus

Link to comment
Share on other sites

A better way to eliminate the error is to move the extClockIn signal to a G_CLK pin (i.e. a pin that supports an input clock). C8 - C15 are G_CLK pins.

 

Magnus

 

There are plenty of those pins free on port C, thanks.

 

Doug

Link to comment
Share on other sites

Doug,

 

I don't think that was the right source code I linked to, let me look again.

 

Jack.

I got the source from comment #16 in this thread. Here's a direct link:

 

http://forum.gadgetfactory.net/index.php?/topic/1925-porting-logic-analyser-from-one-to-pro/page-2#entry14266

 

if it's of any value, I can post up the UCF file with the Wing port assignments moved around so the logic analyzer defaults to work off Wing Port B(0-15), port A(16-31) and Wing Port C is the ext clock, trigger, etc.

Link to comment
Share on other sites

Yeah, there are many versions of the OLS code.  The one I posted in comment #16 in this thread is the Verilog code that's currently being shipped with the Open Bench Logic Sniffer board (http://www.seeedstudio.com/depot/Open-Workbench-Logic-Sniffer-p-612.html) a.k.a. Demon 3.07, ported to Papilio-Pro.  The Demon 3.07 code is a translation of the original SUMP VHDL code written by Michael Poppitz to Verilog by Ian Davis, which fixed several bugs in the original code. 

 

Parallel with this there are also VHDL versions based on the original VHDL code but with bug fixes etc. and I believe this is what Jack is pointing you to. However, I don't think I have seen a version of the VHDL code for Papilio-Pro (see the first few posts in this thread which prompted me to post the Verilog version).

 

Magnus

Link to comment
Share on other sites

I recall you stating it was the Verilog version ported to Xilinx and basically went, huh?  I guess these 2 vendors make similar products or one bought the other and rebanded etc... No worries, that's come out in the wash eventually.  As I recall there was a push to standardize but I've never been in the FPGA segment until now so thanks for the explanation.  As long as there is a path to updates and bug fixes I'm fine with what I was able to get compiled and will look for the github or OLS source location so I can tell when updates/fixes become available.

 

I currently have a bug issue opened with the OLS client so will later on look around for their source trees and see if I can find the original code you based your modifications on. Thanks.  And BTW, I'm quite impressed with the capabilities and value of the boards you all provide and blown away by the support. :-)

 

Doug

Link to comment
Share on other sites

I recall you stating it was the Verilog version ported to Xilinx and basically went, huh?  I guess these 2 vendors make similar products or one bought the other and rebanded etc.

 

I'm not sure what you are referring to here.  All versions mentioned are targeting Xilinx parts.  The original SUMP project (http://www.sump.org/projects/analyzer/) and Papilio-One uses a Spartan-3 FPGA while Papilio-Pro and Papilio-DUO uses a Spartan-6 FPGA.  My port for Pipilio-Pro was basically a port from Spartan-3 to Spartan-6.

 

The best place to go to for OLS support is this forum page: http://dangerousprototypes.com/forum/viewforum.php?f=23&sid=e077fd3e3401a8109f03611c88c18222

 

Magnus

Link to comment
Share on other sites

BTW, here are a few comments relating to the use of SDRAM for data buffering (been there, done that):

1) The SUMP protocol limits the number of samples to 256 Ksamples due to the use of 16-bit registers to hold the count values.  To go beyond 256K the protocol must me amended.

2) JaWi's SUMP client is not designed for large data samples (rendering fails after 1M points and it slows down dramatically).  Sigrok/PulseView is designed for large data samples so this might be an option.

3) The SDRAM does not have bandwidth to store data at the max data rate of the current code (400 MB/s) so somehow there needs to be limits on the sample rate (say max 20 Ms/s for 32-bit data).

 

Links:

 

JaWi's latest SUMP client code is here: http://ols.lxtreme.nl/ols-0.9.7.1-full.zip

JaWi's web page: http://ols.lxtreme.nl/

 

The original Demon 3.07 Verilog code is here: http://www.mygizmos.org/ols/Verilog-7.zip

Ian's OLS web page: http://www.www.mygizmos.org/ols/

 

Magnus

Link to comment
Share on other sites

Ok,

 

So I just realized that all the different versions are pretty confusing without the history of OLS. Maybe this will help make things clearer.

 

  • Everything started with Micheal Poppitz' release of the Open Source "Sump" Logic Analyzer core in 2007 or something like that.
  • In 2009 I started Gadget Factory and created the Butterfly board. One of the first applications was getting the Sump logic analyzer working on it. The buttefly board had very little success and probably sold fewer then 50 boards.
  • At the end of 2009 I partnered with Ian Lesnet from Dangerous Prototypes and we made the Open Bench Logic Sniffer (OLS). I did the FPGA side, he did the microcontroller side of the hardware. I did all of the VHDL work to extend the Sump Logic Analyzer core to add the features that people wanted for the OLS. The OLS was the first board I made that had success, but since it was done in a partnership it proved to be difficult for us to move forward with new versions...
  • Originally we used the original Sump LA client with the OLS but then Jawi came along and made a much improved client.
  • Shortly after that someone who went by "Dogsbody" ported the original Sump Logic Analyzer core, which was written in VHDL, to Verilog and called it "Demon Core". We switched to it because he also added some cool features from the HP 16550a Logic Analyzer. Unfortunately those features were never really taken advantage of.
  • Since those new features never really materialized and I'm much more comfortable with VHDL then Verilog I made a new release of the VHDL code and called it "Blaze Core". 
  • Due to the challenges of developing a product like this as a partnership development of OLS has dropped off.
  • My intention is to continue developing the Logic Analyzer functionality for the Papilio line of boards and I will be doing so with the VHDL based "Blaze Core" which I have ported an 8 channel version of to DesignLab. The Verilog "Demon Core" is not something that I will be supporting going forward.

Hope this makes things a little more understandable in regards to the Logic Analzyer core.

Link to comment
Share on other sites

BTW, here are a few comments relating to the use of SDRAM for data buffering (been there, done that):

1) The SUMP protocol limits the number of samples to 256 Ksamples due to the use of 16-bit registers to hold the count values.  To go beyond 256K the protocol must me amended.

 

---ugh. and without any "extra" bits in the protocol messaging(thinking of how Kerberos left unassigned bits) then I would imagine a major protocol change would be required

 

2) JaWi's SUMP client is not designed for large data samples (rendering fails after 1M points and it slows down dramatically).  Sigrok/PulseView is designed for large data samples so this might be an option.

 

--- got sigrok but pulseview is a PIA to compile. still unsuccessful and bound up on libsigrokcxx and can't find the package. maybe later.

 

---sounds like it would need some form of ring buffer on the data instead of sucking it all in at once. Likewise would require analyzers to know to be retriggered on new data views and probably way more than I'm thinking about now.

 

 

3) The SDRAM does not have bandwidth to store data at the max data rate of the current code (400 MB/s) so somehow there needs to be limits on the sample rate (say max 20 Ms/s for 32-bit data).

 

---ugh

 

Thanjks for the heads up.

 

Doug

 

Links:

 

JaWi's latest SUMP client code is here: http://ols.lxtreme.nl/ols-0.9.7.1-full.zip

JaWi's web page: http://ols.lxtreme.nl/

 

The original Demon 3.07 Verilog code is here: http://www.mygizmos.org/ols/Verilog-7.zip

Ian's OLS web page: http://www.www.mygizmos.org/ols/

 

Magnus

Link to comment
Share on other sites

That does help a lot.  I figured there was a tie between gadgetfactory and papilio.cc and probably OLS. Partnerships and splitting projects is very tough over the long haul as we never know where we or the others will be 5,10, etc years later.

 

But seeing what you all have done I'm a bit surprised this isn't going like crazy on the market. Granted it's not a $20 Arduino but the analyzer aspect alone would make me think any of the EE's out there hacking at home would have at least one of these in there briefcase at all times. Once I get the lid on the box that's what I plan on doing.

 

I'll try to work on getting the Blaze Core up and building if not in the Xilinx ISE(just guessing it'll build there) definately in the DesignLab.

 

Doug 

 

Ok,

 

So I just realized that all the different versions are pretty confusing without the history of OLS. Maybe this will help make things clearer.

 

  • Everything started with Micheal Poppitz' release of the Open Source "Sump" Logic Analyzer core in 2007 or something like that.
  • In 2009 I started Gadget Factory and created the Butterfly board. One of the first applications was getting the Sump logic analyzer working on it. The buttefly board had very little success and probably sold fewer then 50 boards.
  • At the end of 2009 I partnered with Ian Lesnet from Dangerous Prototypes and we made the Open Bench Logic Sniffer (OLS). I did the FPGA side, he did the microcontroller side of the hardware. I did all of the VHDL work to extend the Sump Logic Analyzer core to add the features that people wanted for the OLS. The OLS was the first board I made that had success, but since it was done in a partnership it proved to be difficult for us to move forward with new versions...
  • Originally we used the original Sump LA client with the OLS but then Jawi came along and made a much improved client.
  • Shortly after that someone who went by "Dogsbody" ported the original Sump Logic Analyzer core, which was written in VHDL, to Verilog and called it "Demon Core". We switched to it because he also added some cool features from the HP 16550a Logic Analyzer. Unfortunately those features were never really taken advantage of.
  • Since those new features never really materialized and I'm much more comfortable with VHDL then Verilog I made a new release of the VHDL code and called it "Blaze Core". 
  • Due to the challenges of developing a product like this as a partnership development of OLS has dropped off.
  • My intention is to continue developing the Logic Analyzer functionality for the Papilio line of boards and I will be doing so with the VHDL based "Blaze Core" which I have ported an 8 channel version of to DesignLab. The Verilog "Demon Core" is not something that I will be supporting going forward.

Hope this makes things a little more understandable in regards to the Logic Analzyer core.

Link to comment
Share on other sites

hi mkarlsson

I have been able to extend the implementation on papilio pro to use 256k out of the fpga. That's not a big issue. To go beyond that the use of the on board ram is needed. There is another board from dream source lab that has a similar hardware ( https://github.com/DreamSourceLab?tab=repositories ) but a slightly different ram. They use a different protocol but are able to dump few mega samples without problem. Unfortunatly for Jack the stuff is written in verilog :(. one possibility with relatively low effort is to port that code to papilio pro.

Link to comment
Share on other sites

hi mkarlsson

I have been able to extend the implementation on papilio pro to use 256k out of the fpga. That's not a big issue. To go beyond that the use of the on board ram is needed. There is another board from dream source lab that has a similar hardware ( https://github.com/DreamSourceLab?tab=repositories ) but a slightly different ram. They use a different protocol but are able to dump few mega samples without problem. Unfortunatly for Jack the stuff is written in verilog :(. one possibility with relatively low effort is to port that code to papilio pro.

 

I just downloaded their software package and DSView does not build. it calls a structure member which does not exist in the definition.... I find it "interesting" that they forked PulseView and call it DSView instead of working with the sigrok devs to improve/fix PulseView. The fact the software doesn't build as per their instructions because of incomplete code isn't a good sign.

 

UPDATE: FWIW, I found a single page which said to use ann_format instead of ann_class and it did compile. Turns out it just gives a demo capability so not sure what that's all about.

 

I was also able to find the github sources, tried that and the compilation failed differently.

 

Could you post/provide the source for your 256k Papilio Pro modification? I don't mind trying it. thanks.

 

Doug

Link to comment
Share on other sites

I looked at the SUMP Blaze Core(master from git) and from what I found( I have the Papilio Pro ):

 

1) the "logic_snifferISE" project is for a Spartan 3

2) the "Papilio_Logic_ISE" is for a Spartan 6lx but compiles with errors( not enough slices, and something else ).

3) the "Papilio_One_ISE" compiles and generates the bit file but doesn't run on a Papilio Pro.

 

Is there supposed to be a working project for the Papilio Pro or should I go back to the beginning of this thread an see what process was taking to port from a P1 to the PPro?

 

Doug

What I have in SPI works so I'm up and running, I just wanted to get on the path Jack is with supported code. Thanks.

Link to comment
Share on other sites

Hello Doug,

 

I've been working yesterday and today on the Logic Analyzer "Blaze" core in DesignLab. I should have things sorted out and ready for the next 1.0.7 release of Designlab which will hopefully be done Monday or Tuesday.

 

What I've done so far:

  • Added new DesignLab schematic symbols for a 16 channel and 32 channel LA.
  • Fix the memory bug so now we can use all of the BRAM space for memory. The Papilio Pro has 64K of memory available now.
  • Provided a base, standalone project so the source code is easily accessed in DesignLab.
  • I'm working on adding functionality to easily get your Papilio board setup as a Logic Analyzer with just a couple clicks.

Stay tuned for more info.

 

Jack.

Link to comment
Share on other sites

Archived

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