Shop OBEX P1 Docs P2 Docs Learn Events
Modifying the P1v... theoretically speaking — Parallax Forums

Modifying the P1v... theoretically speaking

rjo__rjo__ Posts: 2,114
in Propeller 1
This is actually about the P2v, but I am putting it here, because I don't want to distract Chip at this point.

Let's say that I wanted the to modify the P1v to eliminate all code that didn't support a very limited subset of the instructions.

Is it possible to create a script to go through the Verilog and eliminate everything that wasn't needed by any of those instruction?

Thanks,

Rich

Comments

  • jmgjmg Posts: 15,173
    rjo__ wrote: »
    Let's say that I wanted the to modify the P1v to eliminate all code that didn't support a very limited subset of the instructions.
    Why do you want to do that ?
    How do you select/choose that "very limited subset of the instructions" ?

    rjo__ wrote: »
    Is it possible to create a script to go through the Verilog and eliminate everything that wasn't needed by any of those instruction?
    Anything is possible ;)
    It gets tricky, based on how variable/fluid that "very limited subset" actually is, and how end to end automated you expect this to be....
    You certainly could remove items not commonly used, like Video generation, (already version that do this).

    You could remove opcodes manually easily enough with Verilog conditionals, and see what the LUT usage saving was.
    Or, you may be able to microcode some, to still be there, but execute more slowly.
  • rjo__rjo__ Posts: 2,114
    edited 2018-04-06 00:49
    Many thanks.

    Let's say I have a program... which by nature uses very few opcodes. I would list the opcodes... and then as if by magic, I would run a script, which would remove everything that wasn't used by my opcodes... not just other opcodes but the dependencies of the unused opcodes, which aren't dependencies of my opcodes.

    I suppose that it would actually have to do the opposite of what I have described... list the opcodes and then add the dependencies.

    I haven't decided that I want to do this, yet. I'm just trying to figure out if it belongs in my thinking at all.

    For other people for instance, it might make understanding Verilog a lot easier...rather than wander through all of the code, just the interesting bits could be separated out.

    I have used both Perl and Tcl... but it was a long time ago and I just skimmed the surface. Both are supported by Quartus, but from the samples I have seen it isn't clear that either would be at all straight forward or even capable.

    What I am talking about seems like it should be already available as an automation tool for Verilog...














  • jmgjmg Posts: 15,173
    rjo__ wrote: »
    What I am talking about seems like it should be already available as an automation tool for Verilog...

    I think I saw a somewhat contrived example of this, sometime back in a NXP example of a small MCU running in their largest CPLD.
    Of course, the CPLD was far more expensive than any equivalent dedicated MCU, and the code size was very small, but marketing is marketing...

    IIRC that did 'unused opcode removal', I think achieved by compile of the CODE ROM into logic, and then the optimizer removed any unused logic.
    In the P1V, there are not many opcodes, and not many 'fat' looking ones.

    First thing would be to generate a table of each opcode, and its incremental LUT cost. That would be interesting & some scripts may helps generate that.

    Maybe MAX and MIN can be deprecated and some of the rotate ops could need many muxes for the any-count nature.

    It's more likely someone would want to remove an opcode, in order to replace it with something more useful.
    There are already gaps in the opcodes to allow doing that, without needing to get more complicated and less portable.

    eg DOCs say
    6.1.1. Words Reserved for Future Use
    Memory Space : DIRB, INB, and OUTB: Reserved for future use with a possible 64 I/O pin model. When used with the P8X32A, these labels can be used to access Cog RAM at those locations for general-purpose use.
    Opcodes: ENC, MUL, MULS, ONES: Use with the current P8X32A architecture yields indeterminate results.














  • TubularTubular Posts: 4,702
    By strange coincidence OzPropDev and I were talking about exact thing this week. His comment was it would need a special 'P1V generator' to strip out the verilog associated with unused instructions

    The context was how many "hobbled" cogs might fit in very small fpgas, eg 4K LE's. It turns out in the small (3x3, 4x4mm) max10's there's only 2kLE or 8kLE anyway.

    It would be good to explore this, but probably more important to test P2 final images right at the moment
  • Cluso99Cluso99 Posts: 18,069
    At one stage I compiled a few variations to determine instruction groups LE requirements.

    There are instruction groups that share Verilog code. To automatically remove single instructions would be quite a complex feat IMHO.
  • rjo__rjo__ Posts: 2,114
    Tubular wrote: »
    By strange coincidence OzPropDev and I were talking about exact thing this week. His comment was it would need a special 'P1V generator' to strip out the verilog associated with unused instructions


    Problem solved!!! It is possible, and it has already been considered. At this point in P2 testing Brian is key... so later, but it is good news.

    Thanks
Sign In or Register to comment.