Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15480 Discussions

What can cause a clock signal being distributed to a DFF chain to have several delta cycles delay on one DFF?

FHall1
Beginner
710 Views

Hello,

 

I am running a simulation in ModelSim using the .vho file generated during compilation of my project containing a .bdf file in Quartus Prime. I was getting inconsistent behaviour in a DFF chain. Upon closer inspection I noticed that the clocks at three DFFs were not entirely in synch, one was always several delta cycles off. Redrawing the .bdf file with exactly the same components fixed the problem, but I am at a complete loss as to what could have caused the clocks to be out of synch. Has anyone experienced this issue and knows what caused it? I've attached screenshots of the part of the .bdf design in question (one with the clocks in synch, and one with the clocks slightly out of synch) along with the corresponding simulation results.

 

As to the software used:

Quartus Prime Version 18.1.0 Build 625 09/12/2018 SJ Lite Edition

ModelSim - INTEL FPGA STARTER EDITION 10.5b (Revision 2016.10) (Quartus Prime 18.1)

 

Thanks for your help!

 

Felix

0 Kudos
2 Replies
MuhammadAr_U_Intel
259 Views
Hi, Did you tried comparing both the ,vho files specifically on the clock signal to get any clue what is causing the delay in clock ? I did noticed the 3 clocks have some delta which isn't expected. I didn't understand how did you fixed this? Since DFF instances are same for both BDF designs. Thanks, Arslan
FHall1
Beginner
259 Views

Hi,

 

How i fixed it: I deleted that part of the .bdf and redrew it using exactly the same DFF type. Why this worked i don't understand, which is what I'm trying to figure out.

 

I just compared the .vho files, specifically the port mapping of the clock inputs of the DFFs in question and noticed the following:

 

   inst2: clk => \CLOCK_1600Hz~inputclkctrl_outclk\

   inst41: clk => \CLOCK_1600Hz~inputclkctrl_outclk\

 

   inst6: clk => \CLOCK_1600Hz~input_o\

   inst44: clk => \CLOCK_1600Hz~inputclkctrl_outclk\

 

   inst11: clk => \CLOCK_1600Hz~inputclkctrl_outclk\

   inst45: clk => \CLOCK_1600Hz~inputclkctrl_outclk\

 

I paired the "equivalent" DFFs to show that the DFF that had a clock signal that had some delta was actually mapped to a different signal than the others. I'll include the parts in the .vho that show where these two signals come from. I don't understand why this happens though.

 

   -- Location: IOIBUF_X0_Y4_N15

   \CLOCK_1600Hz~input\ : fiftyfivenm_io_ibuf

   -- pragma translate_off

   GENERIC MAP (

      bus_hold => "false",

      listen_to_nsleep_signal => "false",

      simulate_z_as => "z")

   -- pragma translate_on

   PORT MAP (

      i => ww_CLOCK_1600Hz,

      o => \CLOCK_1600Hz~input_o\);

 

 

   \CLOCK_1600Hz~inputclkctrl\ : fiftyfivenm_clkctrl

   -- pragma translate_off

   GENERIC MAP (

      clock_type => "global clock",

      ena_register_mode => "none")

   -- pragma translate_on

   PORT MAP (

      inclk => \CLOCK_1600Hz~inputclkctrl_INCLK_bus\,

      devclrn => ww_devclrn,

      devpor => ww_devpor,

      outclk => \CLOCK_1600Hz~inputclkctrl_outclk\);

 

Thanks!

Regards,

Felix

Reply