element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
FPGA
  • Technologies
  • More
FPGA
Forum Trigger pulse generation inside FPGA
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join FPGA to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 5 replies
  • Subscribers 559 subscribers
  • Views 1802 views
  • Users 0 members are here
  • trigger
  • cyclone
  • fpga
  • altera
  • 4
Related

Trigger pulse generation inside FPGA

Kilohercas
Kilohercas over 11 years ago

Hello, i am facing small problem with FPGA programming.

 

Problem is simple, i have unknown length trigger pulse (1ns-5us) that should start CCD readout. What i need is to be able to make that signal as short as possible, so i don't waste clock cycles to start readout. Ideally i should be able to control how long this signal are, new pulse must start at rising edge of trigger pulse, falling edge is ignored, and new falling edge is generated automatically, when x ns had passed from rising edge ( i could do that with 555 timer, but it's is too slow, and it would be nice to use Altera Cyclone 4 EP4CE6E17C6 for that.

 

image

 

This circuit is working very well, only problem is that if trigger is very long, i will miss clock cycles to start readout, and it will be delayed as long TRIGGER is high level. That's why i need to generate falling edge as fast as i can, but at the same time that fpga could catch it.If some one could help me with verliog code for trigger generator i would be very grateful, or any idea would be nice. Note that external trigger is not running on same oscillator, so it is fully asynchronous to fpga

  • Sign in to reply
  • Cancel
  • michaelkellett
    michaelkellett over 11 years ago

    Linas, if I understand correctly, you have an asynchronous pulse which you are feeding directly into 'aclr' which I guess is a synchronous block of logic. The trigger pulse amy be as short as 1ns. The first issue is that this pulse is almost certainly too short to reliably clear anyhting in the FPGA and if it is asynchronous to the ELIS_SK clock it will not reliably meet timing even if it is long enough - sometimes bad things will happen when the trigger arrives at just the wrong time relative to the clock.

    I think you need to stretch your trigger pulse in hardware to be at least 1 clock cycle long. Thn you need to synchronise it to the internal FPGA clock by passing though at least 2 flip flops, then you can detect the rising or falling edges reliably and do the clearing. You will get  a delay of three clock cycles but this can't be avoided with an FPGA. It may be possible to condition the trigger pulse in some other way or to use a PLL on the FPGA to generate a faster internal clock to synch the trigger pulse .

     

    Sorry, can't offer you any Verilog code because I use VHDL and my Verilog is too primitive to expsoe to the world.

     

    MK

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Kilohercas
    Kilohercas over 11 years ago in reply to michaelkellett

    Clear is asynchronous to Counter, right now i am using 10ns pulse from DSP to clear it, and it works very well. This will work if clear pulse is picked by logic, that would clear counter, all other circuit will work without a problem, even if i have massive jitter compared to FPGA clock, which i will have.

     

    i was using compare if ELIS_SK counted to 129, that would mean that i have all data clocked out, and i had other counter to count triggers, if it counts to 1, i will let ELIS_SK to count, when it finishes, i will count finishing edge, and if it's not 1, i will not let it count. in theory it should work , but it had glitches upon glitches. Idea was the same like shoot yourself, you should be able to do that, problem is that FPGA is so fast, when it tries to reset counter it see that counter is reseted, and stop reseting, generating 1ns pulse, and logic is not capable to latch on it image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 11 years ago

    I think this might work:

     

    wire clk;    // Master clock.
    wire pulse;  // Pulse sets FF.
    reg  PFF;    // Pulse storage FF: async set when "pulse" occurs,
                 // sync reset when pulse goes away.
    reg  pulse1, pulse2;    // Resynchronized versions of "pulse".
    reg  PFF1, PFF2, PFF3;  // Resynchronized versions of PFF.
    // Detect rising edge of PFF.  This clears your counter.
    wire edge = PFF2 && !PFF3;

     

    always @(posedge clk or posedge pulse)
    if (pulse) PFF <= 1; else begin
        pulse1 <= pulse; pulse2 <= pulse1;        // Resynchronize pulse to clk.
        PFF1 <= PFF; PFF2 <= PFF1; PFF3 <= PFF2;  // Resynchronize PFF to clk.
        // "pulse" sets PFF asynchronously.  Hold PFF high until PFF3 is set,
        // and keep holding it until pulse goes away.
        // A short pulse sets PFF and PFF3 clears it.
        // A long pulse sets PFF but doesn't clear it until pulse2 goes away.
        PFF <= PFF && !(PFF3 && !pulse2);
    end

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 11 years ago in reply to johnbeetem

    Here's a better version.  I've changed PFF's clocked update so it only occurs when PFF3 is high, i.e., PFF was set several cycles ago.  "PFF <= PFF && !(PFF3 && !pulse2);" has a hazard if a short pulse occurs when clk rises.

     

    wire clk;    // Master clock.
    wire pulse;  // Pulse sets FF.
    reg  PFF;    // Pulse storage FF: async set when "pulse" occurs,
                 // sync reset when pulse goes away.
    reg  pulse1, pulse2;    // Resynchronized versions of "pulse".
    reg  PFF1, PFF2, PFF3;  // Resynchronized versions of PFF.
    // Detect rising edge of PFF.  This clears your counter.
    wire edge = PFF2 && !PFF3;

     

    always @(posedge clk or posedge pulse)
    if (pulse) PFF <= 1; else begin
        pulse1 <= pulse; pulse2 <= pulse1;        // Resynchronize pulse to clk.
        PFF1 <= PFF; PFF2 <= PFF1; PFF3 <= PFF2;  // Resynchronize PFF to clk.
        // "pulse" sets PFF asynchronously.  Hold PFF high until PFF3 is set,
        // and keep holding it until pulse goes away.
        // A short pulse sets PFF and PFF3 clears it.
        // A long pulse sets PFF but doesn't clear it until pulse2 goes away.
       // This version disables the PFF clock until PFF3, which is sync'd to clk.
        // PFF clears when pulse2 (also sync'd to clk) goes away.
        if (PFF3) PFF <= PFF && pulse2;
    end

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Kilohercas
    Kilohercas over 11 years ago in reply to johnbeetem

    thank you, will try that soon and see how it goes.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube