ContributionsMost RecentMost LikesSolutionsRe: CYCLONE IVE ODDR delay mismatch I'm still unsure about the false path issue. I can't figure out why I should disable the path between the falling edge of launch-clk and the rise edge of latch-clk. The launch-clk for oddrs could also be the falling one, since it's a ddr. Re: CYCLONE IVE ODDR delay mismatch Thank you ShengN and thank you cblixt1. So my suspicion about the Vref pins is confirmed. cblixt1: regarding the false path issue, I have some doubts: The oddr register that I am using is capable of launching the data on both the rising and falling edges of the clock. The dac_clk, instead, latches only on the rising edge. The values on the D inputs of the oddr register are updated (by other logic not currently present) only on the rising edge. I can't understand which false paths are correct to insert in this situation.. Re: CYCLONE IVE ODDR delay mismatch Do you think it is possible to force Quartus to use the same type of routing (the fast one) used on all the other pins? I am aware that at the moment the timing is being exceeded, but right now if I wanted to increase the clock frequency I would have limitations precisely due to those 2 "slower" pins. Re: CYCLONE IVE ODDR delay mismatch If you look at the first 2 lines you will notice that the 'data delay' value is about 1 nanosecond greater than all the other lines. Using the ODDRs I expected differences on the order of 100-200 picoseconds between all the pins. This is what I can't understand. Re: CYCLONE IVE ODDR delay mismatch Hi Sheng. Can you share the timing analisys from Pll1/clk0 clock to clk_dac_a or clk_dac_b clocks? CYCLONE IVE ODDR delay mismatch Hello Altera Experts! I am using Quartus Standard 24.1.. I'm building a 10-bit parallel output interface to drive a DAC. I'm using the oddr (ALTDDIO_OUT) registers so that all bits output simultaneously. 9 of the 10 bits are aligned, while one has an additional delay of about 2 nsec. I created two 10-bit buses (to drive two DACs), and the strange thing is that bit (3) is always delayed on both buses. I'm attaching the project, hoping some experts can help me. The ddr registers are correctly instantiated, but in the timing analysis, the bit(3) coming out of the fpga is delayed compared to all the others: TIMING ON BUS_A: TIMING ON BUS_B: REGULAR DELAY: BIG DELAY: The only difference I see is that the "slow" pins are both also Vrefs (pin 105 and pin 80): Could this be the reason? regards, LUCA. SolvedRe: NEW USB BLASTER II HARDWARE FAULT Let's close it. I hope to solve it with digikey through the broker. Regards Re: NEW USB BLASTER II HARDWARE FAULT Hi NurAiman. Digikey wrote to me saying that they needed a proxy from the broker who purchased the device for me, authorizing them to handle the RMA directly with me. The broker sent digikey the proxy authorizing me to handle the RMA. Then a few days ago digikey wrote that they want to deal directly with the broker. Re: NEW USB BLASTER II HARDWARE FAULT It's really a scandal! After a thousand requests and solicitations to digikey, I still haven't managed to get the defective device replaced after several months!. I hope INTEL intervenes and solves my case.. Re: NEW USB BLASTER II HARDWARE FAULT Ok NurAiman. I received the email and responded by entering the requested data. Thank you