Scope Creep

During my work on ORPSoCv3, I realized that there were some problems with the SPI Flash memory model that I planned to reuse from ORPSoCv2. To use the file (and more importantly to make it publicly available) it turned out I needed a written license agreement. I now had three choices:

1. Pretending like I didn't see the license - Not gonna happen. I'm building a product intended for both hobbyist and commercial use, so I want these things to be done correctly, or I will risk that they come back and haunt me.

2. Try to contact the right people to ask for a relicensed version of the file. It could be worth trying, as there is at least a company name and the author's name in the file header that I could use to track down the owner. On the other hand, the last update was in 2007 and even if I would find someone who could claim ownership, it's not very certain that they would allow relicensing the file.

3. Rewrite the code. Even though I have tried hard to not reinvent too many wheels in ORPSoCv3, this is sometimes the easiest way forward.


The third option, which is what I chose, has some added benefits too. The SPI flash model in ORPSoCv2 is targeted for a specific flash that we used on an old board that I don't intend to support in v3, so the new code could probably be made a bit more generic instead. Instead of a monolithic BFM for a chip, I could create a generic SPI BFM (which I'm sure would come in handy in other cases) and try out an idea I've been having about a memory that uses VPI callbacks to store data in dynamically created C structures instead.

This is where the scope creep started...

First of all, the idea of having a dynamically created memory instead of a huge twodimensional array comes from the assumption that in some cases, we need a large memory map, but we only read and write to the small parts of that memory. Having a huge static verilog array means we have to allocate a lot of memory that will never be used, and the simulator might need to check for events on every bit, which could slow things down considerably. (Note here that I'm using might and could, since I haven't done any benchmarks to prove anything yet. It could also be very simulator dependent). So the idea here is to make an array of pointers to memory segments and only malloc a page when it is written to for the first time. The verilog code would have $read and $write functions that can read from memory and some init functions to preload images (elf, exo, bin, vmem, srec and whatever could be useful).

I started hacking on the C code, and it seemed reasonably simple to do this. To try it out, I wanted some real world testing, but unfortunately I didn't have any nice SPI test cases (nor a SPI BFM). The VPI memory backend however would be a good match for a simple model of a Wishbone SDRAM controller . If I could replace the existing controller (Scope Creep), I would be able to run all the existing ORPSoCv2 test cases to get some verification. Looking at the code for the existing model, it turned out to be a little awkward to fit the $read and $write commands in to the existing Wishbone memory model, so I decided to find a proper Wishbone BFM that I could use to interface with the memory backend instead (Scope Creep).

Searching around the internet I found a few commercial ones, a nice looking one in System Verilog, a VHDL version and an implementation in the ethmac testbench (an IP that I also happen to be co-maintainer of).

None of the existing models were up to the task however as I need it to be pure verilog and support Wishbone B3 burst transactions. The first requirement is because neither Icarus Verilog or the free Altera-provided Modelsim supports mixed language simulation, and everything I have is in verilog at the moment. Only the BFM from ethmac fulfilled the first requirement, but unfortunately it didn't seem to support burst transactions. The only thing left to do is to write a brand new verilog based Wishbone slave BFM myself (Scope Creep). I figured that would come in handy anyway, so it wasn't that much of a problem.

Implementing a simple BFM wasn't too much work, but it turns out that having a three weeks old baby and a full-time employement makes it a bit harder to find spare time to work on side projects like this. It also took a while longer since I at some point decided to refactor some things in ORPSoCv3 (Scope Creep),  make a Wishbone interconnect generator to make it easier to hook up the memory model to a CPU (Score Creep), and to test the inteconnect I would need to build a Wishbone Master BFM too (Scope Creep). The interconnect part was eventually dropped, but I did implement a basic Wishbone Master BFM. I also decided to start with a static memory before I tried out the VPI backed memory model.

Having come this far I thought it would be fun to tell the world about my new BFM once it was done, show of the capabilities of ORPSoCv3 and provide some cool benchmarks, and since I'm about ten years behind the rest of the world, I decided it was now time to start my first blog (Major Scope Creep!). Starting a new blog leads to some big decisions. I would either need to use an available web service to host my blog or do it myself. I decided to host it on my NAS since there is already a Wordpress package available for it. After installing the package and fiddling with MySQL permissions (Scope Creep) I realized that I needed a name for the blog, so I took a few days to come up with a number of witty names (Scope Creep), and abandoning them one after one as it turns out that all witty names for a FPGA/Hardware/Open Source/electronics blogs are already taken (stupid internet!).

About this time I also realized that I didn't really want to host my own blog since it probably meant that I had to tighten up the security of my home network and think a bit about how to provide decent availability, so the focus shifted to finding a good platform to use instead. This left me again with several choices, and the only thing to do was to read up on all the pros and cons of available services (Scope Creep). I started registering an account on wordpress, but had to stop when I realized that I still didn't have a name for the blog.

By now I was starting to get really tired of my own inability to finalize things, so once I came up with a name for the blog, I registered a blogspot account instead and started writing. The basic functionality for the BFM is mostly finished now, but I to avoid further delays in putting this first post out, I'll finish it and push it to the ORPSoCv3 repo after I'm done writing. The slave seems to have identical timing to the model I'm replacing, so I'll consider that good enough for now.

I'm fully aware that this first post need a lot of background informaton to make sense for people outside of the inner-most circle in the OpenRISC project, and that I should have written introductions about myself, the OpenRISC project, ORPSoC, Wishbone, BFM:s Open Source Hardware and whatever else I've benn talking about. Well, to relate to the title, I had to stop this scope creep before I totally lost control. So to finish things up and provide pointers about what I might write about in the coming articles, here's a summary of the work that led up to this article.

Initial target: Add an SPI memory model to ORPSoCv3
Work started: VPI backend for a dynamic memory model, Test bench for Wishbone interconnect, BFM-based static memory model
Work done: Basic Wishbone Master/Slave BFM, Choose a blog platform, Write a first post
Work planned: SPI master/slave BFM, Wishbone Interconnect Generator, Finalize, document and release Wishbone BFM, continue working on rough edges in ORPSoCv3
Work dropped: Hosting a blog, secure the home network, integrate existing Wishbone BFM

As you can see, I'm nowhere near starting on the SPI flash memory model, but at least I have a blog and a partially working Wishbone BFM! :)