Sampling faster than the clock

[rman1234]

I'm trying to read a pulse input that has a width of about 20ns. My clock has a period of about 35ns, so I can't sample it with my clock like I would prefer. Can this be accomplished by a process with the pulsed input in a sensitivity list? I'm using some OLD technology, a Xilinx XC4036XL FPGA.

I guess I'm wondering in general how the synthesizer will treat something in a sensitivity list? Does it drop a latch? Does it tie the signals in the sensitivity list to the CLK inputs of a bunch of FFs?

I want to avoid anything that might cause metastability.

Thanks.

 

[ariesm44]

due some reseach

It looks like you have some degree of salvation in this as the XC4000 series registers can clock off either rising or falling edge of the clock. So at least in theory, you can create a clock 35/2 = 17.5ns. Not much room for Tsu/Th times, so metastability must be a considered. Somewhere you will have to hold that input pulse an lock it into your normal clock via a series of registers.

Get yourself a Xilinx handbook. I found this one at Xilinx.com - Xilinx XC4000E/X Series Field Programmable Gate Arrays
May 14, 1999 (Ver 1.6)

The XC4000 also has a feature called "Input Latch for Fast Capture" which uses a X series specific "extra" register in the I/O Block to capture signals with an output clock (created by you). That might work out, but again there is little wiggle room with only a 20 nsec input pulse.

If possible, you may try on the PCB routing the pulse signal to TWO pins and then clocking with oppisite edges. The output would then be OR combined and re-registered at your internal clock rate.

Exactly how you utilize specifing rising_ or falling_ edge clock use in written VHDL code is not clear to me and I don't have knowledge of this. Best bet - call an experienced Xilinx App Engr or use there web form.

From the handbook noted above:
Faster Input and Output
A fast, dedicated early clock sourced by global clock buffers
is available for the IOBs. To ensure synchronization with the
regular global clocks, a Fast Capture latch driven by the
early clock is available. The input data can be initially
loaded into the Fast Capture latch with the early clock, then
transferred to the input flip-flop or latch with the low-skew
global clock. A programmable delay on the input can be
used to avoid hold-time requirements. See “IOB Input Signals”
on page 20 for more information.

Clock Input
Each flip-flop can be triggered on either the rising or falling
clock edge. The clock pin is shared by both storage elements.
However, the clock is individually invertible for each
storage element. Any inverter placed on the clock input is
automatically absorbed into the CLB.


Additional Input Latch for Fast Capture (XC4000X only)
The XC4000X IOB has an additional optional latch on the
input. This latch, as shown in Figure 16, is clocked by the
output clock — the clock used for the output flip-flop —
rather than the input clock. Therefore, two different clocks
can be used to clock the two input storage elements. This
additional latch allows the very fast capture of input data,
which is then synchronized to the internal clock by the IOB
flip-flop or latch.
To use this Fast Capture technique, drive the output clock
pin (the Fast Capture latching signal) from the output of one
of the Global Early buffers supplied in the XC4000X. The
second storage element should be clocked by a Global
Low-Skew buffer, to synchronize the incoming data to the
internal logic. (See Figure 17.) These special buffers are
described in “Global Nets and Buffers (XC4000X only)” on
page 37.
The Fast Capture latch (FCL) is designed primarily for use
with a Global Early buffer. For Fast Capture, a single clock
signal is routed through both a Global Early buffer and a
Global Low-Skew buffer. (The two buffers share an input
pad.) The Fast Capture latch is clocked by the Global Early
buffer, and the standard IOB flip-flop or latch is clocked by
the Global Low-Skew buffer. This mode is the safest way to
use the Fast Capture latch, because the clock buffers on
both storage elements are driven by the same pad. There is
no external skew between clock pads to create potential
problems.
To place the Fast Capture latch in a design, use one of the
special library symbols, ILFFX or ILFLX. ILFFX is a transparent-
Low Fast Capture latch followed by an active-High
input flip-flop. ILFLX is a transparent-Low Fast Capture
latch followed by a transparent-High input latch. Any of the
clock inputs can be inverted before driving the library element,
and the inverter is absorbed into the IOB. If a single
BUFG output is used to drive both clock inputs, the software

 

[ariesm44]

clock multiplier

here is a synthesisable frequency multiplier..
vhdlguru.blogspot.com/2010/04/combinatorial-frequency-multiplier.html

got this from another thread

 

[rman1234]

EEK, I don't like that approach at all... You're banking on some unknown delay from the inverter? That's not a good design approach.

I ended up using the reset input of my DFFs to reset some signals to a state that I want them in when I receive the input pulse.

Does this code look like it will work?

custom_blk: process (ck_26mhz, blk_in, reset)
begin
  -- this will reset either during reset or if there's a pulse input
  if (blk_in == '1' or reset == '1') then   
    delay_counter     <= (others => '0');
    width_counter     <= (others => '0') when (reset == '1')
                         else width_counter;
    blk_sync1 <= (not reset);   -- if in reset this is zero,
                                        -- otherwise saw a pulse and it's 1
    blk_sync2 <= '0';
    blk_sync3 <= '0';
    blk_out_temp <= '0' when (reset == '1') else blanking_out_temp;
    
  elsif (ck_26mhz'event and ck_26mhz = '1') then  -- rising clock edge

  -- rest of code

 

[rman1234]

Okay, almost nobody has responded to my questions but that's OK I'll just have a conversation with myself.

How are you today rman1234? I'm doing excellent. How are you? Oh great thanks. Hey so I tried to compile that code from the above post and I realized I'm an idiot and I used some combinatorial-only structures in a process. Wow you are a n00b. I know. So what did you do? Well I updated the process so it could actually compile. Oh sweet what does it look like now? I'm glad you asked:

  if (blk_in = '1' or reset = '1') then
    delay_counter     <= (others => '0');
    blk_sync2 <= '0';
    blk_sync3 <= '0';     
    pre_blk_flag    <= '0';
    if reset = '1' then
      blk_out_temp <= '0';
      width_counter     <= (others => '0');
      blk_sync1 <= '0';
    else
      blk_out_temp  <= blk_out_temp;
      width_counter <= width_counter;
      blk_sync1 <= '1';
    end if;

  elsif (ck_26mhz'event and ck_26mhz = '1') then  -- rising clock edge
--REST OF CODE

Now I just hope the nice people at the forums would take a minute to look at the above code and tell me if that's terrible design practice or not? Putting If statements in your reset block?

 

[rman1234]

I ended up making my pulse the asynchronous reset for the flip-flops and I used my normal reset as a synchronous reset. This works in simulation and I'm fairly confident it's the most robust design.

Interesting thought though ariesm44 about using both the rising and falling edges to sample a signal.