Honored Contributor
Honored ContributorThanks for your ideas and comments, Stevie (and Brad).
I downloaded, printed and read the document about "primitives" that you mentioned. Though I still feel like I was reading greek-to-me, I nonetheless believe I correctly understood one aspect of the document. And that is, the conceptual and design philosophy appears to be exactly backwards [from what I want to see]! Specifically, I keep reading how these various pieces impose/create/force "divisions" or "boundaries" in the design. Therefore, they appear to be an appropriate design tool for developers who want to be able to say "now listen, Quartus2, you must not combine anything before this LUT_INPUT or after this LUT_OUTPUT into a LE/LUT/LAB". This is exactly 100% opposite of what I want. I want to say, "now listen, Quartus2, you must combine all the following logic elements into one LE/LAB" (unless I wrongly assume you can implement this functionality in one LE/LAB - in which case you should generate an error to inform me of my ignorance of the nature of LEs or LABs). To me, the neandrathal designer, the ability to force a set of logic and register-capture to combine into one physical device element is infinitely more important than the opposite that all the components and techniques I see in the documentation (and you point me to). Why on earth would I want to prevent logic from being combined together to become faster and smaller? Perhaps I might want to prevent Quartus2 from combining *this* set of logic together with *wrong* sets of logic. But these "boundary" components and techniques prevent "this" set of logic from merging with *any* other logic, including the logic I want or need it to combine with. Sorry, but I consider that a perposterous solution to my problem, which is "how do I make sure these sets of logic become combined into one unit, the way I want them to?". I can think of one possible reason that I very much hope is not true (but I think I'm beginning to smell a "rat" of some kind). Altera thinks that we [most sucker engineers] will pay for whatever speed part Quartus2 tells us we must. And they know one way to artificially increase the number of designs that require faster parts is - to limit the number of ways designers can make sure the critical parts of their designs are implemented efficiently. And "efficiently" in FPGAs means "carefully organize the circuit design so the critical speed path is implemented in a way that can be expressed in the minimum number of levels of LE/LABs". At least that's what this newborn neandrathal believes he knows after his first questioning observations of the world of [altera cyclone3] FPGAs. As a long time hardware and software engineer, the notion "find your critical path and spend as much time as necessary to find the fastest possible way to implement that" is as natural as breathing. When I wrote a 3D graphics (game/simulation) engine recently, I noticed the "transform vertex positions to [world (or display)] coordinates" was the most often executed "critical path" in the engine. All the lazy numbhead engineers said the same thing, "you cannot possibly do better than the [OpenGL/DirectX] routines - they have been optimized by the smartest geniuses in the universe". Stubborn doofus that I am, I proceeded to break my butt to totally, clearly understand what needed to be done, and what would be the most efficient data-organization, algorithm-organization and implementation to implement this part of the algorithm. So I ended up coding one 32-bit and one 64-bit set of SIMD/SSE2+ assembly language code to perform this functionality and the result was... [drum roll, please]... my entire program became 6+ times faster. This did not shock me. But, as usual, everyone else who had warned me not to waste my time and effort, did what they always do - they just shrugged, said nothing, and walked away. Look, I've "been there done that" too many times to be uncertain about this, or give in. The notion of "identify and optimize the critical path" is not my invention or discovery. This has been common knowledge for decades if not centuries (or millennia). Therefore, until someone explains to me why optimization of our the critical paths in our designs have been purposely blocked, I will provisionally assume the answer is not an innocent one (because it rarely is). Yes, I am in a [seeming if not actual] difficult position here, being an admitted newbie neandrathal in FPGA design. But I have designed several 16 to 64 bit CPUs (from scratch, mostly with gates and/or modest MSI), so I have some experience and some basis for being skeptical. But at least I very much *want* to be shown that critical path optimization has not been blocked. Because I have work to do, and I'd rather not eject all FPGAs out the airlock. I do have alternatives, and they are cheaper and more familiar to me (albeit larger on PCB). BTW, the LUT_INPUT and LUT_OUTPUT do not appear to be components available in any of the schematic pulldown menus (though the LCELL is). One final comment. A not perfect but certainly reasonable way to provide the functionality I want might be available - but I do not understand Quartus2 well enough to know. The following is what I refer to (tell me if this is possible). If I could make a separate schematic that contains nothing but the elements of the logical component that I need (and that fits into one LE per bit) --- and then have that "synthetic component" available to insert (as a "black-box" or "functional block diagram") in other schematics, the capability and functionality I seek might be available (in practice). While this does not *force* Quartus2 to implement the innards of the "synthetic component" in one LE, this formulation certainly delivers a very strong hint to Quartus2 to try to implement the synthetic component in as few LEs as possible. Can this be done? If not, why on earth not? <bootstrap> PS: I am aware that most FPGA designers write HDL. I am not sure whether this is because many FPGA tools do not support schematic input, or why. I am certainly comfortable with writing code (microcode, assembly, C/C++, etc), but every hardware design/device I have ever created has been with schematic. Personally, I find this better because the ability to visually observe the whole design (then visually drill-down into any subsection) emphasizes the key difference from software --- the entire schematic is "executing" simultaneously all the time. This makes schematic entry for FPGAs much more natural for me. I looked into verilog for awhile after reading your posts, but got grossed out at the way it is formulated (and even more so with VHDL, over all). Maybe I just looked at horrible examples, I dunno. However, the exact same issue exists - I damn well expect to be allowed to identify and carefully optimize my critical paths. To tell me, a CPU designer, that my attitude about "critical paths" is unreasonable --- well --- you don't want to hear my response to that! IMHO. :-) I do appreciate all honest responses, no matter how opposite they may be. Who knows, for some reason I cannot envision, you may be right (for FPGAs). But with me, you really need to prove it. Sorry about that. :o PSS: No, I already know this device cannot afford anything slower than, or more expensive than, the slowest version of the smallest cyclone3. So no, I cannot just let Quartus2 implement my design in some inefficient way - and then steal our money several million times over. This is not a game or educational experience for me. This is serious product design, that must be as competitive as possible (especially these two products). And to answer your comment about "trust", no I cannot "trust" Quartus2. Given my experience with most modern american companies, I know better than that. I will, given positive experience with a company for a couple years (at least), tend to give benefit of doubt (suspect myself rather than them, at first). I just know too much, have experienced and seen too much, understand too well what is modus-operandi of most modern american companies. On the flip side, this makes me value honest people and companies all the more --- once I identify them. I will keep digging and questioning this issue until I am confident I have found and clearly understand the answers.
