Dangerous Prototypes

Here is a new test release that makes it possible to dynamically change the memory depth directly from the OLS client by simply selecting channel groups. If four channel groups are selected then 6K of memory will be available, if two channel groups are selected then 12K is available, only one selected group gets the maximum size of 24K.

Blog posting with more info, screencast, and download links. (http://http://www.gadgetfactory.net/?main_page=wordpress&p=111)

yipiiiiiiiiiiiiiiiii trying it "now" :)

Mission accomplished!
Works as predicted, great!

What wasn't clear to me from the screencast is that it doesn't matter from which channelgroup you sample the 24k. If you request only channelgroup 1 (that would be channels 8-15 with inside numbering scheme, group 0,2,3 disabled) you can sample the full 24k from these 8 channels.
I did not try this on the channnelgroups 2 and 3 because my test-signal is 5V, but I assume I could capture for instance the channelgroups 2+3  at 12k?

RLE only works when all 4 channelgroups are enabled and the depth is set to 6k, that's fine with me. 

Thank you again for starting the project !
Eberhard

Great work, and congratulations to Jochem!

Thanks to Jochem.  I have some thoughts: if this test-release reflects the status of the branch in the SVN, then this dynamic-sample-depth-feature is implemented by treating the BRAM as 32 bits memory, and we loose the "parity" bits in less-than-32 channel mode. In the static sample-depth versions those parity bits are used to mark RLE counts. Wouldn't it in principle be possible to keep the parity bits and treat the sample-memory as 24k 9-bits words all the time? With 32-bits sample depth one would use 4 words to store the data, in 16 bits mode 2 words, in 8-channel-mode 1 word. This would restore the ability to use the 9th bit as RLE marker when not using all the channels.

Thanks again,

Claus

Folks,

If I understand the demo correctly, the correct bitmap configuration is chosen depending on the number of channels chosen.  This is purely the trade-off between the number of channels versus the number of samples, given a set amount of RAM on the FPGA.

So far, so good.. but it appears that the Java client is clueless as to the trade-off above, and you can select more samples for more channels than is available.  Hence the 'signal wrapping' on the demos.

This is sort of obvious, but I suggest that the client could be modified to recognize (or store) the total amount of available RAM, and do a calculation that given the number of channels chosen, gray/grey out the sample sizes that don't make sense.  It could even be set to automatically choose the greatest available sample depth.

As Joel used to say "What do you think, sirs?"

-Crawford

@Crawford,

Yes, I think the Java client should definitely implement a feature where channel group boxes are greyed out depending on sample depth or something. I was just hoping that someone who was good with Java would take this coding on...

[quote author="jack.gassett"]
Yes, I think the Java client should definitely implement a feature where channel group boxes are greyed out depending on sample depth or something. I was just hoping that someone who was good with Java would take this coding on...
[/quote]

I was thinking about implementing this in my alternative client. I'll keep you posted...

Yes, I think the Java client should definitely implement a feature where channel group boxes are greyed out depending on sample depth or something.

While the topic is hot ... I guess it should be the other way round.

The number channels to have to capture is usually not debatable. So the sample depth ComboBox should be the slave of the Channelgroup-selector.

Eberhard 

@Jack

Thanks for the response.  If I was better at Java, I would volunteer.

@Jawi

Go for it... I still need to try your client out.  (I'd be happy to beta test this).

@Eberhard 

Yes, that's what I was thinking: Which channels are selected is the primary choice, and the number of samples is the dependent/limited value

-Crawford

I've just uploaded a new beta release (b3) (http://http://www.lxtreme.nl/ols/ols-0.8.2-b3.tar.gz) of my alternative client that supports the dynamic sample size. In case you select a sample count that is larger than would be supported through the selected channel groups, a warning is given upon capturing. Also, I've added a new option to automatically select the (maximum) sample count based on the enabled channel groups.

@Crawford, if you would like to test this that would be great!

@jawi
I didn't had much time to find out what is exactly wrong, but this is the error message I got trying to execute beta 3:

Artemis:~ Ward$ bash /Users/Ward/Downloads/ols-0.8.2-b3/run.sh 
: command not foundds/ols-0.8.2-b3/run.sh: line 2: 
Exception in thread "main" java.lang.NoClassDefFoundError: nl/lxtreme/ols/runner/Runner
Caused by: java.lang.ClassNotFoundException: nl.lxtreme.ols.runner.Runner
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Artemis:~ Ward$ 

fwiw: beta 2 gives the same error...

[sub:]edit:
oops, just noticed that this is not the appropriate topic, sorry![/sub:]

[quote author="wartos"]

@jawi
I didn't had much time to find out what is exactly wrong, but this is the error message I got trying to execute beta 3:

Artemis:~ Ward$ bash /Users/Ward/Downloads/ols-0.8.2-b3/run.sh 
: command not foundds/ols-0.8.2-b3/run.sh: line 2: 
Exception in thread "main" java.lang.NoClassDefFoundError: nl/lxtreme/ols/runner/Runner

[/quote]

the run script assumes you're running it from the base installation folder, so it cannot find the classes & dependencies it need. Try:

 $ cd /Users/Ward/Downloads/ols-0.8.2-b3/
 $ bash ./run.sh 

[quote author="wartos"]

@jawi
I didn't had much time to find out what is exactly wrong, but this is the error message I got trying to execute beta 3:
[/quote]

Putting this

#!/bin/sh
cd "$(dirname -- "${0}")"
java -Dnl.lxtreme.ols.bundle.dir=plugins/ -cp "bin/*" nl.lxtreme.ols.runner.Runner

into "run.sh" makes it independent of the current working dir (on unix based systems).
 
Eberhard

[quote author="wayoda"]
Putting this

#!/bin/sh
cd "$(dirname -- "${0}")"
java -Dnl.lxtreme.ols.bundle.dir=plugins/ -cp "bin/*" nl.lxtreme.ols.runner.Runner

into "run.sh" makes it independent of the current working dir (on unix based systems).
[/quote]

Very nice! I've updated the run scripts for both Windows and Unix-based systems to work that way. Thanks for the contribution.

I get an error when I try and run the Analyzer from the 2.12TestRelease. I double click on the "run_java_client.bat" and a DOS window opens, then closes. I try same .bat file from DOS myself and the error that comes up is:
Error while invoking application: null

Any suggestions?

I can open the alternative client ok and capture ok.

I have update the f/w to 2.12 as well.

Cheers for the help.

@MarkDixon

That error message means that you don't have rxtx installed in the version of Java that is being picked up in the path.

You can install rxtx or just copy the analyzer.jar file to a newer version of the Full software.

Jack.

Thanks for the info Jack. I will give that a try when I get home!

Thanks

Hello, I'm a complete newbie here. I just got the open logic analyzer, installed 2.12 and it's already been helpful.
(Using Fedora 11 Linux)

A minor bug (or is it a feature?) when I change sampling rate the beginning of the sample is still using the old parameters. See attached image with wrong data highlighted. I sampled once with low rate and then changed the to higher sampling rate and captures again. Signals should have repeating pattern.

Off-Topic newbie question: where can I learn more on using complex triggers?

---

where can I learn more on using complex triggers?

I'm sorry, I don't think we have a guide for it yet. The Oak Micros SUMP handbook might have something. If you manage to learn a bunch about it, would you please share a summary we can add to the documentation?

http://oakmicros.com/content/downloads/ ... Downloads/ (http://oakmicros.com/content/downloads/View-category/Other-Oak-Micros-Downloads/)

[quote author="ian"]
http://oakmicros.com/content/downloads/ ... Downloads/ (http://oakmicros.com/content/downloads/View-category/Other-Oak-Micros-Downloads/)
[/quote]
Thanks, it looks good. It will take me some time to learn all the options, and probably much more time to actually use them.

Hi,

where are the VHDL sources for the 2.12 release?  The dynamic sample depth feature doesn't appear to be in trunk on the Gadget Factory SVN.  I see something on the JochemMMC branch but the comments indicate it is not working.  Are the 2.12 sources in SVN?

Also, how do I build the load?  Which version of ISE (looks like 11.1 from the trunk project file)?  And is Build_All.cmd the official way to build the images?

I've checked out trunk and used Build_All to build it with ISE 11.1 but would rather play with the 2.12 version.  Actually, I translated the windows .cmd file to a bash shell script since I'm using Linux, but is seems to work fine.  I have an OpenBench Logic Sniffer from Seeed Studio I'd like to upgrade and practice some VHDL development on.

Thanks, John McC.

Hello John McC,

Sorry about that, it looks like I was so excited about it working that I did not check the changes into SVN.

I just updated the JochemMMC branch with the changes for Test Release 2.12.

The Build_All.cmd was an easy way to build the multiple bitstreams, but Test Release 2.12 brings everything into one bitstream so there is no need for the build_all.cmd anymore. You can just synthesize inside Project Navigator.

Let me know if you run into any other issues, we'll work through them. I hope to get this branch merged into the trunk and start debugging the RLE issues in the next couple of weeks. I'm wrapping up my current big project (Papilio Barcode Genie kit (http://http://gadgetforge.gadgetfactory.net/gf/project/barcodegenie/)) and should be releasing it over at Gadget Factory in the next few days. This will free me up to move forward with the OLS.

Thanks,
Jack.

Cool, that looks better.  However, when I now try to synthesize in ISE 11.1 I get the following:
[tt:]Started : "Convert HDL Source".
terminate called after throwing an instance of 'Xdm_Exception::UnsupportedFileFormatVersion'

Process "Convert HDL Source" failed

Started : "Convert HDL Source".
terminate called after throwing an instance of 'Xdm_Exception::UnsupportedFileFormatVersion'

Process "Convert HDL Source" failed[/tt:]
Could this be due to the two generated DCM instances that appear to be ISE 12.2?

./ipcore_dir/DCM8to50.vhd:--       /     Version : 12.2
./ipcore_dir/DCM32to50.vhd:--       /     Version : 12.2

Should I just switch to ISE 12.2?  Or the most recent 12.3?  Which version would you recommend?


Cheers,
John McC.

I would go with the most recent, if it doesn't work you can just revert from svn and start over with 12.2.

Jack

Hi again Jack,

looks like something is still missing.  The JochemMMC branch is failing timing on derived clock1 constraints that look related to the  RAM6_Impl.Inst_sram/Sample_RAM/Address_12 source signal (and others starting with the same prefix).  I assume that is a problem--though I don't know enough about ISE and VHDL yet to be sure.  I don't see this with the trunk version. Is it possible you need to check in more files?  It did build a bit/mcs file but I'm guessing it has bad timing.

I get the same result with ISE 12.3 and 12.2.


Thanks,
John McC.

John McC.,

One thing that is frustrating about the Xilinx ISE Project Navigator is that it completely overwhelms you with error messages that 99% of the time have no bearing on the end result of your project. I have never had any single project synthesize without some scary looking error messages pop up. You have to take it with a grain of salt and look into error messages when a project doesn't synthesize. I receive the same failing constraint error message that you do but everything works fine. This is one of the reasons I release Test Releases for a fairly long time before making it official. Test Release 2.12 has been working for a lot of people for a good amount of time now without any complaints.

Digging further into the error message it seems to be caused by some default constraint placed on the pin that is used for the optional "External Clock" that can be used to cascade OLS's. There seems to be a pretty high 10ns constraint, I'm not even sure where this constraint comes from, its not in the ucf file. It appears that the changes for the dynamic memory have changed the timing structure enough that this 100Mhz constraint is no longer being met. So the implication of this is that if someone connects an external clock to the OLS pin they may have problems getting it to be stable above 50Mhz. I'm not so sure this is something to be very worried about.

Jack.

[quote author="jack.gassett"]Digging further into the error message it seems to be caused by some default constraint placed on the pin that is used for the optional "External Clock" that can be used to cascade OLS's. There seems to be a pretty high 10ns constraint, I'm not even sure where this constraint comes from, its not in the ucf file. It appears that the changes for the dynamic memory have changed the timing structure enough that this 100Mhz constraint is no longer being meant. So the implication of this is that if someone connects an external clock to the OLS pin they may have problems getting it to be stable above 50Mhz. I'm not so sure this is something to be very worried about.[/quote]Is there a way in the tools to mark that pin as "disabled" for external clocking purposes?  If so, the error messages might go away.

There is a way to exclude nets from a timing report that would make the warning message go away. But then there are tons of other warning messages too, you will never get all the warning messages to go away. It is something that people complain about at Xilinx events all the time.

Hi Jack,

As long as you're getting the same errors I am, that's fine.  I've still got a ways to go understanding those error/analysis reports.  In any case, I just wanted to be sure I have the latest version of the VHDL.  Now to try upgrading my OpenBench Logic Sniffer...


Thanks,
John McC.

[quote author="jack.gassett"]There is a way to exclude nets from a timing report that would make the warning message go away. But then there are tons of other warning messages too, you will never get all the warning messages to go away.[/quote]Well, entirely excluding a net doesn't seem like a good idea, because you want the warnings which might affect you.  But if you can only exclude certain aspects of the timing report, then that might be good.

It's just that I recall coming across some special mode settings for pins that marked them as bus keepers or Hi-Z (high-impedance) in response to some questions here.

Searching...

Pull-Up, Pull-Down, and Keeper Circuits
Three-state output buffers and bidirectional buffers can have a pull-up resistor, a pulldown resistor, or a keeper circuit. Control this feature by adding the appropriate symbol to the output net of the OBUFT or IOBUF (PULLUP, PULLDOWN, or KEEPER).

It's a long-shot, but I'm guessing that certain assignments of a given pin might make the warnings about clock applications go away.  But that's assuming a very intelligent compiler.

It is something that people complain about at Xilinx events all the time.

Ok, you're all way ahead of me, I'm basically just guessing - based on very brief perusal of the data sheets.