Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> >What you're asking is device-related. What FPGA family are you using? >Generally speaking, Xilinx devices can implement distributed memory >FIFO pretty well, but you need to limit the depth of the FIFO to >get it to run at high clock rates. Also there's a big difference >between common-clock FIFO and independent-clock FIFO. The first >kind can be implemented in SRL, the second cannot. > >Also it would be good to see a full failing path from your timing >report (.twr file) to see if this is a logic level issue or >a routing length issue. > >-- >Gabor It is Virtex 6 and I have achieved better than 368MHz at module level. At integration (into very large project) it fails marginally. As I said it is the path from read register to fifo data output (single clock 16 words depth, distributed ram).I don't expect any logic apart from fifo stages implemented in luts. I am just asking if there is anyway to improve such paths. I tried block ram and it failed very badly. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158026
kaz <37480@fpgarelated> wrote: (snip, and previously snipped) > It is Virtex 6 and I have achieved better than 368MHz at module level. > At integration (into very large project) it fails marginally. As I said it > is the path from read register to fifo data output (single clock 16 words > depth, distributed ram).I don't expect any logic apart from fifo stages > implemented in luts. I am just asking if there is anyway to improve such > paths. I tried block ram and it failed very badly. Do you mean that it fails, even when timing satisfies the post-route timing data? That isn't good. -- glenArticle: 158027
You didn't mention whether this is purely for simulation (e.g for architecture exploration) or for synthesis (building and FPGA). I am not sure that referencing a variable for a type declaration is correct, but some synthesis tools may allow it anyway (since the variable could not have changed value except at run time.) Declarations must be based on static information, known at compile time. Your entity could use a generic (a static kind of "port") to pass this size information in at compile/synthesis time, but that is about as dynamic as it gets for architecture or process declarative regions. Most tools allow specifying the value of top level generics on the command line and/or in a project file. For simulation, subprograms can declare items based on argument values, but for synthesis, this places constraints on how the subprogram is called, and whether those argument values can be known at synthesis time. VHDL (for simulation only) has dynamic memory allocation, and pointers (called access types) with which you can dynamically create data structures. But they are not synthesizable. AndyArticle: 158028
>kaz <37480@fpgarelated> wrote: > >(snip, and previously snipped) > >> It is Virtex 6 and I have achieved better than 368MHz at module level. >> At integration (into very large project) it fails marginally. As I said >it >> is the path from read register to fifo data output (single clock 16 words >> depth, distributed ram).I don't expect any logic apart from fifo stages >> implemented in luts. I am just asking if there is anyway to improve such >> paths. I tried block ram and it failed very badly. > >Do you mean that it fails, even when timing satisfies the >post-route timing data? > >That isn't good. > >-- glen No, by module level I mean when compiled on its own. The actual project is not based on any incremental approach or logic lock but all the lower modules are just added to project to be fitted freely anywhere it chooses. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158029
kaz <37480@fpgarelated> wrote: >>kaz <37480@fpgarelated> wrote: >>(snip, and previously snipped) (snip) >>> It is Virtex 6 and I have achieved better than 368MHz at module level. >>> At integration (into very large project) it fails marginally. As I >>> said (snip, I wrote) >>Do you mean that it fails, even when timing satisfies the >>post-route timing data? (snip) > No, by module level I mean when compiled on its own. The actual > project is not based on any incremental approach or logic lock > but all the lower modules are just added to project to > be fitted freely anywhere it chooses. I use Spartan, so it might be different. Some years ago, I was working on a project where the pre-route timing was so good, maybe twice as fast as it needed to be, and I didn't even bother to look at the post-route timing until I tried it, and it didn't work. At least for Spartan, the routing is optimized over the whole chip. Well, there are things that you can do to give hints and such, but it is easily possible that changing one part changes the timing of some unrelated part. It might be that you can route some modules, keep them fixed while you route others. That probably makes more sense in big designs. But whatever it does, it should meet post-route timing, and you should run that to be sure that is fast enough. -- glenArticle: 158030
On Friday, July 10, 2015 at 10:36:17 AM UTC-7, abd_elhamid_ wrote: > Dear All, > > Why dynamic power after compilation complete equal to zero, any idea how > can I calculate dynamic power at max freq in Quartus? > > Regards > > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Is Power Play turned on in the Settings menu?Article: 158031
Hey folks, my team just posted a new issue of Xcell Journal. Here is the link to the pdf: http://www.xilinx.com/publications/archives/xcell/Xcell92.pdf Here is the link to the digital magazine version: http://issuu.com/xcelljournal/docs/xcell_journal_issue_92 Cheers, Mike SantariniArticle: 158032
Hi, I'm working in Artix-7 and I've got a workable way to adjust the bitslip an= d IDELAY tap settings to lock onto an incoming TMDS encoded stream, but is = there a better way? Currently I count the symbol error rate on the link, and if the rate of bad= symbols is greater than 1:2^20 I then move on to a higher delay tap settin= g.=20 If the delay's tap setting wraps I also assert bitslip input on on the ISER= DES for a cycle, allowing me to try a different alignment. It works well enough in practice but seems ungainly, and has a few problems= lurking under the covers - if the error rate is very close to 1:2^32 it wi= ll never lock, and a second problem is that it might decide to stick with a= n IDELAY that is marginal (e.g. has errors but less than one in a million),= without discovering that a better setting could be one tap away.=20 And not so much a problem for video but if it does get errors it can take a= while to come back into sync (7M symbols or so) The 7-series I/O Resource User Guide is very good at telling you what is th= ere for you to use, but not how best to do it - any suggests would be grat= efully accepted! Mike PS. Code is at http://hamsterworks.co.nz/mediawiki/index.php/SERDES_symbol_= locking if you want a look at it.Article: 158033
Hi Mike, I always use 2 independent types of alignment: Bit- and Word alignment. In first case I ensure that I sample the data as close as possible in the middle of the data eye. This can be performed by example of using 2 delays for one data lane with an variable offset between them. Lets say you have a M-delay and a S-Delay for your data lane (for example you can use IBUFDS_DIFF_OUT buffers on Artix 7 devices when using LVDS). M is at step n and S will be oscillated about amount of shifts, lets say 2 (this depends on the tap width and the width of the open data eye). So S will have the tap values n+2 -> n-2 -> n+2 -> n-2 and so on. Now you compare your data between M and S. When they are equal you sample in the middle of the data eye and everything is fine. When not you have to tap M in the opposite direction until the data is equal. I like this technique, because the bit alignment is performed in real time, which ensures that the link is up in every case (for example voltage or temperature can change). When this works you have the most technical part of alignment done. To implement word alignment, you have to know some known symbols in your data stream. When you find them, everything is good, when not you have to perform bitslips until you get them. Nice regards, TobiasArticle: 158034
Someone is looking to generate compressed images in an FPGA to display graph data on a browser. Looking around the GIF, TIFF or PNG formats seem rather straightforward to implement. Anyone know of an implementation of one of these in an HDL? It doesn't need to implement the entire standard, just enough to generate one image style. -- RickArticle: 158035
I'm turning out a cupboard and have found 10 off Lattice LFECP10E-4FN256C - still sealed in dry packs. Location SW Scotland - seems a shame to bin them - I'll try to give them away at the Wuthering Bytes jolly in Hebden Bridge at the end of Septemebr unless someone here would like them first. Contact me direct if you are interested. mk AT mkesc DOT co DOT uk Michael KellettArticle: 158036
rickman <gnuarm@gmail.com> wrote: > Someone is looking to generate compressed images in an FPGA to display > graph data on a browser. Looking around the GIF, TIFF or PNG formats > seem rather straightforward to implement. Anyone know of an > implementation of one of these in an HDL? It doesn't need to implement > the entire standard, just enough to generate one image style. Does it actually need to be compressed, or will wrapping headers around uncompressed data be enough? All of those have uncompressed formats that will be accepted by a web browser - that may suffice if you aren't concerned about bandwidth, and would be easier to implement. TheoArticle: 158037
On 7/25/2015 2:19 PM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> Someone is looking to generate compressed images in an FPGA to display >> graph data on a browser. Looking around the GIF, TIFF or PNG formats >> seem rather straightforward to implement. Anyone know of an >> implementation of one of these in an HDL? It doesn't need to implement >> the entire standard, just enough to generate one image style. > > Does it actually need to be compressed, or will wrapping headers around > uncompressed data be enough? All of those have uncompressed formats that > will be accepted by a web browser - that may suffice if you aren't concerned > about bandwidth, and would be easier to implement. Yes, I suspect he can even use a fully uncompressed format like bitmap. His requirements to be for the format to be "widely supported" which doesn't indicate how recent the browsers need to be and to produce the image files with little working memory. He seems to like SVG which seems to meet the latter requirement well if meeting the former requirement is a bit fuzzy. It looks like nearly all browsers currently support SVG but only the more recent versions of some. He does not seem to be limited to connection bandwidth and has not indicated his needed update rate. This guy often posts discussion points without giving details until you offer a solution that does not meet one of the unmentioned requirements. Looks like SVG may be the way he goes. -- RickArticle: 158038
"rickman" <gnuarm@gmail.com> wrote in message news:moufqn$8d1$1@dont-email.me... > Someone is looking to generate compressed images in an FPGA to display > graph data on a browser. Looking around the GIF, TIFF or PNG formats seem > rather straightforward to implement. Anyone know of an implementation of > one of these in an HDL? It doesn't need to implement the entire standard, > just enough to generate one image style. There are lots of JPEG encoders out there. Maybe use one? Tomas D.Article: 158039
On 7/26/2015 5:24 PM, Tomas D. wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:moufqn$8d1$1@dont-email.me... >> Someone is looking to generate compressed images in an FPGA to display >> graph data on a browser. Looking around the GIF, TIFF or PNG formats seem >> rather straightforward to implement. Anyone know of an implementation of >> one of these in an HDL? It doesn't need to implement the entire standard, >> just enough to generate one image style. > > There are lots of JPEG encoders out there. Maybe use one? Thanks for the advice. I will use it in the spirit it was intended. :) -- RickArticle: 158040
rickman <gnuarm@gmail.com> wrote: > He seems to like SVG which seems to meet the latter requirement well if > meeting the former requirement is a bit fuzzy. It looks like nearly all > browsers currently support SVG but only the more recent versions of some. If you're just plotting X/Y then SVG may suffice, if you can make a suitable wrapper around it. One other thought - get the browser to do the work. Just emit the data in whatever format you fancy - JSON is a simple one, but even base64 might work - and then just include some Javascript that plots it in the browser for you. There's lots of libraries for that: http://www.sitepoint.com/15-best-javascript-charting-libraries/ You can just use a URL so don't need the JS framework on the FPGA. Lots of 'analytics' sites do this - download the table of (eg) share prices as XML or JSON and plot locally, rather than plotting server-side. Makes for better interaction too - easier to navigate when your browser has the dataset. TheoArticle: 158041
I am very impressed. I was reading about Antti's incredibly tiny FPGA project board and saw a mention of a FOSS FPGA toolchain. Not just the compiler, but the entire bitstream generation! http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/ Several people have built on each other's work to provide "a fully open source Verilog to bitstream development tool chain for the Lattice iCE40LP with support for more devices in the works." http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ https://github.com/cseed/arachne-pnr I haven't tried any of it yet, but I am very impressed that they are reverse engineering the devices so that they can generate bit streams and not rely on the vendor. -- RickArticle: 158042
On 7/27/2015 12:34 PM, rickman wrote: > I am very impressed. I was reading about Antti's incredibly tiny FPGA > project board and saw a mention of a FOSS FPGA toolchain. Not just the > compiler, but the entire bitstream generation! > > http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/ > > > Several people have built on each other's work to provide "a fully open > source Verilog to bitstream development tool chain for the Lattice > iCE40LP with support for more devices in the works." > > http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ > > https://github.com/cseed/arachne-pnr > > I haven't tried any of it yet, but I am very impressed that they are > reverse engineering the devices so that they can generate bit streams > and not rely on the vendor. I found another link relating to the tools called "IceStorm". http://www.clifford.at/icestorm/ -- RickArticle: 158043
On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote: > I am very impressed. I was reading about Antti's incredibly tiny FPGA > project board and saw a mention of a FOSS FPGA toolchain. Not just the > compiler, but the entire bitstream generation! > > http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas- that-small/ > > Several people have built on each other's work to provide "a fully open > source Verilog to bitstream development tool chain for the Lattice > iCE40LP with support for more devices in the works." > > http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ > > https://github.com/cseed/arachne-pnr > > I haven't tried any of it yet, but I am very impressed that they are > reverse engineering the devices so that they can generate bit streams > and not rely on the vendor. Kewl. It'll be even more kewl if it shames the vendors into being open with their bitstream specifications. I have no idea why they seem to feel this needs to be held so close to their chests. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 158044
On 7/27/2015 1:57 PM, Tim Wescott wrote: > On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote: > >> I am very impressed. I was reading about Antti's incredibly tiny FPGA >> project board and saw a mention of a FOSS FPGA toolchain. Not just the >> compiler, but the entire bitstream generation! >> >> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas- > that-small/ >> >> Several people have built on each other's work to provide "a fully open >> source Verilog to bitstream development tool chain for the Lattice >> iCE40LP with support for more devices in the works." >> >> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ >> >> https://github.com/cseed/arachne-pnr >> >> I haven't tried any of it yet, but I am very impressed that they are >> reverse engineering the devices so that they can generate bit streams >> and not rely on the vendor. > > Kewl. > > It'll be even more kewl if it shames the vendors into being open with > their bitstream specifications. I have no idea why they seem to feel > this needs to be held so close to their chests. I seriously doubt this will ever happen. They have all done this nearly 100% of the time and I'm sure they are convinced it is the best way to do business. From what they have said their concern is that with open source tools their hardware will be subject to "problems" caused by poor tools. Or maybe they limit access to chip features through the tools which they couldn't do with FOSS tools. I seem to recall someone ranting that a line of Altera parts had some devices which were labeled as smaller chips but would load and run a bitstream for a larger part. I expect this would show up quickly and clearly if the tools were FOSS. Those who have been in this business long enough may remember the line of parts Xilinx made specifically to support an open bit stream. It was popular with academia and a number of papers were written about researchy things you might do with it. I'm not sure what Xilinx's motive was for producing these chips, but they dropped the line and crushed the molds. I'm pretty sure there is no mention of these parts anywhere on their site now. Or did I only dream all of that? -- RickArticle: 158045
> Those who have been in this business long enough may remember the line of > parts Xilinx made specifically to support an open bit stream. It was > popular with academia and a number of papers were written about researchy > things you might do with it. I'm not sure what Xilinx's motive was for > producing these chips, but they dropped the line and crushed the molds. > I'm pretty sure there is no mention of these parts anywhere on their site > now. Or did I only dream all of that? Maybe you will also be interested in this: https://recon.cx/2015/slides/recon2015-18-andrew-zonenberg-From-Silicon-to-Compiler.pdf Tomas D.Article: 158046
On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote: > On 7/27/2015 1:57 PM, Tim Wescott wrote: >> On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote: >> >>> I am very impressed. I was reading about Antti's incredibly tiny FPGA >>> project board and saw a mention of a FOSS FPGA toolchain. Not just >>> the compiler, but the entire bitstream generation! >>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40- fpgas/ > Excellent! Though I'm not surprised it's Lattice, I vaguely recall looking through an early (pre-2000) toolchain of theirs and thinking the details were closer to the surface than with other vendors. > Those who have been in this business long enough may remember the line > of parts Xilinx made specifically to support an open bit stream. It was > popular with academia and a number of papers were written about > researchy things you might do with it. I'm not sure what Xilinx's > motive was for producing these chips, but they dropped the line and > crushed the molds. I'm pretty sure there is no mention of these parts > anywhere on their site now. Or did I only dream all of that? Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx developed them, as they bought the company that did (Algotronics or Algotronix I think, based in Edinburgh). Presumably they bought them for tech in general or possibly some key patents rather than the specific device family. Which was something of a dead end in other respects, too fine grained (I believe' 1 gate, 1FF per CLB). Much simpler and more regular, but wouldn't scale too well to million-CLB devices dominated by routing, where the XC4000 and later devices would give the same capacity with a much smaller and cheaper die. I think it was that simple regular structure that made opening the bitstream format attractive, as well as killing the device long-term. You may also recall a company that successfully reverse-engineered the bitstream for Xilinx devices, and started to market their own independent toolchain. Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad) file extension. -- BrianArticle: 158047
On 7/28/2015 6:06 AM, Brian Drummond wrote: > On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote: > >> On 7/27/2015 1:57 PM, Tim Wescott wrote: >>> On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote: >>> >>>> I am very impressed. I was reading about Antti's incredibly tiny FPGA >>>> project board and saw a mention of a FOSS FPGA toolchain. Not just >>>> the compiler, but the entire bitstream generation! > >>>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40- > fpgas/ >> > > Excellent! Though I'm not surprised it's Lattice, I vaguely recall > looking through an early (pre-2000) toolchain of theirs and thinking the > details were closer to the surface than with other vendors. > >> Those who have been in this business long enough may remember the line >> of parts Xilinx made specifically to support an open bit stream. It was >> popular with academia and a number of papers were written about >> researchy things you might do with it. I'm not sure what Xilinx's >> motive was for producing these chips, but they dropped the line and >> crushed the molds. I'm pretty sure there is no mention of these parts >> anywhere on their site now. Or did I only dream all of that? > > Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx > developed them, as they bought the company that did (Algotronics or > Algotronix I think, based in Edinburgh). Presumably they bought them for > tech in general or possibly some key patents rather than the specific > device family. > > Which was something of a dead end in other respects, too fine grained (I > believe' 1 gate, 1FF per CLB). Much simpler and more regular, but > wouldn't scale too well to million-CLB devices dominated by routing, > where the XC4000 and later devices would give the same capacity with a > much smaller and cheaper die. > > I think it was that simple regular structure that made opening the > bitstream format attractive, as well as killing the device long-term. > > You may also recall a company that successfully reverse-engineered the > bitstream for Xilinx devices, and started to market their own independent > toolchain. It has been a very long time, but I don't think NeoCAD was spitting out bitstreams for Xilinx parts where they? I may not remember it right, but I thought their claim to fame was their router which did a better job than the Xilinx tools which is why Xilinx bought them. Rather than bury the NeoCAD tools and moving on, they shipped the NeoCAD tools as their main tool. They reverse engineered the routing I know. I guess it wouldn't be so hard to figure out the bit stream too. I recall that NeoCAD was supporting other companies because they realized what a large job it was to write their own tools. So other new entries to the market used NeoCAD as their only tool. There were clauses in place to give them rights to the software if NeoCAD was bought by a competitor, which is what happened. I'm not sure that was much solace since they all ended up having to support their own software at that point which is what they were trying to get away from. > Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad) > file extension. I seem to recall having the NeoCAD tools for some product other than Xilinx. It may be the ORCA devices which Lucent produced with their license from Xilinx. Not an XC4000 clone, but used Xilinx patents with similar functionality. I seem to recall they had the first CLBs where all components were not equivalent. Lattice does that in several of their FPGA lines now that they have the Lucent FPGA products and Xilinx licenses. I recall that Altera has terms in their software to limit what you can do with the bit stream. If you want to make an ASIC you *have* to come to them. That killed a company who was providing exactly that service, bit stream to ASIC. Do all the FPGA makers do that? I would think that alone would be reason enough to reverse engineer the bit stream. That company could then produce the bit stream themselves which would retain the 1:1 relation between your verified FPGA design and the ASIC. Maybe that is why FPGA companies don't want FOSS tools? It would take away their ASIC business. Is that very popular anymore? I haven't seen it promoted in years. -- RickArticle: 158048
Hello all, I am designing a circuit that requires a 10 GHz ADC and a FPGA to generate a 5 Gbps PRBS. I am not able to find a high speed ADC and a supporting FPGA evaluation board. Does anyone know/ can recommend a board? Thanks in advance, VArticle: 158049
On Tue, 28 Jul 2015 13:32:39 -0400 rickman <gnuarm@gmail.com> wrote: > I recall that NeoCAD was supporting other companies because > they realized what a large job it was to write their own > tools. So other new entries to the market used NeoCAD as > their only tool. There were clauses in place to give them > rights to the software if NeoCAD was bought by a competitor, > which is what happened. I'm not sure that was much solace > since they all ended up having to support their own software > at that point which is what they were trying to get away from. > > > Yup, Xilinx bought them too. But their name lives on in > > the .ncd (neocad) file extension. > > I seem to recall having the NeoCAD tools for some product > other than Xilinx. It may be the ORCA devices which Lucent > produced with their license from Xilinx. Not an XC4000 clone, > but used Xilinx patents with similar functionality. I seem to > recall they had the first CLBs where all components were not > equivalent. Lattice does that in several of their FPGA lines > now that they have the Lucent FPGA products and Xilinx > licenses. And NeoCAD is still around: ************************************************************ ** Lattice Synthesis Engine ** ************************************************************ synthesis -f "spi12_impl1_lattice.synproj" synthesis: version Diamond (64-bit) 3.4.0.80 Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved. Copyright (c) 1995 AT&T Corp. All rights reserved. Copyright (c) 1995-2001 Lucent Technologies Inc. All rights reserved. Copyright (c) 2001 Agere Systems All rights reserved. Copyright (c) 2002-2014 Lattice Semiconductor Corporation, All rights reserved. Tue Jul 28 19:53:33 2015 Jan Coombs -- email valid, else fix dots and hyphen jan4clf2014@murrayhyphenmicroftdotcodotuk
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z