how to cheaply-LA a 90s 32 bit board?

[DiTBho]

So, my professional customer's boards at work (Windriver) provide convenient headers for attaching logic probes, and they connect directly to HP-logic analyser pod adaptors.

Execellent but
- being Windriver, it needs a very expensive license
- being HP provessional equipment, it's very expensive (and cannot find one on eBay)

At home I am trying to resurrect and repair a damaged IDT MIPS board (1992) saved from the hydraulic press.
One of the peripherical chip is dead and I am trying to replicate with an FPGA (thanks god it's 3.3V), but timing is not documented, and I need to monitor the bus.

Furthermore, the original firmware is also gone as the UV-EPROM was exposed to sunlight without any protective label, resulting in the complete deletion of the contents (I only read 512Kbyte of "0xFF").

At the moment, I am using a ROM-emulator to test the minimal functions
- RAM
- ROM
- CPU
- Uart

This stuff all work, but I can't use the timer0, the PIC and other devices, including the 4 char alphanumeric LCD, because either they through the multifunction chip that is dead, or they passes through a chip whose register mapping and response I don't know.

That's where a LA is *very* usefull, and, good news, the board is already equipped with a connector and an optional additional DBG-board which allows you to hook up a logic analyser to the main address and data bus with minimal interference with normal function of the logic. The clock is 25MHz clock rate, a modern LA shouldn't have difficulties to capture signals with very short setup and hold times, and on my DSO I see there is a little circuit on the DBG-board that generates "strobes" to capture address and data, and to trigger the test equipment.

Code: [Select]

d00
..
d31

a00
..
a23

rd/wr
/slot

fc0
..
fc3

clock@25Mhz
signals on the asynchronous bus

However, we are talking about a 6 layers PCB and 64 channels at least, so ... what to use? 

[alm]

Parallel buses with this high channel count is what the HP/Tek/Biomation/Philips/etc  boatanchors were made for until they were killed by buses becoming internal to the processor and going serial, so that'd be my choice.

Your speed and channel requirements aren't crazy, so if you have the space I'd think you could find something in the HP 1650/16500/1670/16700/1680/1690 (Firewire) series with decent memory depth or equivalents from other manufacturers for cheap. Before 1680/1690 HP used m68k and PA-RISC (16700), so you might like the architecture . Inverse assemblers are available but usually only for contemporary processors, and sometimes need rare adapters that massage the bus into something easily translatable (e. g. bring out certain flags).

Get something with cables and pods with fly leads. The HP 40 pin pods are available but add up if you need many. Other brands tend to be less available. Adapters to Mictor or 0.1" square pin headers are usually not too expensive in my experience. Shipping might be the highest cost.

If you're looking for a project, you could design your own with an FPGA and external memory. The logic Sump or Openbench Logic Sniffer might serve as inspiration. Buying a 64+ channel solution new will probably be expensive given how much new equipment needs that many channels.

[iMo]

Or take an existing fpga you have handy, and simply connect its pins with the internal LA - ie the ChipScope in Xilinx (it will be generated for you automatically, you need to assign the signals to the internal LA, at least 4x256 signals available, afaik) while you will see the signals on the pins directly in your IDE (like ISE14 or Vivado, or Lattice has an internal LA as well).

You wire the fpga's pins to your DUT board and you will get an LA.

Just a crazy idea..

[alm]

Or take an existing fpga, and simply connect its pins with the internal LA - ie the LogicScope in Xilinx

Interesting. What kind of memory depth can you expect at sample rates like 100 MS/s and up?

[iMo]

Or take an existing fpga, and simply connect its pins with the internal LA - ie the LogicScope in Xilinx

Interesting. What kind of memory depth can you expect at sample rates like 100 MS/s and up?

Would your old HP LA capture 65 signals at 100MSamples/sec and up?

[alm]

Would your old HP LA capture 65 signals at 100MSamples/sec and up?

Yes, the oldest one I listed, the 1650A samples 80 channels at up to 100 MS/s timing, 25 MS/s, though I believe memory is only 1kS, but with a form of run length encoding to compress data. But we're talking 1987 technology here.

The late eighties / early nineties 16500(C) can go up to hundreds of channels at 500 MS/s timing, 140 MS/s state with 2-4 MS memory depth.

The late nineties 16700 with the right cards can go up to hundreds of channels at 2 GS/s timing, 400 MHz state with 32 MS memory again with optional RLE. Getting the right cards is not so much a matter of price but more getting lucky to find an offer with the right cards and finding working cards (there's a long topic about corrosion under the runners on the cards on this forum).

The lower end Windows-based (embedded or external) 1680/1690 series can go up to 800 MS/s timing with 68 channels or 400 MS/s 136 channels with 2-4 MS of memory.

These are the machines computers were designed with from the from the seventies until the early 2000s until developments like PCIe and internal memory buses made them obsolete, so you can usually find them fairly cheap if you're patient. You'll see CPU speeds of that era tracking logic analyzer development (or the other way around): The 140 MS/s starte analyzer module was to support 133 MHz CPUs.

OP was talking about a 25 MHz bus, so I think something like 100 MS/s timing or 30 MS/s state is in the ballpark.

What can an FPGA do with its built-in (into the dev tools) LA? Is it more in the ballpark of the original Saleae Logic?

[SiliconWizard]

For 64 channels, you'll be in the expensive LA territory - or old equipment that may or may not work.

Ones of the few current and affordable LAs I know of with 32 channels are these: http://www.zeroplus.com.tw/logic-analyzer_en/products.php?pdn=1&product_id=765
I don't think they have a model with more than 32 channels, but maybe you can connect several of them and trigger them in chain, not sure.

(I have a DSLogic plus that I talked about before -16 channels though.)

[DiTBho]

For 64 channels, you'll be in the expensive LA territory

I don't have all the documentation, but I read up to 1994, engineers developed around MIPS R4K with something like ~70 lines on the LA, with the clock signal that went from 25Mhz to 50Mhz!!! And we are talking about the early 90s! I cannot find any document about the "expense report" for the laboratory equipment, but certainly the development of these boards I have in my hand cost in the order of >50K modern euros.

You can imagine my feelings when I saw this board abandoned in the cold rain in a box chewed by rats,
which are most likely responsible for shredding the paper manuals that weren't thrown in the "shredder".

[DiTBho]

Or take an existing fpga, and simply connect its pins with the internal LA - ie the LogicScope in Xilinx

Very interesting, it seems brilliant to me, if it works it could be the solution to all my problems!!!

I have to understand if it is possible to slow down the bus cycles by lengthening the wait-states. If it were possible, you could acquire up to almost fill a FIFO implemented into the fpga (with all the BRAM? external synchrounous memory attached to the FPGA?), pause the target bus, and take the opportunity to download the whole train of data to the host.

Maybe the DBG-board can force longer wait-stage cycles!
(I wish I had the manuals!!! damn mice!)

[alm]

I don't have all the documentation, but I read up to 1994, engineers developed around MIPS R4K with something like ~70 lines on the LA, with the clock signal that went from 25Mhz to 50Mhz!!! And we are talking about the early 90s! I cannot find any document about the "expense report" for the laboratory equipment, but certainly the development of these boards I have in my hand cost in the order of >50K modern euros.

That might have been the HP 1650 or 1660 series with 1-2 kS or 4-8 kS of memory (with optional RLE/transitional timing) up to 500 MS/s timing mode sampling rate. According the HP 1994 catalog that would have cost $8.5k for 68 channels and $10.9k for 102 channels. Add another $6.4k for a two channel 250 MHz 1 GS/s scope with 8 kS sample memory.

If you wanted more memory depth in 1994, then you would buy a 16500B mainframe ($8.8k) plus 4x 16542A 16-channel 1 MS 100 MS/s logic analyzer cards ($8.5k each). If you wanted to go crazy, you could add an extension frame for a total of 10 cards between the two units for over 1000 channels. I'm guessing those were mainframe computer applications.

[DiTBho]

umm, a secondo problem: the software to monitor the bus!

Those HP machines are(1) for 68k, while in my case I have MIPS signals and opcode.
Plus, all the lines used by the DBG-board need a program to be decoded and used.


Ummm, I'm more tempted to use several LA drives in a chain(1), the kind I can write the software myself

4x 32 channels?
8x 16 channels?
16x 8 channels?



(1) they are modular machines, so they probably also had other modules for other architectures.
However, it seems that you can find more easily (or only) modules for 68k.

[DiTBho]

Maybe the DBG-board can force longer wait-stage cycles!
(I wish I had the manuals!!! damn mice!)

Found a paper manual: the DBG-board can force longer wait-state cycles!
Excellent!

[alm]

umm, a secondo problem: the software to monitor the bus!

Those HP machines are(1) for 68k, while in my case I have MIPS signals and opcode.
Plus, all the lines used by the DBG-board need a program to be decoded and used.

No, HP machines have software support for a wide variety of CPUs, but support for some was shipped by HP, while others were sold by third parties and are probably unobtanium by now. Now in addition to the software you often need a hardware interface between the processor / bus and the logic analyzer blade that translates signals from the CPU to something easily usable by the logic analyzer. For example extracting address information even when the address bus is internal to the processor.

Finding the dedicated pre-processors that might only fit a single model from a CPU family is going to be a pain for any logic analyzer. It might be worth looking if someone reverse-engineered them, or if you can live without inverse-assembly. I don't think any of the affordable options that are currently for sale offer inverse assembly at all, so you'd be no worse off. In both cases you'd just get the raw bits/words.

[DiTBho]

so, let's assume you'd better use several LA units with Open Source support and write the software by yourself.

I wonder how expensive and feasible it goes this way 

[alm]

so, let's assume you'd better use several LA units with Open Source support and write the software by yourself.

Try to find analyzers that have a good input circuit that doesn't load the bus too much at these speeds and that have a state mode in hardware that is fast enough (25 MHz?) in addition to a timing mode. Inverse assemblers and decoders are simpler if they have one sample per clock instead of having to solve the additional problem of extracting data on the edges of the clock yourself, and the requirements on the sample rate and memory depth will be lower. Unfortunately not many of the cheap logic analyzers offer state mode.

[artag]

so, let's assume you'd better use several LA units with Open Source support and write the software by yourself.

I wonder how expensive and feasible it goes this way 

The problem with using multiple analyzers is that they all need to sample at the same instance. The cheap ones don't have an external clock so you have to use a channel (one from every analyser) to oversample an external one and then put the recordings back together in software.
The only software I know of that does this is ngscopeclient, and that currently has very limited support for capture devices.

[DiTBho]

25 MHz?

yes, 25Mhz is the max freq.

[DiTBho]

Just found that activating the debug-mode on the DBG-board forces the CPU-module to display the instruction stream addresses on its bus during idle bus cycles!

Great! You can extract them!

[Doctorandus_P]

You only need so many channels if you want to do complete state analysis.

If you are just interested in getting the timing right (or verifying it), then a bunch of control signals is most of what you need, and you can use "extra" channels for capturing a few of the data and address bits, but you don't need all address and data bits for this.

[DiTBho]

You only need so many channels if you want to do complete state analysis.

If you are just interested in getting the timing right (or verifying it), then a bunch of control signals is most of what you need, and you can use "extra" channels for capturing a few of the data and address bits, but you don't need all address and data bits for this.

There are several things I need to worry about.

Timing is one of them, but I also have to reverse engineer some ASIC chips that I can't find any documentation for, so I have to sniff their reaction in terms of signals they move(2), plus both the address and the data going in and out of them, and even at the CPU-side that's something I can't do via an EJTAG because the CPU doesn't support it.

I don't have the manual of the main ASIC chip and certain things are not documented in the board manual, so I go ahead blindly; after several attempts, I recently figured out how to force the main ASIC to map "ROM0" to its maximum mappable address space (512Kbyte, not cached), and thanks to that I'm slowly making progress thanks to an EPROM Emulator that speeds up the uploading my replacing firmware, as the network part still doesn't work properly(1) and I need more than 128 Kbytes for a decent gdb stub, a monitor and a udp/ip stack + ethernet driver for the tftpboot client.


edit:
(1) you need to configure the PHY, which again is not documented.
It's memory mapped, here I can try to deassembly the original ROM, but it's a full mess up.
If course I'm studying it, I can load whatever I need via the EPROM emulator and with the original ROM I can also try to sniff what the CPU puts into the PHY registers when it configures the lan. Sniffing with GDB is not possible on the original ROM, because it's neither relocable nor not copied in RAM.
Here, an EJTAG would be more helpful, if only the CPU supported it ...
(2) hw-side, I'm afraid I'll have to replace some components with a CPLD. Also, if I want to expand the bus, there is a bus protocol, again, undocumented: you have to smiff the signals, understand them, and replicate them in your CPLD device.