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
Weng Tianxiang wrote:
> It seems to me that I should buy a VHDL standard book (I've never have
> it).
>
> 93 or 2000 or 2002? Any suggestions?
Get the latest available, but
I would get a copy of Ashenden,
a good vhdl simulator,
and master those first.
-- Mike Treseler
Article: 123401Christian Obel <christian@coo.dk> wrote: > Am I the only one who finds the digital magazine subscription of Xcell > Journal very annoying? I took the opportunity to unsubscribe from ALL Xilinx email stuff. I really enjoyed the print version of the journal. It was a big expensive glossy magazine that announces to the world that Xilinx is a powerful company with the resources to put out something like this. But someone came along and noticed (I'm sure they'll get some sort of award for this) that the PDF documents they send to the printer could just be put up on the web and they can save ALL that large amount of money that went into printing and delivering the magazine. Now it's just one more electronic publication that I'd have to seek out, download, and read out of the many that companies try to get me to look at each month. Sadly I just can't get motivated to spend the extra time to do so. I'm sure Xilinx will save lots of money each year by this move, but I question whether the losses resulting from the decision might not outweigh the cost savings. But of course the one is directly measurable while the other is ephemeral at best. G.Article: 123402
> It seems to me that I should buy a VHDL standard book (I've never have > it). > > 93 or 2000 or 2002? Any suggestions? This is going to sound awful, but I'd actually recommend for your mental health that you not look too deeply at the actual standards. Instead, read about the synthesizers themselves. None of the VHDL synthesizers I've tried completely implement any version of the standard. Instead, they implement odd hybrids of the different versions of the standard, on the grounds that "no one uses this feature" (well, of course! No one uses it because it doesn't work in your popular product!) I get really frustrated when I try to implement something using standard VHDL and find that it is incorrectly or incompletely supported. I wish more people would have higher standards with the software they use. The way I see it, it's false advertising to advertise something as a VHDL synthesizer if it doesn't completely implement the VHDL standard, but not many seem to agree with me. I think it comes down to the difference between engineers and scientists. Scientists prefer theory, and deviations from the ideal grate on us. Engineers prefer practicality, and will tend to solder on (pun intended) through crappy software, more interested in the end result than the process. I have grounding in both, so I complain as I implement, and depend less on crappy software whenever the chance presents itself. Life's too short for bad software.Article: 123403
For Cyclone II devices you will find user guides on alt_dq and alt_dqs megafunctions on the Altera web site at http://www.altera.com/literature/ug/ug_altdq_dqs.pdf. Note that on Cyclone III devices Altera has changed the design/ architecture of DDR/DDR2 interfaces to use a new megafunction called ALTMEMPHY. This new megafunction is included with all versions of the Quartus II software including the free Quartus II Web Edition. This function builds an autocalibrating DDR/DDR2 PHY interface (calibrates out PVT changes) with the goal of relieving designers from much of the timing analysis burden associated with static interfaces and reducing PLL resource needs for wider DDR interfaces. The calibration feature takes advantage of new dynamic phase adjustment circuitry included in the Cyclone III PLL. The PLL phase shift is adjusted at power up and automatically over time to place the read capture clock in the center of the data valid window for the memory data calibrating out changes over process, voltage, and temperature. Cyclone III devices also add 2 additional output registers in the I/O cell that improve write margin timing. The ALTMEMPHY user guide is available at http://www.altera.com/literature/ug/ug_altmemphy.pdf. ALTMEMPHY users have the choice of using the Altera high performance (HP)controller, third party controller, or designing their own controller. The Altera HP controller is included with Altera software subscriptions. Performance specifications are available in the External Memory Interfaces chapter of the Cyclone III Handbook at http://www.altera.com/literature/hb/cyc3/cyc3_ciii51009.pdf . I hope you find this helpful.Article: 123404
On Aug 20, 9:25 am, pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > Hey > > Thanks for your replies, all are very helpful. > But I still don'y know which device to choose. > > At the moment any information about Spartan3 component: IFDDRxxx, OFDDRxxx > and CycloneII: altdq, altdqs will be appreciate. > > Maybe someone have been using both and can compare them. > > -- > PGW For Cyclone II devices you will find user guides on alt_dq and alt_dqs megafunctions on the Altera web site at http://www.altera.com/literature/ug/ug_altdq_dqs.pdf. Note that on Cyclone III devices Altera has changed the design/ architecture of DDR/DDR2 interfaces to use a new megafunction called ALTMEMPHY. This new megafunction is included with all versions of the Quartus II software including the free Quartus II Web Edition. This function builds an autocalibrating DDR/DDR2 PHY interface (calibrates out PVT changes) with the goal of relieving designers from much of the timing analysis burden associated with static interfaces and reducing PLL resource needs for wider DDR interfaces. The calibration feature takes advantage of new dynamic phase adjustment circuitry included in the Cyclone III PLL. The PLL phase shift is adjusted at power up and automatically over time to place the read capture clock in the center of the data valid window for the memory data calibrating out changes over process, voltage, and temperature. Cyclone III devices also add 2 additional output registers in the I/O cell that improve write margin timing. The ALTMEMPHY user guide is available at http://www.altera.com/literature/ug/ug_altmemphy.pdf. ALTMEMPHY users have the choice of using the Altera high performance (HP) controller, third party controller, or designing their own controller. The Altera HP controller is included with Altera software subscriptions. Performance specifications are available in the External Memory Interfaces chapter of the Cyclone III Handbook at http://www.altera.com/literature/hb/cyc3/cyc3_ciii51009.pdf . I hope you find this helpful.Article: 123405
Is there a way I can read in a text / ascii /binary file AFTER P&R is done to mimic a ROM ? I could use block-RAM instead of ROM to read in this file. The normal way to do this is would be to read in the ROM image using core-generator and create a ROM. Then P&R it. I am trying to be clever -- I want to read in a configuration file after P&R is done. Thanks, KaushikArticle: 123406
On Aug 27, 11:33 am, Mike Lundy <novas0...@gmail.com> wrote: > > It seems to me that I should buy a VHDL standard book (I've never have > > it). > > > 93 or 2000 or 2002? Any suggestions? > > This is going to sound awful, but I'd actually recommend for your > mental health that you not look too deeply at the actual standards. > Instead, read about the synthesizers themselves. None of the VHDL > synthesizers I've tried completely implement any version of the > standard. Instead, they implement odd hybrids of the different > versions of the standard, on the grounds that "no one uses this > feature" (well, of course! No one uses it because it doesn't work in > your popular product!) > > I get really frustrated when I try to implement something using > standard VHDL and find that it is incorrectly or incompletely > supported. I wish more people would have higher standards with the > software they use. The way I see it, it's false advertising to > advertise something as a VHDL synthesizer if it doesn't completely > implement the VHDL standard, but not many seem to agree with me. > > I think it comes down to the difference between engineers and > scientists. Scientists prefer theory, and deviations from the ideal > grate on us. Engineers prefer practicality, and will tend to solder on > (pun intended) through crappy software, more interested in the end > result than the process. I have grounding in both, so I complain as I > implement, and depend less on crappy software whenever the chance > presents itself. Life's too short for bad software. Hi Mike, "None of the VHDL synthesizers I've tried completely implement any version of the standard. Instead, they implement odd hybrids of the different versions of the standard" Your comments are interesting and funny !!! There are a lot of definitions I have difficulty to learn so that I have never used them and have never tried them. For example, sharing a signal, block concept and the latest ones that do formal verification are a few features I have never used and tried. I prefer using a very small set of the definitions and the strategy works well. One thing I miss a lot is 'orif' keyword compared to 'elsif'. 'orif' introduces a group of conditions that are mutually exclusive. On any output buses or input buses, all data running on the buses are mutually exclusive. I couldn't persuade James to change his mind. WengArticle: 123407
Thanks for Your answer Mikhail. I am using Altera FPGA. When I compile my design I actualy get waring that my pin is constantly have Vcc value. When my pin works in output mode it should have Vcc value on the output, but I am not shure obout this High impedanse. I understood what You said to me, but I don't think that this is problem. I try something with 1M resistor and this voltage doesn't falling. process (<enable>, <input>) > begin > if (<enable>='0') then > <output> <= <input>; > else > <output> <= 'Z'; > end if; > end process; I understand this code but I have one question if you could answer me. How can I read value that is in bidir pin when it is input. OK, you put it in High impedanse, it is clear. All I do in next few steps is reading this input value. Did You think that in this process I read this value and put it in some temporary value and that value to use in other process or what? That wasn't very clear to me. I want to thank You again for Your try to help me, Mikhail Zoran On Aug 27, 7:13 pm, "MM" <mb...@yahoo.com> wrote: > "Zorjak" <Zor...@gmail.com> wrote in message > > news:1188229899.731509.223520@d55g2000hsg.googlegroups.com... > > > > > I have compiled and programed my fpga and I am not totaly clear about > > somethig. When I use bidirectional pin as input it should be in high > > inpedanse mode, isn't it. But, when I measure the volatage on that pin > > (with multimeter) I am getting 5V. I don't know from where comes this > > 5V. I am very confused. > > Try grounding this pin through a let's say 5K resistor and see if it will > still be at 5V. > > Your synthesizer might not be recognizing a bidirectional signal properly > because you mixed it up with other stuff in the same process. In my > experience it is better to code such things separately following templates > precisely: > > <output> <= <input> when <enable> ='0' else 'Z'; > > OR if you prefer using processes: > > process (<enable>, <input>) > begin > if (<enable>='0') then > <output> <= <input>; > else > <output> <= 'Z'; > end if; > end process; > > If you are using Xilinx open your design in FPGA Editior and see what has > actually been synthesized... > > /MikhailArticle: 123408
manolete@discontrol.net wrote: > On 26 ago, 23:07, Bob Smith <use...@linuxtoys.org> wrote: >> Downloaded ISE 9.2i day before yesterday. Installed t9_2_02i_lin update >> and am just going through the counter example in the "ISE 9.1i Quick Start >> Tutorial" that is in .../doc/usenglish/books/docs/qst/qst.pdf >> >> Everything works until I try to enter the timing constraints. Double- >> clicking "Create Timing Constraints" runs the implement_design function >> which ends with the error: Process "Translate" failed. >> >> This seems similar to a posting by Matthias Alles about "xst fails..." >> and I did a process_cleanup_files as suggested in that thread. >> >> My output is given below. >> >> Any ideas how to get past this? [snip] > > Read the line: > > WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this > technology. > No, this warning will not cause a Translate failure. --- Joe Samson Pixel VelocityArticle: 123409
>It seems to me that I should buy a VHDL standard book (I've never have >it). >93 or 2000 or 2002? Any suggestions? whichever standard (or mix thereof) is supported by the software you expect to use. just because it's in the book doesn't mean it works. -- mac the naïfArticle: 123410
mittra@gmail.com wrote: > Is there a way I can read in a text / ascii /binary file AFTER P&R is > done to mimic a ROM ? > I could use block-RAM instead of ROM to read in this file. I think you can find out where the bits are in the download file and replace them with the desired bits. -- glenArticle: 123411
On Aug 27, 1:33 pm, Mike Lundy <novas0...@gmail.com> wrote: > > It seems to me that I should buy a VHDL standard book (I've never have > > it). > > > 93 or 2000 or 2002? Any suggestions? > > This is going to sound awful, but I'd actually recommend for your > mental health that you not look too deeply at the actual standards. > Instead, read about the synthesizers themselves. None of the VHDL > synthesizers I've tried completely implement any version of the > standard. Instead, they implement odd hybrids of the different > versions of the standard, on the grounds that "no one uses this > feature" (well, of course! No one uses it because it doesn't work in > your popular product!) > > I get really frustrated when I try to implement something using > standard VHDL and find that it is incorrectly or incompletely > supported. I wish more people would have higher standards with the > software they use. The way I see it, it's false advertising to > advertise something as a VHDL synthesizer if it doesn't completely > implement the VHDL standard, but not many seem to agree with me. > > I think it comes down to the difference between engineers and > scientists. Scientists prefer theory, and deviations from the ideal > grate on us. Engineers prefer practicality, and will tend to solder on > (pun intended) through crappy software, more interested in the end > result than the process. I have grounding in both, so I complain as I > implement, and depend less on crappy software whenever the chance > presents itself. Life's too short for bad software. Mike, I share your frustrations, but with a little common sense, most limitations of synthesis are understandable. For instance, time delays (independent of a clock, i.e. "after 5 ns") are meaningless to most synthesizable targets, because there is no ability to accurately implement them. File IO is another (although pre-elaboration level file IO, e.g. using a file to initialize a constant, should be allowed but is not). After all, vhdl is a technology-independent, descriptive language; naturally, there will be some aspects of the language that do not map to certain technology targets. Then there are things like no deferred constants in synthesis still bother me, because there is no good reason for the limitation. Most synthesis tools do not support global signals either. There is an ieee standard for the "minimum" synthesizable subset of vhdl, but its creation was dominated by the big player(s) in synthesis, and focused on what they had already implemented. Since then, updates to the standard have been few and far between, and the standard has also migrated from a template based approach, to a behavioral approach. The tool vendors (some more responsive than others to customer's needs) have since implemented parts of vhdl not handled in the synthesis standard. In some ways, this accelerates the adoption of new features (due to competition), but it also leads to diversity of capabilities across vendors, requiring a minimum "least common denominator" approach to coding for multiple synthesis vendors. The only way to raise the least common denominator is by refusing to buy/use products that fail to keep up with the competition (so they fall out of the business, like synopsys fpga synthesis), or revising the standards (and refusing to buy/use products that don't adhere to the standard). Since both require market response, the standards effort is less meaningful, and has lapsed behind. AndyArticle: 123412
Is there a text version? I've never understood the logic of listening to someone drone on in a thick foreign accent when the same person could just publish the text or write a web article that we can all read much faster. Don't engineers read any more? >Lattice is holding a webcast this Wednesday, August 29th, "Tips to >Avoid Simultaneous Switching Output (SSO) Noise Problems." The >presenters will be Troy Scott, from our software marketing group and >Bertrand Leigh, from our applications engineering group. > >If you're interested, the event takes place live at 11am Pacific, >18:00 GMT. In addition, you will be able to view this webcast archive >on-demand, at your convenience, within 24 hours after the live event >takes place. > >You can register by clicking: >http://www.latticesemi.com/corporate/webcasts/tipstoavoidsimultaneoussw/index.cfm > >Bart Borosky, LatticeArticle: 123413
On Aug 27, 2:32 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Aug 27, 11:33 am, Mike Lundy <novas0...@gmail.com> wrote: > > > > > > It seems to me that I should buy a VHDL standard book (I've never have > > > it). > > > > 93 or 2000 or 2002? Any suggestions? > > > This is going to sound awful, but I'd actually recommend for your > > mental health that you not look too deeply at the actual standards. > > Instead, read about the synthesizers themselves. None of the VHDL > > synthesizers I've tried completely implement any version of the > > standard. Instead, they implement odd hybrids of the different > > versions of the standard, on the grounds that "no one uses this > > feature" (well, of course! No one uses it because it doesn't work in > > your popular product!) > > > I get really frustrated when I try to implement something using > > standard VHDL and find that it is incorrectly or incompletely > > supported. I wish more people would have higher standards with the > > software they use. The way I see it, it's false advertising to > > advertise something as a VHDL synthesizer if it doesn't completely > > implement the VHDL standard, but not many seem to agree with me. > > > I think it comes down to the difference between engineers and > > scientists. Scientists prefer theory, and deviations from the ideal > > grate on us. Engineers prefer practicality, and will tend to solder on > > (pun intended) through crappy software, more interested in the end > > result than the process. I have grounding in both, so I complain as I > > implement, and depend less on crappy software whenever the chance > > presents itself. Life's too short for bad software. > > Hi Mike, > "None of the VHDL > synthesizers I've tried completely implement any version of the > standard. Instead, they implement odd hybrids of the different > versions of the standard" > > Your comments are interesting and funny !!! > > There are a lot of definitions I have difficulty to learn so that I > have never used them and have never tried them. > > For example, sharing a signal, block concept and the latest ones that > do formal verification are a few features I have never used and tried. > > I prefer using a very small set of the definitions and the strategy > works well. > > One thing I miss a lot is 'orif' keyword compared to 'elsif'. > > 'orif' introduces a group of conditions that are mutually exclusive. > > On any output buses or input buses, all data running on the buses are > mutually exclusive. > > I couldn't persuade James to change his mind. > > Weng Weng, What would happen in a simulator if the "orif" conditions were not actually mutually exclusive? How would you allow the user to define said behavior? Is zero-hot and option, or is one-hot guaranteed? How would the user define that? The existing language allows for mutually exclusive conditions, but said conditions must be statically verifiable as mutex and complete (case statements). For dynamic mutex inputs, verification is best handled in an assertion. If a standardized one_hot() or zero_one_hot() function could be created (to operate on an unconstrained vector of booleans, for example), then synthesis could recognize their use in an assertion, and make the appropriate optimizations automatically, without affecting the syntax or structure of the language. The assertion (or other code) could also control what happens when, in fact, the conditions are not mutually exclusive (the same way the language handles indices out of bounds, etc.). In other words, in order to gain that level of control over what happens if mutex is not true, you'd have to use the same amount of code for either solution, and the latter solution does not require a change to the language. Additionally, the use of an assertion is such an application allows the code more flexibility in describing the resulting behavior, without resulting to a single if-orif tree. Simply tell the synthesis tool that, by the way, x and y are one_hot, and it can make optimizations (like sharing resources) efficiently, independent of the rest of the structure. Finally, "orif" would be a very poor choice for such a keyword, even if the feature were a good idea. "Orif" by name implies that multiple conditions are potentially true (logical 'OR' function), and all statements associated with all true conditions would be executed, which is precisely the opposite of what you described. This behavior is equivalent to multiple, non-nested if-then statements. AndyArticle: 123414
On Aug 27, 4:30 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > mit...@gmail.com wrote: > > Is there a way I can read in a text / ascii /binary file AFTER P&R is > > done to mimic a ROM ? > > I could use block-RAM instead of ROM to read in this file. > > I think you can find out where the bits are in the download > file and replace them with the desired bits. > > -- glen Xilinx has a tool for loading roms or rams with hex-file data via the bit file. It merges your original bit file with one or more hex files, according to some memory description. Sorry, I can't recall the name of the utility, but it was developed for use with SW development with embedded CPU(s) in the FPGA, such that you could change the SW code without changing the hardware. andyArticle: 123415
On Aug 27, 3:09 pm, Andy <jonesa...@comcast.net> wrote: > Mike, > > I share your frustrations, but with a little common sense, most > limitations of synthesis are understandable. For instance, time delays > (independent of a clock, i.e. "after 5 ns") are meaningless to most > synthesizable targets, because there is no ability to accurately > implement them. File IO is another (although pre-elaboration level > file IO, e.g. using a file to initialize a constant, should be allowed > but is not). After all, vhdl is a technology-independent, descriptive > language; naturally, there will be some aspects of the language that > do not map to certain technology targets. All true, but remember, I'm complaining about difference between the standard and what companies implement, not the vhdl standard itself. The differences between synthesis and simulation modes (while a tad murky in the standard itself) are perfectly understandable, given both the nature of the output, and vhdl's history. A side note: I'm amused by the parallels between Lisp's development and VHDL's. Both started as documentation formats (... more or less) that someone decided to write an interpreter for. > Then there are things like no deferred constants in synthesis still > bother me, because there is no good reason for the limitation. Most > synthesis tools do not support global signals either. Yeah, both of those bug me. It's so difficult to achieve truly universal constants in a design. > There is an ieee standard for the "minimum" synthesizable subset of > vhdl, but its creation was dominated by the big player(s) in > synthesis, and focused on what they had already implemented. Since > then, updates to the standard have been few and far between, and the > standard has also migrated from a template based approach, to a > behavioral approach. The tool vendors (some more responsive than > others to customer's needs) have since implemented parts of vhdl not > handled in the synthesis standard. In some ways, this accelerates the > adoption of new features (due to competition), but it also leads to > diversity of capabilities across vendors, requiring a minimum "least > common denominator" approach to coding for multiple synthesis vendors. > The only way to raise the least common denominator is by refusing to > buy/use products that fail to keep up with the competition (so they > fall out of the business, like synopsys fpga synthesis), or revising > the standards (and refusing to buy/use products that don't adhere to > the standard). Since both require market response, the standards > effort is less meaningful, and has lapsed behind. That's pretty much my point, yeah. People need to stop allowing companies to shovel crap. Don't buy it if it's crap. If it only implements 1/2 of the standard, let's call it a VH synthisizer instead :P. If you absolutely must buy it (gotta get the product out, after all, even if you have to compromise your values to do so...) then raise a huge stink about how bad the software is. Report every bug you come across. Publicize the worst of them if the vendor still doesn't fix them. Just don't settle for the status quo. C compilers eventually came out of the dark ages. It would be excellent if VHDL synthesizers could do the same.Article: 123416
Hi Folks, I am wondering the implications on PLL power compared to the m/n ratio that is used to generate a particular frequency. So which consumes more power? a. 25MHz src clock into the PLL that generates a 200MHz clock b. 100MHz src clock, 200MHz synthesized clock Thank you. Best regards, SanjayArticle: 123417
Sanjay, I suggest you use the power estimator spreadsheet to answer your question. You did not say if you were asking about Xilinx, or someone else. You will find the V5 power estimator here: http://www.xilinx.com/ise/power_tools/license_virtex5.htm AustinArticle: 123418
Zorjak, I agree with MM, having the input and output behavior in the same process is confusing. Try something like this: en_count <= bidi when con = '0' else '0'; bidi <= '1' when con = '1' else 'Z'; Also, for testing output drive a 1M resistor is too high - I would use <10K. Although if the tools are warning that the output is driven permanently high, this test is unnecessary. -JeffArticle: 123419
Hi,
I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.
> > Hi Mike,
> > "None of the VHDL
> > synthesizers I've tried completely implement any version of the
> > standard. Instead, they implement odd hybrids of the different
> > versions of the standard"
>
> > Your comments are interesting and funny !!!
>
> > There are a lot of definitions I have difficulty to learn so that I
> > have never used them and have never tried them.
>
> > For example, sharing a signal, block concept and the latest ones that
> > do formal verification are a few features I have never used and tried.
>
> > I prefer using a very small set of the definitions and the strategy
> > works well.
>
> > One thing I miss a lot is 'orif' keyword compared to 'elsif'.
>
> > 'orif' introduces a group of conditions that are mutually exclusive.
>
> > On any output buses or input buses, all data running on the buses are
> > mutually exclusive.
>
> > I couldn't persuade James to change his mind.
>
> > Weng
>
> Weng,
>
> What would happen in a simulator if the "orif" conditions were not
> actually mutually exclusive? How would you allow the user to define
> said behavior? Is zero-hot and option, or is one-hot guaranteed? How
> would the user define that?
>
> The existing language allows for mutually exclusive conditions, but
> said conditions must be statically verifiable as mutex and complete
> (case statements). For dynamic mutex inputs, verification is best
> handled in an assertion. If a standardized one_hot() or zero_one_hot()
> function could be created (to operate on an unconstrained vector of
> booleans, for example), then synthesis could recognize their use in an
> assertion, and make the appropriate optimizations automatically,
> without affecting the syntax or structure of the language. The
> assertion (or other code) could also control what happens when, in
> fact, the conditions are not mutually exclusive (the same way the
> language handles indices out of bounds, etc.). In other words, in
> order to gain that level of control over what happens if mutex is not
> true, you'd have to use the same amount of code for either solution,
> and the latter solution does not require a change to the language.
> Additionally, the use of an assertion is such an application allows
> the code more flexibility in describing the resulting behavior,
> without resulting to a single if-orif tree. Simply tell the synthesis
> tool that, by the way, x and y are one_hot, and it can make
> optimizations (like sharing resources) efficiently, independent of the
> rest of the structure.
>
> Finally, "orif" would be a very poor choice for such a keyword, even
> if the feature were a good idea. "Orif" by name implies that multiple
> conditions are potentially true (logical 'OR' function), and all
> statements associated with all true conditions would be executed,
> which is precisely the opposite of what you described. This behavior
> is equivalent to multiple, non-nested if-then statements.
>
> Andy- Hide quoted text -
>
> - Show quoted text -
Hi Andy,
A group of signals is defined as mutually exclusive if either no
signal or only one signal in the group is asserted on any cycle.
Keyword 'orif' has the same language grammar definition as 'elsif'
with one exception: conditional signal contained in leading 'if' or
'elsif' segment and conditional signals contained in the subsequent
and contiguous 'orif' segment in an 'if' statement are mutually
exclusive. Where keyword 'elsif' can be used in a VHDL code, there
keyword 'orif' can be used.
Here is an example on how to use keyword 'orif':
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
...
It has two mutually exclusive signal groups: signals E0, E1 and E2 are
mutually exclusive. So are signals E3, E4 and E5.
The implementation benefits with FPGA are huge !!!
For example:
OutBus has 64-bit width.
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif(CLK'event and CLK = '1') then
If(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
end if;
end if
end process;
1. If the keyword 'orif' is adopted as a VHDL standard, the above
equation would be executed in FPGA chips not by mux, not by case
statement implementation method, but by the most efficient method:
carry chain in Xilinx chips !!!
It would be executed like a sum of products: In assembly language for
shortness:
OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;
The new keyword 'orif' is most beneficial to FPGA users !!!
Please check Xilinx application note about how to implement sum of the
products (I failed to find it)
In other words, if keyword 'orif' is introduced into VHDL standard,
Xilinx carry chain structure would become part of VHDL standard in a
natural way. 'orif' will be refered to carry chain in FPGA
structure !!!
Xilinx Peter, what your idea is about the keyword 'orif'?
2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
that during simulation, if a simulator detects two signals being
active in a mutually exclusive group on current cycle, simulator
issues a fatal error and stops without any user's interference !!!
Simple and reliable !!!
3. I expect Xilinx would be the first company to implement the new
keyword 'orif', because its fastest carry chain feature would be best
used in the situations without users' efforts to change its writing
patterns. You may imagine 64-bit data bus would occupy a lot of space
and resources if not the best carry chains are referenced. And the
routine timing will be hugely saved and running frequency will hugely
boosted.
4. 'orif' name is very appropriate. It means if above conditional
equation is not met, or try this one, or try next, or try the
last, ... it meets the equation above in assembly.
5. Most of programmers never use mutually exclusive property in their
designs and they fear the property would be violated some times. But
here are some hints the violation situation will never happen if it is
appropriate.
a. Data buses are always mutually exclusive !!!
If two data conditions on a data bus may be active at the same cycle,
add minimum additional conditions to make them mutually exclusive.
b. Count loadings are always mutually exclusive !!!
c. All group of register's loadings are always mutually exclusive !!!
d. All FIFO input data loadings are mutually exclusive !!!
6. Keyword 'orif' is useless for IC chip design. Because IC compilers
do their best to optimize them.
7. Mutually exclusiveness is ubiquitout in logic design and I am very
sorry for VHDL without a special keyword to deal with it.
Any comments are welcome.
Weng
Article: 123420Hi, Usually I do not post such questions but I've got no answer from Xilinx and I want to be sure I have right. I've took a deep look to the SODIMM schematic side of ML501 and ML505 from Xilinx. See here: http://www.xilinx.com/bvdocs/userguides/ml505_20061205_bw.pdf SODIMM schematic on page 13. Supply schematic for SODIMM on page 25 (VTTVREF and VTTDDR) Interfacing SODIMM to FPGA on page 3. The schematic is using external 47 ohm terminators for address and control bus and DCI voltage reference resistors for data bus. Active terminators for data bus are supplied from VCC1V8. The regulator used for VTTVREF (page 25) is a 3A sinking/sourcing used usually for external terminators but the load on VTTVREF in my opinion is not bigger than a few miliamps (supplying the VREF of SODIMM and a few Vref inputs in banks 15,17,19,21). Do I have right ? thank you, VasileArticle: 123421
Andy wrote: > Xilinx has a tool for loading roms or rams with hex-file data via the > bit file. It merges your original bit file with one or more hex files, > according to some memory description. Sorry, I can't recall the name > of the utility, but it was developed for use with SW development with > embedded CPU(s) in the FPGA, such that you could change the SW code > without changing the hardware. It's called "data2mem". cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123422
manolete@discontrol.net wrote: > On 26 ago, 23:07, Bob Smith <use...@linuxtoys.org> wrote: >> Downloaded ISE 9.2i day before yesterday. Installed t9_2_02i_lin update >> and am just going through the counter example in the "ISE 9.1i Quick Start >> Tutorial" that is in .../doc/usenglish/books/docs/qst/qst.pdf >> ends with the error: Process "Translate" failed. >> Any ideas how to get past this? > Read the line: > > WARNING:Xst:2734 - Property "use_dsp48" is not applicable for this > technology. Thanks for the reply. Do you have any idea what to do to get rid of this error? thanks Bob SmithArticle: 123423
Thanks for Your try to help, Jeff, I'll try to use input and output behavioral in diferent process. But, a few minutes ago I noticed something else in my work You se that I have one output pin called "test". It has only one driving 'Z' (end of the process). But in my compilaton report I have the same waring as with bidir pin. (Pin test has Vcc driving its datain port). It's like that there is no problem if the pin is biderctional or not. It is something with this "High Impedanse" as I seee it. I am not shure about anything. Library Ieee; Use ieee.std_logic_1164.all; Use Ieee.std_logic_arith.all; Use ieee.std_logic_unsigned.all; Library work; -------------------------------------------------------------------------------- entity io_test_contr is port( con, clk : in std_logic; en_count : out std_logic; bidi : inout std_logic; test : out std_logic ); end io_test_contr; -------------------------------------------------------------------------------- architecture io_test_contr_behav of io_test_contr is signal temp : std_logic; begin process(con, bidi) begin if con='1' then bidi<='1'; en_count<='0'; else bidi<='Z'; if bidi='0' then en_count<='0'; else en_count<='1'; end if; end if; test<='Z'; end process; end architecture; Thanks again for all Your help, Jeff Zoran Jeff Cunningham wrote: > Zorjak, > > I agree with MM, having the input and output behavior in the same > process is confusing. Try something like this: > > en_count <= bidi when con = '0' else '0'; > > bidi <= '1' when con = '1' else 'Z'; > > Also, for testing output drive a 1M resistor is too high - I would use > <10K. Although if the tools are warning that the output is driven > permanently high, this test is unnecessary. > > -JeffArticle: 123424
On 28 Aug., 00:09, Andy <jonesa...@comcast.net> wrote: > On Aug 27, 1:33 pm, Mike Lundy <novas0...@gmail.com> wrote: > > > > > > It seems to me that I should buy a VHDL standard book (I've never have > > > it). > > > > 93 or 2000 or 2002? Any suggestions? > > > This is going to sound awful, but I'd actually recommend for your > > mental health that you not look too deeply at the actual standards. > > Instead, read about the synthesizers themselves. None of the VHDL > > synthesizers I've tried completely implement any version of the > > standard. Instead, they implement odd hybrids of the different > > versions of the standard, on the grounds that "no one uses this > > feature" (well, of course! No one uses it because it doesn't work in > > your popular product!) > > > I get really frustrated when I try to implement something using > > standard VHDL and find that it is incorrectly or incompletely > > supported. I wish more people would have higher standards with the > > software they use. The way I see it, it's false advertising to > > advertise something as a VHDL synthesizer if it doesn't completely > > implement the VHDL standard, but not many seem to agree with me. > > > I think it comes down to the difference between engineers and > > scientists. Scientists prefer theory, and deviations from the ideal > > grate on us. Engineers prefer practicality, and will tend to solder on > > (pun intended) through crappy software, more interested in the end > > result than the process. I have grounding in both, so I complain as I > > implement, and depend less on crappy software whenever the chance > > presents itself. Life's too short for bad software. > > Mike, > > I share your frustrations, but with a little common sense, most > limitations of synthesis are understandable. For instance, time delays > (independent of a clock, i.e. "after 5 ns") are meaningless to most > synthesizable targets, because there is no ability to accurately > implement them. File IO is another (although pre-elaboration level > file IO, e.g. using a file to initialize a constant, should be allowed > but is not). After all, vhdl is a technology-independent, descriptive > language; naturally, there will be some aspects of the language that > do not map to certain technology targets. > > Then there are things like no deferred constants in synthesis still > bother me, because there is no good reason for the limitation. Most > synthesis tools do not support global signals either. The frustrating thing is, that there are papers out there that show how simple it is to greatly expanded the synthesizable subset. Some examples: The following code can be made synthesizable by a simple vhdl->vhdl transformation. A preprocessor would suffice: if rising_edge(clk) and enable='1' then ... Why is there only a single wait statement allowed per process? If all wait statements depend on the same clock signal it is relativly easy to automatically create a state machine with one state per wait statement. What is so hard about replacing "/" by a division circuit? Especially for a tool that is delivered with a core generator that supports division? Especially for division by a constant (can be implemented by a multiplier, yet multiplication is supported)? At least most tools now recognize initialization values for signals. Took them only 20 years to implement that. My frustration comes from work in the EDA software field. I see that really hard tasks that are solved successfully during the synthesis and implementation process and wonder why topics like those above or not handled well, even though they are a lot simpler. Kolja Sulimma
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