Altera_Forum
Honored Contributor
14 years agoautomatic slave module generation
I have written a lot of slave IP lately, and have developed somewhat of a template/style that I use. Sort of like Altera's template, but much cleaner, in my opinion.
While having well-established methods of accomplishing what I need, it is still so much of a manual process, it is prone to errors and various compiler errors, such as missing semi-colons, mis-matched begin/end, etc. Other sources of errors: 1) The register name may need to be entered in multiple places in the code, and you make a typo. 2) The readdata assignment isn't mapped to the same addresses as the write logic. 3) Support signals related to the register name, should be named similarly to the register name, and if you change the register's name, these all need chaging as well. In addition to that, I manually comment the memory map, so if it changes, the documentation needs changes. Sometimes the documentation doesn't get updated. I have a standard way of handing stuff such as: 1) The register at a particular address using a single register name for a general read/write register. 2) The register at a particular address using a single register name as a read-only, or write-only register 3) The register at a particular address using different names for the read-only access, and write-only access. 4) The register contains bitfields that are named. 5) A write to a specific register address needs to trigger a pulse. The pulse may be used for anything such as a write request to a fifo, or a signal to another module to start it's state machine processing. 6) A read to a specific register address needs to trigger a pulse. The pulse may be used as read acknowledge to a FIFO, or whatever else you might want. 7) Writeable self-clearing bits in write-register. 8) Always 0 or 1 bits in read or write registers. I'm thinking of making a VB program to handle the generation of the source code, as a large register map require a lot of manual coding. Although it is somewhat mindless and robotically mechanical for me at this point, it is still time-consuming for prettying up the documentation and prone to making simple mistakes. A lot of my work requires replicating the functionality of a particular peripherial that already exists and has a well-defined datasheet and behavior. This leads me to believe I can make a program to enter in the registers, bitfields and required behaviors directly from a datasheet, and generate all the code that handles the CPU interface read/write, the other required behaviors, and documentation of the memory map in comments. Furthermore, I believe the custom user code can be placed in defined sections outside the generated code, so if anything changed you could regenerate the code. For example, if you are making your own custom peripherial, and need to add another register, this might expand the bits needed in your address range. This now changes not only the address definition, but also the case statement for the address when a write is occurring, the values compared to in the case statement, the readdata assignment logic, and any other code which compares the bit-range of the address register. Also, as development matures, I find myself changing the names of registers and bitfields to something more meaningful, or re-arranging the memory map to group similar register together. Changing a register name requires changing all other signal names responsible for additional behavior just for consistency. I think an app to enter in the register field names, bits, and behaviors (and allow you to save the configuration for later modification), would go a long way to solving these issues of the tedious, non-creative CPU interface code. This would allow me to get straight to work on the coding of the real "guts" module to be instantiated inside the auto-generated IP. Any comments, or additional basic features you can think of?