Basic UVM testbench for a Stream Processor
Other projects
next section →
This page: DUT HWSP specification and testplan

 
 

The Specification

Eventually one must get to the details. So here is the specification and the testplan.
The stream processor with 8 oneproc units is presented first, then the oneproc unit individually.

Oneproc functions
  • Functions
  •        
    Stream Processor
  • Block Diagram
  • Signal Description
        •System
        •Write channel
        •Read channel
  • Bus Transfers
        •System
        •Write channel
        •Read channel
  •        
    Oneproc unit
  • Block Diagram
  • Signal Description
        •System
        •Write channel
        •Read channel
  • Bus Transfers
        •System
        •Write channel
        •Read channel
  •        
    List of Verification items/VID's
  • List of all VIDs



  • General points, terminology, and notation

    This is a normal coverage driven verification effort. This specification will identify items which need to be tested and will give them an identification specifier, a Verification ID (VID). These items are specific things to be covered by a functional test, whether they be correct or incorrect functioning. Some items name assertions, some name tests, some name covergroups, some name explicit scoreboard checks.

    This is a home project, and as such it is subject to many resource limitations. This will impact the constrained random test runtime. And as I don't have access to formal verification tools there will be no formal verification component to the testplan. Also since this is a home project, is suffers the absence of external review and thus violates the good practice of keeping the RTL coders and RTL verifiers from using a single interpretation of the specification. But the upside of there being only one interpreter of the specification is that there need be only a single document. Every single thing one can say in a specification is an item to be verified, a VID.

    In addition to specifying what is to be tested, the VID will also indicate which method in the verification process should cause that item to be tested. The VID will also indicate the expected behavior: if "_ERR" is at the end of the name it indicates an expected error condition. Otherwise the item indicates expected correct behavior. For example, an assertion expected to be hit in a functional simulation at the top level will be VID_SP_func_assert_<assertion identifier> (of course such an assertion may also be triggered in a constrained random test). The VID will also indicate how the item is to be reported: a code coverage item, an assertion collected in coverage, or a report from the scoreboard. The table below shows the nomenclature.


    Test level, <level>
    _SPTop level HWSP
    _OPUnit level of one oneproc

    Verification tool, <tool>
    -
    Formal no tools available
    -
    Emulation no emulator available
    _fpga FPGA requires complete design
    _func Functional simulation, level this testbench
    _rand Constrained random sim, levelthis testbench

    Checking mechanism, <mech>
    _assert Assertionfrom an assertion, and written to the log file
    _self Self check in scoreboardwritten to the log file
    _postp Post Processingextracted from post processing of the log file
    _cpropCover property from simulator's coverage report
    _ccoverCode coverage from simulator's coverage report
    _observeObservation some things need to be seen

    Note: "_ERR" is appended if the assertion is an expected error condition


    The general form of a VID is:
    VID_<level>_<tool>_<mech>_<name>[_ERR]

    Here are some examples:
    VID_SP_rand_self_CMMDarg0onlyChange
    Testing that it is possible to only update the arg0 field and run the same command,
  • tested from the top level, SP,
  • with random testing,
  • and a self-checking mechanism,
  • writing to the log file.


  • VID_OP_rand_ccover_assert_abortToavailableTime
    Testing that the oneproc unit responds to an abort within the required time independent of the computation being performed and the stage of the computation,
  • tested at the unit level, oneproc,
  • with random testing,
  • using an assertion,
  • collected in the coverage report, and
  • the assertion of an error as well should a violation occur.
    There should be one hit to the VID_OP_rand_ccover_assert_abortToavailableTime bin for every abort attempt.


  • In general, the functional tests are for: And since the stream processor can look like a variety of different buffer types, FIFO, LIFO, associative array, etc, (it's really a WIWO, Whatever In Whatever Out), the functional tests must also exercise things like: And the constrained random tests will handle: In the text below, the VIDs are shown in bold on their first occurrence. The tickbox "[ ]" is there because this is a working document where I keep a record of progress. The legend for the tickbox is:
    [ ] means only that the VID is listed.
    [l] means I'll get to it later.
    [D] means it requires a special driver to test.
    [t] means that a test is written that can exercise the VID.
    [c] means that coding is done.
    [i] means that it's integrated.
    [*] means that it's done.

    "later":
        this is for a full HWSP VID, to be done after all the oneproc unit tests are complete.
    "test written":
        a test is written that can exercise the VID.
    "coded":
        if it's a property, the property is written,
        if it's a self test, the scoreboard includes the checking,
        if it's coverage, the coverpoint is written,
        if it's a DUT interface assertion, it's written.
    "integrated":
        this is the "I threw everything together and it compiles properly" state.
    "done":
        it has been verified by observation that the test/check functions as intended.

     
     
     
     

    Stream Processor Functions

    The table below shows the current command set, expected behavior, and associated VIDs. Note that HWSP does not check if either the data or command make sense, so the scoreboard will have to take potential nonsense into account during random testing.
    Embedded side note: Anyone trying to "idiot proof" something like a GUI knows that there is often more code involved in sanitizing input and making certain that user choices make sense than there is code in the actual function. I don't want to put that sort of checking in the hardware. All I ask of the hardware is that complete gracefully in a reasonable amount of time, even when given rubbish commands and/or data.
    The table below does not provide complete details of the commands. For that, see the section A DUT that does something worth testing for each of the computations performed in a oneproc, and dut_pkg.svh which specifies what the expected output should be and the DataRec details.


    Command tests appropriate at the level of the oneproc unit
    General notes for random tests:
  • Vary arg0 and arg1: match expected computation.
  • Vary commands in pipeline mode: match expected computation.
  • Vary write and read protocol.
  • Vary commands, and vary DataRec fields at extremes: verify only graceful completion.
  • Command arg0 arg1 computation
    NOP any value any value No Operation. A NOP should not change the data record in any way. However, NOP is a command and the processor should respond externally in a normal way.
    Because the computations for the SMOOTH and CORR operations take many cycles, the NOP command has been made to delay arg0 number of cycles before completing. This can vastly speed up the constrainted random protocol checking at the HWSP top level. The NOP_sequence currently limits the time range to between 0 and 13 cycles.

    [*] VID_OP_func_self_NOPdoesNotChangeDataRecord
    [*] VID_OP_func_assert_NOPtoDoneIn1_2Clocks
    [ ] VID_OP_rand_assert_CMMDtoAvailableInMclocks
    SMOOTH 0|1 val This operation overwrites values in the array from array[0] to array[N-1] by averaging, where
  • array[0] is located at the offset given by DS, in byte4.
  • N = the value of DL, the contents of byte5, the length of the array.
  • Note that the array cannot begin at an offset less than h'C without overwriting the header information and reserved bytes. This puts a lower limit of h'C for DS.
  • Note also that with a 64 byte memory, the absolute maximum number for length is 63-DS = 51.
  • If arg0 == 0, the value of array[N-1] is untouched.
  • If arg0 == 1, the value of array[N-1] is averaged with the original value of array[0], making it a circular array.
  • A value of DL > 63-DS has unconsidered writing behaviour.

    [*] VID_OP_func_self_SMOOTHmatch_0 i.e. arg0 bit0 == 0
    [*] VID_OP_func_self_SMOOTHmatch_1 i.e. arg0 bit0 == 1
  • CORR arg0 arg1 Perform Pearson's r correlation coefficient computation (described elsewhere).
  • If arg0 == 0, arg1 is ignored.
  • If arg0 == 1, arg1 is taken to be a correlation coefficient threshold in the form b.bbbbbbb, and this processor will stop and assert done if that threshold is reached, abandoning further processing. It would normally run 22 times to evaluate all 11 byte strings in the 32 byte array against "Hello world".

    [*] VID_OP_func_self_CORRmatch
    [*] VID_OP_func_self_CORRearlyDoneOnArg1match
  • Not one of {NOP, CORR, SMOOTH} any value any value All values for the CMMD field which are not one of NOP, CORR, or SMOOTH must be treated as a NOP. Vary arg0 and arg1 for the sport of it.

    [*] VID_OP_func_self_BadCMMD
    Pipelined commands vary vary The oneproc unit is designed to be able to perform pipelined operations. There are two variations.
    1. An initial command followed by "NULL" writes, i.e. assertion only of the signal run and no change to write or load, and
    2. Same-data-different-function operations, where the change is to the CMMD and/or the arg0/1 fields, but not the data.

    [*] VID_OP_func_self_pipeline_null
    [*] VID_OP_func_self_pipeline_nullWithFinal
    [ ] VID_OP_func_self_pipeline_ChangeCMMD

    Mix the pipelining as part of the [l] VID_SP_rand_assert_FillAndKeepFull or similar sequence.

    [ ] VID_OP_rand_self_pipeline



    Command tests appropriate at the level of the HWSP
    Single computation HWSP can perform three different functions, each of which takes one or more arguments.

    Perform various computations singly, waiting on okToRead, and completing acknowledgement before submitting a new task.

    [l] VID_SP_rand_assert_SingleComputation
    Fill then drain HWSP The HWSP can perform up to 8 (see HWSP_PROCS define in the dut_pkg.v) functions concurrently.

    Perform various computations until !okToWrite, indicating that all resources are busy, then wait until okToRead and perform reads until !okToRead. This fills then drains the HWSP. Do this a few times back to back.

    [l] VID_SP_rand_assert_FillThenDrain
    Fill HWSP and keep it full The HWSP can perform up to 8 (see HWSP_PROCS define in the dut_pkg.v) functions concurrently, forever.

    Perform various computations until !okToWrite, then wait until okToRead, perform a single read, and then start a new computation. Keep this up for at least 8 x 3 times, and ensure OoO completion is occurring.

    [l] VID_SP_rand_assert_FillAndKeepFull
    [l] VID_SP_func_self_OoOcompletes
    [l] VID_SP_rand_self_OoOcompletes
    writeReq before okToWrite

    readReq before okToRead
    Both read requests and write requests can occur before or after the corresponding okToWrite or okToRead is asserted.

    Ensure that there is no hang or erroneous assertion of readyToWrite or readyToRead

    [D] VID_SP_func_assert_writeReqB4okToWrite
    [D] VID_SP_func_assert_readReqB4okToRead
    Pipeline commands The HWSP can operate in a pipelined fashion by applying different functions to the same data set.

    Use the smoothing function to test the pipelining function (should run the data down to a flat line average).

    [l] VID_SP_func_self_pipeline

    Mix the pipelining as part of the [l] VID_SP_rand_assert_FillAndKeepFull or similar sequence.

    [l] VID_SP_rand_self_pipeline



    Variations on the assertion of the abort signal
    Abort is not an exceptional behavior. Results from some computation may result in the mooting of all currently running operations, and the abort function is there to cease all such processing and free the processors for new operations.
    Abort changes nothing in the DataRec itself. However, aborting an ongoing operation which itself modifies the contents of the DataRec will leave that part of the DataRec in an unknown state.

    Verify the abort behavior. Also intermix aborts in the random mix.

    [ ] VID_OP_func_cover_abort
    [l] VID_SP_rand_cover_abort


     
     
     

    The Stream Processor

    Block Diagram: Stream Processor

    interface HWSP_sys_if ;
      logic clock ;
      logic reset ;
      logic setLoadMode ;
      logic getLoadMode ;
      logic abort ;
      logic idle ;
    endinterface
    
    interface HWSP_write_if ;
      logic [7:0] frameID_wOut ;
      logic okToWrite ;
      logic writeReq ;
      logic readyToWrite ;
      logic [3:0] wAddr ;
      logic [31:0] wData ;
      logic write ;
    endinterface
    



    interface HWSP_read_if ;
      logic [7:0] frameID_rOut ;
      logic finalBit ;
      logic okToRead ;
      logic readReq ;
      logic readyToRead ;
      logic read ;
      logic [3:0] rAddr ;
      logic [31:0] rData ;
    endinterface
    


     
     
     

    Signal Description: Stream Processor

    All signals are active high.
    Direction is given w.r.t the stream processor.
     
     
    System control group
    Name Direction Description
    clock input system clock. All signals sampled or transition w.r.t. clock's rising edge.
    reset input system reset. Synchronous deassert. Verify the device comes out of reset, and not just at the beginning of the simulation.

    [l] VID_SP_func_assert_resetDeassertNotSynchronous_ERR
    setLoadMode input 0 - set the load mode to serial. This is the default mode, set on reset.
    1 - set the load mode to parallel.
    When the mode is serial, write frames will go to the next available oneproc unit.
    When the mode is parallel, write frames will be assigned to all oneproc units simultaneously. Before setting setLoadMode to a 1 and performing a write in parallel mode, the signal idle must be asserted. getLoadMode must also be asserted to indicate that parallel mode is supported.

    [l] VID_SP_func_assert_setLoadModeParallelAttempted
    [l] VID_SP_func_assert_setLoadModeSerialAttempted
    [l] VID_SP_func_assert_setLoadModeNotIdle_ERR
    getLoadMode output 0 - the actual load mode as far as the HWSP is concerned is serial.

    1 - the actual load mode as far as the HWSP is concerned is parallel.

    The setLoadMode input is a request, and getLoadMode is what the stream processor is actually doing or is capable of doing. If setting setLoadMode to 1, parallel, while idle is asserted does not result in getLoadMode going high, then this SP does not have the parallel load capability.

    [l] VID_SP_func_assert_getLoadModeIsSet_ERR because that's not supported yet.
    abort input 0 - Not an abort.

    1 - Assert to abort all processing.
    In response, idle is asserted to indicate that all processors are idle. abort can be asserted at any time and must be held until the SP asserts idle. Normally, when processing units are finished there must be a corresponding read channel access to free the processor, but no such acknowledgement is required following an abort. The SP will go idle within XYZ clocks following the assertion of abort.

    [l] VID_SP_func_assert_normalAbort
    [l] VID_SP_func_assert_abortDeassertBeforeIdle_ERR
    [l] VID_SP_rand_assert_cprop_abortWithinXYZ
    Abort is not an exceptional behavior, but is expected to occur often. It should be tested as such, probably 5% of the time at least.
    idle output 0 - there is at least one processor busy.

    1 - indicates that no processing is going on in the SP. All oneproc units are available. This can happen because all units completed processing and have been acknowledged (see Read channel control group below) or in response to an abort.

    [l] VID_SP_func_assert_idleFollowsAbort
    [l] VID_SP_func_assert_idleFollowsAllProcsDone

     
     
     
     
    Write channel control group
    NameDirectionDescription
    frameID_wOut output This is the frameID of whatever processor is scheduled to be written to next. It is valid only when okToWrite is asserted. This is provided by the task scheduling mechanism for pipelining operations and can be otherwise ignored.

    [l] VID_SP_func_assert_frameID_wOutFollows
    [l] VID_SP_rand_assert_frameID_wOutMismatch_ERR
    okToWrite output 0 - No processors are available.

    1 - Indicates that there is at least one processor available for a new task assignment.

    This is only an indication that a write request, the assertion of write, will be followed by a readyToWrite within X clocks. The value of X depends on the internal state of the SP and the number of oneproc units inside. The current scheme for processor selection uses a round robin mechanism, a counter, to find the next available processor. With 8 processors, X should be close to 8 at maximum.
    okToWrite is provided because computations may take many hundreds of clock cycles and the CPU or scheduling unit to which this SP is connected may not wish to assert a write request unless it knows at least one processor is available.
    writeReq input 0 - Not a write request.
    Also, following writeReq && readyToWrite, the deassertion of writeReq ends that write channel access on the SP and frees the write channel. The deassertion of writeReq also initiates processing on the selected processor.

    1 - Assert to request write access to one of the internal processors.

    If writeReq is asserted while okToWrite is deasserted, or while okToWrite is asserted but readyToWrite is deasserted, the writeReq can be deasserted. This cancels the write request. The SP does not know there was a write request.

    However, if writeReq is asserted while okToWrite is asserted and the readyToWrite has been asserted for at least one clock, it is illegal to deassert writeReq. In order to "cancel" the write at this stage it is necessary to write a NOP to the processor.

    [D] VID_SP_func_assert_writeReqBeforeOkToWrite
    [D] VID_SP_func_assert_writeReqAfterOkToWrite
    [D] VID_SP_func_assert_writeReqWithdrawnOK
    [D] VID_SP_func_assert_writeReqWithdrawnAfterReadyToWrite_ERR
    readyToWrite output 0 - Not ready to accept a write.

    1 - This indicates that the SP has effectively connected the signals write, wAddr, and wData to one of its internal processors and the Write Channel can be used to access that processor as though accessing a simple memory. The SP will leave the Write Channel dedicated to this access until the deassertion of writeReq, in which case readyToWrite will also deassert.

    [l] VID_SP_func_assert_readyToWriteMoreThanXclocks_ERR
    [D] VID_SP_func_assert_readyToWriteLeadsWriteReq_ERR
    write input 0 - Not a write.

    1 - When asserted, write the data on wData to the address wAddr to the internal memory of the selected processor.
    It is illegal to assert write unless a valid write cycle is in progress marked by writeReq && readyToWrite.

    [D] VID_SP_func_assert_writeB4OKandReady_ERR
    [3:0] wAddr input In this SP the internal oneproc memory is 64 bytes organized as 16 32-bit words. wAddr presents the one-of-16 address.
    wAddr is sampled on the rising edge of the clock when write is asserted.
    [31:0] wData input In this SP the internal oneproc memory is 64 bytes organized as 16 32-bit words. wData presents the 32-bit word.
    wData is sampled on the rising edge of the clock when write is asserted.

     
     
     
     
    Read channel control group
    NameDirectionDescription
    frameID_rOut output This is the frameID of whatever processor is scheduled to be read next. It is valid only when okToRead is asserted. This is provided by the task scheduling mechanism for pipelining operations and can be otherwise ignored.

    [l] VID_SP_func_assert_frameID_rOutFollows
    [l] VID_SP_rand_assert_frameID_rOutMismatch_ERR
    finalBit output This is bit 7 of the command field of whatever processor is scheduled to be read next. It is valid only when okToRead is asserted. This is provided by the task scheduling mechanism for pipelining operations and can be otherwise ignored.

    [l] VID_SP_func_assert_finalBitFollows
    [l] VID_SP_rand_assert_finalBitMismatch_ERR
    okToRead output 0 - All processors are busy.

    1 - Indicates that at least one processor has completed computation and is awaiting acknowledgement to be freed for further task assignment.

    This is only an indication that a read request, the assertion of read, will be followed by a readyToRead within Y clocks. The value of Y depends on the internal state of the SP and the number of oneproc units inside. The current scheme for processor selection uses a round robin mechanism, a counter, to find the next available processor. With 8 processors, Y should be close to 8 at maximum.
    okToRead is provided because computations may take many hundreds of clock cycles and the CPU or scheduling unit to which this SP is connected may not wish to assert a read request unless it knows at least one processor has results to read.
    readReq input 0 - Not a read request.
    Also, following readReq && readyToRead, the return of readReq releases the read channel on the SP. This also returns the processor to the pool of available processors.

    1 - Assert to request read access of one of the internal processors. The processor selected is whichever happens to be ready next in the round robin scheme.
    If readReq is asserted while okToRead is deasserted, or while okToRead is asserted but readyToRead is deasserted, the readReq can be deasserted. This cancels the read request. The SP does not know there was a read request.

    If readReq is asserted while okToRead is asserted and the readyToRead has been asserted for at least one clock, it is harmless to deassert readReq, but the processor will be returned to the pool of available processors.

    [D] VID_SP_func_assert_readReqBeforeOkToRead
    [D] VID_SP_func_assert_readReqAfterOkToRead
    [D] VID_SP_func_assert_readReqWithdrawnOK
    [D] VID_SP_func_assert_readReqWithdrawnAfterReadyToRead_ERR
    readyToRead input 0 - Not ready to accept a read.
    1 - This SP has effectively connected the signals read, rAddr, and rData to one of its processors and the read channel can be used to access that processor as though a simple memory. The SP will leave the Read Channel dedicated to this until the deassertion of readReq, in which case readyToRead will also deassert.

    [l] VID_SP_func_assert_readyToReadMoreThanYclocks_ERR
    [D] VID_SP_func_assert_readyToReadLeadsReadReq_ERR
    read input 0 - Not a read.

    1 - When asserted, read the data on rData from the address rAddr.

    It is silly to assert read unless a valid read cycle is in progress marked by readReq && readyToRead.

    [D] VID_SP_rand_assert_sillyRead
    [D] VID_SP_func_assert_readB4OKandReady_ERR
    [3:0] rAddr input In this SP the internal oneproc memory is 64 bytes organized as 16 32-bit words. rAddr presents the one-of-16 address.
    rAddr is sampled on the rising edge of the clock when read is asserted.
    [31:0] rData output In this SP the internal oneproc memory is 64 bytes organized as 16 32-bit words. rData returns a 32-bit word.
    rData is produced from the rising edge of the clock when read is asserted.

     
     
     

    Bus Transfers: Stream Processor

    N.B.

    In the diagrams below, the arcs indicate control flow.
    All inputs are sampled on the rising edge of the clock
    and all outputs derive from the rising edge of the clock.
    In the example to the right the input edge at 'a' is
    sampled at 'c', and the output change at 'b' is the result
    following the clock at 'c'.


    System

        Reset
    The figure below shows the proper reset sequence. Assert as you will, but make reset deassertion synchronous. reset must be asserted for at least one clock cycle.


    [l] VID_SP_func_assert_resetDeassertNotSynchronous_ERR
    Note: The reset signal will be left out of all following diagrams.



        Load mode
    The input setLoadMode is a request. In order for the SP to use a mode, the output getLoadMode must be in that state. This diagram shows the correct sequence for changing the load mode. setLoadMode can only be changed when idle is asserted.


    [l] VID_SP_func_assert_setLoadModeParallelAttempted
    [l] VID_SP_func_assert_setLoadModeNotIdle_ERR
    [l] VID_SP_func_assert_getLoadModeIsSet_ERR



        abort and idle
    The assertion of abort will cause all processors in the SP to abort their current task. idle is a logical AND of all the available signals from the oneproc units in the SP, so it will assert following the last processor to respond to the assertion of abort. It is expected that abort will be held until the assertion of idle. The deassertion of abort is only required in order to recommence task assignments.


    [l] VID_SP_func_assert_normalAbort
    [l] VID_SP_func_assert_abortDeassertBeforeIdle_ERR
    [l] VID_SP_rand_assert_cprop_abortWithinXYZ




     
     
     
      Write channel usage

        Normal write sequence
    A write can be initiated when readyToWrite is asserted. A write request via writeReq can be asserted before or after the signal okToWrite is asserted as shown in the two diagrams below. Note that the assertion of okToWrite is completely unrelated to the assertion of writeReq. The okToWrite is internally controlled and is asserted as a result of at least one processor being free to be assigned a new task. Assertion of writeReq in the same cycle of okToWrite is also legal as the two are independent.

    writeReq before okToWrite




    okToWrite before writeReq


    With readyToWrite asserted writes can be initiated. The SP looks like a 16 x 32-bit word positive-edge synchronous RAM. Just write to it. The processor being assigned the task will begin on the deassertion of writeReq. Note that there is actually no requirement to do any writing (asserting of write). If one wishes the same computation be performed and the same frameID used, just deassert writeReq immediately following the assertion of readyToWrite. If one is tracking tasks then one should at least change the frameID with a write to byte0 of word 0.


    [D] VID_SP_func_assert_writeReqBeforeOkToWrite
    [D] VID_SP_func_assert_writeReqAfterOkToWrite



    [D] VID_SP_func_assert_readyToWriteLeadsWriteReq_ERR



        Illegal removal of writeReq
    This is is illegal, but should not cause a hang.


    [D] VID_SP_func_assert_writeReqWithdrawnOK
    [D] VID_SP_func_assert_writeReqWithdrawnAfterReadyToWrite_ERR


     
     
     
      Read channel usage

        Normal read sequence
    A read can be initiated when readyToRead is asserted. The read request via readReq can be asserted before or after the signal okToRead is asserted as shown in the two diagrams below. Note that the assertion of okToRead is completely unrelated to the assertion of readReq. okToRead is internally controlled and indicates only that at least one processor has completed its task and has results available. Assertion of readReq in the same cycle of okToRead is also legal as the two are independent.

    readReq before okToRead


    okToRead before readReq

    With readyToRead asserted a read can be initiated. The SP looks like a 16 x 32-bit word positive-edge synchronous RAM. Just read it. The processor selected will become free on the deassertion of readReq.



    [D] VID_SP_func_assert_readyToReadLeadsReadReq_ERR

    Here is a normal read sequence. The value of finalBit and frameID_rOut are not considered.


    Note that there is actually no requirement to do any reading (asserting of read) ... the results can be:

  • discarded,
  • left in place for further processing,
  • actually not in the internal memory. The task could be performed in external memory.

    So no read is required, only the deassertion readReq following the assertion of readyToRead. Actually reading the contents of the currently pointed-to oneproc is up to the overall computational task. For repeated computations, such as in pipelining, the finalBit and frameID_rOut are provided. For example, in the diagram below the state of the finalBit and perhaps the value of frameID_rOut told the scheduler that no read was required ... only an acknowledgement in the form of deassertion of readReq.


    [D] VID_SP_func_assert_readReqBeforeOkToRead
    [D] VID_SP_func_assert_readReqAfterOkToRead



        Illegal removal of readReq
    NOTE: FIXME check behavior of RTL in this case. It is illegal, but should not cause a hang.

    [D] VID_SP_func_assert_readReqWithdrawnOK
    [D] VID_SP_func_assert_readReqWithdrawnAfterReadyToRead_ERR




     
     

    The oneproc unit

    Block Diagram: oneproc unit

    interface oneproc_if ;
      logic clock ;
      logic reset ;
      logic abort ;
    
    
    
      logic [7:0] frameID_wOut ;
      logic available ;
      logic load ;
      logic write ;
      logic run ; 
      logic [3:0] wAddr ;
      logic [31:0] wData ;
    (cont ...)
    
    (... cont)
      logic [7:0] frameID_rOut ;
      logic finalBit ;
      logic done ;
      logic thanks ;
      logic read ;
      logic [3:0] rAddr ;
      logic [31:0] rData ;
    endinterface
    


     
     
     

    Signal Description: oneproc unit

    All signals are active high.
    Direction is given w.r.t the oneproc unit.
     
     
    System control group
    NameDirectionDescription
    clock input system clock. All signals sampled or transition w.r.t. clock's rising edge.
    reset input system reset. Synchronous deassert. Verify the device comes out of reset, and not just at the beginning of the simulation.

    [ ] VID_OP_func_assert_resetDeassertNotSynchronous_ERR
    abort input This signal is identical in function and wiring to the SP level signal abort.

    0 - Not an abort.

    1 - Assert to abort all processing. In response, the available is asserted to indicate that this oneproc is available. This signal can be asserted at any time and must be held until available is asserted. The oneproc will go available within YYY clocks following the assertion of abort.

    [ ] VID_OP_func_assert_normalAbort
    [ ] VID_OP_func_assert_abortDeassertBeforeIdle_ERR,
    [ ] VID_OP_rand_assert_cprop_abortWithinYYY
    Abort is not an exceptional behavior, but is expected to occur often. It should be tested as such, at least 5% of the time.

     
     
     
     
    Write control group
    NameDirectionDescription
    frameID_wOut output This is the frameID of the processor, reflected back to an output.

    [*] VID_OP_func_assert_frameID_wOutExported
    available output 0 - this processor is busy.

    1 - this processor is idle and can be given a new task. This can happen because the unit completed and has been acknowledged, or as a response to an abort. Asserting write or load before available should have no affect. Asserting write and load simultaneously with the assertion of available is legal and has the same behavior as asserting write and load following available.
    If available is deasserted, only the assertion of thanks will cause available to be asserted again.

    [*] VID_OP_func_assert_availableDeassertOnWrite
    [i] VID_OP_func_assert_writeWithAvailable
    [D] VID_OP_func_assert_writeBeforeAvailable_ERR
    load input 0 - Not a load.

    1 - This signal controls the steering logic in the oneproc unit. Both the write channel and the computation function have access to the internal memory for the DataRec, and the load is essentially the multiplexor select line. When asserted, the internal memory is available for writing on the assertion of the write signal.

    [D] VID_OP_func_self_writeWithoutLoad
    [D] VID_OP_func_self_writeWithoutLoad_ERR
    write input 0 - not a write.

    1 - This is effectively the write signal from the SP top level. When asserted with load, place the data on wData at the address of wAddr into the internal memory.
    It is illegal to assert write unless a valid write cycle is in progress marked by load && available, although there should be no affect of doing so.

    [D] VID_OP_func_assert_writeB4available_ERR
    [D] VID_OP_func_self_loadWithoutWrite
    [D] VID_OP_func_self_loadWritesInParts
    [D] VID_OP_func_assert_writeWithoutLoad_AvailableDoesNotDeassert
    [D] VID_OP_func_assert_writeReqWithdrawnAfterReadyToWrite_ERR
    run input 0 - Not run.

    1 - asserted for one or two clocks, this starts the oneproc unit to initiate the computation in accordance with the contents of the data frame written to its memory. Run must be deasserted nCDXYE cycles before the processor is done, so just assert it for one or two clocks and let the processor do its thing.
    I am not going to deal with what happens when run is held asserted, so it will be an error to assert run for more than two cycles.

    [ ] VID_OP_func_assert_loadToAvailableDeassertDelay_ERR
    [ ] VID_OP_func_assert_neverCalculateWithoutRun_ERR
    [D] VID_OP_func_assert_runHeldAsserted_ERR
    [3:0] wAddr input In this particular oneproc unit the internal memory is 64 bytes organized as 16 32-bit words. wAddr presents the one-of-16 address.
    wAddr is sampled on the rising edge of the clock when write && load are asserted.
    [31:0] wData input In this particular oneproc unit the internal memory is 64 bytes organized asa 16 32-bit words. rData presents the 32-bit word.
    wData is sampled on the rising edge of the clock when write is asserted with load asserted.

     
     
     
     
    Read control group
    NameDirectionDescription
    finalBit output This is bit 7 of the most recent value written to the command field.

    [*] VID_OP_func_assert_finalBitFollows
    done output 0 - not done.

    1 - this processor is done performing the computation and waiting for an acknowledgement via an assertion of thanks. done remains asserted until thanks is asserted for one or more clocks. The expectation is that results will be read, although an actual read is not necessary to clear done and free this processor for other processing, only a thanks is required.

    [D] VID_OP_func_assert_readBeforeDone
    thanks input 0 - not thanking.

    1 - acknowledge this processor and free it for other processing. Assertion of thanks deasserts available. Assertion of thanks has no effect unless available is asserted.

    [t] VID_OP_func_assert_thanksWithoutRead
    [D] VID_OP_func_assert_thanksWithAvailableDeasserted
    [ ] VID_OP_func_assert_thanksToAvailableDeassertDelay_ERR
    read input 0 - Not a read.

    1 - When asserted, read the data from the address rAddr and place it on rData.

    It is silly to assert read unless a valid read cycle is in progress marked by done.

    [D] VID_OP_func_self_sillyRead
    [D] VID_OP_rand_assert_sillyRead
    [3:0] rAddr input The internal memory for this particular oneproc unit is 64 bytes organized as 16 32-bit words. rAddr presents the one-of-16 address.
    rAddr is sampled on the rising edge of the clock when read is asserted.
    [31:0] rData output The internal memory for this particular oneproc unit is 64 bytes organized as 16 32-bit words. rData returns a 32-bit word.
    rData is produced from the rising edge of the clock when read is asserted.


     
     
     

    Bus Transfers: oneproc unit

    System

        abort and available
    The assertion of abort will cause the oneproc unit to abort its current task. available is asserted when the oneproc unit has responded to the abort. It is expected that abort will be held until the assertion of available. The deassertion of abort is only required in order to use the oneproc unit, otherwise the oneproc will behave as though in reset and be unresponsive.

    [ ] VID_OP_func_assert_normalAbort
    [ ] VID_OP_func_assert_writeWhileInAbort
    [ ] VID_OP_func_assert_abortDeassertBeforeIdle_ERR
    [ ] VID_OP_rand_assert_cprop_abortWithinYYY



     
     
     
      Write channel usage

        Normal write sequence
    The oneproc unit can be written to after available is asserted. To write to the processor, assert load with wAddr and associated wData. It's a RAM, so order of writes is not important. To start the processor deassert write and load and assert run. Those can occur in the same cycle. The unit deasserts available on the first occurence of load. The oneproc unit should ignore the write signal after run is asserted and until the next assertion of available.


    [D] VID_OP_func_assert_assertRunWithWriteAsserted_ERR
    [D] VID_OP_func_assert_assertRunWithLoadAsserted_ERR
    [D] VID_OP_func_assert_assertRunAfterLoad
    [D] VID_OP_func_assert_assertWriteWhileRunning_ERR
    [D] VID_OP_func_assert_loadToAvailableDeassertDelay_ERR




     
     
     
      Read channel usage

        Normal read sequence
    A read can be initiated when done is asserted. A read is an assertion of read with the desired rAddr. rData follows in the next cycle. Zero or more reads are required. In order to free the processor, say thanks by asserting thanks.


    [ ] VID_OP_func_assert_thanksToAvailableAssertDelay_ERR

        Null read sequence
    A null read is performed by saying thanks following the assertion of done.


    [D] VID_OP_func_assert_thanksOnNullRead





     
     
     

    List of all VIDs


    [D] VID_OP_func_assert_writeBeforeAvailable_ERR<
    oneproc level tests
    [ ] VID_OP_func_assert_abortDeassertBeforeIdle_ERRoneproc_abort_test-
    [ ] VID_OP_func_assert_readB4OKandReady_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_readReqWithdrawnAfterReadyToRead_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_resetDeassertNotSynchronous_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_loadToAvailableDeassertDelay_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_thanksToAvailableAssertDelay_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_thanksToAvailableDeassertDelay_ERRoneproc_badProtocol_1_test-
    [D] VID_OP_func_assert_writeB4available_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_writeB4OKandReady_ERRoneproc_badProtocol_1_test-
    [D] VID_OP_func_assert_writeWithoutLoad_AvailableDoesNotDeassert-
    [D] VID_OP_func_assert_writeReqWithdrawnAfterReadyToWrite_ERRoneproc_badProtocol_1_test-
    [ ] VID_OP_func_assert_thanksOnNullReadoneproc_SMOOTH_1_pipeline_final_test-
    [ ] VID_OP_func_assert_assertRunAfterLoadoneproc_SMOOTH_0_pipeline_test
    oneproc_SMOOTH_1_pipeline_test
    oneproc_SMOOTH_1_pipeline_final_test
    -
    [ ] VID_OP_func_assert_assertRunAfterLoadoneproc_SMOOTH_0_pipeline_test
    oneproc_SMOOTH_1_pipeline_test
    oneproc_SMOOTH_1_pipeline_final_test
    -
    [*] [ ] VID_OP_func_assert_frameID_wOutExportedoneproc_CMMD_mix_1_testoneproc_if
    [ ] VID_OP_func_assert_normalAbortoneproc_abort_test-
    [ ] VID_OP_func_assert_readReqAfterOkToReadoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_readReqB4okToReadoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_frameID_rOutFollowsoneproc_CMMD_mix_1_test-
    [*] VID_OP_func_assert_finalBitFollowsoneproc_SMOOTH_1_pipeline_final_test-
    [ ] VID_OP_func_assert_readReqBeforeOkToReadoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_readReqWithdrawnOKoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_loadWritesInPartsoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_writeReqB4okToWriteoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_loadWithoutWriteoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_availableDeassertOnWriteoneproc_ProtocolVariations_1_test-
    -
    [*] VID_OP_func_self_pipeline
    [*] VID_OP_func_self_pipeline_nullWithFinal
    [ ] VID_OP_func_self_pipeline_ChangeCMMD
    oneproc_SMOOTH_0_pipeline_test
    oneproc_SMOOTH_1_pipeline_test
    oneproc_SMOOTH_1_pipeline_final_test
    -
    [ ] VID_OP_func_assert_readyToWriteLeadsWriteReq_ERRoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_func_assert_readyToReadLeadsReadReq_ERRoneproc_ProtocolVariations_1_test-
    [ ] VID_OP_rand_assert_cprop_abortWithinYYYplaceholdernameoftest-
    [ ] VID_OP_rand_assert_CMMDtoAvailableInMclocksplaceholdernameoftest-
    [D] VID_OP_rand_assert_sillyReadplaceholdernameoftest-
    [ ] VID_OP_rand_ccover_assert_abortToavailableTimeplaceholdernameoftest-
    [ ] VID_OP_func_cover_abortoneproc_abort_test-
    [ ] VID_OP_func_self_CORRearlyDoneOnArg1matchoneproc_CORR_1_single_test-
    [ ] VID_OP_func_self_CORRmatchoneproc_CORR_0_single_test
    oneproc_CORR_1_single_test
    -
    [ ] VID_OP_func_self_NOPdoesNotChangeDataRecordoneproc_NOP_test-
    [ ] VID_OP_func_self_BadCMMDoneproc_BADCMMD_test-
    [D] VID_OP_func_self_writeWithoutLoad-
    [D] VID_OP_func_self_writeWithoutLoad_ERR-
    [D] VID_OP_func_self_loadWritesInParts-
    [D] VID_OP_func_self_loadWithoutWrite-
    [ ] VID_OP_rand_self_pipelineplaceholdernameoftest-
    HWSP level tests
    [l] VID_SP_func_assert_abortDeassertBeforeIdle_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_getLoadModeIsSet_ERRplaceholdernameoftest
    [D] VID_SP_func_assert_readB4OKandReady_ERRplaceholdernameoftest
    [D] VID_SP_func_assert_readReqWithdrawnAfterReadyToRead_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_readyToReadMoreThanYclocks_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_readyToWriteMoreThanXclocks_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_resetDeassertNotSynchronous_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_setLoadModeNotIdle_ERRplaceholdernameoftest
    [D] VID_SP_func_assert_writeReqWithdrawnAfterReadyToWrite_ERRplaceholdernameoftest
    [l] VID_SP_func_assert_frameID_wOutFollowsplaceholdernameoftest
    [l] VID_SP_func_assert_idleFollowsAbortplaceholdernameoftest
    [l] VID_SP_func_assert_idleFollowsAllProcsDoneplaceholdernameoftest
    [l] VID_SP_func_assert_normalAbortplaceholdernameoftest
    [D] VID_SP_func_assert_readReqAfterOkToReadplaceholdernameoftest
    [D] VID_SP_func_assert_readReqB4okToReadplaceholdernameoftest
    [D] VID_SP_func_assert_readReqBeforeOkToReadplaceholdernameoftest
    [l] VID_SP_func_assert_frameID_rOutFollowsplaceholdernameoftest
    [l] VID_SP_func_assert_finalBitFollowsplaceholdernameoftest
    [D] VID_SP_func_assert_readReqWithdrawnOKplaceholdernameoftest
    [l] VID_SP_func_assert_setLoadModeParallelAttemptedplaceholdernameoftest
    [l] VID_SP_func_assert_setLoadModeSerialAttemptedplaceholdernameoftest
    [D] VID_SP_func_assert_writeReqAfterOkToWriteplaceholdernameoftest
    [D] VID_SP_func_assert_writeReqB4okToWriteplaceholdernameoftest
    [D] VID_SP_func_assert_writeReqBeforeOkToWriteplaceholdernameoftest
    [D] VID_SP_func_assert_writeReqWithdrawnOKplaceholdernameoftest
    [D] VID_SP_func_assert_writeB4OKandReady_ERR
    [l] VID_SP_func_self_OoOcompletesplaceholdernameoftest
    [l] VID_SP_func_self_pipelineplaceholdernameoftest
    [l] VID_SP_rand_assert_frameID_wOutMismatch_ERRplaceholdernameoftest
    [D] VID_SP_func_assert_readyToReadLeadsReadReq_ERRplaceholdernameoftest
    [D] VID_SP_func_assert_readyToWriteLeadsWriteReq_ERRplaceholdernameoftest
    [l] VID_SP_rand_assert_cprop_abortWithinXYZplaceholdernameoftest
    [l] VID_SP_rand_assert_FillAndKeepFullplaceholdernameoftest
    [l] VID_SP_rand_assert_FillThenDrainplaceholdernameoftest
    [D] VID_SP_rand_assert_sillyReadplaceholdernameoftest
    [l] VID_SP_rand_assert_SingleComputationplaceholdernameoftest
    [l] VID_SP_rand_self_CMMDarg0onlyChangeplaceholdernameoftest
    [l] VID_SP_rand_cover_abortplaceholdernameoftest
    [l] VID_SP_rand_self_OoOcompletesplaceholdernameoftest
    [l] VID_SP_rand_self_pipelineplaceholdernameoftest
    Current tests:
  • oneproc_ProtocolVariations_1_test
  • oneproc_badProtocol_1_test
  • oneproc_NOP_test
  • oneproc_BADCMMD_test
  • oneproc_abort_test
  • oneproc_CORR_0_single_test
  • oneproc_CORR_1_single_test
  • oneproc_SMOOTH_0_single_test
  • oneproc_SMOOTH_1_single_test
  • oneproc_SMOOTH_0_pipeline_test
  • oneproc_SMOOTH_1_pipeline_test
  • oneproc_SMOOTH_1_pipeline_final_test
  • oneproc_CMMD_mix_1_test
     
     
     
    This is a work in progress