Electronics > FPGA

vhdl - how to use memory bits for data storage?

<< < (6/6)

Someone:

--- Quote from: MadTux on October 26, 2021, 09:08:14 pm ---
--- Quote from: NorthGuy on October 25, 2021, 02:21:07 pm ---
--- Quote from: MadTux on October 25, 2021, 10:43:03 am ---What I found so far, it mostly comes down mostly to coding style

--- End quote ---

It is not coding style.

You read from RAM at one clock edge and then process the data you have read at the next clock edge.

Before the change, you tried to read from RAM and process the data at the same clock edge, which is impossible. So, the tools implemented what you wanted, but could not use RAM for this.

--- End quote ---

Why not? If building a design with TTL chips, I could very well do logic functions (put couple of couple of logic gates/adder/whatnot... on the data bus....) on data as it comes out of the data bus.
--- End quote ---
Its what you described in the code, by declaring the LCD_data as a register:
In the first case you add an additional register on the ram/rom read LCD_rom_out
..which differently-aligns the read address to the data in the second case so they aren't even equivalent..
In the second case LCD_data is muxed from constants and the combinatorial ram/rom read.

Block rams don't have an async read capability, so they cant be used for your second case. Yes, you could declare the registers on the other side of the mux and it would work fine, a clever toolchain might even optimise that for you knowing it wants the register in the ram. But you didn't do that, you asked for and were given an async ram/rom. I'll bet the output log file from the tools make this very explicit to you (but you never read them).

MadTux:
Code is a mess, I know ;-)
But happens, if you playing with lots of things at once: getting blockRAM/ROM implemented, display reasonable numbers on LCD, goofing with onchip PLL....
Guess I'll rewrite everything once LCD works and be careful how on how to use blockRAM.
PLL works fine btw, overclocked that Cylcone1 to 400MHz ;-), gave the PLL wizzard some 25MHz on clock input, while in reality, it's 50MHz, so it doesn't bitch about it. And guess what, it still works, doesn't even get warm, lol.
Perhaps I'll try what's the real limit of these C1s, but 400MHz vs official 275MHz is quite promising ;-) Guess I'll have to pick my Tek7904A/7A29 or even HP8658B for freq measurements from now on, little Hameg 1507 on my bench doesn't do it at these freqs ;-D
WTF, works even @ 500MHz, gets a little warm, though ;-)

BrianHG:
I thought the limit was 472MHz.  This is what's stated in most Cyclones and Max10s ds as well.  It is also the reason why my DDR3 controller works at 500MHz and my HDMI transmitter maxes out at 540MHz as it's only a few % higher.

NorthGuy:

--- Quote from: MadTux on October 26, 2021, 09:08:14 pm ---
--- Quote from: NorthGuy on October 25, 2021, 02:21:07 pm ---Before the change, you tried to read from RAM and process the data at the same clock edge, which is impossible. So, the tools implemented what you wanted, but could not use RAM for this.

--- End quote ---

Why not? <snip> Quartus simply implements that in logic instead of blockRAM.

--- End quote ---

That's exactly what I said.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version