Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 98 — Parallax Forums

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.

  • jmgjmg Posts: 15,140
    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 ?


  • cgraceycgracey Posts: 14,131
    Okay. So, we've got a problem with the BeMicro-A9, only, then.

    Thanks a million for always trying this stuff out!
  • cgraceycgracey Posts: 14,131
    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.
  • cgraceycgracey Posts: 14,131
    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.
  • cgraceycgracey Posts: 14,131
    Ozpropdev, could you please try this file on your BeMicro-A9?

  • ElectrodudeElectrodude Posts: 1,614
    edited 2017-11-12 01:15
    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.
  • cgraceycgracey Posts: 14,131
    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: 14,131
    edited 2017-11-12 01:37
    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.
  • cgraceycgracey Posts: 14,131
    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.....
  • cgraceycgracey Posts: 14,131
    edited 2017-11-12 02:34
    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.

  • cgraceycgracey Posts: 14,131
    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.
  • cgraceycgracey Posts: 14,131
    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,614
    edited 2017-11-12 04:13
    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: 14,131
    edited 2017-11-12 05:18
    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: 15,091
    edited 2017-11-12 08:39
    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.
    
    
  • cgraceycgracey Posts: 14,131
    Evanh,

    PCflux happens in the first cycle.

    Yes, there is a registered partition between ALUs1 and ALUs2.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-12 16:23
    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: 10,193
    edited 2017-11-12 16:45
    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#
    
  • jmgjmg Posts: 15,140
    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.

  • 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
  • jmgjmg Posts: 15,140
    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.