Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 123400

Article: 123400
Subject: Re: Null statement in VHDL
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 27 Aug 2007 11:22:29 -0700
Links: << >>  << T >>  << A >>
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: 123401
Subject: Re: Annoying
From: gavin@allegro.com (Gavin Scott)
Date: Mon, 27 Aug 2007 18:28:11 -0000
Links: << >>  << T >>  << A >>
Christian 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
Subject: Re: Null statement in VHDL
From: Mike Lundy <novas0x2a@gmail.com>
Date: Mon, 27 Aug 2007 18:33:09 -0000
Links: << >>  << T >>  << A >>
> 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
Subject: Re: DDR controller - best device to perform
From: rkruger@altera.com
Date: Mon, 27 Aug 2007 11:55:12 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: DDR controller - best device to perform
From: rkruger@altera.com
Date: Mon, 27 Aug 2007 12:00:46 -0700
Links: << >>  << T >>  << A >>
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
Subject: tricking bitgen into creating rom-like behavior
From: mittra@gmail.com
Date: Mon, 27 Aug 2007 19:03:10 -0000
Links: << >>  << T >>  << A >>
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,

Kaushik


Article: 123406
Subject: Re: Null statement in VHDL
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 27 Aug 2007 12:32:47 -0700
Links: << >>  << T >>  << A >>
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





Article: 123407
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Mon, 27 Aug 2007 13:47:41 -0700
Links: << >>  << T >>  << A >>
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...
>
> /Mikhail



Article: 123408
Subject: Re: Newbie with ISE 9_2_02i_lin gets error : Process "Translate"
From: Joseph Samson <user@not.my.company>
Date: Mon, 27 Aug 2007 17:11:18 -0400
Links: << >>  << T >>  << A >>
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 Velocity

Article: 123409
Subject: Re: Null statement in VHDL
From: Alex Colvin <alexc@TheWorld.com>
Date: Mon, 27 Aug 2007 21:14:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
>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ïf

Article: 123410
Subject: Re: tricking bitgen into creating rom-like behavior
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 27 Aug 2007 13:30:55 -0800
Links: << >>  << T >>  << A >>
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.

-- glen


Article: 123411
Subject: Re: Null statement in VHDL
From: Andy <jonesandy@comcast.net>
Date: Mon, 27 Aug 2007 15:09:48 -0700
Links: << >>  << T >>  << A >>
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.

Andy


Article: 123412
Subject: Re: ANNC: FPGA Noise Fundamentals Webcast
From: MikeShepherd564@btinternet.com
Date: Mon, 27 Aug 2007 23:25:35 +0100
Links: << >>  << T >>  << A >>
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, Lattice

Article: 123413
Subject: Re: Null statement in VHDL
From: Andy <jonesandy@comcast.net>
Date: Mon, 27 Aug 2007 15:34:52 -0700
Links: << >>  << T >>  << A >>
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.

Andy


Article: 123414
Subject: Re: tricking bitgen into creating rom-like behavior
From: Andy <jonesandy@comcast.net>
Date: Mon, 27 Aug 2007 15:38:41 -0700
Links: << >>  << T >>  << A >>
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.

andy


Article: 123415
Subject: Re: Null statement in VHDL
From: Mike Lundy <novas0x2a@gmail.com>
Date: Mon, 27 Aug 2007 22:44:42 -0000
Links: << >>  << T >>  << A >>
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
Subject: PLL Power and m/n ratio
From: fpgabuilder <fpgabuilder-groups@yahoo.com>
Date: Mon, 27 Aug 2007 23:07:18 -0000
Links: << >>  << T >>  << A >>
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,
Sanjay


Article: 123417
Subject: Re: PLL Power and m/n ratio
From: austin <austin@xilinx.com>
Date: Mon, 27 Aug 2007 16:38:51 -0700
Links: << >>  << T >>  << A >>
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

Austin

Article: 123418
Subject: Re: bidirectional pin help
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 27 Aug 2007 20:19:25 -0400
Links: << >>  << T >>  << A >>
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.

-Jeff

Article: 123419
Subject: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 01:11:47 -0000
Links: << >>  << T >>  << A >>
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: 123420
Subject: weird issue on Xilinx ML501/ML505 evkit designs
From: vasile <piclist9@gmail.com>
Date: Tue, 28 Aug 2007 02:48:56 -0000
Links: << >>  << T >>  << A >>
Hi,

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,
Vasile


Article: 123421
Subject: Re: tricking bitgen into creating rom-like behavior
From: Sean Durkin <news_aug07@durkin.de>
Date: Tue, 28 Aug 2007 06:28:31 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Newbie with ISE 9_2_02i_lin gets error : Process "Translate"
From: Bob Smith <usenet@linuxtoys.org>
Date: Tue, 28 Aug 2007 05:07:55 GMT
Links: << >>  << T >>  << A >>
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 Smith

Article: 123423
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Tue, 28 Aug 2007 07:33:13 -0000
Links: << >>  << T >>  << A >>
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.
>
> -Jeff


Article: 123424
Subject: Re: Null statement in VHDL
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Tue, 28 Aug 2007 07:45:18 -0000
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search