Minimum pulse width violation for altsyncram

[Altera_Forum]

Hi, all, 

 During timing analisys I get unexpected minimum pulse width violation for clock signal in very simple project with altsyncram. I am using TimeQuest Timing Analyzer in Quartus II v12 and compile for Cyclone II.  Device has singleport altsyncram, input pins, registers for them, output pin and clock control block. The last is used to guarantee the proper global clock for memory. As everything is synced on front edge of clock, I wouldn't expect low or high pulse width violation for clock.  Here is my sdc file: create_clock -period 220MHz -waveform {0.00 2.27} -name {clk}   For CycloneII memory blocks I would expect fmax not much less, than 250 MHz, but actually I get less than 200MHz for EP2C3F672C6.  Here is message about frequency that I get:  | Fmax | Restricted Fmax | Clock Name | Note | 316.06 MHz | 199.96 | clk | limit due to high minimum pulse width violation (tch)  Types of violation in minimum pulse width report are both high pulse width and low pulse width. Here are some targets of violation from minimum pulse width report:    --- Quote Start ---  sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|q_a[0] sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|q_a[1] <..> sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|q_a[7] sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|ram_block1a0~porta_address_reg0 <..> sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|ram_block1a0~porta_address_reg4 sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|ram_block1a0~porta_datain_reg0 <..> sram_megaf:inst|altsyncram:altsyncram_component|altsyncram_oub1:auto_generated|ram_block1a0~porta_datain_reg7  --- Quote End ---    Is this a problem of not fast enough device or is it something else?  Some authors here previously had similar problem. Some solutions were about synchronizing memory interface, but it wouldn't help in my case as memory inputs are already fed by registers.   I would appreciate any help!  Sincerely,  Olga

[Altera_Forum]

Are you in a -7? The M4k is only spec'd to run at 194.93MHz. None of them seem to be spec'd for 250MHz performance: 

 http://www.altera.com/literature/hb/cyc2/cyc2_cii51005.pdf#page=16

[Altera_Forum]

Rysc, thank you for the link! I guess number I used for reference was not exact. Cyclone II device handbook on Altera official site - this is where I found 250MHz as maximum performance of embedded memory. 

 Actually, I showed results I got for EP2C3F672C6 which is 6 speed grade. So I am still not sure how to interpret data from timing analysis. The biggest question is why high and low pulse width make the limitation, since all elements in device are synchronized only on front edge.

[Altera_Forum]

I think of Minimum Pulse Width violations as pure Fmax limitations for dedicated hardware. For example, if I created a design with just two FFs and they were put right next to each other, normal static timing analysis might evaluate an 800ps data delay, 200ps of skew, and say the device can run at 1GHz. Although the numbers used are correct, the clock tree won't toggle that fast, and so MPW comes in and says it needs to run slower. Dedicated blocks like the RAMs also have MPWs. Now, it may be split into a low and high time requirement rather than a single Fmax value, but the net result is the same. (Perhaps the RAM does something internally on the falling edge). In the end, I don't think it's designed to run that fast.

[Altera_Forum]

Thank you Rysc, I guess what I get is indeed the limitation of embedded memory.