Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1959698100101160

Comments

  • cgracey wrote: »
    Are you saying that the debug interrupt doesn't work only on the DE0-Nano images? Hmmm... I never invoked the write-protect. The DE0-Nano does have the distinction of having only 32KB of hub RAM. Hey! That means it only has 16KB at the bottom of hub RAM ($00000..$03FFF). Is that enough for your code?
    Aha!
    My code is 20k.
    That's my problem.

    Melbourne, Australia
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    ... The DE0-Nano does have the distinction of having only 32KB of hub RAM. Hey! That means it only has 16KB at the bottom of hub RAM ($00000..$03FFF). Is that enough for your code?

    I'll add the comment that small MCUs that can protect portions of memory, often give a choice to how much.
    ie they may allow protect of any choice of 2k/4k/8k/16k, for example.

    How many spare bits are in the Memory protect area ? - can P2 do the same ?


  • Okay. So, we've got a problem with the BeMicro-A9, only, then.

    Thanks a million for always trying this stuff out!
  • Did you try the BeMicro-A9 with DIP_SW1 in each position?
  • BTW Chip, I did try DIP-SW1 in both positions on the CV-A9 board.
    Melbourne, Australia
  • Ozpropdev,

    I'm making a new BeMicro-A9 file now with just two cogs and no CORDIC, so it will compile quickly. It has the old pin assignments, like before. We'll need to know if this works, or something else has broken.
  • Ozpropdev, could you please try this file on your BeMicro-A9?

  • ElectrodudeElectrodude Posts: 1,288
    edited 2017-11-12 - 01:15:08
    Is HUBRAM no longer all contiguous for <1MB? If not, why not?
  • cgracey wrote: »
    Ozpropdev, could you please try this file on your BeMicro-A9?
    Tests Ok Chip.
    Runs my test code fine.
    Melbourne, Australia
  • Is HUBRAM no longer all contiguous for <1MB? If not, why not?

    I you had a whole 1MB then it would be contiguous. For smaller memory, though, the last 32KB is always located up at the top, now, from $FC000..$FFFFF. It can be write-protected, and a gap will exist between where the bottom RAM ends and $FC000.

    Let's say you have 512KB, as the first chip will. Bottom memory goes from $00000..$7BFFF and top memory goes from $FC000..$FFFFF.
  • cgraceycgracey Posts: 11,711
    edited 2017-11-12 - 01:37:33
    ozpropdev wrote: »
    cgracey wrote: »
    Ozpropdev, could you please try this file on your BeMicro-A9?
    Tests Ok Chip.
    Runs my test code fine.

    Well, that's weird, but good, since we've isolated the problem.

    This works:
    h.pin_in[63..0]	= (p[63..56], !s[2], !s[1], !dip_sw[4..1], p[49..0]);
    pin_tri[].in	= h.pin_out[63..0];
    pin_tri[].oe	= h.pin_dir[63..0];
    p[63..0]	= pin_tri[63..0].out;
    

    And this doesn't ?!?:
    case (dip_sw[1]) is
      when b"0" => h.pin_in[63..0] = (p[63..62], p[39], p[41], p[36], p[40], p[57..56], !s[2], !s[1], !dip_sw[4..1], p[49..42], p[60], p[58], p[61], p[38..37], p[59], p[35..0]);
      when b"1" => h.pin_in[63..0] = (p[63..56], !s[2], !s[1], !dip_sw[4..1], p[49..0]);
    end case;
    
    case (dip_sw[1]) is
      when b"0" => pin_tri[].in = (	h.pin_out[63..62],
    				h.pin_out[39],
    				h.pin_out[41],
    				h.pin_out[36],
    				h.pin_out[40],
    				h.pin_out[57..42],
    				h.pin_out[60],
    				h.pin_out[58],
    				h.pin_out[61],
    				h.pin_out[38..37],
    				h.pin_out[59],
    				h.pin_out[35..0] );
      when b"1" => pin_tri[].in =	h.pin_out[63..0];
    end case;
    
    case (dip_sw[1]) is
      when b"0" => pin_tri[].oe = (	h.pin_dir[63..62],
    				h.pin_dir[39],
    				h.pin_dir[41],
    				h.pin_dir[36],
    				h.pin_dir[40],
    				h.pin_dir[57..42],
    				h.pin_dir[60],
    				h.pin_dir[58],
    				h.pin_dir[61],
    				h.pin_dir[38..37],
    				h.pin_dir[59],
    				h.pin_dir[35..0] );
      when b"1" => pin_tri[].oe =	h.pin_dir[63..0];
    end case;
    
    p[63..0]	= pin_tri[63..0].out;
    

    P.S. This is an AHDL file, which Quartus needs at the top level. It's not Verilog.
  • I loaded V27x on CVA9 and that seems to work ok. I have SW1 on.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • I loaded V27x on CVA9 and that seems to work ok. I have SW1 on.

    In my post above, the short code is in the v27x, while the longer code is in the v27. I don't see where the problem is, but the longer code fails. When DIP_SW1 is OFF, it should be the same as the short code.
  • I'm having other very strange problems with V27 too. The basic TAQOZ kernel seems to half work, there are some strange things going on there. Although I am still tracking it down there is one thing I found which may have to do with CORDIC functions. It's a bit awkward to check but I know that I use qdiv for a variety of functions and when I bypassed the higher level call to this in one routine it started working, at least for that routine.....

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • cgraceycgracey Posts: 11,711
    edited 2017-11-12 - 02:34:23
    I'm having other very strange problems with V27 too. The basic TAQOZ kernel seems to half work, there are some strange things going on there. Although I am still tracking it down there is one thing I found which may have to do with CORDIC functions. It's a bit awkward to check but I know that I use qdiv for a variety of functions and when I bypassed the higher level call to this in one routine it started working, at least for that routine.....

    That v27x doesn't have CORDIC. It was just a test to try to figure out why the BeMicro-A9 has been unresponsive.

    Peter, what board are you using?
  • cgracey wrote: »
    I'm having other very strange problems with V27 too. The basic TAQOZ kernel seems to half work, there are some strange things going on there. Although I am still tracking it down there is one thing I found which may have to do with CORDIC functions. It's a bit awkward to check but I know that I use qdiv for a variety of functions and when I bypassed the higher level call to this in one routine it started working, at least for that routine.....

    That v27x doesn't have CORDIC. It was just a test to try to figure out why the BeMicro-A9 has been unresponsive.

    Peter, what board are you using?
    Yes, I've confirmed that CORDIC DOES NOT WORK on V27x :) :) :) RTM!!!

    I've got the BeMicro-A9 or CVA9 for short as my main P2 board, I don't worry about the rest although I do have CVA2, DE0, and DE2-115.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • cgracey wrote: »
    I'm having other very strange problems with V27 too. The basic TAQOZ kernel seems to half work, there are some strange things going on there. Although I am still tracking it down there is one thing I found which may have to do with CORDIC functions. It's a bit awkward to check but I know that I use qdiv for a variety of functions and when I bypassed the higher level call to this in one routine it started working, at least for that routine.....

    That v27x doesn't have CORDIC. It was just a test to try to figure out why the BeMicro-A9 has been unresponsive.

    Peter, what board are you using?
    Yes, I've confirmed that CORDIC DOES NOT WORK on V27x :) :) :) RTM!!!

    I've got the BeMicro-A9 or CVA9 for short as my main P2 board, I don't worry about the rest although I do have CVA2, DE0, and DE2-115.

    Okay. Good. We'll get this thing working properly. Do you see anything wrong in those code-snippets of AHDL?
  • As far as I can tell I can't see a problem and the mapping looks fine too. However I might be able to find out what's going on from a different angle as I can load up V27 onto my old DE2-115 and load TAQOZ to see if I can find anything amiss there.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • As far as I can tell I can't see a problem and the mapping looks fine too. However I might be able to find out what's going on from a different angle as I can load up V27 onto my old DE2-115 and load TAQOZ to see if I can find anything amiss there.

    Ah, good idea.
  • ElectrodudeElectrodude Posts: 1,288
    edited 2017-11-12 - 04:13:33
    cgracey wrote: »
    Is HUBRAM no longer all contiguous for <1MB? If not, why not?

    I you had a whole 1MB then it would be contiguous. For smaller memory, though, the last 32KB is always located up at the top, now, from $FC000..$FFFFF. It can be write-protected, and a gap will exist between where the bottom RAM ends and $FC000.

    Let's say you have 512KB, as the first chip will. Bottom memory goes from $00000..$7BFFF and top memory goes from $FC000..$FFFFF.

    Why not just make it wrap on 512KB versions, so the top half aliases the bottom half? It is simpler and seems more natural. Otherwise, it's awkward to use that top 32KB in non-protected mode because it's 512KB away from everything else.
  • cgracey wrote: »
    Is HUBRAM no longer all contiguous for <1MB? If not, why not?

    I you had a whole 1MB then it would be contiguous. For smaller memory, though, the last 32KB is always located up at the top, now, from $FC000..$FFFFF. It can be write-protected, and a gap will exist between where the bottom RAM ends and $FC000.

    Let's say you have 512KB, as the first chip will. Bottom memory goes from $00000..$7BFFF and top memory goes from $FC000..$FFFFF.

    Why not just make it wrap on 512KB versions, so the top half aliases the bottom half? It is simpler and seems more natural. Otherwise, it's awkward to use that top 32KB in non-protected mode because it's 512KB away from everything else.

    Then, should we ever get a 1MB version, it would potentially break existing code.
  • cgraceycgracey Posts: 11,711
    edited 2017-11-12 - 05:18:36
    It used to wrap, but that was causing huge problems on accidentally-oversized downloads. What we have now is actually very clean. RAM starts at $00000 and then we always have the last 32K of RAM at the top of memory ($FC000..$FFFFF). That gives us TWO stable areas in which to put code, and the latter can be write-protected and conveniently contains the debug-interrupt vectors.
  • evanhevanh Posts: 7,879
    edited 2017-11-12 - 08:39:42
    Chip,
    Here's a variant of both that isn't quite as wide on the page. Also, added the clock edges to my diagram and a key for my lines.
            |                   |                   |                   |                   |                   |                   |
    rdRAM Ib|------+            |           rdRAM Ic|------+            |           rdRAM Id|------+            |           rdRAM Ie|
            |      |            |                   |      |            |                   |      |            |                   |
    latch Da|--+   +--> rdRAM Db|---------> latch Db|--+   +--> rdRAM Dc|---------> latch Dc|--+   +--> rdRAM Dd|---------> latch Dd|
    latch Sa|--+   +--> rdRAM Sb|---------> latch Sb|--+   +--> rdRAM Sc|---------> latch Sc|--+   +--> rdRAM Sd|---------> latch Sd|
    latch Ia|--+   +--> latch Ib|---------> latch Ib|--+   +--> latch Ic|---------> latch Ic|--+   +--> latch Id|---------> latch Id|
            |  |                |                   |  |                |                   |  |                |                   |
            |  +---------------ALU--------> wrRAM Ra|  +---------------ALU--------> wrRAM Rb|  +---------------ALU--------> wrRAM Rc|
            |                   |                   |                   |                   |                   |                   |
            |                   |stall/done = 'gox' |                   |stall/done = 'gox' |                   |stall/done = 'gox' |
            |       'get'       |      done = 'go'  |       'get'       |      done = 'go'  |       'get'       |      done = 'go'  |
    
    clk      _________           _________           _________           _________           _________           _________         
    ________|    1    |_________|    2    |_________|    3    |_________|    4    |_________|    5    |_________|    6    |_________|
    
     PCflux |...................|...........===c===.|...................|...........===d===.|...................|...........===e===.|
     Ifetch |====b====..........|...................|====c====..........|...................|====d====..........|...................|
     Odecod |.........====b====.|...................|.........====c====.|...................|.........====d====.|...................|
     SDfetc |...................|====b====..........|...................|====c====..........|...................|====d====..........|
     Fdecod |...................|.........====b====.|...................|.........====c====.|...................|.........====d====.|
     ALUs1  |========a=========.|...................|========b=========.|...................|========c=========.|...................|
     ALUs2  |...................|========a=========.|...................|=========b========.|...................|========c=========.|
     Rwrite |...................|...................|==a==..............|...................|==b==..............|...................|
    
    
    PCflux - Program Counter updating.
    Ifetch - Instruction fetching from CogRAM, LUT or FIFO.
    Odecod - Opcode decode for S/D operands.
    SDfetc - S and D parallel fetches, if required.
    Fdecod - Fully decode the instruction.  Probably mostly fan-out to feed selected logic block.
    ALUs1  - Stage one execute, do the job. (I'm uncertain of a registered partition from stage two)
    ALUs2  - Stage two execute.  Mostly mux'ing the result from the selected logic block.
    Rwrite - Result write back to D destination if required.
    
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Evanh,

    PCflux happens in the first cycle.

    Yes, there is a registered partition between ALUs1 and ALUs2.
  • cgraceycgracey Posts: 11,711
    edited 2017-11-12 - 16:23:51
    Ozpropdev, Peter,

    Here is a new file for the BeMicro-A9 where I'm assigning an intermediate variable to the DIP_SW1-determined signals, then assigning that variable, all at once, to the TRI element inputs. This shouldn't make any difference, but who knows? Maybe TRI inputs don't like being mux'd directly.

    https://drive.google.com/file/d/1xXIGHczoyVasSMP8c2cvb3hV0sHbVIQq/view?usp=sharing
  • Peter JakackiPeter Jakacki Posts: 8,641
    edited 2017-11-12 - 16:45:43
    I finally got around to digging up my DE2-115 and got V27 into it. I haven't found any problems with it so far though. I will try the new CVA9 in the morning though.
    It's good to see the write protect working :)
    Here WP protects and WE enables.
    MODULES LOADED:
    1EC0: EXTEND.fth          TACHYON FORTH EXTENSIONS for the P2 - 171124-0000
    Mon, 01 Jan 2001 00:00:00
      Parallax Propeller II  .:.:--TAQOZ--:.:. V-10171112.0000 V25 BOOT
    ----------------------------------------------------------------
    TAQOZ#   ok
    TAQOZ#   ok
    TAQOZ# ROM QD
    0F.C000: 16 B8 64 FD E0 07 00 FF 18 01 06 FB 17 5C 65 FD    ..d..........\e.
    0F.C010: E1 07 00 FF 8C 20 04 FB 00 08 80 FF 3F 00 0C FC    ..... ......?... ok
    TAQOZ# 0 ROM !  ROM QD
    0F.C000: 00 00 00 00 E0 07 00 FF 18 01 06 FB 17 5C 65 FD    .............\e.
    0F.C010: E1 07 00 FF 8C 20 04 FB 00 08 80 FF 3F 00 0C FC    ..... ......?... ok
    TAQOZ# $FD64B816 ROM !   ok
    TAQOZ# ROM QD
    0F.C000: 16 B8 64 FD E0 07 00 FF 18 01 06 FB 17 5C 65 FD    ..d..........\e.
    0F.C010: E1 07 00 FF 8C 20 04 FB 00 08 80 FF 3F 00 0C FC    ..... ......?... ok
    TAQOZ# WP 0 ROM ! ROM QD
    0F.C000: 16 B8 64 FD E0 07 00 FF 18 01 06 FB 17 5C 65 FD    ..d..........\e.
    0F.C010: E1 07 00 FF 8C 20 04 FB 00 08 80 FF 3F 00 0C FC    ..... ......?... ok
    TAQOZ#
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    It used to wrap, but that was causing huge problems on accidentally-oversized downloads....
    On that topic, can either the booter, or the downloader, verify the writes ?
    Common in Flash parts, and it could be useful if at least the boundary blocks were verified on any download.
    cgracey wrote: »
    What we have now is actually very clean. RAM starts at $00000 and then we always have the last 32K of RAM at the top of memory ($FC000..$FFFFF). That gives us TWO stable areas in which to put code, and the latter can be write-protected and conveniently contains the debug-interrupt vectors.

    Did On-Semi confirm you can add 32k of RAM ? What speed impact did adding the address bit have ?

  • Looks like Chip either wants to go 32K for the protected region, or it's a typo.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • FC000...FFFFF is 16K

    is it maybe possible to put it at the end of the long address space?

    It could be reached with 'negativ' addresses, and flow over to address 0? So sort of be continuous?

    FFFFC000-FFFFFFFF

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmgjmg Posts: 13,917
    potatohead wrote: »
    Looks like Chip either wants to go 32K for the protected region, or it's a typo.
    I thought that was from 16k for boot plus separate for vectors (also 16k) ? Possibly with two protect bits ?



Sign In or Register to comment.