A netlist of familiar blocks will always be the starting point for some. But this is a self-limiting design method because it does not scale well and is hard to simulate. A designer that sticks with it will eventually learn how describe the same output ports with HDL and simulation.
About all a vendor can do about this is to provide some non-trivial examples that show how to make the RTL viewer draw the schematics to an HDL spec. (hint)
The biggest roadblock to portability are the RAM and FIFO blocks that are not describable in RTL because of asynchronous arbitration. I would much prefer to do my own arbitration *and* infer a simpler block.
I can. A synch fifo using one read port and one write port from an inferred dpram.
Me too.
Ay, there's the rub. Those who write portable code want it all portable. Those cursed with a crusty but popular design will pray for a part that covers all the old gizmos.
Just to clear up any confusion as to what I wanted in the first place. was looking to use a dual port ram with different address and data width on side a and b. I have checked with Synplicity and it is currently no possible to infer a ram of this type. So you need to use Coregen instead Apparently they are looking at implementing it in a future release.
But again, you're probably standards compliant on the physical pin side but what about on the 'other' side? A communication's bridge exists because it connects TWO disparate interfaces, so what is the standard interface that is used internal to the FPGA that you're bridging over to PCIexpress?
And I agree with you about frugality. The 'internal to the chip' standard interface should be something robust yet something that when used in simple comm situations reduces down (via the magic of synthesis logic optomization) to something darn close to the bare minimum. Certainly there are cases where anything over the bare minimum might be too much, but those tend to be exceptions (i.e. relatively small logic that can be hand optomized in the grand scheme of the entire FPGA design).
OK, let's discuss the fifo. Specifically let's take the EIA standard lpm_fifo. That entity defines the input for a hunk-o-code that implements a fifo. If I instantiate an lpm_fifo and target that to the appropriate Xilinx part will I get that 550 MHz performance? If so, then you've provided an example of where standardizing on the interface is a 'good' thing. If not, then can you explain what is so burdensome about the entity definition of lpm_fifo that makes that 550 MHz unachievable?
We're not talking about getting extra functionality, we're talking about getting the same function. The synthesis operation, once it saw 'lpm_fifo' and targetting brand X could know that there is a hard coded thingy to implement it....that's what we pay the synthesis tool to do, right?
Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to talk about optomizing but you brought up the fifo. Things like controllers come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah). Many of these are really communication's bridges that hook two different busses together to exchange information. One one side (the physical pin side) we have all the standards, on the other side...well...a bit lacking (IMO) in calling things a standard....and yet things like Wishbone or Avalon or what have you that were all thought through of as being an 'inside the chip' comm bus really do synthesize and logically optomize quite well.
After getting over the worry (if there is any) about people jumping ship because their code could now be truly portable to brand A, B, C.... you should also recognize that it would also be a productivity improvement because it would improve code reuse and aid in simply division of labor because you wouldn't have these ad hoc, "let me pass you this signal it will happen two clock cycles before that" type of thing.
Perhaps instead of bantering about specific examples that we each seem to think bolster our points you can give us the Xilinx view of
- Standardized internal interfaces, good for business? (Xilinx that is)
- What standards work for these internal interfaces are you compliant with?
- What push for improving these standards are you participating in?
In my view this internal interface should scale well (i.e. not get burdensome in wasting logic resources in the synthesized design) if I want to use it inside a VHDL architecture to communicate between processes all the way up to it being an external interface (if I so choose).
No, I'm thinking of bigger blocks...the things you wouldn't want to have to write the code for because it is just a sub-function of the overall design. Bridges to SDRAM, DDR, PCI, compression, image processing and security algorithms. Not your simple TTL type of stuff.
Why not? Once they see the standardized entity called 'ddr_controller' they would instantiate their own hard coded IP algorithm for talking to the bloody thing. I'm not interested in re-inventing the wheel, just in reusing that wheel.
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? Wishbone is about it for FPGAs...and it needs some work but it's not bad. 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.
I agree
And I'll bet that any engineer worth their salt would also rather not keep re-inventing the wheel and doing needless bus translators.
Yes, they all have their own way of making our lives 'easier'....in their minds at least.
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'.
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 ;)
But it is a standard issued by a recognized body. But I've yet to hear what is soooo burdensome about LPM that it couldn't be supported...'specially since there aren't that many 'useful' functions in there to begin with. And technically speaking I believe Xilinx 'does' support LPM, but from what I hear, not very well.
We should be way beyond standardizing on things as low level as the LPM stuff....but we're not....
I was misinterpreting the original post as wanting to independently vary address and data widths. Bus resizing for various reasons has many applications, I agree.
That's true - my *impression* at the time (which was around 2000) was that Xilinx didn't want to make migration between vendors too easy. That's just my impression mind, I don't know what actually went on. Based on what I read around the LPM website.
That's interesting - any idea how?
In some ways we are - I've never instantiated an LPM_COUNTER, an incrementing variable does the job for me :-)
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
No, just from the (possibly misguided) impression that I got over the years. Googling would seem to indicate that you're correct that they don't have any support for it directly but Synplify does support LPM, so you can get LPM on X by using S (which is what I was thinking since I do have and use S). Googling a bit more and you'll see that Lattice and Actel both claim to support it.
One of the hits that I got on the Xilinx site gives the following two defintions for 'LogiBLOX' and 'LPM'. The word for word match in the definitions would seem to indicate that something petty (or perceived protection of the turf) is keeping them apart.
formatting link
LogiBLOX - Formerly called X-Blox. Library of logic modules, often with user-definable
parameters, like data width. Very similar to LPM.
LPM - Library of Parameterized Modules. Library of logic modules, often with userdefinable
parameters, like data width. Very similar to LogiBlox.
Yeah....in many ways I don't like holding up LPM since most of what is in there is nothing I would instantiate simply because it is (and always has been) too low level and easier to infer directly in the code. It is an example though of a standard that had the basic idea of what I'd like to see happening....just not high enough functionality and didn't get updated to add new stuff to match what is going on in the world.
True, but 475 MHz with default optimization is not bad.
-- Mike Treseler
Info: Selected device EP2S15F484C3 for design "sync_fifo" Info: Fitter is performing an Auto Fit compilation, which may decrease Fitter effort to reduce compilation time Info: Clock "clk" has Internal fmax of 475.74 MHz between source register "\fifo:pushed" and destination register "full_ctr[1]" (period=
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.