What is the difference between these?
Alex R. wrote: > What is the difference between these? First: the name! Second: the sync reset needs a (continous) clock to reset the actual value of a flipflop, the async reset resets a flipflop immediately. Third: why do you ask? Whats the actual problem?
Thank you, Lothar. So the sync reset will wait for a clock signal, then it will reset a device, and the other does it at once. Am I right? Here is the problem as a whole. I'm trying to use a Matlab-generated FIR filter. It runs on higher speed, then the main clock, and it's higher speed is generated by PLL. That is because the filter is made 20x serial to reduce the number of multipliers on a rather small EP4CE6. The data won't feed correctly into it.
Alex R. wrote: > Here is the problem as a whole. And how does this relate to sync or async resets? > It runs on higher speed Any figure for that "high speed"? For me it seems like a simple constraint or clock-domain-crossing problem. Or the FPGA is simply to slow to handle the speed... > The data won't feed correctly into it. But the simulation runs fine?
Guest
#4365169
Alex R. wrote: > Thank you, Lothar. So the sync reset will wait for a clock signal, then > it will reset a device, and the other does it at once. Am I right? No, not at all. Nothing waits for the clock, the clock triggers everything. The asynchrounous reset does nothing at once, it takes some nanosecs for the FF and sometimes longer than setup and clock to output time as for the synchrous reset.
Is somebody familiar with Matlab HDL filters logic? They have reset and clock enable inputs. How to initialize the filter properly? Lothar M. wrote: > Alex R. wrote: >> Here is the problem as a whole. > And how does this relate to sync or async resets? That's what I need to know to imagine timing diagram for the device. >> It runs on higher speed > Any figure for that "high speed"? > For me it seems like a simple constraint or clock-domain-crossing > problem. Or the FPGA is simply to slow to handle the speed... Maybe, this needs to be explored. > >> The data won't feed correctly into it. > But the simulation runs fine? Unfortunately, I test just "in vivo" so far. out of the mist wrote: > Alex R. wrote: >> Thank you, Lothar. So the sync reset will wait for a clock signal, then >> it will reset a device, and the other does it at once. Am I right? > > No, not at all. Nothing waits for the clock, the clock triggers > everything. The asynchrounous reset does nothing at once, it takes some > nanosecs for the FF and sometimes longer than setup and clock to output > time as for the synchrous reset. I don't quite follow you. Of course a small amount of time is necessary for this.