Shop OBEX P1 Docs P2 Docs Learn Events
Github TO DO list — Parallax Forums

Github TO DO list

jac_goudsmitjac_goudsmit Posts: 418
edited 2014-09-24 09:04 in Propeller 1
Hi all!

I've been working on a change to the hub_mem.v module to make it possible to easily change the sizes of the RAM and ROM in the hub (as hardware allows). As I may have mentioned, I want to make it possible to have up to 64K hub RAM, but having the ROM images shadowed in the upper 32K at reset time for full backwards compatibility. I already cleaned up the RAM code by putting the old copy-paste code into a module/endmodule statement and generating 4 instances, and I'm working on an automated system that cherry-picks ROM image files based on the ROM size parameter. I'm getting close but haven't gotten it to work yet.

Meanwhile, I've been following the forum of course, and I'm seeing that new ideas and solutions to known problems are starting to pile up quickly. So I thought I would start on a TO DO list in the GitHub wiki. From now on, that will be my official "list of things that will be added (or have been added) to Github".

I think I added pretty much everything that was on my old (virtual) TO-DO list. I'll keep updating it as I go. If there's anything you would like to add, let me know (but it's a Wiki so it should be possible to edit it yourself).

Here's a copy in case you don't feel like clicking the link.

Under consideration (i.e. these may be added later):
Done or almost done:

===Jac

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2014-09-10 16:27
    Nice job Jac.

    I can generate all the ROM files when you are ready. Rather not do this now.

    IMHO the best approach would be to have the hub ram configurable as I have done, and then map the top section of that to the ROM.
    The part that I couldn't do easily due to limited verilog understanding was to make the rom map to the top of a variable hub ram. So my 48KB mapped just the top 4KB, but would be easy to map the whole 16KB and then load all the rom into the top 16KB.

    You may also want to add my VGA option to the list - VGA only on Cog 0 (or specify which cog#). I haven't disabled everything that could be done.
    Also, I have variable number of cogs.
    Both of these speeds up compilation a lot!
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-09-10 18:32
    Cluso99 wrote: »
    Nice job Jac.

    Thanks!
    I can generate all the ROM files when you are ready. Rather not do this now.

    I used the Spin program that you published earlier to generate the ROM image hex files from the original P1V. My modified version (currently only on my PC at home) creates one 32-bit ROM area and uses $readmemh to read the 32-bit hex values into the right locations. I used a macro to calculate the offset from the beginning of the ROM, and I used another macro to generate an "if" to check that the destination isn't out of range. I set both my RAM and ROM size to 8192 (longs) and then used $readmemh to put the first half (the font) at $8000 and the second half at $C000 and that went right. When I replaced the "second half file" by separate files for each part (log, antilog, sine, copyright, interpreter, booter and runner -- in the right order and at the right locations), it stopped working: I can apparently download a program to RAM but it doesn't run. I must have made a mistake somewhere. I looked at the RTL yesterday (much faster than building the whole thing and downloading to the chip) and it looked okay; I made a couple of improvements (removing some apparently unnecessary flipflops) and then Quartus took a long time compiling and then told me it wouldn't be able to fit my design. I'll continue the fight tonight.
    IMHO the best approach would be to have the hub ram configurable as I have done, and then map the top section of that to the ROM.

    The RAM has to be byte-writeable so it has to be implemented as four instances of byte-wide RAM. That was pretty easy to do. But I want to be able to initialize the ROM from hex files that are 32 bits wide, so I kept the ROM separate unlike your 48K design and the Xilinx designs. When I'm done, it will be possible to adjust the desired RAM and ROM size depending on hardware (DE0 doesn't have enough space for 64K hub memory) and the wishes of the user.
    The part that I couldn't do easily due to limited verilog understanding was to make the rom map to the top of a variable hub ram. So my 48KB mapped just the top 4KB, but would be easy to map the whole 16KB and then load all the rom into the top 16KB.

    Yes, but as I said, I prefer not to have to generate interleaved hex files, because it quickly goes out of hand if you want to do that for each ROM area. Also I want a little more flexibility in ROM and RAM sizes. If someone wants 16K RAM and 4K ROM to make space for some other feature, that should be possible. If someone wants 64K RAM shadowing the full 32K ROM, that should be possible too. The Verilog will be slightly more complicated but it really only comes down to an extra flipflop ("shadow mode on/off") and perhaps a tiny bit of extra glue logic to control the output multiplexers and to detect the first write to any RAM location that overlaps with ROM.

    Mapping the ROM to the top of memory is a bit of a problem but not unsolvable in Verilog. I don't know how good Quartus is at optimizing an arithmetic expression (calculate a ROM address from a hub address using subtraction of a constant from the address bus) into a logic expression (just drop a couple of bits from the address bus), but perhaps that can be manually improved later (e.g. with a case-statement based on the ROM size, or with a couple of macros).
    You may also want to add my VGA option to the list - VGA only on Cog 0 (or specify which cog#). I haven't disabled everything that could be done.

    Do you have a forum thread link for that?
    Also, I have variable number of cogs.
    Both of these speeds up compilation a lot!

    Again, do you have a forum thread link?

    Thanks!

    ===Jac
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-09-10 23:26
    Jac , Nice work! :)
    There's also some DE2 stuff too.
    5 x 120 MHz 64I/O P1V's (40 Cogs) in a DE2-115
    All five propellers can be individually accessed through a single propplug.
    Brian
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-09-10 23:46
    Jac,
    IIRC the Interpreter starts at $F004 and the SIN tables run to $F002. It may well be this boundary overlap causing you problems.

    Yes, I used the RAM to be Byte addressable and thus required 4 Byte files for the ROM to be overlapped. I thought this was best because the full ROM could always be loaded into the upper RAM, wherever that was, and if the user wanted to use part of the space instead of the ROM all he/she had to do was overwrite it with whatever. This applies whether 64KB/48KB/32KB/etc of RAM is used. The ROM just overlays/maps-over the top 32KB of hub RAM.

    BTW I manually split out the Byte ROM files from the 32 bit (long) files using PropTool - it is easy to just cut/paste the byte columns required.

    The VGA and Cog numbers are included in the posted on my "Break the 2KB Cog RAM..." thread
    http://forums.parallax.com/showthread.php/157278-Break-the-2KB-Cog-RAM-barrier-running-PASM-!
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-09-11 07:14
    Thanks Brian and Ray!

    I updated the first post and the Wiki page.

    ===Jac
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-09-13 07:09
    Hi Jac.

    Sorry, I've been slacking on P1V work due to real work and other "fun" projects.

    This morning, I merged you pull request and passed a pull request up to Heater. I'm just a pass through at this point, I hadn't added anything since last time.

    I now see the 2 new directories for Nexys4 and Pipistrello in my repo. What I don't see are the branches you've added which I guess make sense since they really aren't a part of my repo.

    I get confused once we get into branches of downstream repos - I obviously need to spend more time researching Git.

    If I wanted to do work with the "Cluso99" code for example, would I pull it from you (or fork it from you), do my work and if I wanted to have it considered to be included into your repo, then I'd send a pull request to you.

    If I understand this, I shouldn't see one of your branches in my repo because it is your branch and you are downstream from me BUT if I create a branch in my repo, you will get it from me on the next pull because you are downstream, from me?

    I probably wouldn't put the cluso99 code under my repo as a branch since it seems that create some sort of circular monster but I might create a branch with cluso99 and maybe pik33 code and something I add? OR would that best be done by doing that work on a fork of your cluso99 branch?
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-09-13 15:03
    mindrobots wrote: »
    This morning, I merged you pull request and passed a pull request up to Heater. I'm just a pass through at this point, I hadn't added anything since last time.

    Thanks!
    I now see the 2 new directories for Nexys4 and Pipistrello in my repo. What I don't see are the branches you've added which I guess make sense since they really aren't a part of my repo.

    That's correct.

    The Altera branch has the reorganized source code where all Altera targets share the same project file and source files. The Xilinx branch will have the combined Xilinx sources as soon as I can put the Xilinx tools on my system (I have to free up some disk space). The Unified branch will eventually combine all of that.

    I want to keep that big reorganization separate from the master branch for now, until we have more news from Ken or Chip about their plans for Github. If we want them to join the effort, we should make sure that (until we get a nod from Ken or Chip) what's in the master branch is still instantly recognizable as Chip's work, with only the bugfixes and ports to other targets added.
    If I wanted to do work with the "Cluso99" code for example, would I pull it from you (or fork it from you), do my work and if I wanted to have it considered to be included into your repo, then I'd send a pull request to you.

    Yes, and any work that I would pull from your fork would go back into my Cluso99 branch.

    However, my Cluso99 branch is really intended only to merge Cluso99's work. He doesn't want to bother with Github but he does a lot of work on the code; keeping a separate branch for his stuff is easier than asking him to synchronize his home repo with mine. The intention is that all of Cluso99's work will go into the Altera branch (eventually, the Unified branch), so you should really fork the Altera branch (not the Cluso99 branch) if you want to add changes. I'm working on a change to the Altera branch that conflicts with Cluso99's "48K hub RAM" change, and hopefully will be regarded by all as a better way to customize the hub memory sizes, and cherry-pick the ROM areas that are implemented (especially on the DE0). Meanwhile I'm also working on one or two other things, so stay tuned :-)
    If I understand this, I shouldn't see one of your branches in my repo because it is your branch and you are downstream from me BUT if I create a branch in my repo, you will get it from me on the next pull because you are downstream, from me?

    I think you understand that correctly. Pulls and pushes are between branches, not between user id's (the walls between users are mostly generated by automatic access rights management in the Github system, not by Git itself). So I can branch one of your branches (Github calls this a fork), or I can pull your changes and merge them into one of my existing branches. Similarly you can pull code from my branches and either create a fork or merge it into an existing branch that you have write access to. If you want to fork one of my branches, you can, and that new branch would be downstream from me. If you would make changes to your new fork, I wouldn't "see" those on the next pull because my upstream is your master branch.

    You don't have write access to my branches so to merge anything back to my branch from your downstream branch you would have to file a pull request and I would have to merge it (or I would have to give you write access so you can do it yourself). But you have write-access to your master branch so you can create a (downstream) fork from one of my branches and make changes, and then merge those changes into the master branch without my permission. Also, you can merge my branches straight into the master branch (without creating a downstream branch first) without my permission because you are upstream. If I get hit by a bus, everyone can still access my work and you or Heater can pull it into your branches/forks. But for now, I don't recommend it because even though I think the Altera branch is superior because it shares the source files between all Altera targets, it's not instantly recognizable as Chip's work.
    I probably wouldn't put the cluso99 code under my repo as a branch since it seems that create some sort of circular monster but I might create a branch with cluso99 and maybe pik33 code and something I add? OR would that best be done by doing that work on a fork of your cluso99 branch?

    If you (really anyone) want to help with any of the items on the TO DO list, the best thing to do at this time is to fork my Altera branch (or the Xilinx branch if you want to work on Xilinx targets). Then do the work, and send me a pull request. I'll be happy to merge anything back, if it adheres to the rules: no tabs in source files, make small changes at a time so they're easy to follow, follow Chip's coding style and make sure all new features are off by default. And make sure that all three Altera targets (i.e. all revisions in the Quartus project) build without fatal errors, of course.

    ===Jac
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2014-09-24 09:04
    I updated the top post to the latest status. Is there any way we can make this a Sticky?

    ===Jac
Sign In or Register to comment.