1
\$\begingroup\$

I am working on porting a large modern logic IC based PCB design to FPGA. It's a personal project, not work/professional or school homework. Just a learning exercise for myself.

Part of this design uses parallel EEPROMs as ROMs to take inputs on the address lines and perform operations based on the outputs (controlled by what's stored in ROM). Done to save chunks of glue logic on a PCB.

Using the Xilinx ROM Using Block RAM Resources (Verilog) I have made the ROMs and everything is fine. However, I notice that the ROMs have many patterns in them, and are just performing logic functions inside to generate the outputs.

My question is, will the Vivado toolchain work out that the BRAM functionality could be replaced with logic operations and create that instead, or will it always use the BRAMs?

The reason I ask is that on this design the MSB of each EEPROM is a reset control pin, which forces all outputs low. However this takes half of the ROM space (and thus a decent chunk of BRAM) just to contain all zeros. It's an easy win to half the ROM size and just handle the reset condition separately, doing so in the Verilog design. Other parts of the ROM contain large chunks of the same output for many given inputs, just by the nature of what's encoded into the ROMs.

Am I better to let the Vivado tooling do it's thing, or, make a Python script to pre-process the ROM binaries, and try to minimise the logic myself? Sticking with the ROMs maintains the original functionality & thus allows for new features/updates to easily be leveraged. But there are four 32kbit ROMs in the design, and that's tying up a lot of the BRAM resources in the small Artix7 35T part I'm using.

I'm competent with Verilog & hardware design, but not an expert. I can achieve working designs, albeit sometimes they're a bit naïve.

Thanks!

\$\endgroup\$
4
  • \$\begingroup\$ Can the ROMs be changed by the user (e.g. are they socketed)? If they are hardwired, then how would there be new features/updates? \$\endgroup\$ Commented Jan 12, 2023 at 16:42
  • \$\begingroup\$ The ROMs are inside the FPGA. \$\endgroup\$
    – M1GEO
    Commented Jan 14, 2023 at 22:36
  • \$\begingroup\$ I mean the ROMs in the original device. \$\endgroup\$ Commented Jan 15, 2023 at 6:42
  • \$\begingroup\$ Oh, right; They're in sockets (one in a ZIF socket) and the design does receive updates somewhat regularly (I'd say every few months). \$\endgroup\$
    – M1GEO
    Commented Feb 8, 2023 at 17:39

1 Answer 1

1
\$\begingroup\$

Submitting this answer even though I don't know the answer to

My question is, will the Vivado toolchain work out that the BRAM functionality could be replaced with logic operations and create that instead, or will it always use the BRAMs?

If you're using a pre-synthesized library block, definitely not -- in that case you really are directing Vivado to use BRAM. Even if you're not doing that, I still suspect not. It depends on how literal the designers are, and how willing to second-guess you they are.

But I have some other observations:

Sticking with the ROMs ... allows for new features/updates to easily be leveraged.

But then, that's exactly what FPGAs do, too. Especially if you do a good job of archiving your source code. So you're not losing any functionality.

Part of this design uses parallel EEPROMs as ROMs to take inputs on the address lines and perform operations based on the outputs (controlled by what's stored in ROM). Done to save chunks of glue logic on a PCB.

This is actually the oldest "programmable logic" technique. Then people noticed that redundancy that you mention in the memory, and came up with programmable array logic. Later, they came up with the idea of having itty bitty PALs embedded in a larger fabric -- they called it an "FPGA" and here we are.

Am I better to let the Vivado tooling do it's thing, or, make a Python script to pre-process the ROM binaries, and try to minimise the logic myself?

Vivado is, theoretically, at least as good as a human at minimizing logic, so -- no.

I think the first thing I'd want to do is to infer the underlying logic in a meaningful way. In other words, from your question you clearly have a "reset" line -- if you have a "load register A" line or a "run motor backwards" line or whatever, then you should write that logic out in your Verilog, instead of having some huge anonymous case statement in the code.

Then, when you give the project a rest for six months or a year and come back to it you'll have some clue as to what it all means.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks for the insight. I did appreciate that the original design is using the EEPROMs as super simple PAL-type devices - it did make me smile as I wrote the question. Some kind of recursion ;) At the moment, I've just got some huge anonymous case statement in the code and then I separate the signals out with assign statements at the end of the module, after the ROM magic numbers. Mainly so I could just dump the ROMs with a PROM reader and use them. I'll dig into what Vivado actually makes a bit later on and report back. Thanks. \$\endgroup\$
    – M1GEO
    Commented Dec 22, 2022 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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