If you find the reset timing issue in the writing timing domain, please send me your project in order that I can look into it further. Usually we suggest customers set the Add circuit to synchronize 'aclr' input with 'wrclk' option from the FIFO MegaWizard plug-in. This can be done by setting the Add circuit to synchronize 'aclr' input with 'wrclk' option from the FIFO MegaWizard plug-in. If this condition cannot be guaranteed in your design, the aclr signal needs to be synchronized with the write clock. The wrreq signal must be low when the DCFIFO comes out of reset (the instant when the aclr signal is de-asserted) at the rising edge of the write clock to avoid a race condition between write and reset. DCFIFO supports asynchronous clear and asynchronous clear that synchronize with the write clock. But, because the DCFIFO is generated in a dll it appears as opposed to with tcl scripts, it is a little bit harder to modify. In dealing with this kind of issue with other cores, I have been able to get into the design files and make the modifications I needed. Is there any timing analysis's that I can break to help with timing? I do have some fifo's with the read signal equal to not(rd_empty). I don't write to the fifo on the few clocks emmidiately after coming out of reset. I also fail timing on the recovery analysis of a reset signal that is latched on the negative edge of a clock in the fifo. Any thoughts? I am having problems with meeting timing on recovery as well as timing analysis for the outputs because they are on different reset domains. It would be helpful to have those reset inputs into the dcfifo. Outside of the dcfifo i have a reset sequencer circuit which takes a reset signal in and synchronizes it to the different clock domains, going into reset asynchronously and coming out of reset synchronous with the clock. Request title:ĝCFIFO arst for seperate clock domains.ĭescription: When using a DCFIFO, i only have one option for an arst input. Give and take.Ī SR I opened with altera a month ago or so about DCFIFO arst and what you can ignore. It would be nice if altera was better at bringing signals like resets and enabled to the top level and letting the user decide how to hook them up, but they also try to make the easiest to use cores. Good questions, and hope this helps a little slash shows incite into how i have been dealing with it. Just copy the library file into a new directory, make the changes, then include that file into your project so it gets used before the original library file does. Usually the reset circuitry is not in an encrypted section of code, so it should be easy to modify the files you need. Then i wrapped a library around them that looks just like the altera_mf_components library so i can choose which instance to use based on the included library. I just went into the files that handled them and routed certain signals to the top level and certain signals back into the core to be used as the reset.įor the DCFIFO core, i went into the medafunctions/dcfifo.tdf file and modified all of the aclr signals to include both a wr_aclr and a rd_aclr, mapped those to the top level, and then i can provide both a write reset and a read reset signal. I wanted to reconfigure reset sequences on the DDR2HP cores when i shared multiple cores on a single IC. I have had this issue as well in certain places, mainly the DDR2HP cores and the DCFIFO cores. (Of course the same problem could arise in a fifo with 2 different clock - but in that case almost ever after the reset the fifo shall acquire immediatly a data, or you can constrain it at the write_side_clock). Wherealse since it's an Altera Ip I could suppose that the external reset net is designed internally in good manner so that outside I can cut the path. In reality In this particular case I think I can cut the net because in the end data are flushed from the ip and are put in a Fifo that in the begin I can keep in reset. I've also tried to register RST before with 135Mhz, then with 337.5 and then 337.5_90° but of course the paths failed. I've tried to register the RST signal with all theese clock alternatively but have not obtain results. The problem is that "by theory" I should register my RST signal with the clock domain that I've to use, but in a multiclock IP with which you do not have controll - else I should have separate the internal reset with the different clock domain - how can I design the reset network? I'm using ASI receiver IP that works with a lot of clock (135MHz, 337.5Mhz and 337.5Mhz shifted of 90°).Īll theese clock are done by the same PLL that is fed by a 27Mhz (that is the natural clock at which then the data of the Asi are reconstructed - after a fifo).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |