SMA phase adjuster construction?

[rhb]

My objective is to verify FPGA simulator timing vs reality prior to really pushing the FPGA to the limits doing DSP operations.

[joeqsmith]

My objective is to verify FPGA simulator timing vs reality prior to really pushing the FPGA to the limits doing DSP operations.

Simulator timing from the circuit board layout side of things?  It would be interesting to know more about the test setup and what you are attempting to validate with it.   

[RoGeorge]

AFAIK FPGA simulators are digital simulators only.  They do not take into account propagation time at all.  They simulate only the logic behavior of a circuits, and the unit time is the circuit clock.

Meting the timing/speed parameters of a circuit is not the simulator's task.  The simulator is for testing only the logical mistakes in a circuit, not the timing.

[OwO]

To add to the above, the way the timing analyzer works is by tracking delays of every signal and checking the setup and hold time of every register and synchronous element. All the FPGA vendors have characterized every wire, LUT, register, and other resources rigorously and added margins to account for process variations. You should not run logic faster than the timing analyzer indicates, to do so would be overclocking and you won't get any guarantees the design will work on every chip at every temperature and allowed Vccint voltage range.

[joeqsmith]

The tools will provide you with post place and route timing information which will include the propagation delays to the selected pins.   This can then be fed into the layout tool to trim the lengths if needed.   

Depending on the part, the I/O can be trimmed internal to the device. 

[rhb]

I am not designing a board.  I'm writing a reliable and I hope portable FOSS DSO FW stack for Zynq and Cyclone V based DSOs.  I have a Zybo Z7-20 and a Terasic DE-10 Nano to use for the dev work.  The PMOD interface is not available on the Terasic board, so I'll actually have to build two test fixtures.

I fully understand that the vendors have characterized their parts.  But the timing calculations for a particular topology are done in software.  After many years of dealing with complex, expensive software packages I have *no* confidence that they produce the correct answer.  I have constructed test cases that broke far too many codes.  My concern is testing a filter configuration and getting a timing result which the part cannot reliably meet.

A key feature I want to implement is the ability to apply an arbitrary series of FIR and IIR filters and math operations to any input trace and display the result in X-T, X-Y or do anything else the user wishes in real time for 8, 12 & 14 bit ADCs e.g. the HMCAD1520.

In short, I am fed up with crappy DSO FW.  To keep what little bit of sanity I have left, I need a project which presents a serious technical challenge.  This is the project I have chosen.   Because I want the code to be portable, I want to know with absolute certainty that a filter topology actually will run properly at design speed on both parts.  The only way to achieve that is to measure the behavior of the various elements and arbitrary combinations thereof. This is a multi-year project.

[joeqsmith]

I did a search and assume its related to the attached following threads.   Sounds like an interesting and fun project.   I still don't understand how the delay lines fit into it. 

https://www.eevblog.com/forum/projects/open-source-instrument-firmware-project-104048/
https://groups.io/g/LeCroyOwnersGroup/topic/29601845?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29601845

[rhb]

If I'm going to accurately measure FPGA propagation delays, I need to align the 8 channels of the 11801 w/ 4 SD-26 heads installed.  I can adjust the delay for a head, but not for individual channels. 

I'm assuming a priori that I can't make cables which are close enough to the same electrical length.  The need for phase adjusters is imposed by the limitations of the 11801.

Who knows?  I might get lucky.  I'm about to crimp my first coaxial cable. Fortunately this one is not length critical.  I just hope I don't ruin too many connectors.

Except for the mathematics of signal processing, everything I'm doing is new. Or else something I haven't done in 30 years.  So I'm expecting a *lot* of failures.

[joeqsmith]

Perhaps use one reference and compare that using the same test cable with each channel.   Get that torque wrench out...

[rhb]

I'm going to *try* to build matched cables.  But making just one was defeated by none of my BNC connectors for another project matched either of the two crimpers I bought.  So I need to order 2-3 more die sets from China.

I'm already using a torque wrench on the SMAs.

[joeqsmith]

I guess I don't understand the need for any matched cables.  Just one for a reference and one to sample each port.  Perhaps there is a reason you need to look at all the pins at the same time.   Are you trying to tie two of these eval boards together?  One ADC the other the FPGA and you want to run the bus across with these cables?   I'm lost....

[rhb]

The purpose is to examine propagation delays across the output of an adder or multiplier.  In a DSP filter pipeline you have to add latches between stages to retime the bits in an output word.  This imposes a fundamental limit on how fast you can clock the filter.  Adding latches increases the area, power and latency.

My concern it that a software bug might underestimate the skew across the output word and lead to not having a latch where one is needed.  If the skew is such that most of the time the full word is valid at the start of the next clock cycle, but not always, it leads to incorrect output that is very hard to track down and fix.

In addition, the skew  varies with the input.  So I plan to generate all possible inputs to an adder or multiplier and identify the worst case.

@dcarr's suggestion solves the alignment problem very neatly and should be easy to implement.   I can press the center conductor to the board with a non-conductive probe and move it along the trace while watching the scope.  When the timing matches I solder it in place and remove the stub.  A more elaborate arrangement would be to slide  an SMD vertical  SMA-F connector with the through hole pins cut back to locate the correct point, then drill holes and mount an unmodified connector.  That would avoid reflections caused by an asymmetric shield connection that soldering the cable to the board would produce.

I bought a bunch of U.FL to SMA jumpers, so I might be able to use those for the fixture if they test out OK.  That should improve the transition BW.  And a dab of epoxy will make the connection permanent.

[OwO]

The purpose is to examine propagation delays across the output of an adder or multiplier.  In a DSP filter pipeline you have to add latches between stages to retime the bits in an output word.  This imposes a fundamental limit on how fast you can clock the filter.  Adding latches increases the area, power and latency.

My concern it that a software bug might underestimate the skew across the output word and lead to not having a latch where one is needed.  If the skew is such that most of the time the full word is valid at the start of the next clock cycle, but not always, it leads to incorrect output that is very hard to track down and fix.

1. The synthesis tools do not add registers (assuming we are talking about ordinary HDL based design and not HLS). Any register stages are your responsibility and if there is too much combinational delay your design will simply fail timing.
2. The delay depends on the exact placement and routing of your logic. If you try to "probe" an internal signal in your design by bringing it onto an IO pin, the placement of logic resources (and routes chosen) will be completely different from before.  Therefore trying to measure internal logic delay on the IO pins is completely futile. Besides how will you account for routing delay to the IO pin and IOB delay?
3. The timing analysis part of the code is the simplest part. All it has to do is add up all the delays of an existing (already computed) route and check setup and hold times. The actual place & route is orders of magnitude more complex and is where I would expect bugs to be. However as mentioned above just the presence of "debug" logic can alter placement drastically, so anything you verify becomes completely moot when you remove the debug logic.

[OwO]

If you really suspect Xilinx's timing analysis code the best way to verify is to take the post-route netlist and run your own timing verification. You still need to know the specifications of each logic resource and guess at route delays, but if you don't trust Xilinx's device characterization either then your best bet is either characterizing using test designs or wafer level probing.

[rhb]

I just looked at the HiRose U.FL datasheet and did a TDR test of the eBay U.FL plug to SMA-F jumpers I bought for about $0.50 each.  They should work perfectly following the suggestion made by @dcarr.  The only issue left to resolve is whether I can get 50 ohms with a single sided coplanar waveguide or whether I'll need to use a 2 layer board to meet the HiRose footprint.

[joeqsmith]

The purpose is to examine propagation delays across the output of an adder or multiplier.  In a DSP filter pipeline you have to add latches between stages to retime the bits in an output word.  This imposes a fundamental limit on how fast you can clock the filter.  Adding latches increases the area, power and latency.

My concern it that a software bug might underestimate the skew across the output word and lead to not having a latch where one is needed.  If the skew is such that most of the time the full word is valid at the start of the next clock cycle, but not always, it leads to incorrect output that is very hard to track down and fix.

But once you route it out, you will need to consider those effects as well (pin choice and such plus the layout).  You may want to consider Chipscope.   

Adding pipe stages will add a delay but normally I will do this because I am trying to get higher performance (clock it faster).   

[rhb]

I will be using every tool I can.  But I can only work so fast.  I've got another 750 pages of "Planar Microwave Engineering" by Thomas Lee to read before I make a board layout for the phase adjusters. And I might well read Johnson & Graham also.

I've had the FPGA boards for well  over a year.  However, I'm still working on basic infrastructure and background reading.  I spent my career doing things I'd never done before.  I have a hard rule.

I never write code until I've run out of excuses for not writing it. 

The only time I ever got in trouble was the one time I ignored that rule because the task seemed so familiar that I overlooked that the particular use case was different.  I spent a very miserable 2 weeks being reminded that the discrete Fourier transform is defined over a semi-closed interval.

[tomato]

This was 25 years ago.  I don't even remember the company, though I think they were Swiss.

You can't see anything when they are running.  The coolant flood makes the loading door look like a front loading washing machine.  They are the modern version of a screw machine.  CNC instead of cams.  And the parts don't just drop into a hopper.

I'd bet they are the devil to get tuned to produce things to the specs of the Maury 3.5 mm connector.  And almost as much work to keep them in tune.  At 0.0002",  temperature control while turning is critical.  Just a little heating of the part and it will be under size.

Heating of the part isn't a big issue when the parts are that small.