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
> > If you check out the syn directory in that archive it lists the > > sythesis results for various FPGA's. What is interesting is the > > frequency of operation in a Xilinx device is >3X the Altera device. > > If you look closer you'll see that the Altera devices used are pretty > old... Very old. In this case, the best Altera part used is an EP20K100TC144-3 -- an original APEX 20K part, in the slowest speed grade. That product was manufactured at 0.25u technology. It is being compared to a XC2V80CS144-6, which IIRC is a 0.15u/0.13u hybrid, and is the fastest available Virtex-II speed grade to boot. QUICK REMINDER: Altera numbers speed grades such that lower = faster. Xilinx numbers things so higher = faster. Also, I should point out that the reported speeds appear to be based on synthesis estimates -- you really need to run place & route before you can ever compare results between two architectures. Synthesis performance estimates give you a reasonable idea of how changes in a given design affect its performance, and they *should* be tuned to give the right answer on average over a large set of designs. But on any given design there's no guarantee the estimate will be close to the final P&R value, and there are both systematic design-specific and completely random components to this error. In short, comparing post-synthesis Fmax across two chips on one design is quite inaccurate. As other users have pointed out, this core may also be optimized towards Xilinx like architectures. I have not looked at it and thus do not know if this is the case. Regards, Paul Leventis Altera Corp.Article: 73826
I thought I was being clear when I said not to assume I was affiliated with Altera. So to be clear about it, I am not employed by Altera nor do I have the ability to know whether they are considering or Analyzing NV memory for use in their FPGAs. Unfortunately, when creating my original post, I did not realize nor intend for the Altera email address to have been posted I simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I did not remember since it has been a long time since using Google to post (rather than other more anonymous methods). This lead to my reason for disclosure. As an FPGA industry veteran, I am however very interested in continued market research and discussions, which I hope you will agree, can be beneficial to all FPGA users to create and provide vendors feedback. AUSTIN- You have made assumptions in your postings/responses with respect to security. I never mentioned the word government or any of their standards. You have assumed once again. Shame on you again? - Just kidding. Anyway, the link you provided to the xilinx website was informative (http://tinyurl.com/496n2). A couple of comments: In one of my earlier posts, I did not include other options when mentioning NV memories in SRAM fpgas, I should have included battery backed SRAM, Fuse based methods for Key storage, distributed polygon approaches and likely others. One of the most important points the Xilinx link makes which Austin neglected in his assumption that Security is no less than 100%, is the tradeoff of security with cost. While I did say that it was undetectable, I did not say it was suitable for government applications (another assumption). So, the implication in the original posting is that there would be a very low cost NV solution that would be super costly to reverse engineer (order(s) of magnitude more difficult that Flash or even Antifuse) providing a significantly lower cost solution for those non-government applications needing high security than the solutions that Altera or Xilinx currently offer. A decent article talking about security from a practical perspective: http://www.algotronix.com/content/security%20FPL%202001.pdf Also, now coming back to government, although I am not familiar with the specific published requirements (I add that due diligence to my to-do list), I do believe security has been moving target with rising requirements even for government./? So, just as Austin says that there might be ways to detect and capture the Volatile SRAM stored KEY thus enabling the cracking of governement data stream there is a level of probability and cost function involved that is the current governement requirement. I'll bet that this requirement and cost function will continue rise in time. Austin - Why is it impossible to believe that a new NV memory technology can actually exceed this probability / cost function of detecting the stored volatile key? As for Paul's comparison to Max II - I really do not see very many parallels to the bulk of the discusson in this thread regarding applications for the NV on chip memory. Max II does have NV memory and can potentially integrate an external solution. I am trying to emphasize that much of this thread is beyond that - especially with respect to larger data storage and other NV needs (like that of secure processor code). More discussion? Thanks. "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:0LqdnVRXQ4PYyMbcRVn-vA@rogers.com... > > That's a disclosure ? > > Q: Do you work for Altera, or are affiliated with Altera ? > > My guess is no, this Guy guy does not work for Altera. If he does, it's the > first I've heard of him and he is violating Altera posting protocol by not > clearly stating his affiliation in each posting. His email address is also > not in the format of an altera address for someone with the name Guy, and > besides it bounces. > > > Q: Are Altera considering/analysing NV memory in FPGA ? > > We have Non-Volitile memory in our MAX II CPLD family. A Flash block is > used to store the device configuration program. We also expose 8 Kb of > Flash memory for use by the user -- for example, to absorb functions > normally stored in off-chip serial eproms, such as a device serial number. > > I cannot comment on whether or not we are considering it for future FPGA > families, except to say I doubt we would conduct market research in a public > forum such as this. We typically talk to all of our big customers to get > feedback on family plans, and this is done under NDA. > > Regards, > > Paul Leventis > Altera Corp. > >Article: 73827
All, I was fooled by this posting. Any comments I made should not in any way reflect on Altera, as the poster is obviously masquerading as someone who is. I am mostly angry with myself that I reacted the way I did. This is the second time I have been fooled (by a fake Altera poster)! RATS. I should know better, as Paul, and only a select few post on comp.arch.fpga from Altera. I apologize to the newsgroup. Austin (also from home, but over the vpn network) Paul Leventis (at home) wrote: >>That's a disclosure ? >>Q: Do you work for Altera, or are affiliated with Altera ? > > > My guess is no, this Guy guy does not work for Altera. If he does, it's the > first I've heard of him and he is violating Altera posting protocol by not > clearly stating his affiliation in each posting. His email address is also > not in the format of an altera address for someone with the name Guy, and > besides it bounces. > > >>Q: Are Altera considering/analysing NV memory in FPGA ? > > > We have Non-Volitile memory in our MAX II CPLD family. A Flash block is > used to store the device configuration program. We also expose 8 Kb of > Flash memory for use by the user -- for example, to absorb functions > normally stored in off-chip serial eproms, such as a device serial number. > > I cannot comment on whether or not we are considering it for future FPGA > families, except to say I doubt we would conduct market research in a public > forum such as this. We typically talk to all of our big customers to get > feedback on family plans, and this is done under NDA. > > Regards, > > Paul Leventis > Altera Corp. > >Article: 73828
Followup to: <2s0n6qF1f8t1eU1@uni-berlin.de> By author: "Symon" <symon_brewer@hotmail.com> In newsgroup: comp.arch.fpga > > In case people start targeting MicroBlaze and its tools at vendor A's parts? > ;-) > Maybe not! > Syms. > Well, having an open implementation would reduce (although probably not eliminate) vendor lock-in. Some vendors like lock-in; users usually don't. This, of course, can work in reverse: "Well, we'd rather use vendor X right now because we know there is a migration path from X to A if we should need it, and we can use an optimized design for X." -hpaArticle: 73829
In article <UjJ6d.4414$nj.1325@newssvr13.news.prodigy.com>, Guy <guys@altera.com> wrote: >I thought I was being clear when I said not to assume I was affiliated with >Altera. So to be clear about it, I am not employed by Altera nor do I have >the ability to know whether they are considering or Analyzing NV memory for >use in their FPGAs. Unfortunately, when creating my original post, I did >not realize nor intend for the Altera email address to have been posted I >simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I >did not remember since it has been a long time since using Google to post >(rather than other more anonymous methods). This lead to my reason for >disclosure. This seems a shallow excuse, as you are STILL posting with a forged altera address in the from line. If I was an altera lawyer, I'd already have the subpoena to google in the mail... Oh, and just to respond to the rest of the post: Some standards exist for a very good reason. AES in an FPGA is ~500-1000 slices, 10 BlockRAMs, and ~10 cycles at >50 MHz in a "soft" core. Thus, for medium-medium high security applications, using the SRAM based bitfile encryption as the security keystone costs 1 Litium cell, ~1000 slices, and 10 BlockRAMs. Hardly a huge expense, and a significant win over nonvolatile cells. Especially since the battery itself can be used to form a nice bit of potting/intrusion detection as an additional bit of security. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73830
T Lee wrote: > > Forth is very good for small embedded design. > > -Tony Forth is the perfect hacker language. Write it once and no one else will able to read it again. Every time I follow up on a forth project, I have to re-write it in C so it can be read by future programmers. Sorry Tony, I just don't by it. hamilton AT dimensional DOT comArticle: 73831
OK well how do you apply a restraint to a path then?Article: 73832
OK. What is wrong with this code? I am expecting to initiate the SRL16 with some sort of pattern, then loop it around continuously in a 10 bit pattern, put it to a pad where I can see it with a scope. I get a one little blip but not much. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library UNISIM; use UNISIM.VComponents.all; entity srltest is port( clk : in std_ulogic; q : out std_ulogic ); end srltest; architecture Behavioral of srltest is component SRL16 -- synthesis translate_off generic ( INIT: bit_value:= X"1001"); -- synthesis translate_on port (Q : out STD_ULOGIC; A0 : in STD_ULOGIC; A1 : in STD_ULOGIC; A2 : in STD_ULOGIC; A3 : in STD_ULOGIC; CLK : in STD_ULOGIC; D : in STD_ULOGIC); end component; -- Component Attribute specification for SRL16 -- should be placed after architecture declaration but -- before the begin keyword -- Enter attributes in this section -- Component Instantiation for SRL16 should be placed -- in architecture after the begin keyword signal feedback : std_ulogic; begin SRL16_INSTANCE_NAME : SRL16 -- synthesis translate_off generic map( INIT => X"7878" ) -- synthesis translate_on port map (Q => feedback , A0 => '0', A1 => '1', A2 => '0', A3 => '1', CLK => clk, D => feedback ); q <= feedback; end Behavioral;Article: 73833
<Vivek> wrote in message news:ee8920f.-1@webx.sUN8CHnE... > I was reading the manuals for Chipscope Pro and I am a bit confused. Does ChipScope Pro generate some sort of VHDL block that you place in your design and connect the appropriate signals to? > > Or does it generate some vhdl code which you paste into a block? > > I am using chipscope pro 6.2i. If anyone has information in regards to this, pleas elet me know. Thanks > > Vivek not quite but close, CS core gen generates edif files that you can use in verilog vhdl or schematics core inserter insertst the cores directly to netlist so you would not see them at all. coregen generates example files that provide the template you must use to access the cores. you need to connect the control port(s) from icon to all the actual cores and connect the signals and clock thats it antti ebook.openchip.orgArticle: 73834
Since you have a ".edu" address it might be that you want it for an educational cause. If so, then the price will be a small flat fee for a bunch of copies. Nicholas Weaver wrote: > I need ASAP the pricing information for Synplify Pro for Xilinx, for > budgetary placeholder info. > > Anyone know where to find this? Thanks. > > >Article: 73835
Nicholas - First, I have made my disclosure which unfortunately was taking 3-9 hours to post by Google which exacerbated this whole thread - sorry. I will continue under this Moniker until the end of this thread at which point I will move on to a new user name. I attempt to remain anonymous for now as have many individuals on news groups do for various reasons. Anyways, I did not understand your point about the cost of a standard solution for AES solution. That was my whole point that potentially using a huge cost of detection NV technology would save costs in different ways: on chip NV configuration storage reducing system costs (battery, cpld, external config data). As far as security for Key storageI did say there weren't alternatives that already exist, I was exploring the benefits of this new alternative. Then the conversation moved to other secure data storage. AES is current, before it were many other encryption standards, as time marches on, Secure becomes a non-absolute changing value. I am posing an alternative that might provide an equal or greater cost function of obtaining a stored Key than volatile/battery SRAM etc. Thanks. "Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message news:cjfs04$25cm$1@agate.berkeley.edu... > In article <UjJ6d.4414$nj.1325@newssvr13.news.prodigy.com>, > Guy <guys@altera.com> wrote: > >I thought I was being clear when I said not to assume I was affiliated with > >Altera. So to be clear about it, I am not employed by Altera nor do I have > >the ability to know whether they are considering or Analyzing NV memory for > >use in their FPGAs. Unfortunately, when creating my original post, I did > >not realize nor intend for the Altera email address to have been posted I > >simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I > >did not remember since it has been a long time since using Google to post > >(rather than other more anonymous methods). This lead to my reason for > >disclosure. > > This seems a shallow excuse, as you are STILL posting with a forged > altera address in the from line. > > If I was an altera lawyer, I'd already have the subpoena to google in > the mail... > > > Oh, and just to respond to the rest of the post: > > Some standards exist for a very good reason. > > AES in an FPGA is ~500-1000 slices, 10 BlockRAMs, and ~10 cycles at >50 MHz > in a "soft" core. > > Thus, for medium-medium high security applications, using the SRAM > based bitfile encryption as the security keystone costs 1 Litium cell, > ~1000 slices, and 10 BlockRAMs. > > Hardly a huge expense, and a significant win over nonvolatile cells. > Especially since the battery itself can be used to form a nice bit of > potting/intrusion detection as an additional bit of security. > -- > Nicholas C. Weaver. to reply email to "nweaver" at the domain > icsi.berkeley.eduArticle: 73836
Guy wrote: > As far as security for Key storageI did say there weren't alternatives that > already exist, I was exploring the benefits of this new alternative. Then > the conversation moved to other secure data storage. AES is current, before > it were many other encryption standards, as time marches on, Secure becomes > a non-absolute changing value. I am posing an alternative that might > provide an equal or greater cost function of obtaining a stored Key than > volatile/battery SRAM etc. These things do not have to be mutually exclusive : you could deploy obscurity AND Volatile Keys AND NV cyphers AND UniqueID Seeds, all together in the maximal designs. Each one hikes the time/cost to crack the system. In most commercial systems, you only need to hike it above the cost of development (or possibly above litigation risk-cost, as you may be doing some of this to make it impossible to verify patent infringement ;) In government/banking etc, the data payloads give different cost thresholds. -jgArticle: 73837
In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>, Guy <guys@altera.com> wrote: >Nicholas - >First, I have made my disclosure which unfortunately was taking 3-9 >hours to post by Google which exacerbated this whole thread - sorry. >I will continue under this Moniker until the end of this thread at >which point I will move on to a new user name. I attempt to remain >anonymous for now as have many individuals on news groups do for >various reasons. Actually, most on this newsgroup are DELIBERATELY non-anonymous. If you want to verify me, or Peter Aflke, or Ray Andraka, or just about everybody else on this newsgroup post under their own names because it tells alot, and can be used as a pointer to their copus of work. EG, Ray Andraka is a top flight FPGA engineer, able to get things to fit that others would give up on. While I'm a slighly loony ivory tower academic, who's better at coming up with ways to destroy systems. > Anyways, I did not understand your point about the cost of a > standard solution for AES solution. That was my whole point that > potentially using a huge cost of detection NV technology would save > costs in different ways: on chip NV configuration storage reducing > system costs (battery, cpld, external config data). Just accept that Nonvolatile cells are vastly easier to probe, because to probe a volatile cell, you have to remove the chip, and probe the signals under several layers, without disturbing the power supply. It IS doable, mind you, but its a lot more work. Thus the plaintext key which holds the rest of the system together (eg, the bitfile encryption key) is best stored in volatile cells, and are specified as such in many places. The AES point is that you have an AES key embedded in the bitfile, that is used to on the fly encrypt/decrypt a large external store. Thus to crack the store, you need to get either the encrypted AES key by either doing an analysis on the soft-core encrypter OR on the hard-core bitfile loader to get the bitfile's key which is protecting the AES key. Thus the keystone of unencrypted data is the volatile SRAM of the bitfile encryptor, which should be harder to extract than data stored in nonvolatile cells. Also, since you are posting anonymously (falsly), remember that neither Xilinx nor Altera will willingly slow down the circuits, and adding fab steps would be a big No-Go unless the payoff is really, REALLY big. As I've said, one can use the existing bitfile encryption, a battery, an external flash, and about ~1000 slices of glue to create a large nonvolatile protected store, which will be more secure than efectively any solution which just uses nonvolatile storage. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73838
Nicholas- Thanks for the response. Unfortunately because of my current employeement, I can not post as myself like I have done in the past. I recognize that value and promise in due time, I will do it again. (After this thread I will change to a different anonymous moniker). You raise good points, but it appears that you are making assumptions about NV memory detection when you mention probing - doesn't that assume that there is actually a charge (a la flash) stored? What if there was some other storage mechanism, almost like an un readable ROM bit? Would you agree that if the difficulty/cost of extracting a KEY from this NV memory exceed that of the battery/SRAM storage, then it could very well be considered a superior mechanism? This is what I would like to explore. Also, don't forget the fact that one would not even need to store a key for the configuration data since it would be stored on chip in this NV memory. I'll be back in the morning. what do you think? "Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message news:cjg594$28r1$1@agate.berkeley.edu... > In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>, > Guy <guys@altera.com> wrote: > >Nicholas - > > >First, I have made my disclosure which unfortunately was taking 3-9 > >hours to post by Google which exacerbated this whole thread - sorry. > >I will continue under this Moniker until the end of this thread at > >which point I will move on to a new user name. I attempt to remain > >anonymous for now as have many individuals on news groups do for > >various reasons. > > Actually, most on this newsgroup are DELIBERATELY non-anonymous. If > you want to verify me, or Peter Aflke, or Ray Andraka, or just about > everybody else on this newsgroup post under their own names because it > tells alot, and can be used as a pointer to their copus of work. > > EG, Ray Andraka is a top flight FPGA engineer, able to get things to > fit that others would give up on. > > While I'm a slighly loony ivory tower academic, who's better at coming > up with ways to destroy systems. > > > > Anyways, I did not understand your point about the cost of a > > standard solution for AES solution. That was my whole point that > > potentially using a huge cost of detection NV technology would save > > costs in different ways: on chip NV configuration storage reducing > > system costs (battery, cpld, external config data). > > Just accept that Nonvolatile cells are vastly easier to probe, because > to probe a volatile cell, you have to remove the chip, and probe the > signals under several layers, without disturbing the power supply. It > IS doable, mind you, but its a lot more work. > > Thus the plaintext key which holds the rest of the system together > (eg, the bitfile encryption key) is best stored in volatile cells, and > are specified as such in many places. > > The AES point is that you have an AES key embedded in the bitfile, > that is used to on the fly encrypt/decrypt a large external store. > Thus to crack the store, you need to get either the encrypted AES key > by either doing an analysis on the soft-core encrypter OR on the > hard-core bitfile loader to get the bitfile's key which is protecting > the AES key. > > Thus the keystone of unencrypted data is the volatile SRAM of the > bitfile encryptor, which should be harder to extract than data stored > in nonvolatile cells. > > > > Also, since you are posting anonymously (falsly), remember that > neither Xilinx nor Altera will willingly slow down the circuits, and > adding fab steps would be a big No-Go unless the payoff is really, > REALLY big. > > As I've said, one can use the existing bitfile encryption, a battery, > an external flash, and about ~1000 slices of glue to create a large > nonvolatile protected store, which will be more secure than efectively > any solution which just uses nonvolatile storage. > -- > Nicholas C. Weaver. to reply email to "nweaver" at the domain > icsi.berkeley.eduArticle: 73839
Out of curiosity I ran a couple of syntheses+P&R using Quartus II
4.1SP2 Web Edition. This is just synthesizing the mb_cpu as a top
level, with all ports going to auto-assigned pins (presumably,
internal use could be faster.) Frequency is as reported by Quartus
timing analysis. I obviously didn't do anything fancy to try to make
it any faster.
None of these inferred any memory or DSP blocks.
Device Optimization LEs used Frequency
EP1C4F324C7 Balanced 2930 60.99 MHz
EP1C4F324C7 Speed 3010 76.38 MHz
EP1C4F324C6 Speed 3010 84.21 MHz
EP1S10F484C7 Area 2849 70.55 MHz
EP1S10F484C7 Balanced 2931 71.89 MHz
EP1S10F484C7 Speed 3011 71.60 MHz(!)
EP1S10F484C5 Balanced 2931 90.88 MHz
EP2C8F256C8 Balanced 2993 59.27 MHz
EP2C8F256C8 Speed 3075 60.72 MHz
EP2C8F256C6 Speed 3085(?!) 81.27 MHz
EP2S15F484C5 Balanced 2502 94.79 MHz
EP2S15F484C5 Speed 2580 92.83 MHz(!)
EP2S15F484C3 Balanced 2504(?!) 126.04 MHz
A few surprises:
- Sometimes "Balanced" gives a faster design than "Speed"
- Sometimes the number of LEs/ALUTs change when the only thing changed
is the speed grade of the devices.
-hpa (who wishes Web Edition supported EP2S60 so I could
afford to get a devel kit while they're shipping with those :)
Article: 73840> I have even been told that reading out the state of our battery backed > key memory can be done today. > The reason why I do not believe the latter, is that they have to do it, > while keeping the battery backed memory power ON. Just because we don't know how to do it yet doesn't mean that somebody else doesn't know how to do it. Or that it can't be solved with enough money. On the other hand, if it's cheaper to use social engineering or a rubber hose, then it's good enough. How long do your bits last if I just disconnect the battery? (leakage vs capacitance) What if the chip is cold? > Don't bother to argue with me. It is the NSA, CIA, etc. you would have > to convince. Only if that's his market. Maybe what he is thinking about is good enough for some high volume commercial applications. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73841
>The Virtex-4 FIFO has an optional "fall-through" mode, where data written >into an empty FIFO immediately appears on the read output port. >Responding to a different thread: The Virtex-4 FIFO generate FULL and EMPTY >flags and ALMOST FULL and ALMOST EMPTY flags, all internally synchronized >(rising and falling edges) to the relevant clock domain. We just finished >testing asynchronous operation at 500 MHz read clock rate, with no error in >>10e14 "going empty" cycles. >Peter Alfke, Xilinx Applications Neat. Thanks. Can you measure the metastability parameters? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73842
>* PCI 32-bit design -- about 2^25 bus clock cycles >* PCI 64-bit design -- about 100 ms >* Any PCI-X design -- about 100 ms > >The reason a 32-bit PCI design has so much more >time is that it does not need to be ready to see >the busmode/buswidth broadcast which takes place >at the rising edge of reset. Could I grab the mode/width info with a small amount of external logic? (and pass it to the FPGA when its ready) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73843
>(by the way, http://tinyurl.com is a cool way to minimize the pain of >long URLs) Yes, but please include the full URL too. You never know when some nice service might vanish. > http://tinyurl.com/7xemy In this case, it's: http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=alpa_rosetta -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73844
Followup to: <48eaa469.0409291100.3ae7062a@posting.google.com> By author: cyd@spectrum.montana.edu (Cy Drollinger) In newsgroup: comp.arch.fpga > > I am interested in the compatibility of a VHDL project instantiating a > verilog open core, floating point arthmetic block. Is this possible > and if it is not is there another way to use a verilog open core > inside a VHDL project, a transform of some kind? > It depends on your software. Both Xilinx ISE and Altera Quartus support it just fine, but if you're using other tools it's up to each tool. -hpaArticle: 73845
Hi Guys, IS it possible to estimate FPGA configuration time without actually actually porting the bitmap file to FPGA. By looking at the size of the bitmap file or the size of the core. Thanks, SunilArticle: 73846
Followup to: <IJKdnQvu6JrrM8bcRVn-iA@megapath.net> By author: hmurray@suespammers.org (Hal Murray) In newsgroup: comp.arch.fpga > > >* PCI 32-bit design -- about 2^25 bus clock cycles > >* PCI 64-bit design -- about 100 ms > >* Any PCI-X design -- about 100 ms > > > >The reason a 32-bit PCI design has so much more > >time is that it does not need to be ready to see > >the busmode/buswidth broadcast which takes place > >at the rising edge of reset. > > Could I grab the mode/width info with a small amount of > external logic? (and pass it to the FPGA when its ready) > Yes, you'd have to latch REQ64# if you're doing a 64-bit design, and FRAME#, IRDY#, DEVSEL#, STOP# and TRDY# if you're doing a PCI-X design, on the rising edge of RST#. You'd have to worry about bus loading, though. Also, all of this apply if you're doing a plugin card. If you know ahead of time what kind of bus you're plugging into, things are a bit different. -hpaArticle: 73847
On Wed, 29 Sep 2004 21:08:14 +0200, André Schekatz <andre.schekatz@ruhr-uni-bochum.de> wrote: >How to find a Evaluation board for Xilinx Virtex II > >Hallo, >please can anybody help me? >I want to program a Virtex II or Virtex Pro FPGA Chip. Anybody knows an >evaluation board to program this chips? I want to make a fast analogue >digital converter and I want to make a performance check. Fist I wand to >create a program with mathlab and than by hand with VHDL. Please can >somebody tell me a good Evalation Board? I have a gadget of 1500$. The usual place to start a board search is: http://www.fpga-faq.com/FPGA_Boards.shtml =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 73848
Hi KVM, From my limited exposure to the language (I've just done an introduction course), Pros: 1) Very powerful formal language, or assert statement on steroid for hardware engineers :-) 2) Easy to learn, most of the constructs are logical. 3) Most EDA vendors seem to support it. 4) There are even some vendors which can translate your embedded PSL constructs into hardware monitor. 5) PSL can be embedded in your code (hardware engineer) or put into a separate vunit (verification engineer). 6) PSL is a full formal language, a subset can be used in dynamic simulation. Cons: 1) Only supported by high-end $$$ EDA tools (like Modelsim SE) which will limit its uptake. 2) During my PSL course I felt that I needed another language to check my PSL. 3) Easy to create spaghetti code (unreadable constructs). 4) Requires a different mindset, i.e. engineer who do not use assert statements (other than to stop the simulator) or never heard of OVL will not use it. 5) They created different flavoured version for VHDL and Verilog, so you can not write generic PSL. It shouldn't be too difficult to write a translator between the two flavours but I have seen it yet. 6) Some EDA vendors only support the Verilog flavour If you want to learn language, get yourself onto a PSL course to make sure you learn how to think in PSL, secondly get yourself a tool which can generate VHDL from a drawn waveform, this will enable you to create simple stimulus for your PSL assertions. Get Ben Cohen's book, I definitely like the language and will use it for my next design, Regards, Hans. www.ht-lab.com "Kumar Vijay Mishra" <vizziee@yahoo.com> wrote in message news:889cd7c9.0409290603.252ba577@posting.google.com... > Hi. > > I would like to know the pros and cons of having Property > Specification Language now offered with ModelSim 6.0. What is its > future? In this respect, what is assertion-based verification (ABV)? > And why all this now? > > Thanx in advance. > > KVM.Article: 73849
Hi, I have a PLL in my design. This PLL generates two clocks which are used in my design. Now I want to cut these clocks from the design and generate my own clocks for simulation. The testclocks 'l_sdram_clk' and 'l_sdram_clk_90' are going to run when the PLL is locked so that I use the 'l_pll_locked' signal to enable the generation of the clocks. I try that by using GENERATE. But the simulation shows that 'l_sdram_clk' and 'l_sdram_clk_90' remain undefined. How can I solve that problem ? I would appreciate your help. Rgds André Here's the code: architecture xy of zx is ... signal l_pll_locked : std_logic; -- This signal comes out of the PLL, it gets '1' in the simulation test_1: if (l_pll_locked='1') generate process begin l_sdram_clk <= '1'; wait for 3.75 ns; l_sdram_clk <= '0'; wait for 3.75 ns; end process; end generate; test_2: if (l_pll_locked='1') generate process begin l_sdram_clk_90 <= '1'; wait for 1.875 ns; l_sdram_clk_90 <= '0'; wait for 3.75 ns; l_sdram_clk_90 <= '1'; wait for 1.875 ns; end process; end generate; ... end architecture xy;
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