#22 "devel status" tag/attribute for cores


it would be useful if the processor implementations could expose a "devel status" tag or attribute which contains information about the development status of said implementation (i.e. "devel", "alpha", "beta" etc), so that such information can be queried from within the simulator for the currently selected processor. More generally, it would be useful if custom attribute fields could be easily exposed, so that additional info is made available ("VERSION","FEATURES", "TODO", "BUGS", "README")

i.e. along the lines of:

processor info:
description=emulates microchip PIC p16f628
devel status=alpha
version= 0.11 (date)
FEATURES=70% feature-complete
TODO=deal with TRIS issues
BUGS=eeprom support doesn't yet work properly

Although, it would probably be a good idea to to also expose a direct interface, so that individual properties/fields can be accessed directly:

processor <name>
processor <desc>
processor <author>
processor <version>
processor <todo>

In particular the latter should be useful to display fields which may contain more verbose info (such as todo, bugs, readme)

Overall, a facility to easily expose field attributes (i.e. implemented as std::map<std::string, std::string>) would easily provide end users (and potential contributors) with the possibility to query additional info about the status of the processor emulation they're using.


  • Nobody/Anonymous

    Logged In: NO

    with the obvious exception that the following isn't yet done, you could EMULATE what you seem to be looking for by simply using the "symbol" instruction which lets you define arbitrary symbols (key/value pairs):

    symbol name="p16xxxxx"
    symbol desc="my cool PIC emulation"
    symbol author="GPSIM community"
    symbol version="1.0"
    symbol todo="save the world !!"
    symbol bugs="none :-)"
    symbol fixme="indentation style & variable naming needs to be cleaned up"

    so, that's fairly simple to do: simply have each processor set the corresponding symbols and provide support for this info to be easily accessible from the CLI.
    however, given that there's only one single scope for these symbols, you might either want to EMULATE scopes by prepending a token (i.e. "processor.", so that the symbol names could be uniquely identified: symbol processor.name="p16fxxxx") or really start introducing real scopes.

  • Nobody/Anonymous

    Logged In: NO

    making more consequent use of these symbols within the emulator runtime would actually seem like a good idea, as most of the emulator-internal state variables could also be exposed via such symbols, so that the emulator may be easily re-configured at runtime - this could for example be useful to enable/disable certain features which may otherwise have performance impacts (i.e. such as logging/tracing)

  • Nobody/Anonymous

    Logged In: NO

    it is exactly this sort of info that would normally be provided via a so called "property tree" (wikipedia), which is a hierarchical tree of strings and values, where the representation is pretty much like an LDAP directory so that "scopes" are implemented by nested structures similar to directories on a filesystem:

    /internal/processor[0]/name = "pname"
    /internal/processor[0]/desc = "desc"
    /internal/processor[0]/todo = "todo"

    whereas the [x] token at the end of the identifier would serve as an automatically appended index, to allow multiple tokens to be identically-named
    boost has a freely available and powerful property tree implementation.

  • Nobody/Anonymous

    Logged In: NO

    this sort of thing would at least be useful to directly view the implementation status of each core supported by gpsim.
    I have several times been hit by spending unnecessary time on fixing non-bugs, simply because the processor simulation wasn't yet mature enough, only when I checked out the docs, I noticed those entries with a '*' suffix.
    Either this asterisk should be also added by default to all unstable/unfinished implementations, or maybe have each processor module export a processor "warning/info" symbol, which provides short quick infos for possible issues?

  • David Barnett

    David Barnett - 2007-03-03

    Logged In: YES
    Originator: NO

    The scoping issue is taken care of now since the symbol scope is completely hierarchical now. As already mentioned, it would be quite simple (I believe) to add these extra symbols for each simulation object, but there are 2 concerns I'd have about it: maintenance and backwards compatibility.

    Concerning maintenance, the processors themselves are "fully implemented" whenever we describe all of the registers and peripherals that make up the processor. However, several peripherals haven't been implemented and there are bugs with some peripherals. That would mean that if each processor had development status information, then every time we implemented a new peripheral or fixed an existing one, we'd have to track down each processor that included that peripheral and update it. I would strongly advocate using some indirection there to derive the development status of a processor from the development status of its peripherals.

    The other concern I have is that if we add a bunch of extra tags for the development status of each processor, and then we get the peripherals working identically with the real hardware, then we'll have a bunch of redundant clutter bothering the users. The emulation doesn't even need to be *perfect* for that to be a concern, because if there are problems we don't know about yet, then we haven't documented that there's an issue, and I think it's feasible for us to get to a point where all known issues in that arena get worked out before each release. So I definitely wouldn't suggest the "direct interface" since the symbol data is directly available from any context, and I would suggest limiting how much information goes into the built-in help. Then again, we could only include this information for --enable-debug, which would hide it from the end user and prevent things depending on it.

    BTW, could everyone please either log in or give a name in these feature request comments? It's very confusing when everybody's nobody.

  • Nobody/Anonymous

    Logged In: NO

    that's actually a good point, maybe the idea -mentioned in another RFE discussion- to consider tackling processor emulation from a VHDL-oriented POV might actually be worth to consider in the long run?

    basically, PICs aren't terribly complex pieces of hardware, that is most of their built-in peripherals could probably be emulated properly/sufficiently by providing only a very basic subset of support for VHDL.

    that way, the issue of coming up with some custom "markup language" specifically for gpsim, would also be addressed, too.


  • Nobody/Anonymous

    Logged In: NO

    so which subset of VHDL would be specifically needed to be able to describe/emulate most uCs?



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks