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.
You said, "The design didn't seem to fit ID's requirements". Generally the things the Quartus handbook recommends for the incremental compilation design flow also apply to the old bottom-up LogicLock design flow.Incremental compilation and LogicLock are two separate features that are used together. Quartus had a bottom-up design flow before incremental compilation was available. For each project that compiled a portion of the design, the LogicLock region containing that portion was back annotated. A .vqm file was generated. The .vqm file was the post-fit state of the netlist with node names that matched up with the names used for the back annotated locations. Assignments were exported. All this was then imported into the project containing the top level of the design. When this project was compiled, the .vqm files had to be processed by Analysis & Synthesis before the netlist reached the Fitter again. By the time the netlist reached the Fitter in the top-level project, the node names did not always match those in the back annotations, making the back annotations not all work. For some designs, this flow worked well enough. For some designs, it didn't work at all. It might be that your problems are from the limitations of this design flow. Now that incremental compilation is available, use of this old design flow is discouraged. Incremental compilation solves the limitations of the old design flow. The post-fit netlist and locations are preserved together in a way that the lower-level netlist doesn't have to be processed by Analysis & Synthesis when compiling the top-level design. With this improved method, the node names and locations always match up in the Fitter. LogicLock is used with incremental compilation to floorplan the major blocks of hierarchy so that when one block is recompiled, the Fitter has a single area of the device allocated to that block. That is not always necessary, but it makes the Fitter's job easier than forcing the Fitter to work with small open areas scattered across the device. Feel free to set an incremental compilation design partition (with an associated LogicLock region for floorplanning, if appropriate), on a small block of the design. The Quartus handbook has guidelines, not hard rules, for this kind of thing. If you have a small block of hierarchy for which you want to preserve the performance, go ahead and put it in its own design partition. It would be best if this block followed the other design guidelines like having its inputs and outputs registered so that you are not likely to create critical timing paths when you isolate this block into its own design partition.
Well that's fine but one of the drawbacks to nearly all tool usage explanations in the Quartus 2 Handbook (and other similar Altera literature) is that it isn't enough. When you first read it it looks fine and easy but when you actually try and use it you come up way short on specific details you need to really use it. I did try to use ID at the start and got stuck for lack of procedural information with which to go further. Since there wasn't any to be had I had to conclude that the design really didn't meet ID requirements. So when I'm asking for "Detailed instructions" its because there aren't any. Yes I could spend months experimenting and figuring it out for myself but YOU can try and explain my time usage to my boss.So you feel I should give ID another try? Well come up with some good tool usage instructions and a couple or few real good examples and I'll be happy to.
BobF:Why do you want to use ID and/or logic lock? Are you running into timing violations? If you are targeting a 2S60 and you are using about 40% of the resources, your compile/synthesize times should be quite reasonable. I've had some decent results using logic lock--but found that it really wasn't that helpful. Just letting the tool do its thing without my direction seemed to work better--especially when I used Design Space Explorer (DSE) to let it run several iterations. Cheers, Brian
Brian,It was one of the design requirements to be able to modify and/or change and /or add new logic to the design and not affect the routing or timing of that which is not changed. We do A LOT of design changes in our work. The design, at present, doesn't use any of the DSPs and only a small amount of the memory. It was forseen that these would be used in the future but it is not wanted to affect that which does work. It was the reason we chose an EP2S60 in the 1020, its more than we need now and we can go bigger in the same package. I am also having some trouble with the design meeting some of the timing. Its as though I can't add enough timing constraints. When I let the compiler run on its own it fails timing big time. I had been using DSE but sometimes I get better results without it. Its become a real mixed bag, most frustrating. Functionally everything is perfect and I design with provisions for slack in mind but I've appeared to run into a brick wall. I've never had this much trouble with a design in the seventeen years I've been doing this. All of my attempts to get assistance from Altera have come up empty so I'm reaching out elsewhere.
--- Quote Start --- I've had some decent results using logic lock--but found that it really wasn't that helpful. Just letting the tool do its thing without my direction seemed to work better--especially when I used Design Space Explorer (DSE) to let it run several iterations. --- Quote End --- That sounds like a comment about using LogicLock to improve performance. On most designs, LogicLock does not improve performance. Given everything else about the state of the design (the source files and the other Quartus settings being used), the Fitter usually provides the best results that can be expected. If you investigate timing violations thoroughly enough, you see that a LogicLock constraint would not result in a better placement for the failing paths even if at first it appears that LogicLock should help. For designs where LogicLock does help with performance, you need to know what you're doing to use it effectively. You can easily make results worse with LogicLock. For a bottom-up design flow regardless of incremental compilation and for LogicLock used in conjunction with incremental compilation, the appropriate use of LogicLock is to floorplan major blocks of hierarchy. A good floorplan is neutral for its effect on performance. Sometimes a LogicLock floorplan helps performance, but that is the exception. Even for its floorplanning use, LogicLock can hurt performance if used incorrectly or if the design is not architected to make the region-to-region paths not be timing critical. For BobF's application involving performance preservation and compile-time reduction, floorplanning is an appropriate use of LogicLock for either the old design flow (regardless of that design flow's other limitations) or incremental compilation.
--- Quote Start --- I am also having some trouble with the design meeting some of the timing. Its as though I can't add enough timing constraints. When I let the compiler run on its own it fails timing big time. I had been using DSE but sometimes I get better results without it. --- Quote End --- Even if you've been using Quartus a long time, it might be helpful to check whether you've overlooked some basic settings for performance. Start with "Tools --> Advisors --> Timing Optimization Advisor --> Maximum Frequency (fmax)" in Quartus. The Advisor doesn't cover everything, but I often use it to make sure I haven't forgotten one of the usual settings appropriate to get the best possible push-button performance. If none of the recommendations in the Advisor solve your performance problem, then refer to the Quartus handbook in Volume 2, Section III, Chapter 8 "Area and Timing Optimization". I use DSE often for seed sweeps but don't use it anymore for its other kinds of explorations. I start with turning on all the usual settings like physical synthesis with extra effort to get the best possible push-button performance. Then I run a seed sweep to get the random variation for the design so that I will have some basis to judge whether a different result when I change something is clearly because of what I changed or possibly just a random difference. If a seed sweep consistently has timing violations when using the usual settings to maximize push-button performance, most likely a design change like adding a pipeline stage is needed. As I said in my previous post, most designs don't benefit from manual placement optimization with LogicLock to improve performance. If I consistently get positive margin, then I might try backing off on the settings that cost significant compile time. A benefit of either the old bottom-up flow or incremental compilation is that the compile-time-intensive optimizations, especially physical synthesis, don't have to be used on the entire design just because a portion of the design needs them. Floorplanning with LogicLock (with or without incremental compilation) might help performance on your design because your utilization of logic resources is low. The Fitter's algorithms are optimized for typically full designs. That sometimes results in designs with light logic resource utilization getting spread out too much. In that case, a LogicLock region for a block of hierarchy can be helpful for performance.
Brad,Thanks but thats not my issue. I can make timing, very well, in the lower level functions but moving those results into the top level function is not working. Now from what I received via an SR this morning and from your feedback is that using back annotation -> exporting and then importing into the top level design no longer works. (Even though thats whats in the Q2 Handbook for version 7.0). Is that true? If it is, what is the correct procedure for this now?
I'd add that if you are using the 7.0 version of the documentation, the LogicLock methodology is documented, as you said. But in 7.1, the handbook chapters were changed to explain things better. Now the documentation talks about using LogicLock regions to direct placement to a specific part of the chip, but not as a "methodology" to save results. It's covered in the chapter Analyzing and Optimizing the Design Floorplan (http://www/literature/hb/qts/qts_qii52006.pdf). The Incremental Compilation feature is what you'll be using to lock down placement and routing of specific parts of your design, so that's the chapter that will include the detailed instructions. Check out the Recommended Design Flows and Application Examples towards the end of the chapter: Quartus II Incremental Compilation for Hierarchical & Team-Based Design, http://www/literature/hb/qts/qts_qii51015.pdf (pg 57 in the 7.1 version of the doc). The examples should give you some idea of the scenarios where incremental flows would help preserve your results and reduce yoru compilation time.
QII 7.0 still has the LogicLock back annotation, .vqm generation, and setting export required for the old bottom-up design flow. I expect that the old flow works as well in 7.0 as it ever did. As I said in my first post, for some designs and maybe for BobF's in particular, that's not very well at all.
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?
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.
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.
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.
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.
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...
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.
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.
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.