True Dual Port Ram Synthesizes error with two clock signals

[Altera_Forum]

Hello, 

 well i made a vhdl based, true dual port ram, and i wanted to use two separate clock input for each port, but QuatusII don't synthesizes it and generates the following error  Error: Cannot synthesize dual-port RAM logic "ram"  where 'ram' being : shared variable ram : memory_t; ,  well the problem is that when i use two clocks it gives this error, but when i use single clock, all goes well and i get no error.   any thoughts over this problem?  well the configuration of my system is, that i am using a Cyclone III - ep3c16q240 device, and first i want to test this RAM module alone, and further i will integrate it with my core, and then two different systems will be accessing this RAM with their specific clock. so this is the reason i need two clocks.  will be looking forward for the support. thanks for your time.  regards Ammar

[Altera_Forum]

--- Quote Start ---  use two separate clock input for each port  --- Quote End ---   Do you mean four clocks for the dual port ram in total? That's not supported.  You should check in the Cyclone III hardware manual, if your intended configuration is feasible with this FPGA. Also the Quartus MegaWizard is a convenient tool to evaluate the possible configurations. If you know that the configuration is supported, but you have difficulties to infer it from VHDL code, try the Quartus language templates.

[Altera_Forum]

--- Quote Start ---  Do you mean four clocks for the dual port ram in total? That's not supported.   --- Quote End ---    no, sorry its a typo, i wanted to say i need two separate clocks one for each port.  and yes i have checked the Cyclone III hand book, and it supports true-dual port ram with two clock inputs for each port. but i get this error. well okay i will then move to quartus MegaWizard, and will update results then.

[Altera_Forum]

Can you post your code - because what you are trying to do is possible. What is not possible is setting the read/write before write/read behaviour by using a shared variable (whereas you can with other other brand).

[Altera_Forum]

Hmm, it appears you are correct. You cannot create a dual clocked, true dual port ram from code. You can have quartus infer a simple dual port ram (with write/read on clock1 and read only on the other clock2) but not write from both. it is also not listed in the coding templates. 

 Raise an enhancement request with altera.  On a side note: to avoid all the stuff you get with the megawizard, instantiate rams directly in your code. You can control all the paramters yourself.  Just include the library in your file:  library altera_mf; use altera_mf.altera_mf_components.all;  then browse to this directory in your quartus installation: /quartus/common/help/webhelp/master.htm#mergedProjects/hdl/mega/mega_list_mega_lpm.htm  For Quartus releases pre v10.0, you could link to this help from the help menu via "megafunctions/lpm" but that menu choice has gone now, but the help files still exist. Anything listed as a "parameter" is just a generic.

[Altera_Forum]

Oh I see, a surprizing result, the true dual port RAM template of the Quartus editor doesn't compile in Quartus. One would expect, it has been ever tested before. 

 P.S.: I started a new project with default settings from the scratch, and the template true_dual_port_ram_dual_clock compiled correctly.

[Altera_Forum]

Doh 

 Yeah it does work fine Thicko here was trying to use separate read and write addresses.  So yes, Quartus CAN infer true-dual port rams quite easily. Ammar - show us the code you were trying to use.

[Altera_Forum]

hi, well, after being testing all the options, i am back with results, 

1st i tried to check the option of MegaWizard, and i create a Dual port ram with two clocks, configured for Cyclone iii fpga, and yes i created it in a new project. then connected it to input and output pins, assign the pins to fpga-pinout and then i just flashed this dualport ram to my fpga, but it didnt work as it should, as soon as i connect this fpga to a micro-controller (ARM7) it stop working, and when i remove FPGA, then the micro-controller starts to work again, it seems as if their is a problem with the logic, or the way is it flashed? (is it possible? or is their a special way to flash a RAM module to fpga?) this is my first time to use FPGA as a memory module so this is why i have such questions.   2nd, is the question for the code i am using to make my custom dualport ram, well you can see as follows, when i use this code with a single clock then it is compiled, else it wont. and here it is being configured with one clock, so it is working fine.  BUT the problem is the same when i flash this code to fpga, i get the same problem that micro-controller stops working.   i also have checked the results on scope, and it appears that when i flash the fpga with any of the above configurations, it results like the pins of fpga change its state from low to high (during configuration) and then remain high. which doesn't seems normal to me, or is it okay???

[Altera_Forum]

1. There is nothing specially about putting a design into an FPGA. It doesnt just "flash a ram", the entire chip is saved in flash. The problem here is probably down to your logic inside the FPGA. 

 2. I tried compiling you code, I got this error:  info: ram logic "ram" is uninferred due to inappropriate ram size  Plus you also have a chip select. There is no chip select in the HDL template provided by quartus. If you remove the chip select lines it compiles fine. memories inside the cyclone (and every other FPGA) do not have chip select.  It will be up to you to modify your other logic to behave correctly.

[Altera_Forum]

yes, this is the last changes i made to this vhdl, by adding a chip select (i just needed is because its being required in my design, any how, even i remove this,program get compiled, but i dont get proper results from fpga. 

 ok, if there somthing wrong with this code, then to omit this fear, i used the quatrus ii template for true dualport ram, and flash tht to fpga, reaction of fpga was same. so, where could be the problem now?? somthing missed by me or is it the FPGA???  also i tried some other small test codes on this fpga and they worked, and it was just to prove that fpga is alive or dead.

[Altera_Forum]

Obviously, the "microcontroller stops working" issue can't be solved without tri-stating the data output to the bus. This would require in the first place a bidirectional (inout) port declaration, and secondly additional logic setting the output to (others => 'Z') when unselected. The tri-state operation isn't part of the RAM MegaFunction. On write, the cs would be decoded into WE signal, on read, it can be ignored by the RAM, only the bus tri-state matters.

[Altera_Forum]

Do you have any other VHDL? 

The problem is more likely your code being incorrect, or you not doing the interface correctly  What is the Cyclone 3 connected to?

[Altera_Forum]

--- Quote Start ---  Do you have any other VHDL? The problem is more likely your code being incorrect, or you not doing the interface correctly  What is the Cyclone 3 connected to?  --- Quote End ---     well, for now this is the code i am using,  well may be there be an interfacing problem, but this is such a simple structure now, how could there be any interface problem. well the cyclone 3 is connected to a RAM and ARM7, over an address and data bus.  also, all these components are on a custom designed pcb, i.e. fpga, ram, arm7, variable power supplies..etc..

[Altera_Forum]

FvM has outlined the problem. Because you need chip selects you need to implement tri-state buffers on the IO. the CS signals control the tri-states and the we goes into the memory. The memory has no tri-state drivers of its own, so you have to write them yourself.

[Altera_Forum]

--- Quote Start ---  Obviously, the "microcontroller stops working" issue can't be solved without tri-stating the data output to the bus. This would require in the first place a bidirectional (inout) port declaration, and secondly additional logic setting the output to (others => 'Z') when unselected. The tri-state operation isn't part of the RAM MegaFunction. On write, the cs would be decoded into WE signal, on read, it can be ignored by the RAM, only the bus tri-state matters.  --- Quote End ---    well, ok, this works, i have added the tristate as you suggested, and the conflict with Arm has been removed now. but i still have to make sure that the dpram(in fpga) works when it is being enabled by the micro-controller (arm).

[Altera_Forum]

write some data into it and read it back.

[Altera_Forum]

Hello Again, 

 well, i have got some very strange results, but before that i would like to mention few things, i had a problem with configuring my fpga with my designed core, and form every forum and altera support i was said that there is a problem with my vhdl core design. but, last night, i discovered something new and strange,  what i did is i moved to one of the Altera Quartus tools " Chip Planner", and then i randomly select some regions (LogicLock Regions) and forced the Fitter to add my logic in that region, and with a series of hit and trials at certain point the whole logic starts to work, but with some errors, i would also like to mention that in my current design i am also using a True Dual Port Ram MegaCore, and now certain addresses of this MegaCore are not accessible to read and write. and these unaccessible addresses are randomly spread over the region.  so now the question could be that is there a way to test the silicon region of this FPGA, or can i test all the cells inside FPGA that are they dead or alive or working/not-working ??  Regards

[Altera_Forum]

Im guessing you have some unregistered read or write ports, and so you are causing timing problems as you move it around the FPGA, but these timing problems will be different for different parts of the FPGA because of different routing delays.

[Altera_Forum]

--- Quote Start ---  Im guessing you have some unregistered read or write ports, and so you are causing timing problems as you move it around the FPGA, but these timing problems will be different for different parts of the FPGA because of different routing delays.  --- Quote End ---     first apology for a mistake, actually i can read those bad memory locations, but can not write, or what i write is not written so those registers are readable only or so... for instance, the register addressed 0x00 is always 0xcc , no matter what i write on it its always this 0xcc. okay about the timing problems, yes that might be true, but i just made a small test, and what i did, i simply remove the True DualPort Ram form rest of the core, and configured the fpga with this design. and all the registers of the RAM work properly, then i moved the exact same working design to some other location / region of FPGA and, the DualPorted ram stopped working. so now the reasons. could it be that the silicon of the FPGA is damaged?? or  could it be because of the VCC/GND connections of the FPGA?? or some kind of interference inside FPGA??

[Altera_Forum]

--- Quote Start ---   could it be that the silicon of the FPGA is damaged?? or  could it be because of the VCC/GND connections of the FPGA?? or some kind of interference inside FPGA??  --- Quote End ---    My first instinct would be that it is none of these, and something to do with your tests and logic set up. If any of these were the case, I dont think anything would work. Please post some of the code you are using.

[Altera_Forum]

okay, may be you are rite, but, what if the logic is correct, i mentioned in my previous post, i used a MegaCore (true DualPorted Ram) generated by MegaWizard in Quartus, its no more my vhdl code, and now this MegaCore, works in some regions of FPGA and it wont works in the other. so i think the logic is correct. may be we should think about some hardware issue then??