Agilent MSO 5000/6000/7000 - anyone hacked these scopes?

[abyrvalg]

Excellent! The pins are close to each other, check nearby signals (Y3, W1-W4) - where do they go? This can be much easier than decompiling
Decompilation shouldn't be so hard - we don't need entire design in Verilog, just identifiing pins that feed the same piece of logic that our known pins do should be enough.

So that JTAG header is dedicated PROM programming connector. Perhaps there is some debug header that goes to FPGA's JTAG?

[mikeselectricstuff]

Excellent! The pins are close to each other, check nearby signals (Y3, W1-W4) - where do they go? This can be much easier than decompiling
Decompilation shouldn't be so hard - we don't need entire design in Verilog, just identifiing pins that feed the same piece of logic that our known pins do should be enough.

So that JTAG header is dedicated PROM programming connector. Perhaps there is some debug header that goes to FPGA's JTAG?

Possibly on that MICTOR connector?

[Carrington]

I have taken these photographs, they can serve as a reference or comparison.
Unfortunately, the legend on the smaller components, can't be read... LOL, I need more megapixels.

[Carrington]

Rear side:

[taemun]

It's possible (although... insane?) that the FPGA JTAG isn't broken out, and it just reads the bitstream from the XCF chip on boot.  Not sure how they debugged the FPGA in-circuit, or maybe that was all done by the time this board was laid out.

[Carrington]

It's possible (although... insane?) that the FPGA JTAG isn't broken out.

The FPGA pins TMS, TDI and TDO are not directly accessible (no via).

No via, but this pins have a PAD, I don't know if that's what you mean.

[taemun]

Well they'll have a pad for mechanical/soldering reasons - they don't have to be attached to anything else on the board. I meant "broken out" as in "going to a header".

[Carrington]

Well they'll have a pad for mechanical/soldering reasons - they don't have to be attached to anything else on the board. I meant "broken out" as in "going to a header".

Ok, now I understand, but, no idea.

[tesla500]

Isn't the config flash chained up with the FPGA JTAG? I seem to recall the platform flash can be programmed directly via JTAG. Is J2600 near the flash the JTAG for the FPGA/flash?

[Carrington]

Is J2600 near the flash the JTAG for the FPGA/flash?

J2600 appears to be only for the flash, but it is also connected to the CPU (at least TCK).

I seem to recall the platform flash can be programmed directly via JTAG.

I don't know...

Isn't the config flash chained up with the FPGA JTAG?

Apparently not...


And no idea of what is connected to the MICTOR connector.

[abyrvalg]

In theory if everything was debugged on some special debug board, then there is no reason to have that jtag accessible on production version. Just route PROM's jtag to a header for initial/repair programming and to the CPU for regular updates (as I wrote before, CPU uses simple GPIO bitbang XSVF player to update that PROM).

[Carrington]

In theory if everything was debugged on some special debug board, then there is no reason to have that jtag accessible on production version. Just route PROM's jtag to a header for initial/repair programming and to the CPU for regular updates (as I wrote before, CPU uses simple GPIO bitbang XSVF player to update that PROM).

Well that's what it seems they did.

[tesla500]

The FPGA JTAG pins are all on the outside edge of the part, so as long as they haven't been grounded, you could possibly insert pin probes at the edge of the FPGA and connect to the JTAG, whether they've been brought to vias or not. Some very fine jig work would be required though.

[Carrington]

The FPGA JTAG pins are all on the outside edge of the part, so as long as they haven't been grounded, you could possibly insert pin probes at the edge of the FPGA and connect to the JTAG, whether they've been brought to vias or not. Some very fine jig work would be required though.

Good idea, you're right. I'll try. 
First, I will try to "make" a probe, to do that.


I leave it for today.
Cheers.

[mikeselectricstuff]

The FPGA JTAG pins are all on the outside edge of the part, so as long as they haven't been grounded, you could possibly insert pin probes at the edge of the FPGA and connect to the JTAG, whether they've been brought to vias or not. Some very fine jig work would be required though.

Good idea, you're right. I'll try. 
First, I will try to "make" a probe, to do that.


I leave it for today.
Cheers.

..or at least use to find where JTAG pins are brought out.
I can't believe they wouldn't have put JTAG somewhere accessible - there's a Mictor trace connector (probably not fitted on later models), and it could be that the JTAG chain passes through other chips, but I'd be highly surprised if it wasn't there - there's just no way anyone would leave such an important interface off such a complex board.
 

[tesla500]

..or at least use to find where JTAG pins are brought out.
I can't believe they wouldn't have put JTAG somewhere accessible - there's a Mictor trace connector (probably not fitted on later models), and it could be that the JTAG chain passes through other chips, but I'd be highly surprised if it wasn't there - there's just no way anyone would leave such an important interface off such a complex board.
 

I have to agree, it would be stupid not to wire up the FPGA JTAG. It's easy to confirm if the JTAG pins are chained up with the FPGA or not, just measure from the XCF pins to J2600. Perhaps there's a config bit that makes the FPGA JTAG a passthrough? If it became a passthrough it wouldn't show up in the chain.

[abyrvalg]

The FPGA JTAG pins are all on the outside edge of the part, so as long as they haven't been grounded, you could possibly insert pin probes at the edge of the FPGA and connect to the JTAG, whether they've been brought to vias or not. Some very fine jig work would be required though.

Even no need to go under the edge, those vias at the top side of BGA edges go to underlying two outer ball rows, just scratch the green mask a bit to reveal copper.

[Carrington]

The probe was a success. Is a piece of enameled wire with a diameter of ~0.3mm, with the tip bent 90º, see attached image (probe.jpg).

Vias and pads are aligned, but the trace that join them not always join the adjacent via with the adjacent pad, see attached image (bga.jpg).
For this reason some of the connections mentioned in my previous posts are incorrect. I'm going to edit these posts, now. Leaving only the connections that are correct for sure.

These are the good news, see attached image (FPGA-JTAG.jpg). Now I just have to follow this traces.

[Carrington]

The FPGA JTAG seems to be forming a chain with the ASICs and CPU JTAG (excluding XCF04S). This chain could be accessed from the Mictor connector, but this circuit (the chain) is not fully implemented. Looks like Agilent only fully assembled this circuit, if necessary, adding and/or removing some components (probably some resistors). I think that the Mictor connector is mounted, because add it manually later must be hard.

The JTAG connector J2600 is exclusively for the XCF04S, but CPU also accesses this port.
The connector J2400, also seems to be connected to the CPU JTAG.

TMS and TDI (FPGA) are connected to the ASICs U29000, TDO ends on a open jumper between the FPGA and the Mictor, and I have been unable to find where TCK goes.
However I don't think that it matters...

Also seems that the front end is controlled only by the CPU (at least a part).

[mikeselectricstuff]

I think that the Mictor connector is mounted, because add it manually later must be hard.

This connector is probably only for software development/debug - I've only seen it fitted on my early 6034, not on later 6012 or 6034.

[Carrington]

This connector is probably only for software development/debug - I've only seen it fitted on my early 6034, not on later 6012 or 6034.

Probably.


The input stage (with a bit more detail).

[abyrvalg]

Also seems that the front end is controlled only by the CPU (at least a part).

Do you see any direct CPU-frontend traces there? From sw side it looks more like all channel hw is controlled throught "Ponderosa" chips (ASICs closer to CPU). ADC ("Talon") control paths are seen as long serial shift registers chains attached to Ponderosas.

Talons looks same for all BW options, there is a calibration function that temporary configures them to maximum sample rate regardless of model, takes some measurements, then sets back to model-defined values. So BW limiting should happen somewhere in the frontend. Maybe we should measure and compare levels on 1NB7 pins of 6034 and 6012?

[Carrington]

Do you see any direct CPU-frontend traces there?

Yes, some traces go straight from the CPU to the 74ACT174s.

From sw side it looks more like all channel hw is controlled throught "Ponderosa" chips (ASICs closer to CPU). ADC ("Talon") control paths are seen as long serial shift registers chains attached to Ponderosas.

Surely also uses "Ponderosa".

Talons looks same for all BW options, there is a calibration function that temporary configures them to maximum sample rate regardless of model, takes some measurements, then sets back to model-defined values.

Interesting...

So BW limiting should happen somewhere in the frontend.

I also think so.
But the question is: What chip sets the BW? CPU, FPGA, ASCIs or 1NB7-8453. And how? A command, a jumper, ...

Maybe we should measure and compare levels on 1NB7 pins of 6034 and 6012?

Unfortunately the 6012 does not use the 1NB7. The 1NB7-8453 is mounted on the 603*s, 605*s and probably on the 610*.


This frontend is not from a 603*, I don't know to which model belongs.

[mikeselectricstuff]

I had a recollection that there was something odd about the 6104 so I re-read the datasheet and spotted this :

MSO/DSO601xA/603xA: 2 GSa/sec each channel
MSO/DSO605xA/610xA: 4 GSa/sec half channel*, 2 GSa/sec each channel
....
*  Half channel is when only one of channel 1 or 2 is turned on, and only channel 3 or 4 is turned on.

This would suggest that on both the 6054 and the 6104, it uses the whole ADC, and maybe both input amps for one channel instead of muxing it between 2 channels.
I suspect that the omitted, bypassed, relay on the 6034 is to connect the two inputs together to feed into the two parallel channels. Would be pretty easy to check this.
I think this means that you're probably more likely to be able to upgrade a 6054 to a 6104 than a 6034 to a 6054, however I expect the 6054 and 6104 differ mostly by the frontend - really  looking forward to seeing Tesla500's 6104 pics - make sure you look under those cans (assuming they haven;t soldered them for 1GHz!)

 

[tesla500]

Here's an imgur album of MSO6104A images

http://imgur.com/a/7vAeG

This scope is (I believe) from 2006, I purchased it in 2008 from Newark as a refurbished former demo unit. I figured if it survived being shipped around so much it's probably pretty solid. They stupidly listed a bunch of them on ebay at the same time with no reserves, got it for $5k. All the future auctions had reserve prices after that  They even gave me a free 8M upgrade because the listing said it had that, but it only came with 1M enabled .

Uses a different hybrid than the others, 1NB7-8477.

Edit:
Found a pic of the hybrid with the top popped off. I wonder what scope that's from, and what they're trying to do with those coax cables soldered onto the outputs?