Team:BostonU HW/Improve

BostonU_HW

Improve
Improving on Neptune

Improving Upon the 2016 BostonU HW Project: Neptune

During the course of our 2017 iGEM Project, the BostonU HW team worked to improve upon the 2016 BostonU HW Project: Neptune. Neptune allow uses to specify, design, and control a microfluidic chip. For more information regarding specific elements within Neptune, please refer to their wiki. Our team worked to improve the specify and design portion of the Neptune software workflow. This Neptune can be broken down into five basic blocks:


The portion of Neptune’s workflow we contributed to was Fluigi. Fluigi is a place-and-route software that receives a detailed microfluidic description in the form of MINT code, and outputs a fully routed chip design with accompanying SVG and JSON files. During the process of our iGEM project, 17 distinct microfluidic chip designs were coded in MINT and routed using Fluigi. These chips ranged from designs replicated from various journals to original designs for the MARS Repository. While designing and routing these chips we were able to identify issues, limitations, and areas for improvement in the Fluigi and Neptune software system. These issues were identified as elements of Fluigi to fix or improve upon. During the course of our 2017 iGEM project, we altered design rules that would be necessary to integrate into the layout algorithms, some of them in particular are:

  1. Ports are no longer automatically pushed to the edges of a design. When manufacturing a chip using photolithography ports must be at the edges of the chip. However, when using the Makerfluidics workflow this is no longer a requirement; ports can be located anywhere on a chip, within reason. In fact, many designs benefit from or rely on ports being placed in nontraditional locations. Therefore, the pre-existing design rule that ports must be pushed to the edges of a chip needed to be updated. Instead of automatically pushing all ports to the edges of a design, Fluigi can now infer whether or not doing so would be beneficial/required. Thus, the design rule was updated to be more relaxed and accurate for the Makerfluidics workflow.
  2. Primitive locations can be set in the X and/or Y direction. When designing a chip using Fluigi’s place and route system, primitives are defined by the user but the location and connections of these elements of these primitives are determined by Fluigi’s place and route system. However, for some designs the location of primitives must be in specific locations. Fluigi contains a function that allows primitives to be locked in place, the set function, however this function requires both an X and Y coordinate. For some designs, only one of these coordinates is known or required. To accommodate this, Fluigi’s pre-existing “set” design rules was updated to allow the user to set a primitive’s X coordinate, Y coordinate, or both. This updated design rule made the “set” function more practical to use.
  3. Subtle routing changes were added to make designs more practical and functional. Fluigi’s place and route system is effective at connecting primitives with channels, however, it did not always make these connections in the most practical or functional ways. For example, random bends or “kinks” would sometimes be added to channels during the routing process. While a chip with random bends is still a valid design, it may not necessarily be practical as these bends may affect fluid flow. Fluigi’s design rules regarding bend tolerance have been progressively increase over time, thus limiting the amount of unnecessary bends that can be added to a design.

The impact of these improved design rules can be seen in the two Fluigi-routed chips below. On the left is an output design for eColiBasic5. This chip was designed and routed prior to many of these improvements being implemented. While this chip represents a valid design, it is not optimized or practical due to bends and port location issues. On the right is an output design for eColiBasic6 following the implementation of the previously identified improvements. The MINT code for these two microfluidic chips is nearly identical, but the outputs are entirely different. eColiBasic6 is a cleaner, more practical and functional design that can be manufactured and tested.


eColiBasic5

This chip was designed and routed in an earlier version of Fluigi in which the design rules had not been updated.
This output is not ideal as it has many unnecessary bends make the design impractical for real life usage. Fluigi's design rule limitations also made it so that elements of the final design could not be included, such as properly connected ports in the middle of the device.

eColiBasic6

This chip was designed and routed in an improved version of Fluigi in which the updated design rules had been implemented.
This output is much cleaner, having significantly less unnecessary kinks and bends, and includes portions of the chip design not previously possible; for example, two ports were placed and routed in locations not previously possible in earlier iterations due to ports being pushed to the edge.




Besides these software improvements and updates, our 2017 work with Fluigi and Neptune brought other issues and suggestions to light as well. Many of these will be implemented in future iterations of Fluigi. A short list of these can be seen below.

Issues
  1. Bend penalties are not clearly characterized
  2. Random “kinks” will be added to straight channel connections
  3. Channels will overlap when they are not supposed to
  4. Primitives will overlap when they are not supposed to
  5. Nesting trees within each other leads to spacing issues

Suggestions
  1. Requiring all primitive dimensions to be evenly divisible by lambda (scaling value) so that scaling back up after routing retains exact primitive dimensions
  2. Adding the ability to reflect modules horizontally and/or vertically

Through our work on Fluigi, the 2017 BostonU HW team improved upon both Fluigi and Neptune. We identified issues and limitations associated the Fluigi place and route tool, an integral portion of the Neptune software workflow. By helping to improve Fluigi, we have also built upon the 2016 BostonU HW project Neptune.