anchor.diff:  
   Here we have a single ARM debug system and physical port and only one transaction at a time
   can be handled.
  -To make our transaction methods concurrent-ready they should be modified like this:
  +To make our transaction methods should be modified like this to make them concurrent-ready:
   
   ~~~ruby
   def read_register(reg, options={})
  
positive.code: ip2:  __▄███████████████████████████████████████████████████████████████████████████████▄__________________________
  ~~~
  
  ### Programming Concurrent Sequences
  
  
  ### Reserving Serial Resources
  
  
  
  
  		○ A concurrent pattern is called a pattern sequence in Origen, and a single threaded sequence is created almost exactly like a standard pattern is (and this would generate the same output as the equivalent standard pattern):
  
  		Pattern.sequence do |seq|
  		  # Perform some test on IP1
  		  dut.ip1.do_something
  		end
  			
  		○ However, we now have access to the sequencer which allows concurrency to be programmed very easily:
  
  		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
  			# Use the exact same code as you would use in a regular pattern
  			dut.ip1.do_something
  		  end
  		
  		  # Now start another thread to test a second IP in parallel
  		  seq.in_parallel :ip2 do
  		    dut.ip2.do_something_else
  		  end
  	    end
  
  		○ The sequencer also allows whole standard patterns to be called in-line (seq.run "some_pattern"), allowing IP-level patterns to be developed and debugged standalone, then sequenced into a concurrent pattern with other standard patterns. The generate command is also being updated to support this common use case without having to even create a dedicated sequence file: origen g pat1 pat2 pat3 --sequence my_sequence
  		○ APIs are provided to allow applications to serialize access to resources which should only be accessed by one thread at a time - e.g. a comms interface or an ADC for embedded measurements. It is envisaged that plugins will be updated to use these APIs to make them concurrent-ready in due course, and therefore typical applications will not need to do anything special to enable concurrency in the future.
  	
  	          def measure_voltage
  	      # This will block concurrent threads, allowing only one at a time
  	      # to execute this, while being ignored when generating a regular
  	      # pattern. :adc is just an identifier for this resource, and the
  	      # same ID should be used to block off access to the same resource
  	      # in other places.
  	      PatSeq.serialize :adc do
  	        dut.adc.do_something
  	      end
  	    end
  
  
  % end
  
negative.code: ~~~
  
  Note that Origen does not automatically serialize access to the read/write register methods
  since some applications may choose to use different ports/protocols depending on what register/IP is being
  targeted and therefore enforcing serialization at the read/write-register-method-level may not be
  desired in all cases.
  
  Exactly the same `PatSeq.serialize` wrapper should be added to any other methods which 
  utilize a single silicon resource which may be used by multiple concurrent threads. Here is another
  example of where a method exists to use an on-chip ADC to perform an embedded measurement:
  
  ~~~ruby
  def measure_voltage
    # This will block concurrent threads, allowing only one at a time to execute this, while being ignored when
    # generating a regular pattern. Again, :adc is just an identifier for this resource, and the same ID should
    # to this same resource in other places where it is used.
    PatSeq.serialize :adc do
      dut.adc.do_something
    end
  end
  ~~~
  
  ### Creating Concurrent Sequences
  
  Once your application has been made concurrent-ready by adding the necessary serialization points, the
  simplest way to create a concurrent pattern is to generate two or more existing patterns into a
  combined concurrent pattern.
  
  For example, say that we have two existing patterns called `ip1_test.rb` and `ip2_test.rb`, these
  could be generated as two separate patterns like this:
  
  ~~~text
  origen g ip1_test ip2_test
  ~~~
  
  To generate them as a concurrent pattern, what Origen calls a pattern sequence, then simply add the
  `--seq(uence)` option and give a name for the concurrent output pattern:
  
  ~~~text
  origen g ip1_test ip2_test --seq my_concurrent_pattern
  ~~~
  
  This approach to concurrency provides the key benefit that IP-level tests can be
  developed and validated on silicon as standalone patterns, and then once everything is working they can be
  re-generated into a concurrent version for production test time saving.
  
  After the concurrent sequence has been generated, Origen will provide a concurrency execution
  profile like the one shown below to give an indication of how efficient the combined pattern is.
  This shows the execution time profile of the final pattern on the ATE, so in this example we have a pattern
  which will take just over 40ms to execute, and we can see that the overall test time is driven by the
  test on IP1 and that the testing we are doing on IP2 comfortably fits within that.
  
  In this diagram an empty time interval means that no activity was taking place - which could mean that
  either the thread was finished or it was completely blocked while waiting to access a serialized resource.
  A half-block means that it was active for < 50% of that time interval and a full block means that it
  was active for > 50% of the given interval.
  
  ~~~text
        |-------------------------|-------------------------|-------------------------|-------------------------|----
  