"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:4quvu0Foq72hU1@individual.net...> KJ wrote: > >> But you didn't answer the question....reworded to 'What is the name of >> that >> standard IP'? lpm_fifo is the only one that I can think of that fits >> your >> functional description. Writing the function yourself (while you may >> want >> to do it anyway) does not qualify it as a 'standard'. You write good >> code >> Mike, but not everything you write is ready to be called a standard ;) > > Ready or not, > I'll call it sync_fifo. > See it here: > http://home.comcast.net/~mike_treseler/I've got the definite impression that we are not on the same page when we talk about what it means for something to be 'standardized'. The usage I'm talking about is that something 'standardized' if it is interchangable with something else that accomplishes that same function but not necessarily in the same way. Although the fifo functionality is pretty low level, since you suggested it I'll use it for the example....it will also be a good indicator of exactly what I mean about the lack of standardization even on something that is easy to describe. Copied below (without permission of the authors but only done for demonstration purposes) are the entity definitions for 'lpm_fifo' (an EIA standard) and 'sync_fifo' (Mike Tressler standard). Keeping mind what it is that a fifo is supposed to do (the function) and the intended USER of the fifo who has to deal with the interface to that function (i.e. signals and generics on the entity) let's peruse these two. Both have generics for specifying width of the fifo...but can't agree on the name of that generic parameter. Both have generics for specifying the depth of the fifo....but again can't agree on the name of that generic parameter. Both are bad from the standpoint of the user since Mike makes you specify depth as an address length (which is really log2(depth)) and lpm_fifo makes you use two parameters (the depth and log2(depth)). Each has their own unique way of not really telling you that their parameters really are simply log2(depth). Lpm_fifo allows you an option (Lpm_Showahead) for having the output show up as soon as it is available or only after in response to the read command. sync_fifo has no similar option. Having used fifos for a number of years I can say that both forms are generally useful depending on the application and performance requirements so in that regard sync_fifo is less useful than lpm_fifo. Lpm_fifo has some mystery parameters (lpm_type and lpm_hint) that are intended to be used to pass information further down the tool chain. From the standpoint of a user of the fifo, they just clutter up the interface and are no value. sync_fifo has nothing comparable so in that regard it is better tham lpm_fifo. LPM intended those to be used to pass info on to the fitter in some way but those strings are all going to be 'vendor specific' so no kudos there. Users of a fifo need to reset it, write to it and read from it. Again here there is no naming consistency on any of the signals with the exception of the 'full' and 'empty' status outputs. sync_fifo also has some two forms of reset (rst and init) that apparently Mike has found to be useful that the rest of the industry has not seen to be of enough value to include. Maybe sync_fifo is more useful because of this...or maybe it was a band-aid for a particular nitch problem but in most cases I would likely end up tying them to the same signal or tying one of them to '0'. lpm_fifo also has two forms of reset (async and sync); I won't rant on the dubious value of async resets maybe some find value to it. Although 'full' and 'empty' outputs are usually all that most users of a fifo will need, there are more than a few occasions where more status is needed. 'sync_fifo' does not provide anything, 'lpm_fifo' goes to the other extreme and provides a raw dump of the count. What is generally more useful would be to have a number of flag outputs where the depth where the flag gets triggered can be specified by a generic value (like half full, three quarters full, .98% full, etc.) Give both a failing mark on this for not giving much thought to how fifos really get used. Users of fifos tend to think of 'writing' and 'reading' the fifo, not 'pushing' and 'popping' it as sync_fifo does. In fact 'push' and 'pop' give the implication of a stack (which is a "last in first out" memory) not a fifo (which is "first in, first out") which would make one question whether you're even using the right function so demerits to sync_fifo on that one. So now that the long winded critique of two definitions of a fifo has been completed, so what? Why does any of this matter? Mike would probably agree that his 'sync_fifo' could very well have been implemented with the exact same set of parameter and signal names as lpm_fifo but he chose not to. So what is the impact of that decision? Well, if you want to switch from lpm_fifo over to Mike's sync_fifo because maybe it is so much better you've got a bunch of editing to do (every usage of lpm_fifo)...and yet sync_fifo implements the EXACT SAME FUNCTION. Even worse, maybe you'd just like to evaluate that supposed performance improvement. You're not getting anything more, and maybe you're simply trying to figure out if you get better performance using Mike's implementation but you've got a bit of effort in front of you to do that evaluation. Why? Because the interface to these two things that implement the EXACT SAME FUNCTION are completely different. Which is the situation that we're in today. Some FPGA vendors support the one sorry standard that exists (LPM) but are not doing much to improve it and move up the ladder to more higher level functions while one large FPGA vendor (namely 'X') does not directly support it that one standard...but they do provide their own unique way to implement the EXACT SAME FUNCTION. Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550 MHZ but doesn't seem to grasp the fact that he is talking about performance and that that hard coded fifo is implementing the EXACT SAME FUNCTION. I find it hard to believe that the Xilnx tool set could not, once it encountered the entity called 'lpm_fifo' that it could plop in that hard coded block. Maybe there are some usage restrictions that would prevent that hard coded block from always being instantiated but hey, isn't that what synthesis is supposed to figure out? How to best implement the specified function? Perhaps Peter can explain to everyone how the interface to that Xilinx hard coded fifo differs in some fundamental manner that the interface to that EXACT SAME FUNCTION could not be the same. Last, I would like to thank Mike for making available his code on his web site. His example designs are a definite 'good' thing. My comparisons of Mike's fifo implementation to LPM fifo is not meant to imply that his is any way worse just that it goes to show you that even with something simple, agreement on the interface to the EXACT SAME FUNCTION differs for no rational reason. Mike being able to reuse 'sync_fifo' wherever he needs fifo functionality though is no different than any other FPGA vendor pushing their 'standard'. Look at the IC industry and how they can standardize on things and fairly ask yourself why IP can't follow that model. Hint: The answer is not "Well IP is not the same as ICs".....if you analyze it rationally I think you'll see that the answer is more along the lines of "Well dang, it really could be standardized and still come out with new stuff as well as improve on old stuff". KJ ------------- entity LPM_FIFO generic ( LPM_WIDTH : natural; -- MUST be greater than 0 LPM_WIDTHU : natural := 1; -- MUST be greater than 0 LPM_NUMWORDS : natural; -- MUST be greater than 0 LPM_SHOWAHEAD : string := "OFF"; LPM_TYPE : string := L_FIFO; LPM_HINT : string := "UNUSED"); port ( DATA : in std_logic_vector(LPM_WIDTH-1 downto 0); CLOCK : in std_logic; WRREQ : in std_logic; RDREQ : in std_logic; ACLR : in std_logic := '0'; SCLR : in std_logic := '0'; Q : out std_logic_vector(LPM_WIDTH-1 downto 0); USEDW : out std_logic_vector(LPM_WIDTHU-1 downto 0); FULL : out std_logic; EMPTY : out std_logic); end LPM_FIFO; entity sync_fifo is generic (dat_length : natural := 16; add_length : natural := 8 -- 7 for 127x16 8 for 255x16 ); port (clk : in std_ulogic; rst : in std_ulogic; -- powerup init of pointers, flags init : in std_ulogic; -- synch init of pointers, flags -- (but not data) push : in std_ulogic; -- data_i latched on edge after push -- ok to push and pop at same time pop : in std_ulogic; -- hold one tick, read data_q while low data_i : in std_logic_vector(dat_length-1 downto 0); data_q : out std_logic_vector(dat_length-1 downto 0); -- readback full : out std_ulogic; empty : out std_ulogic); end sync_fifo;
Dual Port RAM
Started by ●October 30, 2006
Reply by ●November 4, 20062006-11-04
Reply by ●November 4, 20062006-11-04
Well, KJ, first of all, tone down, and dont second-guess how much I can grasp. "Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550 MHZ but doesn't seem to grasp the fact that he is talking about performance and that that hard coded fifo is implementing the EXACT SAME FUNCTION." I have designed FIFOs over a longer time period than anybody else in the world, for I created the world's first IC FIFO design in 1970, the Fairchild 3341. So much for credentials... When we put a HARD FIFO into the Virtex-4 and Virtex-5 devices, we realized that it had to be fully functional, fast and small, for every BlockRAM is "burdened" with it. And once the transistors are implemented on the chip, there is nothing that can be changed or taken away, and any additional circuitry in the fabric would reduce performance significantly. (There was, unfortunately, a subtle error in the Virtex-4 implementation that forced us to come up with a work-araound. We did not repeat that mistake inVirtex-5). We had talked to many customers and listened to their ideas. That's why there are not only programmable "ALMOST" full or empty flag, there is also the "First-word-fall-though option", (Lpm_Showahead), and a synchronous option that avoids the one-clock ambiguity at the trailing edge of FULL or EMPTY (inherently unavoidable in an asynchronous FIFO, but avoidable in a synchronous one). We designed the FIFO to be fast and small, with a comprehensive and intuitive user interface. If somebody wants to have a different interface, thousands of gates and LUTs are available to implement that. Did we design the LUTs to a specific standard? Do SRL16 shift register abide by an industy-wide standard? Are clock-multiplexers standardized? How's about DCMs and PLLs, and IDELAY and ODELAY fine-tuning circuits, and even multiplier/accumulators. Of course not, none do! Inside the chip we optimize the circuitry, and we are running way ahead of standardization. But, thanks to programmable logic, you can add soft standardization layers to your heart's content. Nothing stops smart IP of implementing any conceivable standard, but unfortunately usually at a cost and performance sacrifice. If someone knows a smarter way to design FPGAs, we really are listening. Honest ! Our customers want performance at the lowest cost, plus ease-of-design. But everybody has his own ideas about relative priorities. Peter Alfke, from home ================== On Nov 4, 11:38 am, "KJ" <kkjenni...@sbcglobal.net> wrote:> "Mike Treseler" <mike_trese...@comcast.net> wrote in messagenews:4quvu0Foq72hU1@individual.net... > > > > > KJ wrote: > > >> But you didn't answer the question....reworded to 'What is the name of > >> that > >> standard IP'? lpm_fifo is the only one that I can think of that fits > >> your > >> functional description. Writing the function yourself (while you may > >> want > >> to do it anyway) does not qualify it as a 'standard'. You write good > >> code > >> Mike, but not everything you write is ready to be called a standard ;) > > > Ready or not, > > I'll call it sync_fifo. > > See it here: > >http://home.comcast.net/~mike_treseler/I've got the definite impression that we are not on the same page when we > talk about what it means for something to be 'standardized'. The usage I'm > talking about is that something 'standardized' if it is interchangable with > something else that accomplishes that same function but not necessarily in > the same way. Although the fifo functionality is pretty low level, since > you suggested it I'll use it for the example....it will also be a good > indicator of exactly what I mean about the lack of standardization even on > something that is easy to describe. > > Copied below (without permission of the authors but only done for > demonstration purposes) are the entity definitions for 'lpm_fifo' (an EIA > standard) and 'sync_fifo' (Mike Tressler standard). Keeping mind what it is > that a fifo is supposed to do (the function) and the intended USER of the > fifo who has to deal with the interface to that function (i.e. signals and > generics on the entity) let's peruse these two. > > Both have generics for specifying width of the fifo...but can't agree on the > name of that generic parameter. > > Both have generics for specifying the depth of the fifo....but again can't > agree on the name of that generic parameter. Both are bad from the > standpoint of the user since Mike makes you specify depth as an address > length (which is really log2(depth)) and lpm_fifo makes you use two > parameters (the depth and log2(depth)). Each has their own unique way of > not really telling you that their parameters really are simply log2(depth). > > Lpm_fifo allows you an option (Lpm_Showahead) for having the output show up > as soon as it is available or only after in response to the read command. > sync_fifo has no similar option. Having used fifos for a number of years I > can say that both forms are generally useful depending on the application > and performance requirements so in that regard sync_fifo is less useful than > lpm_fifo. > > Lpm_fifo has some mystery parameters (lpm_type and lpm_hint) that are > intended to be used to pass information further down the tool chain. From > the standpoint of a user of the fifo, they just clutter up the interface and > are no value. sync_fifo has nothing comparable so in that regard it is > better tham lpm_fifo. LPM intended those to be used to pass info on to the > fitter in some way but those strings are all going to be 'vendor specific' > so no kudos there. > > Users of a fifo need to reset it, write to it and read from it. Again here > there is no naming consistency on any of the signals with the exception of > the 'full' and 'empty' status outputs. sync_fifo also has some two forms of > reset (rst and init) that apparently Mike has found to be useful that the > rest of the industry has not seen to be of enough value to include. Maybe > sync_fifo is more useful because of this...or maybe it was a band-aid for a > particular nitch problem but in most cases I would likely end up tying them > to the same signal or tying one of them to '0'. lpm_fifo also has two forms > of reset (async and sync); I won't rant on the dubious value of async resets > maybe some find value to it. > > Although 'full' and 'empty' outputs are usually all that most users of a > fifo will need, there are more than a few occasions where more status is > needed. 'sync_fifo' does not provide anything, 'lpm_fifo' goes to the other > extreme and provides a raw dump of the count. What is generally more useful > would be to have a number of flag outputs where the depth where the flag > gets triggered can be specified by a generic value (like half full, three > quarters full, .98% full, etc.) Give both a failing mark on this for not > giving much thought to how fifos really get used. > > Users of fifos tend to think of 'writing' and 'reading' the fifo, not > 'pushing' and 'popping' it as sync_fifo does. In fact 'push' and 'pop' give > the implication of a stack (which is a "last in first out" memory) not a > fifo (which is "first in, first out") which would make one question whether > you're even using the right function so demerits to sync_fifo on that one. > > So now that the long winded critique of two definitions of a fifo has been > completed, so what? Why does any of this matter? Mike would probably agree > that his 'sync_fifo' could very well have been implemented with the exact > same set of parameter and signal names as lpm_fifo but he chose not to. So > what is the impact of that decision? Well, if you want to switch from > lpm_fifo over to Mike's sync_fifo because maybe it is so much better you've > got a bunch of editing to do (every usage of lpm_fifo)...and yet sync_fifo > implements the EXACT SAME FUNCTION. Even worse, maybe you'd just like to > evaluate that supposed performance improvement. > > You're not getting anything more, and maybe you're simply trying to figure > out if you get better performance using Mike's implementation but you've got > a bit of effort in front of you to do that evaluation. Why? Because the > interface to these two things that implement the EXACT SAME FUNCTION are > completely different. Which is the situation that we're in today. Some > FPGA vendors support the one sorry standard that exists (LPM) but are not > doing much to improve it and move up the ladder to more higher level > functions while one large FPGA vendor (namely 'X') does not directly support > it that one standard...but they do provide their own unique way to implement > the EXACT SAME FUNCTION. > > Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550 > MHZ but doesn't seem to grasp the fact that he is talking about performance > and that that hard coded fifo is implementing the EXACT SAME FUNCTION. I > find it hard to believe that the Xilnx tool set could not, once it > encountered the entity called 'lpm_fifo' that it could plop in that hard > coded block. Maybe there are some usage restrictions that would prevent > that hard coded block from always being instantiated but hey, isn't that > what synthesis is supposed to figure out? How to best implement the > specified function? Perhaps Peter can explain to everyone how the interface > to that Xilinx hard coded fifo differs in some fundamental manner that the > interface to that EXACT SAME FUNCTION could not be the same. > > Last, I would like to thank Mike for making available his code on his web > site. His example designs are a definite 'good' thing. My comparisons of > Mike's fifo implementation to LPM fifo is not meant to imply that his is any > way worse just that it goes to show you that even with something simple, > agreement on the interface to the EXACT SAME FUNCTION differs for no > rational reason. Mike being able to reuse 'sync_fifo' wherever he needs > fifo functionality though is no different than any other FPGA vendor pushing > their 'standard'. > > Look at the IC industry and how they can standardize on things and fairly > ask yourself why IP can't follow that model. Hint: The answer is not "Well > IP is not the same as ICs".....if you analyze it rationally I think you'll > see that the answer is more along the lines of "Well dang, it really could > be standardized and still come out with new stuff as well as improve on old > stuff". > > KJ > ------------- > entity LPM_FIFO > generic ( > LPM_WIDTH : natural; -- MUST be greater than 0 > LPM_WIDTHU : natural := 1; -- MUST be greater than 0 > LPM_NUMWORDS : natural; -- MUST be greater than 0 > LPM_SHOWAHEAD : string := "OFF"; > LPM_TYPE : string := L_FIFO; > LPM_HINT : string := "UNUSED"); > port ( > DATA : in std_logic_vector(LPM_WIDTH-1 downto 0); > CLOCK : in std_logic; > WRREQ : in std_logic; > RDREQ : in std_logic; > ACLR : in std_logic := '0'; > SCLR : in std_logic := '0'; > Q : out std_logic_vector(LPM_WIDTH-1 downto 0); > USEDW : out std_logic_vector(LPM_WIDTHU-1 downto 0); > FULL : out std_logic; > EMPTY : out std_logic); > end LPM_FIFO; > > entity sync_fifo is > generic (dat_length : natural := 16; > add_length : natural := 8 -- 7 for 127x16 8 for 255x16 > ); > > port (clk : in std_ulogic; > rst : in std_ulogic; -- powerup init of pointers, flags > init : in std_ulogic; -- synch init of pointers, flags > -- (but not data) > push : in std_ulogic; -- data_i latched on edge after push > -- ok to push and pop at same time > pop : in std_ulogic; -- hold one tick, read data_q while low > data_i : in std_logic_vector(dat_length-1 downto 0); > data_q : out std_logic_vector(dat_length-1 downto 0); -- readback > full : out std_ulogic; > empty : out std_ulogic); > > end sync_fifo;
Reply by ●November 5, 20062006-11-05
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162698535.527609.266650@f16g2000cwb.googlegroups.com...> Well, KJ, first of all, tone down, and dont second-guess how much I can > grasp. > "Peter Alfke goes off on his rant about his X's hard coded fifo runs at > 550 > MHZ but doesn't seem to grasp the fact that he is talking about > performance > and that that hard coded fifo is implementing the EXACT SAME FUNCTION."I call them as I see them. You were the one who several times went on with the sales pitch on the 550 MHz fifo when we were talking about interface standardization, not performance.> I have designed FIFOs over a longer time period than anybody else in > the world, for I created the world's first IC FIFO design in 1970, the > Fairchild 3341. So much for credentials...Good, now let's move on.> > When we put a HARD FIFO into the Virtex-4 and Virtex-5 devices, we > realized that it had to be fully functional, fast and small, for every > BlockRAM is "burdened" with it. And once the transistors are > implemented on the chip, there is nothing that can be changed or taken > away, and any additional circuitry in the fabric would reduce > performance significantly. (There was, unfortunately, a subtle error in > the Virtex-4 implementation that forced us to come up with a > work-araound. We did not repeat that mistake inVirtex-5).Even now, instead of actually responding to anything that I had posted you are rambling on about things that Xilinx has done inside the various X products. It reads again like a sales pitch, give it a rest....the relevance of what you have to say to my post is completely missing.....maybe you intended this for some other post, who can tell?> We had talked to many customers and listened to their ideas. That's why > there are not only programmable "ALMOST" full or empty flag, there isI'm thinking that the programmable flags idea came not so much from listening to customers but from the discrete fifos that existed long before in the industry that also had 'programmable' flags. A bit of digging would've led you to that what most customers really needed was not programmability of the flag levels but being able to specify as a generic parameters the fifo fill level and how many flags were needed. The discrete IC fifo guys couldn't really do this so they had to make it programmable, but in the soft IP world of CPLD/FPGAs you could....but instead chose to copy industry parts. Maybe that's a good decision, maybe not but I'll bet not having run-time programmability is acceptable in most situations. For the others, this would be a different function (different entity).> We designed the FIFO to be fast and small, with a comprehensive and > intuitive user interface.Fifo interfaces are all pretty intuitive, so why does X not support the lpm_fifo interface? Is it not intuitive?> Are clock-multiplexers > standardized? How's about DCMs and PLLs, and IDELAY and ODELAY > fine-tuning circuits, and even multiplier/accumulators. Of course not, > none do!Why not? As a user I want to multiply and divide clock frequency, skew them if necessary and possibly mux them together. Sounds like something that can be standardized to me. Toss in standardization of the various memory controllers as well while you're at it since the memory devices are standardized. Remember what standardization means....interchangable with somebody else equivalent function.> Inside the chip we optimize the circuitry, and we are running way ahead > of standardization.That's your opinion (about being so far ahead). Does that statement also imply that Xilinx is just so far ahead that they can't bother with component standardization? That's another reading I could take away from that statement and seems to be what you're suggesting as well.> But, thanks to programmable logic, you can add soft standardization > layers to your heart's content. Nothing stops smart IP of implementing > any conceivable standard, but unfortunately usually at a cost and > performance sacrifice.Maybe. Are you suggesting that the lpm_fifo function wouldn't run at your horn tooting 550 MHz? Would be a bit of a bummer to think that you couldn't.> If someone knows a smarter way to design FPGAs, we really are > listening. Honest !I don't want to design FPGAs, I want to use them better and not be re-creating the wheel either and I think darn near all of your users would too. The Xilinx way appears to be to avoid adhering to or encouraging any design standards for IP creation other than to imply that the X way is the only and the best way.> Our customers want performance at the lowest cost, plus ease-of-design. > But everybody has his own ideas about relative priorities.Yep KJ
Reply by ●November 5, 20062006-11-05
KJ, is it so difficult for two reasonably intelligent engineers to communicate ? We are forced to be very efficient (small size) and very (fast high clock rate), that's what the market demands. Sacrificing performance by adhering to one or another of the so-called interface standards is, at best, our second or third priority. You may not like it, others do. 'nough said. Peter Alfke On Nov 5, 3:08 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:> "Peter Alfke" <a...@sbcglobal.net> wrote in messagenews:1162698535.527609.266650@f16g2000cwb.googlegroups.com...> Well, KJ, first of all, tone down, and dont second-guess how much I can > > grasp. > > "Peter Alfke goes off on his rant about his X's hard coded fifo runs at > > 550 > > MHZ but doesn't seem to grasp the fact that he is talking about > > performance > > and that that hard coded fifo is implementing the EXACT SAME FUNCTION."I call them as I see them. You were the one who several times went on with > the sales pitch on the 550 MHz fifo when we were talking about interface > standardization, not performance. > > > I have designed FIFOs over a longer time period than anybody else in > > the world, for I created the world's first IC FIFO design in 1970, the > > Fairchild 3341. So much for credentials...Good, now let's move on. > > > > > When we put a HARD FIFO into the Virtex-4 and Virtex-5 devices, we > > realized that it had to be fully functional, fast and small, for every > > BlockRAM is "burdened" with it. And once the transistors are > > implemented on the chip, there is nothing that can be changed or taken > > away, and any additional circuitry in the fabric would reduce > > performance significantly. (There was, unfortunately, a subtle error in > > the Virtex-4 implementation that forced us to come up with a > > work-araound. We did not repeat that mistake inVirtex-5).Even now, instead of actually responding to anything that I had posted you > are rambling on about things that Xilinx has done inside the various X > products. It reads again like a sales pitch, give it a rest....the > relevance of what you have to say to my post is completely missing.....maybe > you intended this for some other post, who can tell? > > > We had talked to many customers and listened to their ideas. That's why > > there are not only programmable "ALMOST" full or empty flag, there isI'm thinking that the programmable flags idea came not so much from > listening to customers but from the discrete fifos that existed long before > in the industry that also had 'programmable' flags. A bit of digging > would've led you to that what most customers really needed was not > programmability of the flag levels but being able to specify as a generic > parameters the fifo fill level and how many flags were needed. The discrete > IC fifo guys couldn't really do this so they had to make it programmable, > but in the soft IP world of CPLD/FPGAs you could....but instead chose to > copy industry parts. Maybe that's a good decision, maybe not but I'll bet > not having run-time programmability is acceptable in most situations. For > the others, this would be a different function (different entity). > > > We designed the FIFO to be fast and small, with a comprehensive and > > intuitive user interface.Fifo interfaces are all pretty intuitive, so why does X not support the > lpm_fifo interface? Is it not intuitive? > > > Are clock-multiplexers > > standardized? How's about DCMs and PLLs, and IDELAY and ODELAY > > fine-tuning circuits, and even multiplier/accumulators. Of course not, > > none do!Why not? As a user I want to multiply and divide clock frequency, skew them > if necessary and possibly mux them together. Sounds like something that can > be standardized to me. Toss in standardization of the various memory > controllers as well while you're at it since the memory devices are > standardized. Remember what standardization means....interchangable with > somebody else equivalent function. > > > Inside the chip we optimize the circuitry, and we are running way ahead > > of standardization.That's your opinion (about being so far ahead). Does that statement also > imply that Xilinx is just so far ahead that they can't bother with component > standardization? That's another reading I could take away from that > statement and seems to be what you're suggesting as well. > > > But, thanks to programmable logic, you can add soft standardization > > layers to your heart's content. Nothing stops smart IP of implementing > > any conceivable standard, but unfortunately usually at a cost and > > performance sacrifice.Maybe. Are you suggesting that the lpm_fifo function wouldn't run at your > horn tooting 550 MHz? Would be a bit of a bummer to think that you > couldn't. > > > If someone knows a smarter way to design FPGAs, we really are > > listening. Honest !I don't want to design FPGAs, I want to use them better and not be > re-creating the wheel either and I think darn near all of your users would > too. The Xilinx way appears to be to avoid adhering to or encouraging any > design standards for IP creation other than to imply that the X way is the > only and the best way. > > > Our customers want performance at the lowest cost, plus ease-of-design. > > But everybody has his own ideas about relative priorities.Yep > > KJ
Reply by ●November 6, 20062006-11-06
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162777204.878034.242930@f16g2000cwb.googlegroups.com...> KJ, is it so difficult for two reasonably intelligent engineers to > communicate ?No, and I might suggest that you would not find it so difficult either if, when you make your posts, you would give the courtesy of replying to what was said in the post that you're replying to instead of going into a speech or sales pitch. Speeches and pitches can be interesting and can often spawn their own sub-topics, but that doesn't make them relevant to the discussion. One technique is to not top post.> We are forced to be very efficient (small size) and very (fast high > clock rate), that's what the market demands.Among other demands as well. Customers are like that. We all have them.> Sacrificing performance by adhering to one or another of the so-called > interface standards is, at best, our second or third priority.And yet the basis for this statement is "because Peter said so". You haven't been able to offer even a single example to back up what you've said. You have offered no benchmarks, no references, nothing to back up your statement that one would be "Sacrificing performance by adhering to one or another of the so-called interface standards".> You may not like it, others do.Others are free to (dis)like things for no rational basis if they so choose. Personally I think you're shortchanging the intelligence of a good chunk of your users and power users with the statements you've made in this thread.> 'nough said. > Peter AlfkeKJ
Reply by ●November 6, 20062006-11-06
Maybe I'll regret jumping in here, but here's my take :-) We designers want standard interfaces to FPGA bits and bobs. FIFOs are a good example, no-one *wants* to design their own. There is a "standard" interface defined, but it's not used across all vendors, which makes life painful to port... Also, mostly we don't need lots of clever configurations. If I want to use Xilinx's FIFO, I use code like this (with some snippage): -- FIFO18: 16k+2k Parity Synchronous/Asynchronous BlockRAM FIFO BlockRAM Memory -- Virtex-5 -- Xilinx HDL Libraries Guide, version 8.2.2 FIFO18_inst : FIFO18 generic map ( ALMOST_FULL_OFFSET => X"0080", -- Sets almost full threshold ALMOST_EMPTY_OFFSET => X"0080", -- Sets the almost empty threshold DATA_WIDTH => 18, -- Sets data width to 4, 9, or 18 FIRST_WORD_FALL_THROUGH => false) -- Sets the FIFO FWFT to TRUE or FALSE port map ( DO => DO, -- 16-bit data output DOP => DOP, -- 2-bit parity data output EMPTY => EMPTY, -- 1-bit empty output flag FULL => FULL, -- 1-bit full output flag WRCOUNT => WRCOUNT, -- 12-bit write count output DI => DI, -- FIFO data input, with determined by DATA_WIDTH DIP => DIP, -- 2-bit partity input RDCLK => RDCLK, -- 1-bit read clock input RDEN => RDEN, -- 1-bit read enable input RST => RST, -- 1-bit reset input WRCLK => WRCLK, -- 1-bit write clock input WREN => WREN -- 1-bit write enable input ); As an aside: And what's this DI/DO and DIP/DOP about? I ask for 18 bits, I just want 18-bits! Now, not inly is this non-standard, if I want a different size, I have to instantiate a different component with a different name! The same goes for RAMs. Anyway, if I want to use most others' I use this: LPM_FIFO_1: entity work.LPM_FIFO generic map ( LPM_WIDTH => LPM_WIDTH, LPM_WIDTHU => LPM_WIDTHU, LPM_NUMWORDS => LPM_NUMWORDS, LPM_SHOWAHEAD => LPM_SHOWAHEAD, LPM_TYPE => LPM_TYPE, LPM_HINT => LPM_HINT) port map ( DATA => DATA, CLOCK => CLOCK, WRREQ => WRREQ, RDREQ => RDREQ, ACLR => ACLR, SCLR => SCLR, Q => Q, USEDW => USEDW, FULL => FULL, EMPTY => EMPTY); Now, I agree with KJ, the LPM_WIDTH and WIDTHU thing is daft. The TYPE and HINT don't usually help me much, but the rest of it maps directly onto Xilinx's template doesn't? There's a different entity with async clocks, for those cases, but chnaging between async and sync clocks happens a lots less often than between sizes of FIFO! And if I change the size, the SW is smart enough to instantiate the low-level stuff in the right way for me. If I need absolute control, then sure, I can go and instantiate those myself, but for the majority, all I need is a straightforward FIFO! And again the same applies for things like LPM_RAM. They all do the same thing. Why can't I just write the same thing for all of them? After all, I can write a bit of VHDL to wrap it, which get's me there - but why do *I* (and everyone like me) have to do this, why can't the vendors do it for me? Maybe I'm missing something fundamental, but when I use a FIFO, all I want is a simple FIFO with a consistent interface. Do others have a different view? Perhaps we should all get together and write the wrappers and docs for this between us for the benefit of future generations ( :-)?) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
Reply by ●November 6, 20062006-11-06
Hi KJ,>>> Tell me what prevents everyone from standardizing on an interface to >>> their components in a manner similar to what LPM attempts to do? The >>> chip guys do it for their parts, the FPGA vendors don't seem to want to >>> do anything similar on the IP core side. >> I don't think anything prevents it, other than whatever all-pervading >> force there is in the universe which prevents people from agreeing about >> things. :-) > But it's not really an all-pervading force. If it were we wouldn't have > any standards like PCI, I2C, PCI Express, DDR....on and on and on. So > where is the list of interface standards for inside the chip?I wish I could be that idealistic! :-) Here are two questions to which I don't have precise answers: (1) How many DDR SDRAM chips were sold worldwide in 2005? (2) How many FPGA IP cores were sold worldwide in 2005? With or without actually finding the answers, now speculate as to the relative importance of standardization for these two application areas.> Wishbone is about it for FPGAs...and it needs some work but it's not bad.It's not one-size-fits-all though; in fact, nothing really is. That is half of the problem. Many of the more interesting IP cores use variable and/or non-standard word sizes, have non-obvious flow control requirements stemming from extensive pipelining and buffering, and so on. If every FPGA user just wanted to build SoCs based around a microprocessor with a big old local bus with all the peripherals hanging off it, then life would be much easier. As it is, we try to provide the most flexible interfacing options possible, so that no-one is prevented from using a particular core just because their system is wired together in a way that we hadn't thought of.> So do the big guys all support Wishbone? Build it into their system > design tools? Ummmm....well....no....what do they support? Well, here is > the Brand A 'standard', brand X standard etc.In an embedded system-builder context, brand A have their proprietary bus, whereas brand X's bus structure did at least come from IBM (which in my mind makes it "somewhat more standard"; you may of course disagree). When it comes to "raw" IP blocks, the basic, pervasive idioms of two-wire synchronous handshakes and simple flow-controlling pulses are simple to comprehend and use. The names and exact timings may be different but if you go and compare the datasheet-specified interface for a brand X Turbo Encoder and the brand A equivalent, you'll probably find there's very little difference.> Choosing a standard based on features and performance that are relevant is > exactly the right thing. That's not what you're basing your decision on > between 'X' and 'A'.I would respectfully disagree, certainly as far as embedded processing is concerned. Sure, there are many other important factors, and many people do treat - or try to treat - FPGAs as commodity products, but I would certainly not make a big A vs X purchasing decision without making a diligent study of the relative merits of the microprocessor interfaces favoured by each vendor. Cheers, -Ben-
Reply by ●November 6, 20062006-11-06
Martin Thompson wrote:> Maybe I'll regret jumping in here, but here's my take :-) > > We designers want standard interfaces to FPGA bits and bobs.<snip> It's nice to hear another opinion, but.... I have a software guy that wants us FPGA designers to standardize on 16550 UARTs for our embedded designs. WTF?! This device is from a quarter century ago and made to work with serial links that are quite a bit worse than the embedded applications I have today. WHY is a standard interface desired when much of what "was" there can become completely superfluous? Personally - and this is opinion as it is with the other posts - I want to get the best performance/cost/size balance I can strike. Why should I burden my design with bloated code to pacify others who want to blow my performance, increase my cost, or bloat the size? If you want a standard interface, make one. PLEASE don't force me to use silicon with hard-coded features that are much less than what they could be all for the sake of conformance. The only time I would care to see a standard interface pursued is if there is ZERO impact to my engineering tradeoffs. - John_H
Reply by ●November 6, 20062006-11-06
John_H wrote:> Martin Thompson wrote: > > Maybe I'll regret jumping in here, but here's my take :-) > > > > We designers want standard interfaces to FPGA bits and bobs. > > <snip> > > It's nice to hear another opinion, but.... I have a software guy that > wants us FPGA designers to standardize on 16550 UARTs for our embedded > designs. WTF?! This device is from a quarter century ago and made to > work with serial links that are quite a bit worse than the embedded > applications I have today. > > WHY is a standard interface desired when much of what "was" there can > become completely superfluous? > > Personally - and this is opinion as it is with the other posts - I want > to get the best performance/cost/size balance I can strike. Why should > I burden my design with bloated code to pacify others who want to blow > my performance, increase my cost, or bloat the size? > > If you want a standard interface, make one. PLEASE don't force me to > use silicon with hard-coded features that are much less than what they > could be all for the sake of conformance. > > The only time I would care to see a standard interface pursued is if > there is ZERO impact to my engineering tradeoffs. > > - John_H
Reply by ●November 6, 20062006-11-06
I couldn't agree more, John. I have no use for primitives, or IP for that matter, that has been crippled or bloated in order to comply with some arbitrary "standard" that is not likely to match my needs anyway. Much more important is complete, concise, and clear documentation, visibility into the guts of the IP, and tools that work properly.
