Preserving WYSIWYG LUT input assignments

[Altera_Forum]

I am working on a Stratix III design in which I need to very precisely control delay paths on some outputs from my design. In a previous version of my design, I hand instantiated WYSIWYG cells and used routing constraints to achieve this. (I do this for just a few critical cells at the output of my design - less than 1% of the total design.) 

 I am following the same methodology on the design update, except that now Quartus wants to remap (rotate) the inputs of my hand instantiated combinatorial WYSIWYG LCELLs. For instance, I have a 2-1 mux in which my HDL uses the dataa and datab LUT inputs for the input data and dataf for for the select. After I compile the design and analyze it in TimeQuest, I can see that while the function of the LCELL has been preserved, it is now implemented with datac and datae as the data inputs and datab as the select.  Does anyone know how to keep Quartus from remapping the inputs of WYSIWYG LCELLs?  Thanks, Jeff

[Altera_Forum]

The actual inputs used are a function of the router. That being said, the routing variation is usually larger than the variation of inputs through the LUT, so unless you lock down the routing, I don't think just locking the LUT inputs will work. Make a copy of your design and go to Assignments -> Back-Annotate and lock everything down to the routing level. The syntax of the .rcf is pretty good, and it supports wildcards, so you might be able to pull out the routes you need. 

Note that the .rcf does not drive placement, i.e. if the placer doesn't put a LUT in the right spot, the .rcf is useless, so you'll need the placement assignments for the nodes you're working on in conjunction with the .rcf. How tight of control do you need? Have you tried timing constraints to drive it? The nice thing is that the fitter has the D5 and D6 delay chains to help dial in a value. Also, you could just lock everything down and manually assign D5 and D6 yourself. What you're trying to do is very difficult. Besides fine-grained control, you need to work with and understand the fitter, the timing models, etc. Good luck.

[Altera_Forum]

I realize that I will need to control both the routing and the LUT inputs to have any chance of meeting my target, which is path lengths that are matched to within about 100ps. In the previous generation of this design, I first locked down the LUTs and then used the back-annotation results to control placement and coax the router into using identical types of routing between the cells. In that case (Stratix I) I was able to match path lengths to within about 200ps. 

 Since I haven't yet placed any routing constraints on the design, I'm not sure why the fitter is ignoring my specified inputs on the WYSIWYG cells. These are in a reserved LogicLock region that has very low utilization (less than 20% of the ALMs). Given that each ALM only has 3 inputs and one output I would expect the routing density to be very low as well. I know that, even so, by constraining the LUT inputs I can create a non-routable design, but it seems to me that the fitter isn't even trying to preserve the LUT input assignments since about 90% of them are getting remapped.  Any ideas on how to get the fitter to stop doing this remapping?  Jeff

[Altera_Forum]

That's the thing, it's not trying at all. The WYSIWYG LCELLs only map the functionality, not the path used. The router can do whatever it wants. (Third party synthesis tools map everything to WYSIWYG primitives. They label them "blindly", and if the router had to follow those mappings, designs would quickly become unroutable.) I don't know of any controller way to do this beside an .rcf.

[Altera_Forum]

Oh, and depending how you do timing constraints, note that you won't get 100ps variation. Stratix III models on-die variation, so the exact same path in the same corner has a "fast" and "slow" sub-model. So if you use timing constraints like setup and hold, or skew, you'll see a lot more variation. It's not that it's necessarily larger in hardware, but Stratix I didn't model that.

[Altera_Forum]

I previously came across the arbitrary router changes to WYSIWYG LUT input assignments. http://www.alteraforum.com/forum/showthread.php?t=27284  

My conclusion had been, that the inputs don't have full symmetrical routing capability and that's effectively impossible to implement a low level design with input connections at will.  The other explanation would be, that Quartus just isn't prepared to observe low level user assignments and doesn't try to utilize the existing routing capabilities as far as possible.    --- Quote Start ---  That's the thing, it's not trying at all.  --- Quote End ---   I agree that the second explanation sounds plausible. But in either case, the consequences are similar: There's no effective way to control the selection of LUT inputs than precise and tight timing constraints.

[Altera_Forum]

The WYSIWYG primitives really only control the synthesis of the LUT, not the input usage. 99% of the time that's what you want, since you don't want synthesis forcing specific LUT usage when it has no idea how it's going to place/route. (Remember that WYSIWYG are used by 3rd party synthesis, and probably internally). Forcing specific input usage would greatly restrict routability and hurt timing. 

In essence, there would need to be two WYSIWYG primitives, one that has fixed inputs or one that lets them rotate(actually, an attribute would make more sense, but there isn't one). In general, it makes sense to control this in the router .rcf, since fixing the inputs without fixing the routes is usually pretty useless. The router has more variation than the path through the LUT. Note that you can wildcard the .rcf a lot. Here's some examples:   A global routing can be input to Quartus as an .rcf file where only the channels to be used to complete the router are specified. This is done by using wildcarding, choice and the zero_or_more keyword to allow Quartus to choose the type and number of wires in each channel. For example:  signal_name = Input3 {  IO_DATAIN:*;  zero_or_more, R4:X*Y30* || R8:X*Y30* || R24:X*Y30*; # (1) zero_or_more, C4:X7* || C8:X7* || C16:X7*; # (2)  LOCAL_INTERCONNECT:*;  dest = ( nor3, DATAA ); }  The RCF fragment above indicates we desire a route that uses as many horizontal wires in the Y = 30 channel as necessary, and then as many vertical wires in the X = 7 channel as necessary. Any set of wires that matches these constraints is acceptable.   Note that lines (1) and (2) can be re-written in more compact but slightly more general form as follows:   zero_or_more, *:X*Y30*; # (1’) zero_or_more, *:X7*; # (2’)  The only difference between (1) and (1’) is that other routing resources, besides R4, R8, and R24, will be allowed for that step.   • Wire Type Routers  A wire type router produces somewhat more detailed output than a global router. It not only says what routing channels to use, but also what type of wire to use, and potentially, how many of each type of wire. It does not specify exactly which wires should be used to implement route, however, it simply specifies their types. For example, the RCF fragment below specifies that this net should be routed using one R8 wire, followed by one C8 wire. Quartus is free to choose which R8 and which C8 wire to use.    signal_name = Input3 {  IO_DATAIN:*;  R8:*; C8:*;  LOCAL_INTERCONNECT:*;  dest = ( nor3, DATAA ); }  The example below specifies not only what types of wires to use, but also which channel each should be in.  signal_name = Input3 {  IO_DATAIN:*;  R8:X*Y30*; C8:X7*;  LOCAL_INTERCONNECT:*;  dest = ( nor3, DATAA ); }  The example below is even simpler as it allows Quartus to choose how to get in and out of the function blocks, and simply specifies the types and channels of the wires to be used between the function blocks.  signal_name = Input3 {  zero_or_more, *; # Quartus can start the route as it pleases  R8:X*_Y30*; # Must use one R8 wire in the Y=30 channel. C8:X7*; # Must use one C8 wire in the X=7 channel.  zero_or_more, *; # Quartus can end the route as it pleases.  dest = ( nor3, DATAA ); }

[Altera_Forum]

Thanks for some insights to the amazing world of routing constraint files!

[Altera_Forum]

Nice explanation. This will definitely help me in the next phase of constraining my design. Thanks!