User Profile
User Widgets
Contributions
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..38Views0likes2CommentsRe: 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.55Views0likes2CommentsRe: 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.55Views0likes1CommentCYCLONE 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.Solved158Views0likes15CommentsRe: 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.969Views0likes0Comments