1
\$\begingroup\$

I'm confused about the trigger for reading ROM.

I want to read one of 4 k bytes but it appears the clock is free running and may be continuing to read the same address while I'm processing the byte I read.

I can't use a wait value, since every byte has a different processing time. Sorry for this simple question that is not answered in any of a 100 tutorial files.

\$\endgroup\$
0
\$\begingroup\$

Your question's vaguer than it could be but I take it you're talking about an FPGA internal Block RAM that's being pre-loaded during configuration and used as a ROM.

This can vary depending on the FPGA family you're using but in general terms...

The ROM (Block RAM configured as read-only) reads are combinatorial but, during generation of the IP part, the address input and data output can be registered i.e. passed through D-type Flip-Flops (DFFs). Some FPGAs insist upon particular input/output registers, others let you choose. Their use can improve timing (max. clock frequency) if your has other combinatorial elements in the corresponding address input path or data output path.

If you use no address/data DFFs, your data output will be valid within a time specified in the FPGA data sheets. That can be converted into clock periods for the synchronous circuit around it, minimum 1 clock.

If you use just address or just data DFFs, your data output will be valid within 2 clocks of address valid.

If you use both address and data DFFs, data will be valid within 3 clocks of address.

The ROM has has no 'data valid' output. It's up to your logic circuit design to take data this specified number of clocks after the address changes. You can produce a 'data valid' by passing a single '1' bit into a delay shift register (SR) when you change the address. If the shift register length is that of the address-ROM-data delay, the '1' arrives at the SR output as the data arrives at the ROM output.

For fast throughput then, with careful design, you can pipeline ROM output data so that an address changes every clock gets a data output every clock, with every address-in-data-out pairing having a fixed latency of 'n' clocks.

\$\endgroup\$
2
  • \$\begingroup\$ Awesome rapid response identifies "latency" options not found in any of my searches. \$\endgroup\$ – NSSTEELMAN Apr 12 at 21:04
  • \$\begingroup\$ Awesome rapid response identifies "latency" options not found in any of my searches. \$\endgroup\$ – NSSTEELMAN Apr 12 at 21:04
0
\$\begingroup\$

There is no rule that says when you need to increment the address. Just increment it when you are ready for the next byte. Keeping in mind the latency of the ROM.

\$\endgroup\$
1
  • \$\begingroup\$ Your assumptions are correct. Your answer is on target and saves me from endless searches. THKs \$\endgroup\$ – NSSTEELMAN Apr 12 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.