Avoiding names that are already defined by python and so cannot be used to name a ROM.

[philiprbrenan]

If one attempts to create a ROM using a configuration file named array.py, globals.py effectively executes:

import array

Because array is also the name of a standard Python module, Python imports that module rather than the intended configuration file. Then the user receives the following error:

python3 rom_compiler.py array.py
Traceback (most recent call last):
File "rom_compiler.py", line 41, in <module>
openram.init_openram(config_file=args[0])
File "/opt/OpenRAM/compiler/globals.py", line 186, in init_openram
read_config(config_file, is_unit_test)
File "/opt/OpenRAM/compiler/globals.py", line 384, in read_config
OPTS.output_name = "sram_{0}b_{1}_{2}{3}".format(OPTS.word_size,

AttributeError: 'options' object has no attribute 'word_size'

Unfortunately, this error message is rather misleading. A new user could reasonably spend a considerable amount of time trying to understand why word_size is being reported as missing by rom_compiler.pywhen it is clearly present in the user's configuration file.

It would be helpful if this situation could be detected and reported more clearly. For example, the command-line/configuration-file handling could check that the requested configuration file has actually been loaded and provide an appropriate error if it has not. Or a standard set of command line keywords could be used to supply the options.

This relatively small change could prevent a surprisingly large amount of debugging time. Clear error messages would seem to be particularly valuable to new users, since encountering an apparently inexplicable error early in the process of engaging with OpenRAM can quickly undermine confidence in it.

I appreciate that there may be good reasons for the current implementation, but I wonder if this could be considered as an improvement to make OpenRAM a little easier to engage with as a new user?

[mguthaus]

The rom compiler is experimental and not well tested. If you have a fix, I'm happy to merge it into the dev branch.

[philiprbrenan]

If you could point me to a definitive list of parameters for each compiler and their default values, I could define an OpenRAM.py command using argparse so that the user could enter something like:

python3 OpenRam.py  array --rom --word-size-in-bytes=1 --content-file=aaa.hex --content-type=hex --name=array 

The OpenRAM command would then validate the arguments and call the appropriate compiler via subprocess so that potentially very little existing code would have to be changed except perhaps for the naming of the ROM. Currently the base name of the configuration file minus any .py extension appears to be used as the generated module name, possibly explaining why the current mechanism was used as a way of obtaining this information without using a keyword/value pair.

I suspect that the other compilers will also run into the problem described above as they appear to use the same mechanism to load their config files.

[mguthaus]

This already exists:

https://github.com/VLSIDA/OpenRAM/blob/stable/sram_compiler.py

Also check out the basic usage documentation:

https://github.com/VLSIDA/OpenRAM/blob/stable/docs%2Fsource%2Fbasic_usage.md

[mguthaus]

To be clear, everything is config file based. We opted to not use command line arguments since there are many and they are prone to error and/or difficulty replicating flows.