Shop OBEX P1 Docs P2 Docs Learn Events
DE0 emulation: Chip are these variations possible??? — Parallax Forums

DE0 emulation: Chip are these variations possible???

Cluso99Cluso99 Posts: 18,069
edited 2013-03-16 08:58 in Propeller 2
Chip:

The DE0 has two limitations that I wonder if it is possible to overcome simply... (without going to a DE2)

1. Would it be possible to create a 2 cog version by removing all the video functions?
This would allow me/us to...
a) Develop drivers (which will require the basic counter functions)
b) Develop the spin interpreter more easily

2. Would it be possible to increase the hub ram beyond 64KB (to say 80KB)? (preferably with 2 cogs as above)
This would allow me/us to...
a) Develop the spin interpreter to use >64KB

Basically, what I would like to do is get a simple serial driver running in the second cog.

Obviously, if it is not easy to do, just say so.

Comments

  • cgraceycgracey Posts: 14,151
    edited 2013-03-15 00:49
    The single cog takes ~85% of the DE0-Nano's FPGA. We couldn't strip the cog down enough to fit two of them. We could probably get more than 32KB of hub RAM, though. 64KB wouldn't fit, but maybe something like 48KB would work. I'll look into it tomorrow.
  • TubularTubular Posts: 4,702
    edited 2013-03-15 03:18
    Ray, you mention your target is to get a simple serial driver working in the second cog. There is a good chance you can use the multi threading to achieve this, but you have to be careful not to double up on resources. You could do a software RX stack instead.

    I've been looking at Chip's monitor code, to see if it is possible to compress it from current 3 tasks down to 1 so it can run inside a single task of the DE0. The 3 tasks currently are
    i) main menus, command processing, serial tx
    ii) serial rx
    iii) autobaud detection

    If you forget the autobaud detection and initialize with a fixed, known baud rate, you're down to two tasks.

    The monitor is more or less a half duplex query/response system, with commands terminated with a CR, so I think it would be possible to start accumulating a query, as soon as enter/CR is received cut over to the command processor and do the serial tx, then back again into RX mode afterwards.

    The other thing to note regarding serial is that the cogs load really fast. You could literally load/reload a brand new cog image in between the bits at 38400 baud, probably even 57600, and on the real silicon at least 115200. It would be possible to "context switch" in between received bits, so long as they were relatively noise free and you knew how long before you expect the next bit transition
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-15 07:01
    Ray:

    For the debug kernel, I added a "look for start bit on Rx" into the LMM loop, and if I detected a start bit, I jumped to a "read byte" routine... you could do the same for Spin. For Tx, I just jumped to a "send byte" routine. I had the baud rate set to 115200 at start up. Using this method, a second cog is not needed to develop VM's.

    You could also run two tasks, one the interpreter, the other a simple debugger.

    Chip:

    More hub on the DE0-Nano would be much appreciated; it would make the emulation even more useful (larger programs, bigger screen buffers etc)

    Tubular:

    Making a version of the monitor that fits into another cog driver/program as a task, that uses as little cog memory is possible (all menu's and text left in the hub), would be EXTREMELY useful for de0-nano users, and later for the real P2. Fixing the baud rate (say to 115200) would not be an issue. Heck, I'd use it all the time.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-15 07:06
    Bill Henning wrote: »
    Making a version of the monitor that fits into another cog driver/program as a task, that uses as little cog memory is possible (all menu's and text left in the hub), would be EXTREMELY useful for de0-nano users, and later for the real P2. Fixing the baud rate (say to 115200) would not be an issue. Heck, I'd use it all the time.
    If you're not hung up on being able to do everything on the P2 itself, a really simple monitor loop that really provided nothing more than peek/poke of COG and hub memory combined with a program on the PC side that parses commands would be useful and should take up very little space.
  • TubularTubular Posts: 4,702
    edited 2013-03-15 15:52
    Yes I think keeping it compact and use minimal resources would be the key thing. As far as peek/poke go keep the commands compatible with Chip's monitor commands (. : etc)

    It should also be possible to look up Cog memory, stack pointers, counter values, need to work what ascii characters to select the resources. Perhaps something like 'G' to select cog ram
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-15 15:54
    Tubular wrote: »
    Yes I think keeping it compact and use minimal resources would be the key thing. As far as peek/poke go keep the commands compatible with Chip's monitor commands (. : etc)

    It should also be possible to look up Cog memory, stack pointers, counter values, need to work what ascii characters to select the resources. Perhaps something like 'G' to select cog ram
    I guess my idea was to have the commands the user types on the PC the same as what Chip's monitor uses but the protocol between the PC and the COG could be anything, probably something binary so no parsing code needs to be in the COG. I guess it depends on how much space you want to allocate to the monitor stub that runs in the COG.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-15 17:56
    The 2nd cog could be a very much stripped down cog if that helps. No requirement for the CLUT.

    While two way serial would be nice, in fact sending would surfice.

    Perhaps there is another way - implement a UART with a windowed tx & rx register - fixed baud rate. But this may be harder to implement.

    Other alternative will be to just implement a transmit routine in the main cog. I want to avoid multitasking in this part of development.
    BTW I had forgotten that there was only 32KB in the HUB on DE0.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-15 17:59
    Ray,

    Since the Spin VM has a byte fetch loop, it is easy to integrate a fixed rate serial in/out. That's how the LMM kernel debugger engine I built works, and it works fine at 115,200 :-)

    I think you can grab just the LMM debug kernel from the code repository, please feel free to grab the rx/tx routines for the Spin VM.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-16 02:11
    Thanks all for the tips. I was in a hurry when I replied last, so did not have the time to address the replies.

    Bill & Lachlan: Yes, I guess I need to just have a simple txbyte routine that I can call when I need to send a debug byte(s) to the pc. A heck of a lot can be done when debugging by just "poking" characters out somewhere.

    Chip: Thanks. I had not realised a cog took so much of the DE0 space.
    Regarding the 48KB, if you can fit it in without too much trouble, that would be fantastic. Would you be able to make a second build with the hub 0-32KB and 64-80KB (presuming this is quite simple)? This way I could test the >64KB hub by just bypassing the 32-64KB area.

    David: It might be worth my while bringing my debugger for the P1 out of the mothballs. It used 4 longs in the shadow ram to execute LMM instructions. Combining this and the P2 Monitor could be quite beneficial to us all.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-16 05:17
    Cluso99 wrote: »
    David: It might be worth my while bringing my debugger for the P1 out of the mothballs. It used 4 longs in the shadow ram to execute LMM instructions. Combining this and the P2 Monitor could be quite beneficial to us all.
    That does sound useful but won't you need serial code to talk to the PC as well? Surely that can't fit in four longs. :-)
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-16 06:45
    David Betz wrote: »
    That does sound useful but won't you need serial code to talk to the PC as well? Surely that can't fit in four longs. :-)
    The actual debug code is in hub and is executed by a 4 long lmm execution unit in cog. Will still require serial but provided I execute serial only when required, as was suggested above, it would work. There are some instructions that will not run in lmm mode such as reps and delayed instructions though.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-16 07:07
    Cluso99 wrote: »
    The actual debug code is in hub and is executed by a 4 long lmm execution unit in cog. Will still require serial but provided I execute serial only when required, as was suggested above, it would work. There are some instructions that will not run in lmm mode such as reps and delayed instructions though.
    That sounds very clever and should make for a minimal footprint debug solution.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-16 08:58
    I for one would love to see your debugger on the P2!
    Cluso99 wrote: »
    Thanks all for the tips. I was in a hurry when I replied last, so did not have the time to address the replies.

    Bill & Lachlan: Yes, I guess I need to just have a simple txbyte routine that I can call when I need to send a debug byte(s) to the pc. A heck of a lot can be done when debugging by just "poking" characters out somewhere.

    Chip: Thanks. I had not realised a cog took so much of the DE0 space.
    Regarding the 48KB, if you can fit it in without too much trouble, that would be fantastic. Would you be able to make a second build with the hub 0-32KB and 64-80KB (presuming this is quite simple)? This way I could test the >64KB hub by just bypassing the 32-64KB area.

    David: It might be worth my while bringing my debugger for the P1 out of the mothballs. It used 4 longs in the shadow ram to execute LMM instructions. Combining this and the P2 Monitor could be quite beneficial to us all.
Sign In or Register to comment.