| Logic Analyzers?? [message #9198] |
Wed, 13 October 2021 12:24  |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
I have a Saleae 8 line USB analyzer that I like. Works great for debugging SPI, I2C, PWM types of signal on ARM Cortex-m4 type systems. But now that I'm starting to play with MC680X0 again, only 8 signals is a real drawback. I know Saleae makes a 16 signal version but that seems like it too would be too few signals for working with 32 bit systems.
So what's a decent hobbyist level logic analyzer?
Some of my criteria:
* At least 32 signals [more would be nice]
* Usable from Mac OS or Linux [standalone is OK, Windows only is not]
* Capable of analyzing at least 25MHz signals [50MHz would be nice for a future project I have in mind]
* Doesn't require taking out a second mortgage [less is better even if it means compromising on some of the other criteria]
The last one is important as the household CFO thinks retrocomputing is a waste of both time and money.
And something easily obtainable would be nice.
Mike
[Updated on: Wed, 13 October 2021 12:25] Report message to a moderator |
|
|
|
| Re: Logic Analyzers?? [message #9200 is a reply to message #9198] |
Wed, 13 October 2021 13:33  |
robg
Messages: 43
Registered: October 2017
|
Member |
|
|
Hi Mike,
I've also been noodling around in the 68K space, and agree that the options for >16 channel logic analyzers are limited.
I'm reasonable happy with the DSLogic U3Pro32 that has 32 channels, and it meets your criteria except possibly the need for a second mortgage. It's currently on sale for $400 USD. It's also available at Amazon (US at least) so is easily obtainable.
The hardware is pretty good. The software, DSVIEW, is okay. On the plus side, it is an open-source fork of the sigrok PulseView app. But it is not as intuitive as I would like. The keyboard/mouse interface for panning and zooming does not make sense to me. The protocal viewing stuff seems a bit obtuse. I've run into bugs related to saving traces in various formats. But at the end of the day it gets the job done and I'd recommend it. (I have no affiliation, etc.)
I've also got an old HP/Agilent 16702B logic analyzer from the mid/late 90s that has an interface that I understand and more channels than I would ever need. But it is so loud that I can't really use for more than 30 minutes at a time. There's a fan mod I should do at some point...
There are other >=32 channel analyzers listed on a sigrok wiki page that you could explore.
-- Rob
[Updated on: Wed, 13 October 2021 13:35] Report message to a moderator |
|
|
|
| Re: Logic Analyzers?? [message #9201 is a reply to message #9200] |
Wed, 13 October 2021 15:16 |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
The DSLogic U3Pro looks like it'd work but the price is pushing my budget. I went ahead and downloaded DSView in demo mode. The interface will take some getting used to but most of it is similar to the Saleae interface. The "Parallel" decoder seemd to be limited to 8 bits, which is a bit short for 24/32 bit addresses or data. I guess one could add multiple decoders, one for each byte, and then reorder them properly to make it easy to read.
I also found the Digilent Digital Discovery on Amazon:
https://www.amazon.com/Digital-Discovery-Speed-Logic-Analyze r/dp/B07RDZL55M/ref=psdc_5011666011_t3_B00CG49P90
It looks like it might work too and is a bit cheaper. Unfortunately, they want your info before they'll let you download the app to try in demo mode. Maybe later.
I hadn't looked on SigROK in a couple of years. Unfortunately, it looks like most of the "supported" HW that has 32 channels is dead. I did look at the Openbench Logic Sniffer a couple of years ago but couldn't find where I could buy and assembled one. Thought about building my own FPGA based one but that would be another development project that took me away from the things I really wanted to do.
Thanks for the pointers. I don't think I've found the "perfect" one for me yet so I'll keep looking.
Mike
|
|
|
|
|
|
|
|
| Re: Logic Analyzers?? [message #9210 is a reply to message #9207] |
Thu, 14 October 2021 15:24 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
mikemac wrote:
"...I couldn't find an Openbench Logic Sniffer but the schematics for it were available..."
Thanks, I searched on that and found enough websites to give it a ponder.
I used a few logic analyzers through the decades but generally have to agree with my mentor/VPE back in the early 1980s who believed that the logic analyzers should be locked up until an engineer could convince him that it was really needed. If you don't make it hard to get hold of, every engineer will invent a need just to experiment/play with one. That would kill ee-lab productivity.
[Updated on: Sun, 31 October 2021 08:58] Report message to a moderator |
|
|
|
| Re: Logic Analyzers?? [message #9211 is a reply to message #9210] |
Thu, 14 October 2021 15:48 |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
jayindallas wrote on Thu, 14 October 2021 15:24mikemac wrote:
"...I couldn't find an Openbench Logic Sniffer but the schematics for it were available..."
Thanks, I searched on that and found enough websites to give it a ponder.
I used a few logic analyzers through the decades but generally have to agree with my mentor/VPE back in the early 1980s who believed that the logic analyzers should be locked up until an engineer could convince him that it was really needed. If you don't make it hard to get hold of, every engineer will invent a need just to experiment/play with one. That would kill ee-lab productivity.
Once eproms were obsolete and we could quickly download firmware updates in-circuit, I found that it was much faster to write a conditionally assembled test routine and run that code get the test information I needed.
Here's another design you may want to ponder: https://sigrok.org/wiki/CoLA
Generally speaking, I prefer using SW techniques for debugging whenever I can. But sometimes you just need some visibility into what the HW is actually doing, not what I think it's doing.
I somewhat disagree with your mentor's philosophy. If you have tools, I feel everyone should be fluent in using them so when the occasion arises, anyone and everyone can help out. Within reason of course. Engineers, being engineers, can find lots of ways to eat up time "playing with toys". But trying to debug a HW timing issue using SW can be a big time sink!
Mike
|
|
|
|
| Re: Logic Analyzers?? [message #9212 is a reply to message #9198] |
Thu, 14 October 2021 19:39 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
mikemac wrote:
"...Here's another design you may want to ponder: https://sigrok.org/wiki/CoLA ..."
That looks interesting... I'll read it through this weekend.
One thing that strikes me wrong with it is the three 34-pin header connectors, doesn't look like a reliable and rugged choice in my opinion for supporting probes that will go every which direction.
[Updated on: Sun, 31 October 2021 08:59] Report message to a moderator |
|
|
|
|
|
| Re: Logic Analyzers?? [message #9218 is a reply to message #9217] |
Sat, 16 October 2021 09:12 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
mikemac wrote:
-------------
"...I seem to be spiralling down the rabbit hole! Can you see why I never get anything built?..."
jayindallas replies:
-------------------
I think that's how you know you're at the cusp limits of current technology... the speeds are not quite adequate for a proper, safe, reliable design.
mikemac wrote:
-------------
"...When you only have 8 channels, I guess those cheap sets of 10 quick clips off of Amazon work well enough. Once you start increasing the number of channels beyond a couple of dozen or so, you're probably going to need to start worrying about cable management..."
jayindallas replies:
-------------------
One way to get around high channel needs to trigger is to insert an early software output signal to trigger a capture and hope that you get the scenario you're targeting in the capture buffer. This can at least improve your odds of capturing the elusive event.
I'd equate it to using a storage scope over and over until you finally capture the elusive scenario that has been driving you nuts. Proves that sometimes an exhaustive loop can be faster than setting up all the conditions and triggers.
[Updated on: Sun, 31 October 2021 09:01] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Logic Analyzers?? [message #9225 is a reply to message #9221] |
Sat, 16 October 2021 14:19 |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
plasmo wrote on Sat, 16 October 2021 13:33mikemac wrote on Sat, 16 October 2021 09:26Looking at all of these analyzers built from a FPGA along with thinking about my next M68K project has given me a new appreciation of the difficulty of the logic analyzer's task.
Don't give up on CPLD,
Bill
Give up? Never! Go away and lick my wounds for a while, definitely! But give up? Nah.
I think I've been making my life more difficult than needed for a variety of reasons:
1) I thought there was a minimum clock speed I could run the CPU at. I thought it was like 80% of the stated frequency. That would have precluded me from slowing the whole system down enough for my 25MS/s Saleae to be useful. I just checked section 12-5 of the user manual and it says the min frequency is 0, periodically sampled but not 100% tested. So I should be able to run it at say 10MHz and have my logic analyzer keep up.
2) Similarly, I thought the SDRAM had to run at speed. None of the datasheets I have specify a min clock speed though. And I know some working designs run the PC100/PC133 SDRAM at the CPU clock rate of 25MHz. So I guess as long as I meet the 64ms refresh interval, I should be able to slow the memory down to my hypothetical 10MHz too.
3) I was trying to run both the memory and CPU at their respective max clock speed. So an asynchronous memory system! That makes things much more complicated. For example, since the SDRAM only outputs valid read data for one of its clock cycles, the output data would have to be buffered and held until the slow CPU got around to latching it. But running things synchronous to the CPU clock makes life a LOT simpler!
Now for #3, I may have to revisit that one if/when I want to add other bus masters. Synchronous probably would still work if everything ran at an integer multiple of a common clock. But PCI's 33MHz doesn't go into the CPU's 50MHz nicely. [ No PCI in the first version or three! Gotta get the basics working first! ]
I'm starting to think I understand enough that I can actually build this thing. And that's always a bad sign! 
Mike
|
|
|
|
| Re: Logic Analyzers?? [message #9226 is a reply to message #9224] |
Sat, 16 October 2021 14:25 |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
Andrew B wrote on Sat, 16 October 2021 13:43The new Parallax Propeller 2 with some suitable circuit to protect its 3V pins might also be an interesting alternative to an FPGA for a logic analyzer.
My system is at 3V so that wouldn't be a problem. I don't know enough about the Propeller 2 to know what other issues might arise. Like are there enough pins? Is it fast enough to sample at a sufficient rate? Does it have enough storage to capture a useful number of samples at the max sample rate?
Added: Is there a way to "latch" all of the inputs at the same time? Reading one GPIO at a time would add a ripple to the timing fo the signals.
Mike
[Updated on: Sat, 16 October 2021 14:29] Report message to a moderator |
|
|
|
| Re: Logic Analyzers?? [message #9227 is a reply to message #9226] |
Sat, 16 October 2021 17:15 |
 |
Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
|
Senior Member
Administrator |
|
|
mikemac wrote on Sat, 16 October 2021 14:25Andrew B wrote on Sat, 16 October 2021 13:43The new Parallax Propeller 2 with some suitable circuit to protect its 3V pins might also be an interesting alternative to an FPGA for a logic analyzer.
My system is at 3V so that wouldn't be a problem. I don't know enough about the Propeller 2 to know what other issues might arise. Like are there enough pins? Is it fast enough to sample at a sufficient rate? Does it have enough storage to capture a useful number of samples at the max sample rate?
Added: Is there a way to "latch" all of the inputs at the same time? Reading one GPIO at a time would add a ripple to the timing fo the signals.
There are 64 I/Os and the status of each block of 32 can be read at the same time with a single instruction which returns a 32-bit value representing the state of all the inputs.
Max sample rate would be dependent on the speed of a tightly coded assembly loop, most instructions take 2 clocks and the chip is rated up to 320 Mhz, so I'd expect you could sample multi-Mhz signals with a tight loop.
RAM is a little tight - 512 32-bit longs per core and 512KB in the hub. But people have been experimenting with external HyperRAM chips.
I think you could make a neat little 16 or 32 channel analyzer and use the other 32 pins for an external RAM to store data.
There was some early experimentation with this back in 2016 (on the FPGA development versions of P2, before the real chips existed) - https://forums.parallax.com/discussion/163967/propeller-2-lo gic-analyzer
[Updated on: Sat, 16 October 2021 17:16] Report message to a moderator |
|
|
|
|
|
| Re: Logic Analyzers?? [message #9247 is a reply to message #9227] |
Tue, 19 October 2021 07:02 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
andrewb wrote:
-------------
"...here are 64 I/Os and the status of each block of 32 can be read at the same time with a single instruction which returns a 32-bit value representing the state of all the inputs...RAM is a little tight - 512 32-bit longs per core and 512KB in the hub..."
jayindallas replies:
-------------------
The propeller might be used to convert the high-count parallel inputs into RLE (Run-length encoded, i.e. how many samples while the each individual input remained unchanged) as vectors(as in APL's definition a set of numbers of whatever count: pin 1: {2,450,2,55} pin 2: {10,10,10...}). That would do enough data compression that it could offload values into an external lesser-high-speed memory, as its buffers grow.
Generally the method would be to keep two images of the last two 32-bit IO port reads. They alternate being the LAST read and the CURRENT read image. Read/store the CURRENT, XOR with the LAST, the 32bit result of 0's and 1's mean respectively, are shifted into a carry flag to determine the action for each IO bit. If there is an index counter that can point to a set of 32 ram values to be each ports current RLE count, then a loop shifting the 32bit XOR result into the carry flag, would trigger what is done for each 32 32-bit counters. 0 bit means no change of level so just increment that IO ports counter, 1 means a change of level has occurred to that counter is done, and moved to an appropriate RLE buffer compressing it, then clear the counter for that port signal.
If you want to do even better compression, set up an automata theory method to ensure no ambiguity when decoding. Your goal is to use a single bit pattern for each time the counter runs past a selected max count. 00h now represent 8 times through the selected count maximum. For long duration signals, they'll be mostly composed of these and within the automata construct, as a leading string of zeroes, then perhaps a 1 bit to denote that the last sub-max count value follows as an x-bit binary value. This can be better than big count values that 32-bits can give you. You just do the math or tune it to be most efficient. Or use a mode selector for a automata construct that is better for each type of selectable settings.
P2 Doc: "...64-bit free-running counter which increments every clock, cleared on reset..."
With a free-running clock you don't need to increment counters for each unchanged signal. This requires you instead to save the last transition counter value for each sample signal. That calculation can be handed off to another cog so the sampling remains clean.
[Updated on: Sun, 31 October 2021 09:06] Report message to a moderator |
|
|
|
|
|
| Re: Logic Analyzers?? [message #9276 is a reply to message #9273] |
Fri, 22 October 2021 22:08 |
cluso99
Messages: 40
Registered: June 2017
|
Member |
|
|
The P2 has 8 32bit cores (called cogs).
Each pair of cores can share 2KB between them directly as dual port 32bit RAM.
All 8 have 4KB of which 512 x 32bit can also be used as registers.
All 8 also share a common 512KB hub RAM. They can also run code from here (called hubexec) with a rather ingenious parallel access (called egg-beater).
P2 can run at over 360MHz when overclocked. Each instruction mostly takes 2 clocks so we have 8 cores * 360MHz / 4 = 1440 MIPs.
There are also internal DACs and ADCs - VGA uses 5 I/O pins and no external resistors are needed.
Each of the 64 I/O has a smartpin circuit which can do special things!
And then there is a streamer for each cog capable of shifting data in or out 32bits per clock.
P2 has been in production for more than a year.
see forums/parallax/com for more info.
BTW there are a couple of logic analyser code examples which might be useful.
[Updated on: Sun, 24 October 2021 14:34] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Logic Analyzers?? [message #9371 is a reply to message #9291] |
Tue, 09 November 2021 08:29 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
====================
QUESTION: CAN A P2 SYNCHRONIZE a 64 IO SAMPLE?
====================
It appears the answer is YES, using 2 cogs, each on standby to sample alternate sets of 32 parallel IO pins into a 32b long values. The standby state is released and synchronized by an EVENT that releases a WAIT-EVENT instruction. When the EVENT occurs, both cogs begin executing their next instructions, one cog sampling the high 32b parallel IO pins while the other cog samples the low 32b parallel IO pins. The WAIT-EVENT would be a CT1/CT2/CT3 count (*1 see note below), which would be the period of sampling. This construct would be faster than an interrupt construct which has additional clock cycle overhead.
These two cogs (of eight) would grab the samples, front-load any data that can be passed to other cogs to quickly expand the parallel processing power of the P2, and then be available to do further processing with any excess remaining time before they return safely to standby, awaiting the next sample WAIT-EVENT.
I'm assuming a design that maximizes P2 capability to convert 64b parallel IO samples into an encoded image stream fed over USB to another processor that would store the image collection and run the man-machine interface capable of providing rich features in a nonrealtime, post processing manner, thus another cog would be used to USB-stream the encoded image output from the P2. If the USB-downstream processor is a typical computer, all the better.
That leaves 5 other cogs for processing the sample and encoding it into that stream plus any excess available processing time this 1 USB-streaming cog may have. In this approach, the USB streaming time is the potential timing bottleneck. Clever encoding and p2 algorithm design should overcome this bottleneck. If not a twin USB-stream may have to release the bottleneck; though less desirable.
*1 - The documentation on CT1,CT2,CT3 is poor. I'm assuming its the upper 32b of the 64b free-running counter/timer. The documentation is ambiguous at best and I don't need the question resolved immediately so I'm just assuming its fast enough, for now. There are other ways to create EVENTS faster than the CTx set. An external clock signal, internally synchronized via SMART PIN setting could be one solution, though it eats a 64th pin. If I find a better alternate solution other than CTx set that does not give up a full 64b IO sample, I'll update this message. After all, anyone would buy a 64pin Logic Analyzer instead of a 63pin Logic Analyzer because that's just the way consumers think.
POSTNOTE:
=========
I'm not designing a logic analyzer. I'm doing another P2 design that's similar and of particular interest to me, to get an appreciation of what the P2 can offer. I'll write to this topic when I learn P2 capabilities that would be useful to a logic analyzer design.
[Updated on: Wed, 10 November 2021 20:49] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Logic Analyzers?? [message #9445 is a reply to message #9443] |
Wed, 01 December 2021 19:57 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
quarterturn wrote:
"...I like my HP 1630D logic analyzer...I have a soft spot for vintage CRT stuff..."
jayindallas replies:
I liked the crisp crt screens on the early 80s logic analyzers. I used a tektronix logic analyzer that had a tiny screen but it was great for the speeds of MultiBus back then. However I'd rather have HDMI and modern comm options now.
I have a soft spot for Z80/64180s. I bought a Z80 S-100 kit at college and taught myself about microprocessors, there were no classes about it yet. After graduation I bought Z80s then 64180 systems for home.
[Updated on: Fri, 03 December 2021 14:48] Report message to a moderator |
|
|
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
