FPGA one-shot

IDELAY sounds ideal for setting my pulse width, because it's calibrated and tweakable. We'll look into that.

I did a ring oscillator to measure chip temperature, on a part that didn't have an internal sensor.

formatting link

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

Den torsdag den 14. december 2017 kl. 04.43.29 UTC+1 skrev John Larkin:

something like this?

module top(input trig, inout trgd, output oneshot);

IOBUF IOBUF_inst ( .O(trigdi), // Buffer output .IO(trgd), // Buffer inout port (connect directly to top-level port) .I(trig), // Buffer input .T(0) // 3-state enable input, high=input, low=output );

assign oneshot = trig & ~trigdi;

endmodule

I haven't tried but it results in this,

formatting link

I'm guessing Tiop + Tiiop width

Reply to
Lasse Langwadt Christensen

John Larkin wrote on 12/14/2017 1:31 PM:

It still has to be routed to the logic. So you haven't worked around the problem of wildly variable routing delays which add to your pulse width.

As usual John is trying to work with things he doesn't understand by applying methods he has used on totally unrelated designs. Sit down and draw a block diagram showing not just the delay you wish to control, but the delays on every bit of wire in the design. Then maybe the picture will emerge.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

Right. IDELAY can be added to tune that. Slew rate maybe too.

This chip drives a 14-bit DAC that isn't implemented yet, so I have essentially 14 test points that I can probe. And a ton of unused balls as the delay nodes. So I think we'll do a bunch of simple experiments on the next build, to see what sorts of delays we can get, and how repeatable they are.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

Den torsdag den 14. december 2017 kl. 20.23.56 UTC+1 skrev John Larkin:

for IDELAY you need a 200MHz reference, then you might just be able do is synchronous pissble with a DDR to double the resolution

looks like you can also play with iostandard and drive to get different delays

page 34.

formatting link

Reply to
Lasse Langwadt Christensen

This signal is generated within the FPGA and sent out? And, you just want to stretch it? Make a counter with a few bits, set it to zero when TRIG occurs, and count up at the available clock rate, and generate RX. When the counter reaches the max, turn off RX and don't increment the counter again.

This is so simple, I must be misunderstanding what you want to do.

Jon

Reply to
Jon Elson

What's the fastest clock on the FPGA? If you have a 100 MHz clock, then, set a FF on the rising edge of TRIG on a clock edge, and clear it on the next clock edge. That will give a 10 ns wide pulse.

Jon

Reply to
Jon Elson

He doesn't want to generate a high speed clock to make a 10 ns wide pulse. He is thinking he only needs to deal with the delays of the logic elements when his real enemy is the routing. It's not at all about using a precisely controlled delay from any block in the FPGA, it's about the interconnection being consistent between iterations of the design layout.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

Looks like around 5 ns out and back in, which sounds fine for what we want to do. We prefer to not have a 200 MHz clock on this chip, so we'll probably avoid IDELAY.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

The ultimate source is external and asynchronous to any clocks.

Well, make a pulse at the rising edge of TRIG. That pulse clears some external ECL logic running around 600 MHz.

If I did this synchronously, I'd need maybe a 250 MHz PLL'd clock, and use both edges probably, and worry about metastability, and we'd rather not have such a clock on this chip. And for obscure reasons, we prefer a truly async delay, namely not have the edges quantized to a clock.

I should have included a precision analog ramp and a comparator to time this out. I'll do that next rev.

You are saying, basically, "don't do that" but we really have to.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

No. I think I know why.

Makes complete sense. Knowledge locked up in someone's head => company in pieces.

Reply to
krw

You didn't read a word I wrote. The company failed because like so many in the dot com bubble they didn't see it was a bubble and borrowed a shit-ton of money to expand, then when the bubble burst they couldn't pay the debt. it had nothing to do with the dick-head I had for a boss.

The dick-head came from the company's history developing as a startup and having loose engineering management principles. So he didn't know any better because they never taught him any better. But the company was a technical success. Ask anyone who works in telecom if they've ever used a T-BERD. It is highly regarded test equipment from what I've heard and very widely used.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

the

in VHDL:

routing.

and so

There is no manual step needed. Once you lock the pins, the routing will be fixed (to an extent).

I haven't done manual routing on an FPGA since the '90s.

I haven't done manual placement for a few months. Even then, it was all in the form of relative placements in HDL, so the tools still have the ability to move the entire macro around on the die.

Allan

Reply to
Allan Herriman

You're lying, as always.

No, they failed because their business practices sucked and their people sucked more.

So you agree with me. Funny that.

Reply to
krw

Nonsense. The next release of the routing software, or even the next modification to the HDL may completely change the routing.

Have you tuned for exact timing of asynchronous timing?

...and you're not controlling the largest variable, the routing.

Reply to
krw

"To an extent" is one of those things where the devil is in the details. Routing within a block is dedicated and either a path exists or it doesn't. But routing between blocks is much more flexible and so subject to variations depending on what the software chooses.

It has been a long time since I opened up a Xilinx chip in the editor, but the interconnects have always been in levels. There are direct links between adjacent blocks, north, east, south and west. These are the fastest and not subject to much variation from routing choices since there aren't any choices other than use them or not.

See the diagonal traces between blocks in the chip editor image in the link you provided? Those will not be direct traces. The software will have to pick a route through the routing matrix which can be very different from run to run. When the circuit has an async feedback path, the software can't time it, so there is no way to place a timing constraint to make it use a faster path. So the tools won't help you here. This has to be addressed manually on each run of the tools.

You might be able to put together a script to semi-automate it, but you will need to handle this outside of the normal automated tool usage. It should be completely documented so it can be repeated anytime the device is touched.

Placement is easy, it can be done in the HDL. Routing is another matter altogether.

There are (or were) things called "hard" macros. This is a piece of logic with routing that is already done and can be dropped into a design as an entity. I don't know if they are supported in HDL. I don't know they are still supported at all. Their down side is that nothing could be routed through the hard macro since the tools have no idea what can be used and what can't. I suspect it was just too hard a problem to deal with for the routing tools to work optimally. This is similar to the issues of partial reconfiguration. The partial reconfiguration was the easy part. Developing tools to support designing modules to use in partial reconfiguration was the hard part. Same problem, getting the tools to effectively route in just a portion of the chip.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

Yeah, that's the general advice. But, if you have some unbonded pads on the die, or balls that are not connected to anything, you ought to be able to use one to make up a crude analog one-shot.

You have HUGE flexibility on Xilinx I/O pads. You can configure pull-up and pull-down resistors, and tri-state outputs that also have input buffers. So, you use the pad capacitance, plus pull-up. Pulse the output buffer active for an instant, then back to tri-state, and read the input buffer. Now, since you want to have the output SHORTER than the input pulse width, it gets tricky. But, routing a signal through a few buffers and then X-OR with itself could either give you the pulse you want or be wide enough to trigger the tri-state, and then the pad RC would stretch it. You may have to make sure the tools don't instantiate a weak keeper on that pad. (Although the weak keeper ought to be weaker than the pull-up, it could interfere with the timing.)

Jon

Reply to
Jon Elson

The pullups are, I think, 20K, and that with just one pF is more delay than I want. Too bad.

We're going to do some experiments and see what happens. A few places on the chip, to see how consistent the delays are.

I think it will be OK; other people sort of disagree. If the round-trip through the i/o cell is 5 ns, and the flop is in the i/o bank, the only compiled routing delay is getting out of the receiver and back into the flop clear, which should be short. I think we can constrain that too so it doesn't make the grand tour of the chip. If that delay is anywhere between 0 and maybe 4 ns, it will work.

I'll post any results.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

In general, I agree with that. Look sideways at the PAR software or make a trivial change to the source code and it will do something completely different, and often something unexpected. Sometimes it will do something wildly suboptimal.

But in this case, I believe Larkin has just one connection that will be contained within a single switch box next to the IOB. It will not use any inter-switchbox routing (with all the uncertainty that entails).

My experience has been that in this particular case (and this particular case only), locking the pins correctly may remove any choice the router has, resulting in repeatable routing. (I won't say repeatable timing, because we still have PVT to worry about.)

Depending on the exact switchbox resources used, this may also require that other routing be prohibited in that area to work.

Perhaps I should point out that whilst I have done some of this sort of manual placement and routing recently, I have not done the exact route of IBUF output to OUTFF clear input. Sometimes there are quirks that do not become apparent until the design hits the tools.

'nuf said.

Allan

Reply to
Allan Herriman

I guess my work with Xilinx parts is getting old. I didn't remember the IOB FFs *having* accessible async Clear/Preset inputs which would have required a FF from the fabric. But I looked at the Xynq data sheet and the IOB FF have accessible Clear/Preset inputs. So there will be routing on the general fabric as I expect there is no direct connection between the input and the Clear pin within the IOB.

As to your presumption of this removing "any choice the router has", I think that is fallacious. The switch matrix is a general purpose routing medium and I have seen the tool do, as you say, "wildly suboptimal" routes. The only way to tell is to give it a try.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

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.