How to use this

[Electronscape32]

Im very new to VHDL but i dont know how to use this!

have you got a basic setup i could use?

id like to use 4 switched, 1 and 2 to increase the address, and 3 and 4 to set a value i have 4 7segment display too

Im really at my witts end! PLEASE help! :)

[dnotq]

If you are new to HDL (VHDL or other), FPGAs, electronics, or DRAM, then you really might want to consider learning more of the basics first. SDRAM is not quick or easy to use. To use this core you will need to have a strong understanding of FSMs, and have some sort of SoC, CPU core, (or dedicated FSM) that can address a memory device.

This core is set up to make a specific SDRAM (the part number I wrote this for is given in the code) look and operate like an SRAM. That means you should at least know how to use an SRAM in your system first. Even better to just use Block RAM to get your system working, then switch to an external RAM device if you need more memory.

There are a lot of books and websites on for helping people learn HDL and FPGAs.

[Electronscape32]

I didn't expect an answer! but I'm very very green with the VHDL... believe me, I'm working on learning VHDL all over again, i think i just jumped into the depend expecting it to be easy! I WAS WRONG lol

I've decided for now that i should use a simple SRAM to start with,

i know there are timing things to work on, but even then i'll have problems with writing and reading, id need some sort of pipeline to handle this? like a dualport ram? write to one, read from the other, and let the SRAM controller use the buffers?

does that sound like an approach worth trying?

Im a heavy C coder so just remembering that the FPGA does things at once is almost alien to me! (i almost gave up)

THANK YOU for responding though...

do you have an example i could look at for your SDRAM ? i mean i wont understand it at first (i learn by example) but VHDL isn't one of those is it lol

[Electronscape32]

can you recommend a tutorial website / book for VHDL? (Verilog is simply too alien to me lol)

[Xalior]

https://nandland.com/ is a good start if you have never touched a synthesis platform before.

[Electronscape32]

Thank you Xalior!!!

[dnotq]

Learning FPGAs has very little to do with writing HDL (VHDL or Verilog), and more to do with learning and understand digital logic and basic electronics. HDL means "hardware description language", and when you write HDL you are not writing code, you are literally describing hardware. If you don't know what the hardware is supposed to look like, you won't have much luck describing it.

Knowing how you would build a circuit using actual logic chips, like the 74LS series, will make your FPGA work much easier and successful. You should always be able to draw at least a general logic diagram of the circuits you are trying to describe with whatever HDL you decide to use.

Hardware is hard, that's why it is called hardware. You need to stop thinking in software terms, hardware is not like software, and there is not a whole lot from software programming that applies to writing HDL. The biggest similarity is that writing HDL looks like software code, which in some cases is unfortunate because it gives the sense that writing code and HDL are somewhat related.

As for the remembering "FPGAs do everything at once", that is simply inherent in all hardware, and requires a change in mindset. Simple example: say you have two kitchen timers and you set one for 5 minutes and one for 10 minutes. When the 5 minute timer is done, it does not affect the 10 minute timer in any way. They are separate hardware, they work at the same time because they are different circuits. If you want them to interact, say one timer starts the next, or something like that, then you need other circuits to tie them together and coordinate their interaction.

When I was getting into FPGAs I found that books from the 1970s and 1980s on digital computer design and architecture are really good sources of information (digital logic has not changed, it is only smaller and faster). I also needed to stop thinking in terms of software and sequential instruction "execution", as mentioned above.

Two of the best FPGA books I have read are:

FPGA Prototyping by VHDL Examples, Pong P. Chu https://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/0470185317/ref=sr_1_3?crid=1TDFWX89ZI7AA

Digital Design and Computer Architecture, Sarah and David Harris https://www.amazon.com/Digital-Design-Computer-Architecture-Harris/dp/0123944244/ref=sr_1_2?crid=XS6D9MQR7HGH

The Pong Chu books are expensive, but worth the money IMO. The Harris books are good too, and 1st edition is fine.

If you have never synthesized a design into an actual FPGA, then you need to get a small FPGA devboard and start with some really basic circuits and work up from there. The "Hello, World" of FPGAs is blinking and LED.

[Electronscape32]

the strange part is... i was able to get a pretty comprehensive PONG game working on a VGA... the "process" and rising_edge clocks brought me RIGHT BACK to the good old days of flip flops! soon as i understood that, the Pong game just simply got easier to understand.

I have a dev board (a chinese thing documents are a nightmare but was able to unerstand with limited understanding) I got basic BRAMs working though i didnt fully understand why a ram had TWO ports (i've since read on this and it makes total sense why! it brillient for buffering)

i fully understand how an FPGA work. they're almost like tons of 74LS chips... i was mad on the JK FLIP flop. so the first description was a 4 bit JKFlip flop and a BCD 7447 chip.

i just learned that the FPGA can have several bits of hardware inside it, and you treat each one as tho you're "gluing" logic together! THAT was the missing key for my SDRAM thing, i was not really understanding the "write enable" wait for a bit "enable chip" wait for a bit.......... the waiting part is not relevant in FPGA unless you describe a 555 time (although isn't that classed as analog?? LOL )

Also totally forgot about propagation delay too! so THATS a noodle to unlock too!

ive gone back to the drawing board and going through the nandland site... hated boolean logic. and yet i want to go into FPGA! lol i almost quit 4 times! so 2 years later im having another crack.

Thank you for the links!! you've gone out your way for a budding random!! this wont be forgotten!!!

after Looking at bother Verilog and VHDL...... i seem to have found that VHDL is more readable to me than Verilog is considering how Verilog sort of resembles C ... my thought was "get completely away from C programming when dealing with FPGA"

the SRAM might push me into not giving up and teach me were i keep going wrong ;)

[dnotq]

I'm partial to Digilent devobards and Xilinx FPGAs, myself.

Any time you get more than some simple logic where you need a clock, then you are squarely into synchronous digital design, and propagation delays matter, which is entirely driven by your clock's period.

To use a memory device you will need to be able to control timing in your circuit, which is done with your clock and some form of state (usually managed with registers). You can sequence things like memory access with a hard-wired FSM, or in an SoC you usually have a CPU core controlling the address and data bus.

SDRAM (synchronous DRAM, which includes all forms of DDR1,2,3,4,5,6) is, as the name implies, synchronous and requires a clock. It is also "command based memory", and requires specific initialization and sequencing to read and write data (which is what my SDRAM core does.)

The "set write-enable, then wait" is accomplished with an FSM, and the waiting is based on your clock. Depending on the speed of your system clock, and how long you need to wait, yes, you might need to implement some sort of timer, etc.. This is not uncommon when interfacing external memories, etc..

BlockRAM is dual-port because in the FPGA "they can be", and it makes using them easier and more flexible. They are also usually single-cycle access, so very fast and interface really well with your other internal circuits. They are mostly used for buffers and clock-domain crossing, but on larger FPGAs there might be enough BlockRAM to implement a SoC main memory, etc..

Agreed totally on getting away from anything that looks like C (i.e. Verilog) when dealing with hardware. I prefer VHDL as well.

[Electronscape32]

i am finding that most of my dreams are thinking about sequential logic... in VHDL its dirt simple to DO a counter... the case WHEN option is extremely useful i found.... i think my problem is, the interconnectivity of the files and instantiation of things. implied logic is not so difficult now (ever since i realise that the Cyclone - the one i have EC6CE22 ) requires a M9K to be at least a certain size, the type array thing blew me away simple yet complex.

i dont think i'll be working with SDRAM anytime soon since i have to work out how to cross clock domains too

especially if i want to have a VGA data from the SDRAM! from what i've calculated a 100Mhz SDRAM will still need about 7ns to do a command, in total roughly about 20ns in total! which is far too slow for 640 x480 pixel display.... so THATS where the FIFO BRAM would come in! draw the line from the FIFI buffer... then on the porch and backporch time, load up the fifo from the SRAM!

i think i understand what NEEDS to be done, its the HOW and when that got me, so clearly im not ready for anything quite LIKE this!!

im trying to build up a home brew computer with a 68000 CPU (so DTACK is a thing too!) now ive done a graphics board with an STM32 it has onboard ram controller and a lot of clock cycles, but the delay between data transfer from the CPU core ram to the graphics adaptor is simply tooo slow for anything complex THATS why i wanna try this in FPGA!

the VGA i couldn't believe just how EASY doing that on an FPGA was in comparison!

but the trade off is, EASY to do on FPGA a PAIN to access ram MCU easy to read stuff from ram, a PAIN to get VGA working! lol

this is why i chose VHDL too, its sooo soo different from C it forces my mind to think differently too

the procedure feature on VHDL is astounding! same hardware and can be use multiple times at the same time!! again i want to make a 8x8 pixel char draw on the screen using one of these..... but more reading.

your SDRAM controller is precicely what i need tho, as in Acts like an SRAM, but i dont know how to connect your controller with my project...

is your controller meant to be a seperate file that i instantiate? or plop it into "TOP LEVEL"? thats the part im still not quite understanding

[dnotq]

There is no clock-domain crossing for SDRAM, it is synchronous (that's what the "S" is all about). But is does have clock requirements due to refresh demands.

A 640x480 VGA pixel is ~40ns. A 100MHz SDRAM needs about 70ns for a random memory address access, so to use SDRAM to hold a VGA screen you will need to be more efficient with reading the memory to support scan-out. My controller was design to act like a 70ns SRAM, so it will not work for this purpose.

Getting a VGA monitor to sync is easy, just a pair of counters and some combinatorial logic, mostly. Getting data pumped out at the pixel rate is entirely a different matter. You might want to look at my F18A project, or the CollectorVision Phoenix, or many of the coin-op open-source cores out there, etc.. They are all doing video and driving external monitors.

Building retro computers on FGPAs is really fun, however I would recommend you start with one of the 8-bit CPUs, like a Z80 or 6502, and keep the speed around 1MHz to 3.58MHz (common for Z80). You can bring that kind of system up much easier use BRAM for the main RAM and ROM. After that, start expanding to the bigger and more complicated chips like the 68K, etc.

Yes, the SDRAM is designed to be instantiated. But you need to have the real external memory connected to your FPGA, and I designed it specifically for the chip on my devboard. You might have to customize it for your specific SDRAM chip. Again, not a trivial task since SDRAM is overly complicated.

[Electronscape32]

see this would be perfect, i realise that this controller would be too slow for VGA, but it might be good for a VIC chip ;)

already stuck trying to get a bidirectional ram access... this is going to do my head in! what i thought i knew about digital electronics, im woahfully behind!

entity top_srammer1 is

port (
    clkIn    : in std_logic;
    segment7  : out std_logic_vector(7 downto 0);
    SEGPWR   : out std_logic_vector(3 downto 0) := (others => '1'); -- power up display 0 to 3
    key          : in std_logic_vector(3 downto 0);
    key_reset : in std_logic;

    -- SRAM PHYSICAL CONNECTIONS --
    sram_addr   : out std_logic_vector(18 downto 0);
    sram_data   : inout std_logic_vector(7 downto 0);
    sram_we     : out std_logic:='1';   -- write enable
    sram_oe     : out std_logic:='0';   -- output enable (will need this to get data from chip, will likely need to buffer this for the VGA)
    sram_ce     : out std_logic:='0'    -- chip select

);
--sram_oe <= '0';
--sram_ce <= '0';
--sram_we <= '1;

end top_srammer1;

-------- its turd, but im trying to work this one out!

signal data_in : std_logic_vector(7 downto 0);
signal data_out : std_logic_vector(7 downto 0);
signal we : std_logic;

begin

data_in <= sram_data;
sram_data <= data_out when we = '1' else "zzzzzzzz";

this didn't work the sram_data is a std_logic_vector on a port

the instantiated just made a WHOLE lot of sense!! i just need now to learn how to do that part, i wont be using your model yet until i have the basics down!

and i believe doing a bi-directional 8 bit port is pretty important! tri-states have always confused me before, but in fpga EVEN MORE so!

[Electronscape32]

its crap code, but... IT WORKS!! i have a slight better understanding, but this is awesome!!!! turns out zzzz is not the same as ZZZZ :/ thank you so much for your help! i WILL be back ..................... sorry ;)