Forum Update - Announcement about May 10th, 2018 update and your password.

Fast hub RAM timing

2»

Comments

  • cgraceycgracey Posts: 9,141
    edited January 24 Vote Up0Vote Down
    TonyB_,

    I've gone into the hub FIFO block and made sure that things can't happen out of order:

    - After RDFAST, RFxxxx reads, WFxxxx ignored
    - After WRFAST, WFxxxx writes, RFxxxx ignored (returns $00000000)
    - When RDFAST/WRFAST are configuring, WFxxxx ignored, RFxxxx ignored (returns $00000000)

    I'm really glad you brought this up, because there were some ambiguities in these cases that needed certainty. For example, what RFxxxx returns when it can't get data, and when the GETPTR value can be incremented.

    I wouldn't suppose someone would leave a streamer running while issuing a new RDFAST or WRFAST, but now we know what to expect in that case and it coincides with likely expectations.

    I will get a new version out soon with the new quick-exit RDFAST/WRFAST and this cleaned up RFxxxx/WFxxxx behavior.

    Thanks, again, for bringing this up.


    P.S. I'm running it now and it's a lot better with RFxxxx returning 0's. Very sensible now.
  • evanhevanh Posts: 5,112
    edited January 24 Vote Up0Vote Down
    Chip,
    Obviously an ignore state is a bug from a use view. On that note, in the two cases where RFxxxx is issued while RDFAST is configuring or where WFxxxx is issued while WRFAST is configuring, we could go one step further and stall on RFxxxx/WFxxxx. With this in place then the two operating modes no longer have significant use difference. The b31 flag can be got rid of and only the more streamlined mode exists.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • cgraceycgracey Posts: 9,141
    edited January 24 Vote Up0Vote Down
    evanh wrote: »
    Chip,
    Obviously an ignore state is a bug from a use view. On that note, in the two cases where RFxxxx is issued while RDFAST is configuring or where WFxxxx is issued while WRFAST is configuring, we could go one step further and stall on RFxxxx/WFxxxx. With this in place then the two operating modes no longer have significant use difference. The b31 flag can be got rid of and only the more streamlined mode exists.

    There's a lot of assumption of RFxxxx/WFxxxx being able to execute immediately. It would be pretty disruptive to unravel that thing and put it back together with stalling. That's way too much for me to handle, at this point. Hub exec uses this, too.

    This RDFAST/WRFAST D[31] quick-exit is a nice trick for advanced programmers, but I don't think it should be made a standard behavior. My reasoning has to do with the streamer and starting it up with known timing. RFxxxx and WFxxxx, when issued from software, just GO. The streamer, though, may be issuing hidden RFxxxx/WRxxxx's like a drunk sailor and if we do a new RDFAST, for example, in software, we just need some predictable behavior regarding what kind of data interruption the streamer experiences. Data going to 0 until the new stream is available is nice. Software is never going to get this response unless you did the D[31] thing, which is not for casual programmers.
  • Good info there. Heh, I've not read up on actually using the Streamer. I'm happy.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • TonyB_TonyB_ Posts: 581
    edited March 4 Vote Up0Vote Down
    cgracey wrote: »
    TonyB_ wrote: »
    Another query I have is about the block size in RDFAST/WRFAST/FBLOCK.

    64 bytes is 16 longs or 16 cogs * one long per cog, which is what determined the minimum size of the hub FIFO? Now there are only 8 cogs is the FIFO smaller?

    The FIFO is smaller, yes.

    The block size could be smaller, too.

    I keep the block size at 16 longs, though, so that we can have software compatibility across a family chips, with up to 16 cogs.

    Chip, thanks for that and the other info and changes you made yesterday.
    Formerly known as TonyB
  • TonyB_TonyB_ Posts: 581
    edited March 4 Vote Up0Vote Down
    deleted
    Formerly known as TonyB
  • TonyB_TonyB_ Posts: 581
    edited March 11 Vote Up0Vote Down
    TonyB_ wrote: »
    Here are the old 16-cog timings from Instructions v31 :
    	16-cog timing
    	Cogex cycles	Hubex cycles
    
    RDBYTE   9-24		9-44
    RDWORD   9-24*		9-44*
    RDLONG   9-24*		9-44*
    
    WRBYTE   3-18		3-38
    WRWORD   3-18*		3-38*
    WRLONG   3-18*		3-38*
    WMLONG   3-18*		3-38*
    
    	* +1 if crosses hub long
    
    	16-cog timing
    	Cogex cycles
    
    RDFAST  10-25 + WRFAST finish
    WRFAST   3    + WRFAST finish
    FBLOCK   2
    
    RFBYTE 	 2
    RFWORD   2
    RFLONG   2
    RFVAR    2
    RFVARS   2
    
    WFBYTE   2
    WFWORD   2
    WFLONG   2
    

    Chip, do you have time at the moment to tell us the timings for the above instructions for the 8 cog versions, including the new fast RDFAST/WRFAST? Have the latter been added to a public FPGA version? (I can't test it but others could.)
    Formerly known as TonyB
  • I will measure the times soon for 8 cogs.
  • cgracey wrote: »
    The next thing I need to do is get new FPGA images out. We need everyone who can, to try them out. There should be no surprises.

    Q1. Is the fast RDFAST/WRFAST with D[31]=1 already in an FPGA image?
    Q2. If there is a WRFAST but no WFxxxx then a RDFAST, does the RDFAST cancel the WRFAST (and vice-versa)?

    One final PM sent about XBYTE.
    Formerly known as TonyB
  • TonyB_ wrote: »
    cgracey wrote: »
    The next thing I need to do is get new FPGA images out. We need everyone who can, to try them out. There should be no surprises.

    Q1. Is the fast RDFAST/WRFAST with D[31]=1 already in an FPGA image?
    Q2. If there is a WRFAST but no WFxxxx then a RDFAST, does the RDFAST cancel the WRFAST (and vice-versa)?

    One final PM sent about XBYTE.

    The D[31] no-wait for RDFAST/WRFAST has been in there for a while.

    Yes RDFAST and WRFAST are mutually exclusive. One cancels the other.
  • Thanks for the info, Chip. Another PM sent.
    Formerly known as TonyB
Sign In or Register to comment.