Re: ESR Meter - Roll your own - ESRrev0.JPG

Considering the low impedances involved, could we add that it must be a four terminal design, so that it might actually work without having to be soldered to the parts being tested?

Never heard of VMX. What's that?

Here's a cute little digital delay generator...

Check out the specs compared to the SRS or Signal Recovery or Greenfield or Quantum Composer boxes. Getting the insertion delay and jitter down were pretty hairy, actually. I'd explain our phaselock algorithm, but you'd think it stinks.

Just now I'm working on a 4-channel arbitrary waveform generator in the same box, with the same ethernet and stuff. I'm considering a whole line of PoE based instruments, since it would be fairly easy to flip a lot of our existing analog front-ends and signal-crunching code into a different context.

C'mon Fred, show us some stuff you've designed. I think maybe you're like a fat, lazy couch potato who eats Fritos and drinks Bud and criticizes every move that real football players make.

Get off your butt and design something! You'll feel better.

John

Why not make it a group project, for real? I'd be willing to do the first cut at schematic and algorithms. What we really need is someone to hack the real code; I hate to program, and I'm going to do it most of the weekend likely [1], so I'm not going to volunteer for that part!

I'm sure Fred would make valuable design contributions.

But no ASCII art! We can just post sketches to abse.

John

[1] statistical analysis of some FPGA configuration patterns, leading up to a fast, small compression/decompression algorithm. We need to fit an application program and 8 megabits of Xilinx config stuff into a 4 mbit Eprom.

Yup, it should be 2/4 terminal. Somebody makes some sorta-affordable Kelvin clips. I'll try to find the source.

John

Ummmm...maybe I mean VMI (VXI)? But I know that acronym mainly as Virginia Military Institute:-)

OMG, that would be too much study to just ending up conceding your end products have excellent performance, despite the ugly ways you use to get there...

I'm just not interested in designing anything, it's too much like work.

I think Xilinx has some stuff on their site regarding compressing FPGA patters. IIRC, they're quite compressible, easily (RLL or some such).

--
  Keith

It looks logical that it would be your task to do that research and post a concise summary of requirements.

John

I'll volunteer, on provision that you, and anyone else contemplating a serious contribution, read a few things so as to understand the problem domain (testing, and in particular in-circuit testing of e-caps) better.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
Dave M
MasonDG44 at comcast dot net  (Just substitute the appropriate characters in the 
address)

"In theory, there isn\'t any difference between theory and practice.  In 
practice, there is."  - Yogi Berra

Please No, I specified ACII drawings because they're available to everyone to view, and because then the drawings and conversation is archived. It also has the huge advantage that we can comment on circuit details, while the reader can see the circuit, right in the post. Finally it's actually quite easy. You can do it John! Same for you Jim.

Agreed. My circuit will be four terminal.

I'm going to post at least one complete circuit, and it won't use any algorithms. I'm more interested in seeing several circuits. Contest or perusal, call it what you will, but I prefer a tour to a committee meeting.

It will be especially easy if we talk about functional sections of the circuit, rather than starting out with the whole system. Someone with lots of ASCII experience can build up larger drawings as the component sub systems get distilled. I have no use for contests, but arriving at a practical design by group consensus is something I can definitely learn from and probably build.

I'm looking for something that will be fast and easy to decode at fpga config time.

I just did some statistical analysis of a bunch of existing Spartan 3 bit streams. If you treat them as bytes, and histogram the byte codes, there's some impressive stats, with code 0x00 of course dominant, then

0xFF, and the next 16 most common codes huge, tapering off pretty hard. That makes sense, since LUT bits are usually zero, so simple codes like 0x01...0x80 and simple 2-bit combos are most common. Block ram is usually 0 in our designs, too. So a fixed dictionary should work pretty well.

So it looks like a byte stream would do, with byte codes that say stuff like...

00000000 end of file

001nnnnn make N zero bytes, N=1 to 31

010nnnnn make N 0xFF bytes, ditto

011nnnnn the following N bytes are raw, unencoded stuff

1nnnnnnn look up code N in dictionary, N = 1 to 127

where the dictionary is a list of the most common 96 single bytes followed by the most common 32 byte pairs. Net compression in this case is just about 1:1!

Something like that.

Now the question is, how much compression will this give? I suppose I'll have to code it and see. I need less than 2:1 now, and that shouldn't be hard.

John

It should be very simple, a sharpie sketch on an a-size sheet of grid paper, neglecting the display maybe.

John

Is it intended to be used in-circuit?

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Run-length is pretty simple. The reason this caught my eye was we were looking at doing some invention here. As it turned out there was no inventing to be done because the problem was so simple.

I think you'll find that it's not only a byte of '00s' that's dominant, but *many* bytes. IIRC a '0' turns off a passgate and '1' on. There are *MANY* more off passgates than on. This, and the fact that many cells aren't used at all (even columns), makes run-length work out very nicely.

That should be a piece of cake. Again, look at the Xilinx app notes. I remember there being more information in there. Watch bad encoding though. Bad things happen to FPGAs with random bits set.

--
  Keith

Depends on what you want to use to unpack this, and what from.

Are the cells 8 bit multiples in size ?

Run-Length coding can work well, and even an extremely simple form like (eg) a 12 bit RLC field of

nnnnVVVVVVVV

where nnnn loads a counter (can be non linear - ie mini-table) and repeats the VVVVVVVV pattern until the counter hits zero, then another frame is fetched from the SPI memory.

That sort of coding can fit into a CPLD/Serial FLASH combo, which can give fast loading, and usefull compression.

Dictionary based compression needs table storage, so is more suited to small uC. Config clock speed is likely to be lower. (if that matters?)

-jg

An PC will build a rom image from uP hex code (S28 files, from an assembler) and one to as many as 6 FPGA config files (.RBT files, from the Xilinx tools) We burn a rom and it gets plugged into the end-product. At startup time, the uP code runs and early-on it will unsquash the compressed FPGA configs and load the chips, usually by bit-banging a parallel port. This can take several seconds already, so I don't want to slow it down much more.

The bit patterns in a Xilinx config file sure look like they are.

That requires treating the squeezed data as a stream, which is a nuisance to unpack, and has a lot of overhead in the "random" regions of the config data. The data tends to be long runs of 0's and clumps of messy stuff. I'm thinking that a byte-oriented dictionary thing might be able to have roughly zero overhead in the data clusters, and be very efficient in coding the long runs of zeroes and the occasional

0xFFs. But if bytes do tend to repeat, there might be a way to express that and pack a little better.

This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a couple of hundred bytes in rom maybe. My whole application program, tables and all, comes in under 10K bytes!

John