List view

• Ability to layout disconnected devices

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to automatically assign pins for each component

  When the connections are not defined, Fluigi should be able to assign the closest pin

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to place and route with just JSON descriptions

  This means that it would have a JSON parser and create MINT equivalent microfluidic devices from them.

  No due date
  0% complete0 open0 closed

• Ability to reuse older/completed layouts

  This functionality would enable the layout algorithm to see placements of similar netlists and adapt the placement for the new device (thus allowing knowledge based layout in the future).

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to individually place and route

  This would allow only some components, connections to be used placed and routed. This would also allow disconnected devices to be placed and routed.

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to import 3DuF designs

  Have the `IMPORT` work with the designs generated in 3DuF. This would require the following in 3DuF: 1. Ability to create terminals where the channels would connect 2. Ability to automatically determine the dimensions

  No due date

  •0/2 issues closed
  0% complete2 open0 closed

• Ability to work with non-planar layouts

  Most microfluidic designs require planar layouts. In case non-planar layouts are added we need to be able to handle them and do the routing in a manner such that we there are no issues.

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to accept layout constraints

  The Microfluidic device model should reflect the layout constraints given by MINT and should also have a general datastructure and methods that will allow them to be generated programmatically.

  No due date

  •0/3 issues closed
  0% complete3 open0 closed

• Ability to instantiate valves and grover valves in the same manner

  Regardless of what kind of a valve is used, the MINT syntax should always be `VALVE x on channel1; ` or `3DVALVE x on channel1; ` TODO: 1. Syntax which treats 3DVALVE like a module must be phased out 2. The method for channel generation should change so as to break the path and insert the valves while maintaining that the same valves are being used.

  No due date

  •0/3 issues closed
  0% complete3 open0 closed

• Ability to extend DRC by adding new rules

  Need to rework the entire DRC architecture to only work on the final features that are generated and also be able to easily extend the rules that would be used to verify the chip design. Ideally this would include a mechanism that would allow designer to generate rule scripts that would be used to extend the DRC capability without having to write code. The current DRC accepts very few rules and basically drives the entire algorithm. We need to have a more comprehensive DRC and make that work at different levels of abstraction. Levels: Technology – wire width, spacing, component/feature spacing Functional – TBD Microfluidic Functionality Design Methodology – Clustering , hierarchy depth, etc. in Analog VLSI. Commercial – Number of layers, chip area The technology levels themselves will have multiple levels of DRC that need to be run.

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to abstract layers for manufacturing

  Given a layout / netlist which only has functional (logical) layers, we need to be able to arbitrarily generate custom 2D/3D planes based on how it will be manufactured. Thereby we need to divorce logical layers from manufacturing layers.

  No due date

  •0/2 issues closed
  0% complete2 open0 closed

• Ability to have n layers

  MINT currently cannot handle more than 1 functional layer block, this would have be increased and processed based on the total number of layers. In addition to this when placing new layers, it should import layout constraints from the layers that have already been placed.

  No due date

  •0/2 issues closed
  0% complete2 open0 closed

• Ability to enumerate collections of components

  For statements like GRID and BANK. The placement should treat it like a single block but the output device model should fully enumerate the components. Eg. `BANK b1 of CELL TRAP 1 to 8;` should generate `b1_1 , b1_2, .... b1_8`

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Ability to treat channel composites differently

  Whenever modules that only incorporate channels like FAN, TREE and Rotary are encountered, there should special considerations for the routing and additional steps for the DRC.

  No due date
  0% complete0 open0 closed

• Ability to generate different layout problems

  For a given unconstrained design, the algorithm should be able to generate a variation of possible constraints that it can apply for the design and do the layout based on those constraints.

  No due date
  0% complete0 open0 closed

• Ability to include different place and route algorithms

  This means a standard interface is available that converts a device description to the form that is used by the algorithm.

  No due date

  •0/6 issues closed
  0% complete6 open0 closed

• Ability to have user definable primitives

  The tool should be able to read the JSON technology file that is associated with the primitive and draw the design based on that.

  No due date

  •2/2 issues closed
  100% complete0 open2 closed

• Ability to have rip-n-reoute strategies

  In case a routing fails, or causes collisions we need to be able reroute the channel again.

  No due date

  •0/4 issues closed
  0% complete4 open0 closed