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
Martin Schoeberl wrote: > >I need to use only 5 out of the 8 cases, but for completeness's sake, > > a default case is needed in order to avoid unwanted latches. This default > > case isn't covered by simulation. As a result, it will bring the coverage > > down > > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > > > How do I treat this situation? > > > What about taking the 5th case as the default case. That means > having 4 selects and the default covers the 5th case and > 6th to 8th. I like that idea! I wish I had thought of it... To the OP, I am curious, what tool are you using to analyze your simulation coverage of your code? I'm also curious if having 100% coverage of the HDL does anything other than saying there are no statements that were not tested? I don't think it actually verifies that they code will work will it? For example, if the statements in case 2 and 3 were swapped, it would still be covered, but produce a wrong result. Is there a way to verify that the wrong result will be caught?Article: 106076
David R Brooks <davebXXX@iinet.net.au> wrote: >It certainly is a religious war :-) >FWIW, VHDL derives more from Ada, while Verilog derives from C. >This means that VHDL is strongly typed, while (classic) Verilog is not. >That may be a plus or a minus, according to your viewpoint. Heh, a hardware engineer once told me the only thing you need to remember with VHDL is to only ever use one type..... --Article: 106077
Daniel O'Connor <darius@dons.net.au> wrote: > Uwe Bonnes wrote: > > End of June Eric(?) told that he had not had time yet to put something > > into > > the project he put on sourceforeg. Hopefully things change. > There's code there now. > (I checked it out from SVN and submitted a patch to get it to build under > FreeBSD) I also submitted some patches, with the user visible ones: - try do detect cable type - Reconfigure after Flash programming More to come if patches are applied. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 106078
Guru schrieb: > Thank Antti for uploading them to your site. > What is the difference between the uploaded PPClinux and Hydra PPlinux? > > Guru > > Antti wrote: > > Hi > > > > I have uploaded the files once available from Pauls website at the > > university in Australia > > > > http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=select&id=11 > > > > the archive contains all that I fetched from the web when it was > > available. I do not know exact reasons why the original pages are > > vanished, but for me the files from there have been a big help to get > > ppc linux working on Virtex-4 > > > > Antti no difference, except we do not call it hydra PPClinux :) ok, seriously the support-DVD for hydraXC includes (amongst other goodies) 1) a PPC-linux capable EDK reference design 2) VMware image with pre-installed ppclinux (from Pauls website) configured for ref design 3) small bootloader that pulls the image.bin from the mini-SD card into SDRAM so if you say "update bitstream" in EDK you get download.bit and if you type "make" in the VMWare then you get image.bin and as result inserting a miniSD with download.bit and image.bin will load the PPC-hardware and then eventually the ppclinux. it boots to console prompt and has basic networking capabilities. this getting started is also visualized as the welcome image here http://hydraxc.xilant.com/ :) There are some other drivers what either are or will be available for the linux - sd card driver is due to be released (bitbang sw, native mode not spi) - it has some issues with automtatic partition support - ISP1761 host drivers, they are now released by Philips as open-source (search sourceforge for ISP167x!) unfortunatly for linux 2.6 only (previous under-NDA driver was for linux 2.4.x but its too buggs anyway) AnttiArticle: 106079
Evan, Yes, you are being paranoid. Unlike others, our app notes have been tested, and reviewed by senior engineers... Austin Evan Lavelle wrote: > I've got a Spartan-3 which is configured (in master serial mode) from > an XCF04S, and which is also in a JTAG chain which looks like this: > > connector -> Serial PROM/XCF04S -> XC3S1000 -> 3.3V device ->- > connector <---------------------------------------------------| > > The problem is that bank 4 on the Spartan-3 must have a VCCIO of 3.3V, > and the dedicated JTAG and configuration pins on the Spartan-3 are > powered on VCCAUX, at 2.5V. The last device in the chain is also a > 3.3V-only device. > > I've read Kim Goldblatt's appnote on this (XAPP453), and the obvious > answer is to use a 3.3V JTAG/programming connector, and to set the I/O > voltage on the PROM to 3.3V. There are 4 inputs on the Spartan-3 which > are overdriven (PROG_B, TMS, TCK, TMI) so they need limiting resistors > on them. > > The problem is, I don't really like this. There are 4 (or maybe just > 3) input-protection diodes in the Spartan-3 which are almost > permanently on, at about 9.5mA each. The Spartan-3 data sheet says > that the inputs won't be damaged if the input voltage is kept below > about 3.1V, but the last thing I want is a 676-pin package with blown > inputs which can't be configured. Am I just being paranoid? The other > problem is that my VCCAUX regulator now has to potentially supply > ~120mA instead of ~80mA. > > So, my plan B is to run JTAG and configuration at 2.5V instead. This > means that VCCJ and VCCO on the XCFO4S are at 2.5V instead of 3.3V, > and: > > 1 - the DIN input on the Spartan-3 has reduced noise immunity (2.5V > input, 3.3V buffer), but this should be Ok > > 2 - the 4 JTAG inputs on the other 3.3V device in the chain also have > reduced noise immunity; again, should be Ok > > 3 - the TDO from the 3.3V device gets back to the programming > connector as 3.3V, instead of 2.5V. I can handle this with a 74AHC14 > buffer (a spare from the JTAG drivers at the connector) > > 4 - INIT_B at the Spartan has an internal pullup to 3.3V, but the > XCF04S has a 2.5V INIT_B input. However, the XCF04S data sheet says > that the inputs are at least 3.6V-tolerant for VCCO at a nominal 2.5V. > So, I can just pull up INIT_B to 3.3V anyway. > > At first sight, it seems to me that plan B is much better than plan A. > Any thoughts? > > Thanks - > > EvanArticle: 106080
Markus Zingg wrote: > I have to implement a design which requires an FPGA, but to do so > among other things I obviousely first have to learn one of the two > mentioned languages. Take a book, that teaches both languages and learn that language, that your employer requires first. Learn the other language as you need it. "HDL Chip Design" by Douglas Smith was the book I took. > I have a strong background in C programming > (should that matter anyhow) ... Verilog looks like C. This can be an advantage while learning the syntax and a big disadvantage, because modeling hardware not is the same as writing software. VHDL needs more characters to type (the code becomes bigger) but a lot of parts of the syntax is self-explaining. But because you have strong C background this is not so important. VHDL is strongly typed. A lot of people complain, because that forces them to write want they want but on the other hand a lot of typing errors are trapped by the syntax check. Verilog is the opposite: Less to type, but with a lot of pitfalls for errors. There is a award-winning paper by Clifford E. Cummings: "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!" A lot of pitfalls and none of them would have happened if VHDL would have been chosen. I personally prefer VHDL but the boss and the costumer decide what I have to do. RalfArticle: 106081
Thanks Mike Treseler I am not reading a vhdl netlist. I am reading a uart application codes. For example, the input signal (RXD signal) of FPGA firstly go through a IBUF then a BUFG. What's the uses of them respectively? Why need use these buffers? When need use them? Or we actually don't need to care these buffers at all. Mike Treseler wrote: > ZHI wrote: > > I am a newer for FPGA. I am reading some vhdl codes of others. I find > > they often use some buffers in design, such as IBUF, OBUF, FDCE, > > FDCE_1,etc.I have checked these buffer function but still not very sure > > the reason why these buffers put there. > > Maybe you are looking at a vhdl netlist. > Creating a netlist of buffers registers > and luts from vhdl source code is the > job of synthesis. > > -- Mike TreselerArticle: 106082
> I'm also curious if having 100% > coverage of the HDL does anything other than saying there are no > statements that were not tested? Typically when people refer to 100% coverage all they actually mean is that every statement has been hit. What it 'should' mean is that every statement has been hit under every possible condition as well. That kind of info is also available (at least Modelsim's code coverage tool has it, I'm guessing that other simulators do as well). Even though most people only mean that the code has at least been hit, and not the more inclusive 'under all conditions' the statement that they at least hit every line is at least a big step up from not knowing whether or not you've actually hit every line of code in your testing. > I don't think it actually verifies > that they code will work will it? No > For example, if the statements in > case 2 and 3 were swapped, it would still be covered, but produce a > wrong result. Is there a way to verify that the wrong result will be > caught? Make use of the 'assert' statement liberally throughout both the design code and the testbench code. Using asserts make the simulation testbench self-verifying to the extent that you've coded an assert for every functional point. In the particular case that you've described of swapping cases, presumably 'some' output will misbehave and cause the design to 'not work' at some level. If there is an assert statement checking that the design is working correctly it should catch it. If it doesn't, then this implies that either there was no 'assert' to check that the design was working under those conditions or that the testbench didn't exercise things adequately to uncover the inadvertant 'case swap' or (somewhat unlikely) that cases 2 and 3 really are not distinct and really are the same thing to the extent that they cause no observable misbehaviour of the design. Liberal use of assertions is a 'best practice' (in my opinion and I've been using them for years). VHDL has had it since day 1, Verilog has recently added it. There are now even special languages about to help ease the task of writing the design assertions (google for PSL). KJArticle: 106083
> We have made a PCI board using Xilinx PCI core. with master and target capabilities. It works well with intel PCs, but with AMD PCs if i plug the card the PC will not boot. > > Does any one had similar expereince ? Any pointers for the cause will be helpful for me > > Thank you bijoy Do you have the "enable 66" pins connected correctly? How about the PDE? Are you forcing a certain PCI mode or speed? And does the BIOS have some bus speed setting contrary to that? Are you sure you're decoding the address right? You could have some devices on this PCI bus whereas the one on your intel board could be dedicated. I saw that issue before where it worked fine when it was the only device on the bus but not otherwise. Is your PCI clock going in on a clock pin or do you need to manually adjust the skew on each compile?Article: 106084
I took some ada software courses to learn some of the "software engineering" approaches to design and coding in the similar VHDL language. One of the tenets they used was to never code anything but null in a 'when others' clause. 'When others' was strictly for language issues, and was not to be used for functional code. Anything that could happen was to be handled explicitly, and anything that could not happen was not to be handled, because it could not be tested anyway. Now, in certain HW applications, things like SEUs, reset values, etc. can make "impossible" things suddenly become very probable. But it usually takes far more than adding "others" clauses to handle them correctly, since most synthesis tools perform a reachability analysis, and optimize out anything that is "impossible" anyway. So, if the synthesis tool thinks that input values 6 through 8 are not possible, it will optimize out any logic that distinguishes between them and any possible other value. To reach 100% coverage, you'd be testing code that is going to get optimized out anyway, and your "100%" code coverage metric would be no more meaningful than "99%". BTW, I believe Synplicity has stated that they will start honoring initial values (either explicit or implicit) in their FPL synthesis tools, so booleans and integers will have proper initial values, even if they are not explicitly reset. Now, transitioning out of the reset/config value on the first clock edge after reset/config can be problematic, but that's not an initialization problem (and not one that would be caught simply by using slv data types), it is a reset/config synchronization problem, and a whole other topic altogether. AndyArticle: 106085
Hello Tommy, Thanks for the advice and terminology correction. 50 MHz is the rate that I would like be able to retrieve bit patterns stored in the SDRAM. So I should have put my specification at 1 GB/s (I need to get 20 Bit patterns at 50 MHz). I'll focus on trying to implement the connection over the PLB bus. I understand that this is not the ideal way to start out with FPGAs. Unfortunately though I need the FPGA, and in particular this memory link for my research work so I can't choose an easier project. By now though, as a grad student, I am very used to frustrating learning curves. Thanks again though for helping me choose the easier route to deal with this problem. cheers, -Dan Tommy Thorn wrote: > D. Schuette wrote: >> I'm relatively new to FPGA programming and looking for some advice. I >> have an application that needs reliable, high bandwidth (+50 MHz), > > Bandwidth is measured in bits/s or bytes/s. How much are you storing > each cycle? > >> The three >> possible ways I have come up with for implementing this part of my >> project are: > .... >> 2. As before I could use the EDK memory controller core as a separate >> peripheral on the PLB however this time I could implement my peripheral >> as a master on the PLB bus. I believe that this would allow my peripheral >> to directly access the SDRAM controller without interference of/with the >> processor. However I do not know how difficult it is to write a PLB bus >> master and I do not know how to predict how detrimental other traffic on >> the PLB bus will be to the available bandwidth for my application. > .. > > To me this is the "obvious" right way to go unless you're really > pushing things to the edge (which will require special tricks with > DDR). Rest assured, writing a PLB master is way way easier than > writing a DDR SDRAM controller (admitted I have no experience with PLB, > but otherwise there would be something very wrong with the PLB > design!). > >> As I mentioned I am a relative beginner with FPGA programming and am >> looking for advice on how to proceed. I would also greatly appreciate any >> links to example projects or documentation that might be relevant to this >> project. > > Methinks that this is not likely to be the best way to get started with > FPGAs. You may start with a few simpler projects first, followed by a > few simple PLB peripherals. Otherwise you'll spend a lot of time in > frustration. > > TommyArticle: 106086
bijoy <pbijoy@rediffmail.com> wrote: >Hello all, > >We have made a PCI board using Xilinx PCI core. with master and target capabilities. It works well with intel PCs, but with AMD PCs if i plug the card the PC will not boot. > >Does any one had similar expereince ? Any pointers for the cause will be helpful for me > Did you use the latest core version? A few years ago I had similar problems. The first occurance was solved by using the latest core, the second time certain DELL pcs had a flaw in the bios which didn't allow the card enough time to load the fpga. Try to get a logic analyzer and measure the time between reset and the first configuration access cycle. There should be at least 1 second in between. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106087
I can't remember who in this newsgroup who knows both and, whichever he's using at any given moment, always regrets he doesn't use the other language. NicolasArticle: 106088
Frank Buss wrote: > pinod01@sympatico.ca wrote: > > > The section that is not functioning according to my description is the > > section in the VHDL code that has the IF statement that compares > > "updated_addr = comp_addr". Can someone correct the piece of VHDL > > code below? > > I didn't analyze your code in detail, but if you change a signal in a > process, it will be not changed until the end of the process. Use > variables, if you need some sequential order. > > -- > Frank Buss, fb@frank-buss.de > http://www.frank-buss.de, http://www.it4-systems.de What Frank said, but with some additional info: Signal updates are postponed until the assigning process suspends, either at an explicit wait statement, or at the bottom of the process. Any signal assigned inside the clock-edge if/then clause in a clocked process infers a register. Any reference to that signal is a reference to the output of the inferred register, no matter when/where it occurs relative to any assignment. Variables update immediately upon assigment. A variable reference infers storage (i.e. a register in a clocked process) if the variable is read before it is written in a given execution of the process, in which case it must "remember" the state from the previous execution. If a reference to a variable executes after an assignment to it, then that reference infers a combinatorial path instead of a registered one. AndyArticle: 106089
Andy wrote: > One of the tenets they used was to never code anything but null in a > 'when others' clause. 'When others' was strictly for language issues, > and was not to be used for functional code. Anything that could happen > was to be handled explicitly, and anything that could not happen was > not to be handled, because it could not be tested anyway. Just out of curiousity, was another one of the tenets to not use 'else' (or equivalently only use 'else null;')? Seems like the same rationale would apply to the if/elsif/...else/endif statement as well. > So, if the synthesis tool thinks that input values 6 through 8 are not > possible, it will optimize out any logic that distinguishes between > them and any possible other value. You're assuming that all tools will do this. It's better practice to have the 'when others' code for those that might not do such "in depth" analysis. In fact, one could also say that those tools that disregard the 'when others' statements because the result of their optomization analysis has decided that such states could not possibly occur should be used with suspicion. As you also pointed out, when such things really do matter (i.e. critical designs) the techniques that are then required go far beyond just 'woops I'm in the wrong state, go back to 'Idle' response. For most other applications though the 'woops I'm in the wrong state, go back to 'Idle' response is perfectly appropriate and yet if optomized away it will mean that the synthesized design does not match the source...which is almost always bad. > To reach 100% coverage, you'd be > testing code that is going to get optimized out anyway, and your "100%" > code coverage metric would be no more meaningful than "99%". Depends. Not knowing any more about the design I was simply suggesting that the tools were pointing to a possible design issue that should be looked into. In that spirit, the fact that the tool did not give the desired 100% should be looked at as a 'good thing' in that maybe things like simple power up oddities not being considered is something that should be looked at in the design. KJArticle: 106090
Daniel O'Connor schrieb: > Antti wrote: > > > http://inisyn.org/src/xup/ > > > > its already done! I was kind of hoping someone does it, > > and voila, done... > > Have you (or anyone else) tried it with the Platform USB cable? I'd imagine > it would be almost identical to the stuff that's on the S3E starter board > but you never know how bloody minded some hardware companies can be ;) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C as long as the platform usb and s3e starte use the same FX2 firmware and same CPLD file they should be fairly compatible. the difference could be in additional control outputs of the CPLD as the platform cable has tri-state busdrivers not present in the starterkit. so control outputs for them may have to be tied to some level in the CPLD. well thats a guess I have not checked or tried it yet. AnttiArticle: 106091
Prior to a few years ago, my design style would have been pretty much applicable to either language with little impact, even though I use vhdl. However, in the last few years, I have started using variables instead of signals in vhdl, the former being akin to blocking assignments in verilog, but without the accompanying race-condition risks associated with verilog. The resulting descriptions are much more like SW, in that when a variable is assigned, it is immediately updated, and subsequent references to it are to the updated value. With VHDL signals, or Verilog non-blocking assignments (the most commonly used kind), the code looks like SW, but does not read or execute like it because of the magical postponement of the updates. I now tend to use single, clocked processes within an architecture (akin to a module in verilog), with variables for everything, registered or combinatorial, except the IO. Granted, Verilog would also work if I used the same style, but it is way too easy in Verilog to use the wrong type of assignment when you are using both kinds, and there are no protections against doing so. In VHDL you cannot do a blocking assignment to a signal, and you cannot do a non-blocking assignment to a variable. Since a variable cannot be read by another process, there is no chance of a race condition. Both languages are completely capable of describing virtually any digital logic system that is possible to build (and quite a few that are not!), but it boils down to a particular style, and the pros and cons of that style for a particular user, customer, or organization. AndyArticle: 106092
Hi, All this information is very interesting. I didn't want to make a new thread for my question but I was wondering which of these languages can be used more error-freely while using Xilinx CAD tools ISE and EDK. Because I already know some Verilog however thinking that VHDL is a more widely used language!!, I didn't actually dare to use Verilog for my designs to do simulation or other things that I had to deal with low level HDL in the tools. I really prefer to use Verilog as I'm more comfortable with it and I don't want to spend much time learning VHDL at this time. But I'm afraid that I have to deal with some errors in EDK or ISE or in my simulation because Verilog is not strongly supported by Xilinx tools. Do you have any idea about that? Will I probably face problems just because I'm using Verilog. Thanks, Amir Nicolas Matringe wrote: > I can't remember who in this newsgroup who knows both and, whichever > he's using at any given moment, always regrets he doesn't use the other > language. > > NicolasArticle: 106093
> Yes but the link is for SDRAM (Synchronous Dynamic RAM) while the O.P. > asked about > SRAM (Static RAM) > > <snip from the original post> We would really like to use a DDR2 SRAM (for reasons I don't want to go into), but Mega-core doesn't support it <end snip> There is no such thing as DDR2 SRAM which implies that the original post had a typo. Given that the most likely explanation is that the original poster meant to type 'DDR2 SDRAM' and not 'SRAM' as you have surmised. KJArticle: 106094
KJ wrote: > > For example, if the statements in > > case 2 and 3 were swapped, it would still be covered, but produce a > > wrong result. Is there a way to verify that the wrong result will be > > caught? > > If it doesn't, then this implies that either there was no 'assert' > to check that the design was working under those conditions or that the > testbench didn't exercise things adequately to uncover the inadvertant > 'case swap' or (somewhat unlikely) that cases 2 and 3 really are not > distinct and really are the same thing to the extent that they cause no > observable misbehaviour of the design. That is what I am referring to. The fact that the statements were "exercised" is not the same thing as saying they were "tested" to work correctly. If a tool can tell you if a statement was exercised under "all conditions", what exactly does that mean, "all conditions"? I would assume it means all combinations of the signals that are inputs to the statement. I think it is still up to the test designer to determine if the test distinguishes failures in the code from working code. I guess you could compare it to a spell checker. It will certainly be useful to catch errors and omissions, but it will not substitute for a pair of eyes going over the code just lick as pell checker kin miss at least too different kinds of mistakes. ;^)Article: 106095
> There is no such thing as DDR2 SRAM which implies that the original > post had a typo. Look at this: http://www.necel.com/memory/en/products/sram/ddr-18m.html ;-) ThomasArticle: 106096
Andy wrote: > I took some ada software courses to learn some of the "software > engineering" approaches to design and coding in the similar VHDL > language. > > One of the tenets they used was to never code anything but null in a > 'when others' clause. 'When others' was strictly for language issues, > and was not to be used for functional code. Anything that could happen > was to be handled explicitly, and anything that could not happen was > not to be handled, because it could not be tested anyway. I don't follow this at all. I am pretty sure that putting NULL in a when others clause will create a latch, no? NULL is saying to do nothing which means hold your present state, ergo a latch. > Now, in certain HW applications, things like SEUs, reset values, etc. > can make "impossible" things suddenly become very probable. But it > usually takes far more than adding "others" clauses to handle them > correctly, since most synthesis tools perform a reachability analysis, > and optimize out anything that is "impossible" anyway. Only if the tool can determine that the condition is not "possible". Often the condition is a function of how a design is used rather than how it is built. Given the constraints on the inputs, a condition may be "impossible" with no way for the tool to know that. > So, if the synthesis tool thinks that input values 6 through 8 are not > possible, it will optimize out any logic that distinguishes between > them and any possible other value. To reach 100% coverage, you'd be > testing code that is going to get optimized out anyway, and your "100%" > code coverage metric would be no more meaningful than "99%". > > BTW, I believe Synplicity has stated that they will start honoring > initial values (either explicit or implicit) in their FPL synthesis > tools, so booleans and integers will have proper initial values, even > if they are not explicitly reset. Now, transitioning out of the > reset/config value on the first clock edge after reset/config can be > problematic, but that's not an initialization problem (and not one that > would be caught simply by using slv data types), it is a reset/config > synchronization problem, and a whole other topic altogether.Article: 106097
KJ wrote: > Andy wrote: > > One of the tenets they used was to never code anything but null in a > > 'when others' clause. 'When others' was strictly for language issues, > > and was not to be used for functional code. Anything that could happen > > was to be handled explicitly, and anything that could not happen was > > not to be handled, because it could not be tested anyway. > > Just out of curiousity, was another one of the tenets to not use 'else' > (or equivalently only use 'else null;')? Seems like the same rationale > would apply to the if/elsif/...else/endif statement as well. > > > So, if the synthesis tool thinks that input values 6 through 8 are not > > possible, it will optimize out any logic that distinguishes between > > them and any possible other value. > > You're assuming that all tools will do this. It's better practice to > have the 'when others' code for those that might not do such "in depth" > analysis. In fact, one could also say that those tools that disregard > the 'when others' statements because the result of their optomization > analysis has decided that such states could not possibly occur should > be used with suspicion. As you also pointed out, when such things > really do matter (i.e. critical designs) the techniques that are then > required go far beyond just 'woops I'm in the wrong state, go back to > 'Idle' response. For most other applications though the 'woops I'm in > the wrong state, go back to 'Idle' response is perfectly appropriate > and yet if optomized away it will mean that the synthesized design does > not match the source...which is almost always bad. > > > To reach 100% coverage, you'd be > > testing code that is going to get optimized out anyway, and your "100%" > > code coverage metric would be no more meaningful than "99%". > > Depends. Not knowing any more about the design I was simply suggesting > that the tools were pointing to a possible design issue that should be > looked into. In that spirit, the fact that the tool did not give the > desired 100% should be looked at as a 'good thing' in that maybe things > like simple power up oddities not being considered is something that > should be looked at in the design. > > KJ No, they did not go that far, though you are right, at least when dealing with conditions having more than two possible values. I'm not even saying it is a great idea for hardware, just an interesting way to think about it. In the example above where someone spoke of combining the last legal condition with all the remaining, illegal conditions by using "when others", I would problably prefer something like "when 5 | others", even though it would be identical in operation, it would be a little more self documenting. It is certainly hard to "argue excellence" against covering all the bases, but where does one stop? If the conditions really are unreachable (excluding SEU, invalid synchronization, etc.), regardless of whether the synthesis tool recognizes it or not, how are you going to test it (the rtl)? How do you know that you made the right choice of what to do in that case? In many cases, "when others" is only required because of metavalues in the logic system (x, u, -, etc.) If I'm using enumerated types that only define a subset of the hardware representable states, I've already made a tradeoff. If I want to handle the remaining states, I have to tell the synthesis tool that they even exist (which in itself is based on what representation they use, binary or one hot, etc.) before I can tell it what to do with them. My point about 100% vs 99% coverage was more a stab at blindly thinking (even on the part of the customer, whom we know is always right!) that 100% coverage is good, and 99% coverage is bad. 'Tain't necessarily so, though you are right that uncovered code is a good alert to "go check it out". Perhaps the SW practice came about strictly because of coverage tool issues in the first place (i.e. all uncovered statements had to be null statements?)! AndyArticle: 106098
If your concern is how well Xilinx XST supports Verilog, I'd have to say it's pretty good. I've been using the Xilinx tools with Verilog for a number of years now and it works fine. I'd say that picking VHDL or Verilog is not dependant on the tool support. The tools usually will work fine with either language. The choice should be made on which language will work best for YOU, not based on the Xilinx tools. John Providenza Xesium wrote: > Hi, > > All this information is very interesting. I didn't want to make a new > thread for my question but I was wondering which of these languages can > be used more error-freely while using Xilinx CAD tools ISE and EDK. > Because I already know some Verilog however thinking that VHDL is a > more widely used language!!, I didn't actually dare to use Verilog for > my designs to do simulation or other things that I had to deal with low > level HDL in the tools. I really prefer to use Verilog as I'm more > comfortable with it and I don't want to spend much time learning VHDL > at this time. But I'm afraid that I have to deal with some errors in > EDK or ISE or in my simulation because Verilog is not strongly > supported by Xilinx tools. Do you have any idea about that? > Will I probably face problems just because I'm using Verilog. > > Thanks, > > Amir > > Nicolas Matringe wrote: > > I can't remember who in this newsgroup who knows both and, whichever > > he's using at any given moment, always regrets he doesn't use the other > > language. > > > > NicolasArticle: 106099
Andy wrote:
> Granted, Verilog would also
> work if I used the same style, but it is way too easy in Verilog to use
> the wrong type of assignment when you are using both kinds, and there
> are no protections against doing so.
True. Design rule checking is critical
for variable-style regs but it can done
when vhdl is not available or well supported.
1. Top module is all wires and instances.
2. Sub-modules are built from single, named, clocked blocks.
3. All regs are declared and used only in the single block.
4. All "<=" assignments are to local ports.
5. All "=" assignments are to local regs.
simple example:
http://home.comcast.net/~mike_treseler/single_block.v
http://home.comcast.net/~mike_treseler/single_block.pdf
-- Mike Treseler
PS: yes, I have read Cliff Cummings' Award-Winning Verilog Papers:)
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