search

byuccl / rs-cad

CAD Tools (Packer, Placer, & Router) for RapidSmith2.
3 stars 1 forks source link

Pass-through fixes (mcmlFix) #28

Closed nelsobe closed 5 years ago

nelsobe commented 5 years ago

Added code to fix two pass-through (route-through) issues that were preventing mcml and cholesky_mc from completing:

  1. CARRY4: special casing for the A56LUT, CYINIT, and AX pin. When A6LUT is occupied by a LUT6 cell then the ALUT cannot be shared between the S[0] and DI[0] functions. If the AX pin is being used for CYINIT then there is a problem. This fixes that by adding additional pass-through LUTs.

  2. CARRY4: when both the CO[k] and O[k] pins drive non-flip flop signals then there is a *OUTMUX conflict. Added code to add latch pass-throughs to fix.

trharoldsen commented 5 years ago

For the A le C4 inputs, there are 2 areas of concern I believe. All of them are only relevant for the A LE when the AX pin is required for the CIN pin.

  1. If either the S or DI pin sources are not LUTs, a RT needs to be inserted for both the S and DI sources.
  2. If the number of nets going to the S and DI LUT sources is more than 5, a RT needs to be inserted for both sources.

As for determining if the CIN pin is needed, I have some code that does that calculation in the save X pin for CIN (or something like that) pack rule that could be reused.

nelsobe commented 5 years ago

1 is what this fix is intended to handle. But, I don't think there is code to handle issue #2.

Related question: does issue #2 exist for all the ABCD positions as well? Does the rest of the code handle this kind of pin counting?

Related question #2: does the code yet handle the needed pin reordering and tying A6 to VCC for when a LUT is fractured and shared?

nelsobe commented 5 years ago

The logic for pass-throughs in the DI[0] position has been modifed to respond to comment above of @trharoldsen . Now, if more than 5 unique signals drive the LUTs feeding the DI[0] and S[0] pins, pass-throughs will be inserted. It turns out the need for this is pretty rare - only happens twice in all the benchmarks thus far.

The FF pass-through code on the output side has not been modified since the previous commits to this branch - it seems to be working well. The case of needing this is quite common in the benchmarks.

Outstanding question: is counting nets like this sufficient here - does the rest of the code handle fracturing the luts and reordering the pins appropriately?