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

1136137139141142150

Comments

  • cgraceycgracey Posts: 9,593
    edited May 8 Vote Up0Vote Down
    ozpropdev wrote: »
    ZEROX Zero extends D above bit S[4:0].
    Basically Chip is doing a single instruction AND dirb,##3fffffff

    Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.
  • Peter JakackiPeter Jakacki Posts: 7,719
    edited May 8 Vote Up0Vote Down
    cgracey wrote: »
    ozpropdev wrote: »
    ZEROX Zero extends D above bit S[4:0].
    Basically Chip is doing a single instruction AND dirb,##3fffffff

    Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.

    But zerox clears all bits after the specified bit and does not include the bit itself so therefore an operand of #30 means only the top bit is cleared so it is a ##7FFFFFFF.
    This is borne out by this test.
    TAQOZ# -1 3 ZEROX .LONG 0000.000F ok
    TAQOZ# -1 30 ZEROX .LONG 7FFF.FFFF ok
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • cgracey wrote: »
    ozpropdev wrote: »
    ZEROX Zero extends D above bit S[4:0].
    Basically Chip is doing a single instruction AND dirb,##3fffffff

    Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.

    But zerox clears all bits after the specified bit and does not include the bit itself so therefore an operand of #30 means only the top bit is cleared so it is a ##7FFFFFFF.
    This is borne out by this test.
    TAQOZ# -1 3 ZEROX .LONG 0000.000F ok
    TAQOZ# -1 30 ZEROX .LONG 7FFF.FFFF ok
    

    I should have used #29, then. I'm glad you found this.
  • Cluso99Cluso99 Posts: 13,916
    edited May 10 Vote Up0Vote Down
    This is the code in question
    reset_pins      setint1 #0                      'disable int1
    
                    mov     dira,#0                 'reset smart pins (avoids output on mode clears)
                    zerox   dirb,#29		'clear rx & tx (P62-63) Others???   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
                    'decod   dirb,#(tx_pin-32)	<<<<<<<<<<<<<<<<<<<<< BUT THIS MAKES MORE SENSE (pbj)
    
                    wrpin   #0,#rx_ths              'clear rx_ths mode
                    wrpin   #0,#rx_tne              'clear rx_tne mode
                    wrpin   #0,#rx_pin              'clear rx_pin mode
            _ret_   wrpin   #0,#tx_pin              'clear tx_pin mode
    
    lut_end
    
    It seems to both Peter and I that since all pins P00-P31 are cleared with the MOV DIRA,#0 that you would also be clearing at least all pins P32-P61. Whether in fact you also want to clear P62-P63 is unclear to us.

    Do you want TX (P62) to remain an output?

    Do you also want to clear P32-P61?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I made a variation of Chip's instruction spreadsheet that breaks out instructions into multiple sheets (by group), sorts on the instruction name, and hides some of the columns. I've found this particularly useful for reading on my mobile devices. Here's the link, in case anyone else might find it useful:

    https://docs.google.com/spreadsheets/d/1ViilDWiG-hqwsFdjcPgyFfPIfej9bKpKxNTPTigLRIw
  • Seairth wrote: »
    I made a variation of Chip's instruction spreadsheet that breaks out instructions into multiple sheets (by group), sorts on the instruction name, and hides some of the columns. I've found this particularly useful for reading on my mobile devices. Here's the link, in case anyone else might find it useful:

    https://docs.google.com/spreadsheets/d/1ViilDWiG-hqwsFdjcPgyFfPIfej9bKpKxNTPTigLRIw
    Excellent, good work!

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Nice job Seairth.

    Just realised we missed a very important instruction out of the P2
            FINDBUG  D   wcz
    
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Chip,
    The FPGA code is too big for our forum. Could you please post it thanks.

    All,
    For those with BeMicroCV-A9 boards...

    Here is the latest code v134a as follows (uses BeMicro_A9_Prop2_8cogs_v32d.jic)...

    Chip's latest ROM_Booter v33d with the special new ROM section commented out

    Peter's TAQOZ BOOTROM(7) from dropbox BOOTROM.spin2 12/5/2018 23:41 using reset_pins instead of inline at start

    Ray's SD boot code SD2_133jx/ROM_133k

    Ray's Monitor code LSD_v133i/ROM_133k

    I have checked out the serial, monitor and taqoz without using pullups. SD and Flash not tested yet.

    Pins P58..P61 are for connections to Flash (4-pin only) and/or SD card. There is no internal FPGA connections on these pins and they are NOT connected to the on-board SD card!!
    P63  Rxd
    P62  Txd
    
    P61  spi-CS  sd-CK   pu = spi flash
    P60  spi-CK  sd-CS   pu = SD card (pullup is internal on the card)
    P59  spi-DI  sd-DI   pu = Serial   pd = Stop
    P58  spi-DO  sd-DO
    
    Here is the boot sequence...
    P59 pullup = goto Serial
    P60 pullup = goto SD card
    P61 pullup = goto SPI Flash
    P59 pulldn = Stop
      else     = goto Serial
    

    Please test this out urgently as this is scheduled to go to OnSemi on Monday!!!

    Don't forget to program the new fpga code into your BeMicro A9 board.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • To enter TAQOZ from Serial, type "> " without quotes to autobaud the serial code, then "Prop_TAQ" or for the monitor "Prop_MON".
    From the monitor enter <esc><cr> to goto TAQOZ.
    For instructions/commands see the relevant thread.
    For SD, copy a binary file named "_P2_BOOT.BIX" or "_P2_BOOT.BIY" to the card. I posted a simple file in the SD Boot thread.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I thought I would pass this info on as I found it fascinating. Hope I get it right.
    Chip said that the testing involves a mass of gates which serialise all the outputs from all flops in the chip. This accounts for ~15% of the gates on the die!!! It also impacts the ultimate chip speed as it is also a gating factor :(
    OnSemi also does full testing on every bit of RAM with rolling patterns.
    It's all controlled by software far removed from the real silicon. When the software passes, the chip is pretty much guaranteed to work!
    IIRC there were 22 processes to make the 350nm P1. There will be 100+ for the 280nm P2. And a process may contain a number of exposures of different masks to create one layer.
    And this is a smallish chip on an old generation process. Imagine what goes into making a Xenon CPU or Apple A10 CPU !!!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.
  • jmgjmg Posts: 12,090
    Cluso99 wrote: »
    Chip's latest ROM_Booter v33d with the special new ROM section commented out

    A glance at this shows..
    * Delay after SPI reset is still a fixed 50us. My previous posts suggested making this a polling step, as the newer SPI Flash parts have variable delay exits from reset, depending on what they were doing. Data says commands are ignored during this phase.
    ie you issue reset (SW, or SPI flash may have a HW reset pin), and then poll the part for a valid response.
    Quad and Octal wired parts may be best to use HW reset pins, to cover all possible modes and exits. Users may wire that directly to the P2 reset pin.

    Device ID looks suitable, as it is always <> 000000,ffffff, or an alternative may be to wiggle a status bit, and confirm it follows.
    It's not clear if simply (re)reading status is enough on a floating pin ?

    * Transmit routine still has a 1ms delay for all calls
    transmit mov y,##rc_max/1000/4 'wait 1ms to allow host turn-around
    As I mentioned before, that represents a long time to add to boot, and it could be smarter to make that 1 char time ?

    * ' Receiver ISR - detects maintenance ">" chrs
    This still swallows the ">", which I think is not really needed by the string compares (they ignore it anyway), but it does impact other code that might use the serial buffers.

    As a test, the faster tx delay code should be able to accept a continual stream (no gaps or delays) of
    "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 ....."
    and properly exit and autobaud on that, at any phase.
    If the host has buffers, the reply is fewer chars than enquiry, so any buffer overrun should be avoided.
  • With the new pull-ups, there is no delay in selecting Serial, Flash, or SD Boot. And Serial can be disabled with a pulldown, giving a little security.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 13,916
    edited May 12 Vote Up0Vote Down
    Dave Hein wrote: »
    Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.
    Currently, there is no real ROM image to try out. It has to be downloaded. Maybe later today (Sunday morning LA time) we might have ROM code ready to put into FPGA ROM. Then if Chip has time he might be able to make a few versions.

    So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Here is v134b code to replace v134a code a few post back.

    As above, load new fpga code (BeMicro_A9_Prop2_8cogs_v32d.jic)

    Re-power the BeMicro

    With pnut, compile and download this code (ROM_v134b.spin2)

    With PST, reset P2 by toggling DTR off/on (this goes to the new downloaded ROM code v134b

    Type "> " and the "Prop_Chk 0 0 0 0 " and you should see the message "Prop_Ver X" displayed. This verifies we are running the new downloaded 134b code.

    Type "Prop_TAQ" to goto TAQOZ or type "Prop_MON" to goto the Monitor. Both will display info automatically.

    For TAQOZ, type Ctl-W to display a list of words

    For Monitor, type "100L<cr>" or "FC000.FC100L" where L can be lower or upper case

    For Monitor, type "<esc><cr>" to goto TAQOZ.

    Note quotes not required, and <esc> is the escape character, <cr> the enter character.

    Note this code blocks new downloads because it returns "Prop_Ver X" so you know you are running this version. Just edit ROM_v134b.spin and edit this line
            ver             =       "X"   ' "F"             'Prop123-A9 / BeMicro-A9, 8 cogs, 64 smart pins <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< temp
    
    back to version "F". You will need to re-power to go back to original fpga rom first, and repeat the above steps.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Dave HeinDave Hein Posts: 5,577
    edited May 13 Vote Up0Vote Down
    Cluso99 wrote: »
    So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
    What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.

  • Where is the "BeMicro_A9_Prop2_8cogs_v32d.jic" file?
    Can all these elusive files be zipped up and posted in one place.

    It worries me a bit that only a few of us (maybe 5) actually have Bemicro-A9 boards.
    Melbourne, Australia
  • Dave Hein wrote: »
    Cluso99 wrote: »
    So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
    What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.

    No because...
    1. Connecting the SD via an internal connection in the FPGA throws up internal pullups
    2. The BeMicroCV-A9 has external pullups added to some of the pins which interferes with the pullup detection - I desoldered them on my pcb but couldn't remove those added somehow in the verilog. No time to debug the problem.

    You cannot use the SD on other pins because that's not what we are testing now.

    But, you can try the monitor and taqoz. However, we will need new code to just test the actual monitor and taqoz code, and it's Mothers' Day here so I won't have time till tonight.
    I put the monitor code up weeks ago but no-one tried it :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 13,916
    edited May 13 Vote Up0Vote Down
    ozpropdev wrote: »
    Where is the "BeMicro_A9_Prop2_8cogs_v32d.jic" file?
    Can all these elusive files be zipped up and posted in one place.

    It worries me a bit that only a few of us (maybe 5) actually have Bemicro-A9 boards.

    I can email it. Its too big to post on the forum :(

    What is your email addr Brian? PM me as I've lost it :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmg wrote: »
    Cluso99 wrote: »
    Chip's latest ROM_Booter v33d with the special new ROM section commented out

    A glance at this shows..
    * Delay after SPI reset is still a fixed 50us. My previous posts suggested making this a polling step, as the newer SPI Flash parts have variable delay exits from reset, depending on what they were doing. Data says commands are ignored during this phase.
    ie you issue reset (SW, or SPI flash may have a HW reset pin), and then poll the part for a valid response.
    Quad and Octal wired parts may be best to use HW reset pins, to cover all possible modes and exits. Users may wire that directly to the P2 reset pin.

    Device ID looks suitable, as it is always <> 000000,ffffff, or an alternative may be to wiggle a status bit, and confirm it follows.
    It's not clear if simply (re)reading status is enough on a floating pin ?

    * Transmit routine still has a 1ms delay for all calls
    transmit mov y,##rc_max/1000/4 'wait 1ms to allow host turn-around
    As I mentioned before, that represents a long time to add to boot, and it could be smarter to make that 1 char time ?

    * ' Receiver ISR - detects maintenance ">" chrs
    This still swallows the ">", which I think is not really needed by the string compares (they ignore it anyway), but it does impact other code that might use the serial buffers.

    As a test, the faster tx delay code should be able to accept a continual stream (no gaps or delays) of
    "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 ....."
    and properly exit and autobaud on that, at any phase.
    If the host has buffers, the reply is fewer chars than enquiry, so any buffer overrun should be avoided.

    The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
  • Dave Hein wrote: »
    Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.

    Yes, but I won't have time to make it until about 20 hours from now.

    I'll need to get the final code from Cluso99 and Peter Jakacki.
  • jmgjmg Posts: 12,090
    cgracey wrote: »
    The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
    True, but you have captured 7T and 5T inside the Auto-Baud, so it is quite minimal overhead to either add those, or double one, to give a useful delay value ~ 1 Char time.
    To someone trying to sense reset exit and then load code at 1Mbd, that 1ms MIN, is > 100 char times.
  • Cluso99 wrote: »
    Dave Hein wrote: »
    Cluso99 wrote: »
    So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
    What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.

    No because...
    1. Connecting the SD via an internal connection in the FPGA throws up internal pullups
    2. The BeMicroCV-A9 has external pullups added to some of the pins which interferes with the pullup detection - I desoldered them on my pcb but couldn't remove those added somehow in the verilog. No time to debug the problem.

    You cannot use the SD on other pins because that's not what we are testing now.

    But, you can try the monitor and taqoz. However, we will need new code to just test the actual monitor and taqoz code, and it's Mothers' Day here so I won't have time till tonight.
    I put the monitor code up weeks ago but no-one tried it :(
    Taking a soldering iron to my DE2-115 is probably a showstopper for me. I have tested things using the small prototyping board that plugs into the main FPGA board. If there's a way to wire it that way that would be desirable. The flash chip does sit in a socket on the prototyping board, so pins 59-61 are accessible from the socket. I don't know if pin 58 is available on the prototyping board.

    If hardware mods are needed for the DE2-115 it would be good to get specific instructions on how to make the changes.

    Cluso99 and Peter, do you have links to your standalone code and documentation where we can just download it? I can try testing it that way.
  • I haven't posted my latest standalone code.

    You can try the last release in the appropriate threads. The changes since have really been code tidy.

    Next time on my computer will be tomorrow evening (18 hrs from now) and I will be testing the SD in ROM code just to ensure the booted can pass control to my code.
    There are no plans to make any more changes to my monitor or SD code unless we find a problem.

    We now have Chips booted passing control to our code (includes YAQOZ). I now have my monitor taking the user settings including baud from Chips booted and Peter is working on the same for TAQOZ. The booted does autobauding.

    We've just to verify the pull-up functions correctly and passes control to our respective code. It should go to OnSemi Monday morning. After that Chip said he will make FPGA releases for some of the boards, including DeNano as the boot code will work on a single cog.

    Oh forgot, I asked Chip to check the code for sending and receiving characters using the smart pin uart as the code I am using was from a long time ago. I am polling the receive.

    So that's the latest info.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • We have checked the code. Mine is done and Peter is just doing a little timing test/tweek before he sends it to Chip.

    If you plug an SD card in with code in the MBR/VOL or a file, then it boots that :)

    TAQOZ and the Monitor can go back and forth between them. We use the serial settings passed from the booter and autobaud routine.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    We have checked the code. Mine is done and Peter is just doing a little timing test/tweek before he sends it to Chip.

    If you plug an SD card in with code in the MBR/VOL or a file, then it boots that :)

    TAQOZ and the Monitor can go back and forth between them. We use the serial settings passed from the booter and autobaud routine.
    Sounds good!

  • Cluso99 wrote: »
    ...If you plug an SD card in with code in the MBR/VOL or a file, then it boots that :)...

    Super!!!

    This is so important for being able to completely configure a P2 system without needing any tools or special IDE's, etc. This is a really nice feature.
  • Agreed. Well done gents. SD is worth it.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmgjmg Posts: 12,090
    cgracey wrote: »
    The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.

    If you do not want to preserve the baud values, and alternative is to simply remove the tx start delay entirely, as I think that's a legacy from the single-pin boot mode (that is no longer in the ROM I believe) ?
    All MCUs and USB links, have Duplex UARTS so they do not care about relative phase of TX.RX.


  • K2K2 Posts: 607
    Cluso99 wrote: »
    Chip said that the testing involves a mass of gates which serialise all the outputs from all flops in the chip. This accounts for ~15% of the gates on the die!!! It also impacts the ultimate chip speed as it is also a gating factor :
    You seem to be describing JTAG. On many chips it has a second life as a programming and debugging aid for code developers.

Sign In or Register to comment.