Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

VHDL array clearing overflow memory

KfirMaymon84

Newbie
Joined
Jun 14, 2024
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
18
Hello,

I'm writing TFT driver for Basys 3 board (a hobby project),
in my design, I have an array of 8-bit * 28810,

full code line #79
Code:
  type t_Memory is array (0 to 28810) of std_logic_vector(7 downto 0);
  signal memBuffer : t_Memory := (others => (others => '0'));

when I'm trying to clear the array I'm getting overflow memory

clear array code:
full code line #113
Code:
if counter < 28809 then
memBuffer(counter) <= (others => '0');
counter <= counter + 1;
end if;--counter < 28809

Screenshot 2024-06-14 094533.png


without code in line #114
Code:
--memBuffer(counter) <= (others => '0');
Screenshot 2024-06-14 094826.png


I have attached the full code, what I am missing?
thanks for helping,
--- Updated ---

I notice that every assignment to the array is taking a lot of memory LUT,
way is that?

Code:
memBuffer(to_integer(unsigned(memoryAddress))) <= memoryData;

take more than 50% of the memory.
 

Attachments

  • TTF_Driver.zip
    2.7 KB · Views: 19
Last edited:
You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
 
Last edited:
You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
Thanks,

I did use it before but because I'm sharing the ram with Microblaze I had problems debugging it.
 
You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
I’m kind of surprised the tool didn’t figure out how to implement the inferred RAM and just tried to stick it all in LUTs. Maybe there’s some configuration bit in the tool about how to implement RAM?
 
I’m kind of surprised the tool didn’t figure out how to implement the inferred RAM and just tried to stick it all in LUTs. Maybe there’s some configuration bit in the tool about how to implement RAM?
The tool is processing any synthesizable HDL, to guarantee memory implementation in block RAM, you can either write structural code with low level primitives or refer to memory inference templates, otherwise you easily define logic that's incompatible with block RAM capabilities.
 
The tool is processing any synthesizable HDL, to guarantee memory implementation in block RAM, you can either write structural code with low level primitives or refer to memory inference templates, otherwise you easily define logic that's incompatible with block RAM capabilities.
All these years of development and AI yet they can't manage to infer a ram except from a template or do they care about easing design entry?
 
All these years of development and AI yet they can't manage to infer a ram except from a template or do they care about easing design entry?
The block RAM is synchronous. For reading, it clocks in the address in one clock cycle and clocks out the data in the next.
If you assign the address in one clock cycle, the RAM output can be assigned to other signals 2 clock cycles later.
You get the data from an asynchronous distributed RAM one clock cycle earlier.
It is very easy to write code that can't be implemented in block RAMs. The write timing is easy, the read timing is tricky.
It is easier to see/avoid the limitations of the wanted block RAM if it is implemented as a separate clocked process.
 
For BRAM inferences, you cannot reset the whole memory (or ever parts of them) in one cycle. The BRAM does not support it, thus the tool is inferring LUT instead.

If you need to reset the RAM, you probably need a long reset time (28810 cycles), where each cycle reset one individual BRAM address.

The most common way to proceed is not to reset the RAM and considere the RAM "dirty" after a reset. If you need the RAM cleared for simulation purposes, there are ways to clear the RAM in simulation and even after a FPGA power up, but not after a logic reset in one cycle as you want.
 

LaTeX Commands Quick-Menu:

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top