altsyncram in simple dual-port mode

--- 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

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.

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[];

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.

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

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

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.

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

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

:)