Re: board - T562.jpg

Rob, my best FPGA guy, has given up on using the Xilinx 8.2/sp3 IDE software... it's way too flakey. But he says the underlying chunks work fine from the command line, so he put together a "make" thing to process the chip we're working on. So it looks like the core fpga-crunching software was coded by people who know what they're doing, and the IDE wrapper (which runs in 90 megabytes of ram!) was coded by Windows programmers.

John

Reply to
John Larkin
Loading thread data ...

How do you synchronize the input clock with the internal CE signal? If it is not synchronized, couldn't you get nasty splinter pulses?

How do you control the timing of the delay line? Is the timing window that you can work in pretty wide?

Reply to
rickman

The gate signal is totally async to the clock. We're sort of hoping that the output of the logic block is either going to go high or not. A metastability glitch within a Spartan3 flip flop is (optimistically) narrower than the inter-cell routing can propagate. We'll have to try that and see. I could put setup and hold time requirements on the trigger gate specs, and make it the customer's problem!

The downstream logic has to work at 80 MHz max. So if we experimentally tune the BUFG output width to, say, 4 ns, we should have a pretty good margin both ways. Most silicon processes seem to be pretty stable these days.

I suppose we could make the delay tunable through a register our uP could write, and we could check a test point now and then to make sure we have it right. Just a mux selecting delay-line taps would work. We only need to do this once in the product, and it's important, so this is worth some hassle. The trick is, I suppose, to only take risks when you really need to.

John

Reply to
John Larkin

Seems the GUI-mafia just love RAM.. :)

Reply to
pbdelete

I'm not sure I understand your problem, so I'll ask a few more questions. What is the speed of the clock in the design? How often does the internally clocked CE signal gate the external signal to generate a clock pulse? If the external signal will not generate a clock edge on every internal clock there might be an easier way to do this that does not depend on timing delays. It can generate a clock enable signal that is asserted on every other clock cycle. But this may or may not work for your application.

Reply to
rickman

The product is a digital delay generator. Given a customer trigger, it generates four pulses, each programmable for delay and width from the trigger. There are three clock nets on the chip:

  1. Trigger, qualified by a separate gate signal, firing this one-shot. This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This drives a bunch of logic, including optional gate/countdown/burst logic, all of which starts...
  2. A non-continuous delay-generator clock. Following the trigger, we start a gated 50 MHz oscillator that's used to time out 8 coarse delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip analog fine delays trim the actual edges to 10 ps resolution. This 50 MHz clock is phase-locked to...
  3. A 40 MHz clock, from a TCXO.

A digital PLL thing longterm locks the customer-triggered 50 MHz clock to the local 40 MHz crystal oscillator but keeps the 50 MHz thing phase-coherent to the customer trigger, so the delay outputs don't jitter.

Given all these clocks, and all the signals making multiple passes on and off the chip, we're getting output jitters in the ballpark of 50 ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8 ps range, but their critical paths are power-hogging PECL.

Generating accurate, low-jitter delays from a random trigger, but with crystal-oscillator accuracy, is an interesting problem in general, and it's been approached a lot of ways. We think ours is nicely suited to implementing in an FPGA with minimal external stuff. Our main limitation seems to be on-chip crosstalk and maybe a bit of ground bounce.

John

Reply to
John Larkin

I can't say I really understand what you are doing. Obviously how you are solving this problem is something that is too complex for a verbal description without diagrams and detailed explanations. But thanks for trying.

Reply to
rickman

That's one of the laws of software:

All programs expand to consume all available resources

I remember implementing a RAM test in 34 bytes, and a 16x16 integer multiply in < 50 bytes.

Cheers

PeteS

Reply to
PeteS

I once wrote an Eratosthenes' prime number sieve using the video display as an array memory (on a 4K machine).

Reply to
Homer J Simpson

--
How high did it go?  to 9?
Reply to
John Fields

You still count on your fingers?

Reply to
Homer J Simpson

--
Sure. For lots of things.
Reply to
John Fields

Try taking off your shoes if you can stand the smell. That will almost double your counting ability.

Reply to
Homer J Simpson

--
Almost?

Hmmm... I take it back.  Did your sieve go as high as 7?
Reply to
John Fields

If it did it would exceed your IQ by a comfortable margin.

Reply to
Homer J Simpson

--
Well, there ya go!  That's not too bad, actually, considering that
before I took on the job of teaching you how not to walk on your
 Click to see the full signature
Reply to
John Fields

You seem to have a fixation about where YOUR next banana will be inserted.

Reply to
Homer J Simpson

--
Not me...  Mine will be sliced up, placed on some Cheerios and milk
and inserted into my alimentary system at the mouth end.
 Click to see the full signature
Reply to
John Fields

reserving about 1/4 of that for the program it should be able to go somewhere past 10,000 but not beyond 25,000.

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
 Click to see the full signature
Reply to
joseph2k

And yet you constantly make comments about other people being gay, comments based solely on your own fixations. Based on experience?

Reply to
Homer J Simpson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.