anchor.diff:  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
   
   
   
   
  -		○ 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
  
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: 
  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 should be modified like this to make them concurrent-ready:
  
  ~~~ruby
  def read_register(reg, options={})
  