Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

Problems using Logic Lock

To start I'm using Full Quartus 2 version 7.0 (I've been instructed by my boss not to upgrade until after the design is finished and working). I'm trying to design into a Stratix 2 EP2S60F1020I4 device.

I originally looked into and tried to start with using the Incremental Design Flow from bottom up but the design didn't seem to fit ID's requirements. So, stepping away from ID I just went with trying to Logic Lock parts of the design.

Requirements for design involving Logic Lock:

1. Preserve performance for specific high speed modules.

This I'm attempting to do by completing them and Logic Locking them in their lower

level projects and importing them into the top level.

2. Try to reduce compile times.

This is an untrue statement, what is wanted that any recompiles of the top level design

only work on those functions that have been changed and not those that haven't.

The result should be shorter compile times with design changes.

I've been trying my best to follow the Logic Locking directions given in the Quartus 2 Handbook Chapter 13: Logic Lock Design Methodology for version 7.0.

Its not working. Particularly when I import everything in I get No-fit errors where the compiler is trying to place two separate, supposedly, Logic Locked items into the exact same location. What I've been learning is that the documentation on Logic Lock is inadequate and /or in error. My last SR to Altera on this suggested I should not be back annotating. I do not see any way forward then with either Logic Lock or ID. Does any one have good information, procedures, etc. on how to use Logic Lock?

(Extremely) Detailed instructions are welcome.

Basic Design information:

The design is rather complex requiring interfacing with cameras, ADCs, DACs, Transducers, analog logic controls, very high speed transceivers and other logic.

The highest clock speed is 500MHz however this I keep to few simple functions.

I do use at least one EPLL in the design to generate three 200MHz clocks, two at 40/60

and one at 60/40 with phase shifts as required by the camera.

The transceivers, however, require an extremely low jitter clock at 125MHz which I generate from the 500MHz in logic.

All I've stated above simplifies the very unsimple design and states some of the fastest clock speeds I must deal with. It is expected that the entire design should use no more than 40% of the logic resources of this device.

There is logic running at much lower speeds and nearly all the clocks for them are generated in logic. (25MHz, 10MHz, 2MHz, 1MHZ, 100KHz, 10KHz and 2Hz)

Some of the subfunctions of the design are over 1000 LCELLs but most are not, not good for ID. The higher speed subfunctions I want to Logic Lock down their placement and routing however I do not want to lock down the slower speed functions.

EX:

The interface to the high speed transceiver(s) must run at 125MHz and requires tracking of Disparity. This needs locking down and its size is less than 300 LCELLs.

The interface to the ADCs is running at 10MHz even though its logic is making decisions based upon readings. At 10MHz this does not need to be locked down but its size is over 1100 LCELLs.

19 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Steve,

    Thanks. I am using Q2 v7.0 and have been instructed not to upgrade till after the project is completed and working. Now I had used some v7.1 documentation earlier and ran into mismatch problems so I'm not too eager to do so again.

    Also I have read v7.1 ID examples and they aren't helpful, they are extremely generic and read well for a manager but not a user. I've read most of the Altera literature on LL and ID, LL since v5.0. The hard copies in front of me are very badly dog eared. I'll review it yet again but this chapter is the problem not the solution.

    Are you just saying that the issues I'm having with v7.0 are better documented in v7.1 literature?

    OR

    Are you saying I can use the v7.1 instructions on v7.0 software?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Well... I guess I'm showing that Altera's documentation now agrees with Brad that the old LogicLock flow is not recommended any more, so you should try using incremental compilation instead. And I do think the 7.1 documentation adds a bit more, yeah.

    If you are worried about conflicts, I guess the 7.0 chapter should work OK too, if you have a dog eared version of that as well! I think it had a similar example section, and the procedural stuff should all be in there. Check out the sections "Preparing a Design...", "Compiling a Design", and then the more detailed sections on "Setting the Netlist Type" and "Creating a Floorplan" (that last one is the LogicLock region bit).

    Do you have specifics about the problems you had when you tried the incremental flow? I think in your posts you mostly discussed the problems with the LogicLock flow...? Maybe I (or Brad or some other users) can help address the incremental issues, so at least you are focusing your attention on the tool that Altera is promoting to meet your goals!

    P.S. Your goals as stated in your first post sound just like the quoted benefits of the incremental compilation feature!

    Requirements for design involving Logic Lock:

    1. Preserve performance for specific high speed modules.

    This I'm attempting to do by completing them and Logic Locking them in their lower

    level projects and importing them into the top level.

    2. Try to reduce compile times.

    This is an untrue statement, what is wanted that any recompiles of the top level design

    only work on those functions that have been changed and not those that haven't.

    The result should be shorter compile times with design changes.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Stevie,

    I've been away the last couple days.

    I'll try and review the Incremental Design documentation again this weekend. One of the first issues I remember being is the guessing of just how much logic one needs per partition when beginning an Incremental Design.

    The pinout of the FPGA was nearly complete when I started working on the design and choosing partitions correctly was not intuitive.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Sounds like a good plan. Remember that partitions are "logical" partitions of your design hierarchy. They don't specify a location on the device floorplan.

    The partition size (amount of logic per partition) is not really that important, because the tool is pretty flexible. You want to have reasonably even chunks of logic so that you'll get the compilation time savings when you change one of them. You also don't want them too small, because that will restrict cross-boundary optimization perhaps more than required to get the compilation time benefits. Just take care with the recommendations for partition boundaries, signals crossing bondaries etc. It's all in the docs.

    You might be thinking about LogicLock regions, which are physical regions that you can use to isolate placement of logic to one area of the chip. Using physical regions for each partition can help ensure good quality of results when you recompile (and of course are needed to avoid placement conflicts if you want to import an already-placed partition from another team member's Quartus II project). But creating a floorplan is not always absolutely necessary. Also there are instructions in the doc that tell you how to use Auto-Floating regions to let the fitter give you a first hit at it.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Stevie,

    Actually not a good plan. Because of the problems with LL and the# poor documentation on ID and LL I'm so far behind this project may be canned before I can get ID to work!

    My boss read this stuff over and decided that I should upgrade so now I'm in the middle of installing v7.1+.

    You asked so here's your first question:

    1. I have a number of small functions that must be placed and Locked into their locations.

    They occupy from less than one LAB to up to four LABs. They run at 500MHz and my experience so far has been that if I don't Lock them and their routing down the Q2 compiler at the Top Level WILL mess them up.

    How do I deal with these functions in the ID methodology?

    To help in understanding this here's some more info;

    Two of these functions are critical and both run at 500MHz. Both generate outputs that will be Globals to ALL of the other logic. One function generates a pair of Global Reset signals shortly after FPGA configuration. The second generates two Global Clocks from the 500MHz input clock, 250MHz and 125MHz. The 500MHz is an ultra stable LVDS clock input and the 250MHz and 125MHz, particularly the 125MHz, MUST be ultra stable as well for the high speed serial transceiver devices. So PLLs are no good for these two clocks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Sounds like quite a project. OK, I'll save you the warnings about driving a clock with outputs of logic, because I'm sure you must have heard them before... Some issues are covered in http://www.alteraforum.com/forum/showthread.php?t=754. Don't assume the clock skew isn’t an issue... And try to avoid paths that cross between the clock domains as much as possible, etc etc.

    To optimize your blocks with incremental compilation, you can use a bottom-up flow where they are each defined in separate Quartus II projects, or you can include them as part of a top-level project where everything is partitioned and set the rest of your design blocks with a Netlist Type of Empty while you optimize the small blocks. The top-down flow is somewhat "easier" as you have only one QII project. The two flows should be explained OK in the docs. Create Partitions, set Netlist Types, compile. I suggest you post here or file an Altera mysupport SR if you have *specific* questions that come up.

    When partitioning the rest of the design, check out the guidelines in the handbook about registered boundaries, cross-partition paths etc. Also there are a few restrictions that hopefully won't aply, but I think they are all in the chapter too.

    To control the blocks placement, you can assign them to small LogicLock regions before you compile or after you see the first fitter-chosen result. Use Auto-Floating regions for the first round, or set it to your desired size. If the Fitter doesn't do exactly what you want with them, you can use the Chip Planner and Resource Property Editor to move nodes around in the floorplan. This is instead of trying to back-annotate the assignments and then changing the assignments manually.

    Once you have the fitting you want, whether you used LogicLock regions with Resource Property Editor or the Fitter found a good solution the first time through, set the Netlist Type to Post-fit and the Fitter preservation Level to Placement & Routing (assuming you want the routing as well) for the partition. This will tell the Fitter to re-use the database netlist next time so you get the same P&R results.

    Assuming the top-down (one project) flow: Then you can set the other partitions from Empty to Source File and compile with the logic from those partitions while your small blocks are fixed in the device.

    That's the basic overview. Hope it helps! Gotta go...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I only have a couple minutes now, but have had similar problems.

    For small sections of High speed logic associted with a fixed resource, like a pin, I have had success from a very simple technique of opening the timing closure floor planner and drag-N-Drop the registers of that logic into the LAB next to the pins. I get an identical fit every run, same placement and same timing slack numbers. It isn't a proof, but performance is retained. That's what I needed. There are less GUI ways, but I like the shortest path.

    For a large heirarchical design where the lower levels individually fit and ran at speed, but when everything gets thrown into the pot the route gets horked: That happened to me on a DSP related project, and I learned the significance of registered boundaries to functional blocks. It is a style, but it saved my ... skin. And, there is rarely a reason to not have that emphasis.

    I know I'm not expanding any documentation, but if either of my it worked for me ideas help, it was worth starting the weekend at 5:05 instead of 4:55.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Stevie and Randall,

    Randall first;

    Did that once, God help you on a design change. Yes it can work but;

    1. Your locations for that logic are frozen to those LCELL locations in the project. If you change the design or drop that part of the design from the overall project those locked LCELLs will remain there no matter what. I have a coworker who does that all the time, the only way to remove or change the logic is by scragging the project back to source and starting again. Very dangerous and extremely limiting.

    Also it wasn't the logic placement that the compiler messed up but the routing. My 250MHz clock is/was a simple toggle flip-flop clocked at 500MHz. When selected to make the output a Global clock the compiler routed the toggle feedback first to the Global then back to the register. The result was a 125MHz clock due to delays. To fix it I fed the output of the toggle flip-flop to into another d-flip-flop and clocked it at 500MHz. Its output was to be the Global clock. The compiler decide I didn't need the second d-flip-flop and removed it. The result was the same 125MHz as before The fix was to set Preserve Register in the assignment editor for both flip-flops.

    Stevie,

    1. I don't get those skew clock or other warnings in my logic generated clock designs. I do declare the generated clocks as such in the Assignment Settings and Set them as Globals in the Assignment Editor. I follow all the steps and get them recognized as clock signals without issues.

    2. I'm going to start a new thread I'll cal Designing with Incremental Design? I've read the v7.1 chapter on ID and find it a good piece of non-technical sales literature.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thank you for your best wishes. I am fortunate enough to have not misused the Altera tools like you described and have not encountered runaway assignments you warned about. None the less I will be mindfull of your advice.