exdeath
Lifer
Self learning VHDL and most internet examples are overly simplified.
When accessing external SRAM for example they always show:
data <= sram(address);
But I know there is say 10 ns access time.
Am I missing something above?
I'm wondering why it's not data <= sram(address) after 10 ns; or something like that.
Still trying to wrap my head around the idea of events being scheduled and not happening immediately so perhaps if the process event occurs in an interval longer than the minimum access time of the SRAM it completely hides the access time or something.
Edit: I think I might be starting to see it.
"sram" or the part that the "address" is given to is often defined as a signal so the sram(address) happens immediately on assignment, but the assignment to data does not, something about assignments to non signals being scheduled and not happening immediately. Then whatever mechanism which governs when these scheduled events run (on the next "process" invocation which is > tAccs?) ensures that data is valid by the time it assigns it.
Ultimately I'm needing an example of say you had a process driven by a 150 ns dot clock and wanted to asynchronously access 10 ns SRAM 8 times per pixel on each tick of the dot clock to drive RGB values every 150 ns based on some combination of the 8 values read from SRAM (eg: multiple random and indirect accesses for name tables and tile fetches in a 80s/90s style VDP.)
Impatiently waiting for my Altera DE1.
I'm sure I can look up numerous MAME sources or something like that since retro microcomputer/console/arcade synthesis in FPGAs is an extremely popular hobby but much would be over my head right now, so just focusing on isolated basics with the whole back to back asynchronous memory access within a clock driven process window.
When accessing external SRAM for example they always show:
data <= sram(address);
But I know there is say 10 ns access time.
Am I missing something above?
I'm wondering why it's not data <= sram(address) after 10 ns; or something like that.
Still trying to wrap my head around the idea of events being scheduled and not happening immediately so perhaps if the process event occurs in an interval longer than the minimum access time of the SRAM it completely hides the access time or something.
Edit: I think I might be starting to see it.
"sram" or the part that the "address" is given to is often defined as a signal so the sram(address) happens immediately on assignment, but the assignment to data does not, something about assignments to non signals being scheduled and not happening immediately. Then whatever mechanism which governs when these scheduled events run (on the next "process" invocation which is > tAccs?) ensures that data is valid by the time it assigns it.
Ultimately I'm needing an example of say you had a process driven by a 150 ns dot clock and wanted to asynchronously access 10 ns SRAM 8 times per pixel on each tick of the dot clock to drive RGB values every 150 ns based on some combination of the 8 values read from SRAM (eg: multiple random and indirect accesses for name tables and tile fetches in a 80s/90s style VDP.)
Impatiently waiting for my Altera DE1.
I'm sure I can look up numerous MAME sources or something like that since retro microcomputer/console/arcade synthesis in FPGAs is an extremely popular hobby but much would be over my head right now, so just focusing on isolated basics with the whole back to back asynchronous memory access within a clock driven process window.
Last edited:
