anchor.diff:  have to be managed by Origen to prevent collisions when multiple concurrent pattern threads
   try to access the same resources at the same time.
   The most common of these as discussed above will be the communications port, but on-chip
  -parametric measurement systems and pins over which external references are provided
  +parametric measurement systems and pins over which external references are supplied
   could be other common considerations.
   
   Once these resources have been identified, some minor markup should be added to your application
  -to make Origen aware of the places that it must serialize access.
  +to make Origen aware of the places that it must serialize thread access.
   
   For example, consider that we have the following register transaction methods implemented in
   our top-level controller:
  
positive.code: ~~~
  
  Note that Origen does not automatically serialize access to the read/write register methods
  since some applications may choose to use different ports depending on what register/IP is being
  targeted.
  
  Exactly the same `PatSeq.serialize` wrapper should be added to any other methods which 
  
  
  ### Creating Concurrent Sequences
  
  When 
  
  In this case Origen will automatically apply only a single pattern startup/shutdown 
  
  ~~~text
        |-------------------------|-------------------------|-------------------------|-------------------------|----
  
negative.code: ip2:  __▄███████████████████████████████████████████████████████████████████████████████▄__________________________
  ~~~
  
  All patterns always have a main thread and when generating a concurrent pattern like this it never
  does very much. Most of the activity will occur in the threads that have been created to generate
  each of the individual patterns that are included in the sequence.
  
  Note that any arguments passed to `Pattern.create` by the individual patterns will be ignored
  when generating a concurrent sequence like this. If your application uses
  [startup and shutdown callbacks](<%= path "guides/misc/callbacks/#Pattern_Generation" %>)
  then those will be called only once and any activity from those will be in the main thread as
  shown at the start of the above example.
  
  If you need more control over this then a dedicated source file should be setup for the concurrent
  pattern as discussed in the next section.
  
  ### Programming Concurrent Sequences
  
  To have more control over the options that you would like to pass to your startup/shutdown methods or
  to create dedicated concurrent patterns which don't have conventional pattern equivalents, then
  it is possible to create pattern sources files which define a concurrent test sequence.
  
  Test sequence source files should be created in the conventional pattern directory, but internally
  they should call `Pattern.sequence` instead of `Pattern.create` as shown below:
  
  ~~~ruby
  Pattern.sequence do |seq|
  
  end
  ~~~
  
  Any options passed into `Pattern.sequence` will be passed into your startup/shutdown in the same
  way as per conventional patterns.
  
  In fact, conventional patterns can be written as conventional patterns if you want to, these will
  generate identical output patterns:
  
  ~~~ruby
  Pattern.create do
    dut.ip1.do_something
  end
  
  Pattern.sequence do |seq|
    dut.ip1.do_something
  end
  ~~~
  
  The sequencer option that is passed into the main block allows other pattern sources to be run. This
  next example will look for pattern sources called `ip1_test` and `ip2_test` and generate them to
  run sequentially within a single pattern. So aside from concurrency, pattern sequences can also be
  used to compose sequential patterns which are comprised of multiple conventional patterns.
  
  ~~~ruby
  Pattern.sequence do |seq|
    seq.run :ip1_test
    seq.run :ip2_test
  end
  ~~~
  
  To make these run concurrently we need to create parallel threads to run them in, and in fact
  this is exactly equivalent to what Origen will do when generating multiple patterns with the
  `--sequence` option:
  
  ~~~ruby
  Pattern.sequence do |seq|
    # Start a concurrent thread, :ip1 is just a name here to identify this thread,
    # it can be called anything
    seq.in_parallel :ip1 do
      seq.run :ip1_test
    end
  
    # Start another parallel thread, note that since the above has created a parallel thread,
    # it will not block the main thread's execution of this sequence, meaning that both of these
    # threads are effectively launched at the same time
    seq.in_parallel :ip2 do
      seq.run :ip2_test
    end
  end
  ~~~
  
  
  
  
  
  ### Reserving Serial Resources
  
  
  
  
  
  
  % end
  