altsyncram in simple dual-port mode

[Altera_Forum]

Hi, the altsyncram in simple dual-port mode does not seem to work correctly. It appears to have some internal pipelining on the data and address inputs relative to the wren and even each other. 

 Also, the modelsim model seems to work slightly differently than the actual FPGA-based instantiation (shown with Signal Tap).   Any insights into the use of this megafunction in the Stratix III?   Thank you for any help!   Shayle

[Altera_Forum]

In any ram you may have options of registering the input, address, output. Moreover the clock edge used may not always be the rising edge. This may be behind what you observed though you haven't specified what is wrong.

[Altera_Forum]

--- Quote Start ---   the modelsim model seems to work slightly differently than the actual FPGA-based instantiation (shown with Signal Tap).    --- Quote End ---  Post your testbench, the testbench waveforms and your SignalTapII waveforms.  I've never had any issues with Modelsim vs SignalTap with the altsyncram component (except for the time I used a newer version of Modelsim-SE, rather than the Modelsim-ASE version shipped with Quartus). Though I've only ever used it in single-port or dual-port mode. Perhaps simple dual-port has an issue. You could try it in dual-port mode and see if that changes the results.  Cheers, Dave

[Altera_Forum]

Thank you Kaz. I believe all clocking is rising edge. 

 I have attached an update of data captured showing what I believe to be incorrect behavior in both the FPGA instantiation and in Modelsim, and also showing the two not matching each other for identical designs.   The drawing also has the text explanation included below. Please let me know if you have further questions on my description. Your help is greatly appreciated!   Thank you, Shayle ******************************* From attached drawing: Top picture:  Signal Tap capture of altsyncram behavior in Stratix III, showing read data correct in sequence but at wrong addresses. Output mode is non-registered, so data 1 should be at address 0, data 9 at address 1, etc. Bottom Picture:  Modelsim behavior of identical altsyncram design showing correct data from address 3 and above. However, data at addresses 0, 1, and 2 are incorrect. I suspect there is some internal pipelining going on in the altsyncram function that I don't know about, and that Modelsim models that differently than that of the actual instantiation. Any help or insights are greatly appreciated.

[Altera_Forum]

Thank you, Dave.  

 Please see my new update which I think contains the information you mentioned.   I am also adding the following design file info...and yes, it is AHDL!   :-) ...but the megafunction IP is transparent to the HDL, of course.   Thanks...here's the relevant code:   INCLUDE "altsyncram.inc"; constant TRADE_DAYS_MAX = 60;   TradeDays_Store : altsyncram WITH (  ADDRESS_ACLR_B = "NONE",  ADDRESS_REG_B = "CLOCK0",  CLOCK_ENABLE_INPUT_A = "BYPASS",  CLOCK_ENABLE_INPUT_B = "BYPASS",  CLOCK_ENABLE_OUTPUT_B = "BYPASS",  INTENDED_DEVICE_FAMILY = "Stratix III",  LPM_TYPE = "altsyncram",  NUMWORDS_A = 2^(log2(TRADE_DAYS_MAX)),  NUMWORDS_B = 2^(log2(TRADE_DAYS_MAX)),  OPERATION_MODE = "DUAL_PORT",  OUTDATA_ACLR_B = "NONE",  OUTDATA_REG_B = "UNREGISTERED",--"CLOCK0",  POWER_UP_UNINITIALIZED = "FALSE",  --RAM_BLOCK_TYPE = "M144K",  READ_DURING_WRITE_MODE_MIXED_PORTS = "DONT_CARE",  WIDTHAD_A = log2(TRADE_DAYS_MAX),  WIDTHAD_B = log2(TRADE_DAYS_MAX),  WIDTH_A = 256,  WIDTH_B = 256,  WIDTH_BYTEENA_A = 1  );   TradeDays_Store.clock0 = clk0;  TradeDays_Store.data_a[] = data_stock_data_in[];  TradeDays_Store.address_a[] = TDS_wrAddress[];  TradeDays_Store.wren_a = TDS_wren;  TradeDays_Store.address_b[] = TDS_rdAddress[];  data_stock_data_out[] = TradeDays_Store.q_b[];

[Altera_Forum]

signaltap is correct, data will have latency of one clock at least as address is registered apparently. 

Modelsim is showing same latency but your clocking is different.

[Altera_Forum]

I agree with Kaz. The SignalTap response looks correct. 

 If your Modelsim stimulus is not very close to that in hardware, then you will see what appears to be a difference.  Post your Modelsim testbench code and we can comment on that.  Cheers, Dave

[Altera_Forum]

Hi Dave and Kaz (and others), 

 Attached is the Modelsim folder that includes my .do file and the .vho netlist file that Quartus created from the original AHDL design.   I believe the Modelsim waveform shows the inputs matching the values and timing of the Signal Tap waveforms, which is why I suspect a problem in Modelsim or in Quartus's netlist generation...perhaps the latter makes more sense. But maybe I have missed something.   As for the Signal Tap display, the megafunction wizzard diagram shows one register on each of the data, address, and wren control signals. Normally that means that the data presented at the same clock edge as the wren will go into the address that is presented at that same clock edge. I have suspected, as Kaz also hypothesized, that there is a mismatch in altsyncram internal pipelining between the address path with respect to data and wren. Although that could be handled by an additional, external register delay on the write address port input, there seems to be other problems as well.   I have attached a document showing two Signal Tap drawings. The first simply adds the extra, external write address delay to the write address port and has a continuous, incrementing write address, regardless of the other inputs. This works as expected.   The second drawing shows the same design and inputs, but with the address being set to exactly what is needed, matching the data and wren. Here, three writes fail to occur that should have occurred, and the only difference is that the write address is not continuously incrementing.   Any insights you have to this problem would be greatly appreciated!   Thank you, Shayle

[Altera_Forum]

Now you confirmed what I said:  

input data and address are registered, so data written will be coincidental with address but data read out will not be be coincidental and must be delayed by one clock (what you call mismatch)  so your first posted signaltap waves are correct.  Now the issue is why modelsim is different. I believe it is not different in this respect. It shows one clock delay as well.   You are not comparing like by like as you are not dealing with a synthesisable testbench. It looks like your clocking changes in between. Show us the clock waveforms in both cases and you will see.

[Altera_Forum]

Hi Shayle, 

  --- Quote Start ---   Attached is the Modelsim folder that includes my .do file and the .vho netlist file that Quartus created from the original AHDL design.   --- Quote End ---    This is not a testbench though. All you have uploaded is the .vho file.  A testbench should create an instance of the component and then drive signals onto the component ports, and check the response on the output ports. You really need to learn how to do this.  There's an example in this thread:  http://www.alteraforum.com/forum/showthread.php?t=32386  Cheers, Dave

[Altera_Forum]

Hi Kaz and Dave, 

 As you described, I have determined that the altsyncram function is working correctly and that problems I had with it were really more of trying to deal with my perceived belief that Modelsim/Quartus netlist extraction wasn't working correctly.   I have now determined that Modelsim is also working correctly and that the issue is that Modelsim required >0 ns of hold time on the write date port input. This result is in line with what I believe you were getting at earlier in the thread along with a hint I noticed in that the data output Modelsin was showing was delayed by 1 ns from the clock (tCO time).   As the netlist is generated by Quartus without timing info, i.e. only by Analysis and Synthesis, I was expecting only a functional simulation. However, I see Modelsim still includes timing, at least in some ways, and so for at least some input I must have greater that 0 ns of hold time.   That is the interesting solution to this problem, as simple as it now seems.   I agree that I should look into more sophistigated types of testbench simulation, which can also provide the advantage of interactive simulation. But for now, for this work, the *.do file feeding into Modelsim is good and works well, and uses the Altera model of the IP, though this exercise has certainly underlined the importance of understanding even the most subtle aspects of the tools used (such as the >0 ns hold time on the inputs in the stimulus file).   Thank you again for your help in getting me to this understanding and achieving success in my design work.   Shayle :)

[Altera_Forum]

Hi Shayle, 

  --- Quote Start ---   I have determined that the altsyncram function is working correctly and that problems I had with it were really more of trying to deal with my perceived belief that Modelsim/Quartus netlist extraction wasn't working correctly.    --- Quote End ---    I'm glad you have it working.  I would discourage using whatever technique that resulted in a testbench that uses Tcl to force signals onto the design. If you are serious about HDL coding, then you need to learn how to code for both synthesis and simulation using VHDL and/or Verilog/SystemVerilog.  I know, its a lot to come to grips with when you are starting out. But when you have some time, make the effort to learn how to use Modelsim. It will pay off pretty quickly when designs 'just work' in hardware, given that you have them working in the simulator. Its a lot easier to see all the signals in Modelsim than it is to tap them with SignalTap, but then it is nice to see the SignalTap waveforms matching simulation too.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Yes, good advice. All very true.   I will do that later, when I get back to Verilog. For now, I am using AHDL and letting Quartus generate the netlist.   When I get a chance, I will follow your recommendation.   Thanks, Shayle