Forum Discussion
Honored ContributorTrue Dual Port Ram Synthesizes error with two clock signals
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 Ammar22 Replies
Altera_Forumshared variables are not synthesizable
- Altera_Forum
Reviewing the thread, I see, that up to the middle, every reported issue has turned out as case of effectively operating the RAM in an incorrect way or some basic logic design error. Also considering a learning curve, it seems most likely that we still have something similar, possibly less obvious. Of course, an additional hardware issue would be possible though. Everything can be found out by intelligent utilization of debugging methods, particularly Signal Tap.
- 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??
- 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--- 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
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
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
write some data into it and read it back.
- 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
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.
