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
2017JanFebMarApr2017

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 147025

Article: 147025
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 9 Apr 2010 19:01:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip)
 
> Without starting a major argument, anyone care to share their feelings
> on the differences in the two languages?

I started with verilog, as that is what others I was working with
were doing, and was also told that it was a better choice for
previous C programmers.  (Not that I believe that HDL should be
related to a software language.)

At some point, I learned to read VHDL, at least enough to convert
an module to verilog when needed, or to understand why something
didn't work the way I thought it should.  (I had one project with
schematic capture, VHDL, and AHDL, and then I started adding
verilog to it.)  

It seems to me that verilog, similar to C, gets the ideas across
without being excessively wordy.  In comparison to some other
languages, I find the convenience in C of converting between
char and int without the need for any special conversion operation
(such as the Fortran CHAR function) convenient.  

Well, I write my verilog mostly using continuous assignment,
with a fairly small amount of behavioral verilog.  For those who
prefer behavioral coding, the recommendation might be different.

-- glen

Article: 147026
Subject: Re: I'd rather switch than fight!
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Fri, 9 Apr 2010 12:07:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 3:07=A0pm, rickman <gnu...@gmail.com> wrote:
> I think I have about had it with VHDL. =A0I've been using the
> numeric_std library and eventually learned how to get around the
> issues created by strong typing although it can be very arcane at
> times. =A0I have read about a few suggestions people are making to help
> with some aspects of the language, like a selection operator like
> Verilog has. =A0But it just seems like I am always fighting some aspect
> of the VHDL language.
>
> I guess part of my frustration is that I have yet to see where strong
> typing has made a real difference in my work... at least an
> improvement.

I think Andy has it about right.  If you think signed arithmetic
was a tad messy in VHDL, wait until you find how successfully you
can be screwed by Verilog.  The really cool thing is that Verilog
is polite, and doesn't tell you when it's screwing you.  At least
VHDL is up-front about it.  How many times have you created a
design in VHDL that got through compilation, but was broken in
a surprising way that was directly related to a quirk of the
language?  Betcha you can count the occurrences on one hand.
Verilog does that to you all the time; it has startlingly
weak compile-time checking, and only slightly stronger
elaboration-time checking.

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one?  How about signed values being silently zero-filled
to the width of a wider target?

>=A0My customer uses Verilog and has mentioned several times
> how he had tried using VHDL and found it too arcane to bother with.
> He works on a much more practical level than I often do and it seems
> to work well for him.

Is "practical" here a euphemism?

> One of my goals over the summer is to teach myself Verilog so that I
> can use it as well as I currently use VHDL. =A0Then I can make a fully
> informed decision about which I will continue to use. =A0I'd appreciate
> pointers on good references, web or printed.

Good luck.  As I've pointed out on many occasions, the textbook
situation is much less satisfactory for Verilog than it is
for VHDL.  Whatever you do, PLEASE get yourself a copy of
Sutherland's Verilog Gotchas book (much of it is available free
online).  You may not understand all of it at first, but
you sure will want to revisit it later.  It's just a pity
that it's incomplete and doesn't cover ALL the many ways
in which Verilog can silently mess you up.

To be serious for a moment: a training class from a
reputable independent provider will save you a ton
of money in the long run.  Your time is valuable.

> Without starting a major argument, anyone care to share their feelings
> on the differences in the two languages?

Errrrm, I think I just did.
--
Jonathan Bromley

Article: 147027
Subject: Re: I'd rather switch than fight!
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 09 Apr 2010 19:31:20 GMT
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

>I think I have about had it with VHDL.  I've been using the
>numeric_std library and eventually learned how to get around the
>issues created by strong typing although it can be very arcane at
>times.  I have read about a few suggestions people are making to help
>with some aspects of the language, like a selection operator like
>Verilog has.  But it just seems like I am always fighting some aspect
>of the VHDL language.
>
>I guess part of my frustration is that I have yet to see where strong
>typing has made a real difference in my work... at least an

I also write a lot of C. Over the past years I've noticed that C
compilers (GCC to be exact) have become much more strict when it comes
to type checking. No more automatic casting. I'm sure this is done for
a good reason!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 147028
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 13:05:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 2:07=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

> > I guess part of my frustration is that I have yet to see where strong
> > typing has made a real difference in my work... at least an
> > improvement.
>
> I think Andy has it about right. =A0If you think signed arithmetic
> was a tad messy in VHDL, wait until you find how successfully you
> can be screwed by Verilog. =A0The really cool thing is that Verilog
> is polite, and doesn't tell you when it's screwing you. =A0At least
> VHDL is up-front about it. =A0How many times have you created a
> design in VHDL that got through compilation, but was broken in
> a surprising way that was directly related to a quirk of the
> language? =A0Betcha you can count the occurrences on one hand.
> Verilog does that to you all the time; it has startlingly
> weak compile-time checking, and only slightly stronger
> elaboration-time checking.
>
> How comfortable are you with most-significant bits being
> silently lost when you copy a wide vector into a narrow
> one? =A0How about signed values being silently zero-filled
> to the width of a wider target?

Personally?  Very.

As the proponents of agile programming languages (I love Python) will
point out, the sort of typing errors that you are describing are but a
small subset of the ways you can screw up your design.  Any reasonable
testbench will find these issues.

And BTW, (IMO) it's *much* easier to code a reasonable testbench in
verilog than in VHDL.  But, obviously, your mileage varies.

Regards,
Pat

Article: 147029
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 13:16:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 2:31=A0pm, n...@puntnl.niks (Nico Coesel) wrote:

> I also write a lot of C. Over the past years I've noticed that C
> compilers (GCC to be exact) have become much more strict when it comes
> to type checking. No more automatic casting. I'm sure this is done for
> a good reason!

I used to write a lot of Modula-2.  It was much better than (pre-ANSI)
C (and in fact was one of the contenders for the language the DOD uses
as ADA now, which is what VHDL was based on).  IMO, Modula-2 was at a
sweet spot on verbosity vs. checking.  But then ANSI C came along, and
was "good enough".  Combine that with the compilers getting smart
enough to let you know about potential pitfalls, and there wasn't much
room for another language in the ecological niche that C fills, and,
for example, the Modula-2 ecosystem dwindled to nothing, and the Ada
ecosystem limped along, primarily propped up by the DOD and
educational institutions.

I think there really is a good corollary with HDLs there -- Verilog
synthesizers and simulators have a lot of options for telling you
about warnings and things, and Verilog occupies the same sort of sweet
spot as C, with only a few people preferring Ada or VHDL over C or
Verilog.

Regards,
Pat

Article: 147030
Subject: Re: FMC Boards ?
From: Yan <yan.li.ua@gmail.com>
Date: Fri, 9 Apr 2010 13:58:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:51=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 7, 6:50=A0pm, Yan <yan.li...@gmail.com> wrote:
>
>
>
> > On Mar 31, 10:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote:
>
> > > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp60=
5 ?
>
> > > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD
> > > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD
>
> > > > Buying Xilinx products now means going through Avnet, which is a
> > > > nightmare and HUGE lead times ...
>
> > > > Thanks,
> > > > rudi
>
> > > While the XM104 is listed with a 8 week lead time on the Avnet site, =
I
> > > know that we have these available in inventory and they will ship
> > > promptly after the order is placed. =A0The XM105 is listed with a 2 w=
eek
> > > lead time.
>
> > > There are a number of other companies releasing FMC cards, just be
> > > sure that the cards support a VADJ of 2.5V and there shouldn't be a
> > > problem.
>
> > > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/
>
> > > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com=
/0/62/651.html
>
> > > And Xilinx has a number of other boards in pipeline to be released
> > > next quarter.http://www.xilinx.com/fmc
>
> > > Ed McGettigan
> > > --
> > > Xilinx Inc.
>
> > Ed,
>
> > I just board a ML605 kit and is shopping FMC daughter board. I
> > understand that Xilinx worked with Analog Device on a multi-mode radio
> > demo platform. Analog Devices provided a RF board called Mixed Signal
> > Digital Pre-Distortion (MSDPD) board. I wonder if that board is
> > available for purchase. I got the information from:
>
> >http://www.xilinx.com/publications/prod_mktg/Radio-TDP-SellSheet.pdf
Many thanks.

>
> > Yan- Hide quoted text -
>
> > - Show quoted text -
>
> This FMC board was developed by Analog Devices and while I had some
> involvement in the initial design phase I'm not sure what the go-to-
> market strategy was for the board. =A0I would suggest that you use the
> "Contact Wireless" team link on this page to get further information
> on availability.http://www.xilinx.com/esp/wireless.htm
>
> Ed McGettigan
> --
> Xilinx Inc.


Article: 147031
Subject: Module wise FPGA resource utilization report
From: "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com>
Date: Fri, 09 Apr 2010 17:57:27 -0500
Links: << >>  << T >>  << A >>
Hello,

We are trying to determine the number of slices that a specific module in
the design consumes upon synthesis. Is there a way to generate a report
that shows resource utilization per module using Xilinx ISE Webpack v11.5
?

Thanks and Regards,
Vikram.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147032
Subject: Re: Predefined MACRO's in XST v11.5
From: "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com>
Date: Fri, 09 Apr 2010 18:48:09 -0500
Links: << >>  << T >>  << A >>
RK,

>By having a synthesize-time flag, one could create two different
>codes, and "if-def" according to which version of XST is being used.
>
>eg:
>
>`ifdef L.70  // this is 11.5
>foo <=3D ~bar;
>`else
>foo <=3D !bar;
>`endif

Thank you for your response. Your understanding of our requirement is
correct.
What is L.70 ? Is it something that is predefined in ISE to indicate XST
v11.5 ?

Thanks and Regards,
Vikram.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147033
Subject: Declaring gated clocks
From: VDT153 <vdt153@gmail.com>
Date: Sat, 10 Apr 2010 11:10:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am working on moving an ASIC design to FPGA. For this i am using
synplify pro synthesis tool. But, the tool does not seem to recognise
all the gated clocks [sometimes because it cant recognise the base
clock].

is there any alternative method to declare the base clock for the
gated design other than using the create_clock contraint in the sdc
file.

Thanks in advance
vdt153

Article: 147034
Subject: Re: Module wise FPGA resource utilization report
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sat, 10 Apr 2010 12:57:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:57=A0pm, "vragukumar"
<vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote:
> Hello,
>
> We are trying to determine the number of slices that a specific module in
> the design consumes upon synthesis. Is there a way to generate a report
> that shows resource utilization per module using Xilinx ISE Webpack v11.5
> ?
>
> Thanks and Regards,
> Vikram. =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

The synthesis log/report file should contain the amount of LUT,
Registers, RAM and IO were used.  The number of slices that this will
ultimately be used is very dependent on the entire design, the
utilization of the device and mapping options.

Ed McGettigan
--
Xilinx Inc.

Article: 147035
Subject: Re: I'd rather switch than fight!
From: -jg <jim.granville@gmail.com>
Date: Sat, 10 Apr 2010 16:06:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 2:07=A0am, rickman <gnu...@gmail.com> wrote:
> One of my goals over the summer is to teach myself Verilog so that I
> can use it as well as I currently use VHDL. =A0Then I can make a fully
> informed decision about which I will continue to use. =A0I'd appreciate
> pointers on good references, web or printed.

You could also look at Jan Decaluwe's MyHDL ?

http://www.myhdl.org/doku.php

and a case example here :

http://www.jandecaluwe.com/hdldesign/digmac.html

this allows you to go in either direction, to VHDL to Verilog, and to
'test early'.

-jg




Article: 147036
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jandecaluwe@gmail.com>
Date: Sat, 10 Apr 2010 18:04:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 9, 2:07=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
> wrote:
>
>
>
> > > I guess part of my frustration is that I have yet to see where strong
> > > typing has made a real difference in my work... at least an
> > > improvement.
>
> > I think Andy has it about right. =A0If you think signed arithmetic
> > was a tad messy in VHDL, wait until you find how successfully you
> > can be screwed by Verilog. =A0The really cool thing is that Verilog
> > is polite, and doesn't tell you when it's screwing you. =A0At least
> > VHDL is up-front about it. =A0How many times have you created a
> > design in VHDL that got through compilation, but was broken in
> > a surprising way that was directly related to a quirk of the
> > language? =A0Betcha you can count the occurrences on one hand.
> > Verilog does that to you all the time; it has startlingly
> > weak compile-time checking, and only slightly stronger
> > elaboration-time checking.
>
> > How comfortable are you with most-significant bits being
> > silently lost when you copy a wide vector into a narrow
> > one? =A0How about signed values being silently zero-filled
> > to the width of a wider target?
>
> Personally? =A0Very.
>
> As the proponents of agile programming languages (I love Python) will
> point out, the sort of typing errors that you are describing are but a
> small subset of the ways you can screw up your design. =A0Any reasonable
> testbench will find these issues.

I believe you are mixing up dynamic typing (Python) with
weak typing (Verilog).

Python is dynamically but strongly typed. The silent Verilog-like
behavior as Jonathan was describing is extremely un-pythonic.
In Python, you would get a traceback immediately.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com

Article: 147037
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jandecaluwe@gmail.com>
Date: Sat, 10 Apr 2010 18:21:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:53=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I think I have about had it with VHDL. =A0I've been using the
> > numeric_std library and eventually learned how to get around the
> > issues created by strong typing although it can be very arcane at
> > times. =A0I have read about a few suggestions people are making to help
> > with some aspects of the language, like a selection operator like
> > Verilog has. =A0But it just seems like I am always fighting some aspect
> > of the VHDL language.
>
> > I guess part of my frustration is that I have yet to see where strong
> > typing has made a real difference in my work... at least an
> > improvement. =A0My customer uses Verilog and has mentioned several time=
s
> > how he had tried using VHDL and found it too arcane to bother with.
> > He works on a much more practical level than I often do and it seems
> > to work well for him.
>
> > One of my goals over the summer is to teach myself Verilog so that I
> > can use it as well as I currently use VHDL. =A0Then I can make a fully
> > informed decision about which I will continue to use. =A0I'd appreciate
> > pointers on good references, web or printed.
>
> > Without starting a major argument, anyone care to share their feelings
> > on the differences in the two languages?
>
> > Rick
>
> The best online references are the Sutherland Verilog references.
> There is an online HTML reference for Verilog 95 (excellent), and a
> PDF for Verilog 2001 (good):
>
> http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.htmlh=
ttp://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_g...
>
> Cliff Cummings has a lot of good papers on Verilog at his site:
>
> http://sunburst-design.com/papers/
>
> In particular, if you read and carefully grok his paper about non-
> blocking vs. blocking assignments, you will be well on your way to
> being a Verilog wizard:
>
> http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

The infamous Guideline #5 bans variable semantics from always blocks
with sequential logic. It must be the Worst Guideline ever for RTL
designers.
The result is not wizardry but ignorance.

How are we supposed to "raise the abstraction level" if Verilog RTL
designers
can't even use variables?

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com

Article: 147038
Subject: Re: I'd rather switch than fight!
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sat, 10 Apr 2010 20:42:08 -0500
Links: << >>  << T >>  << A >>
Why do people keep comparing the checking that is inherent in VHDL with
what is done in Verilog? There is a whole class of tools called rtl
checkers that are designed to catch these language gotches before you run
simulation. Yes there are lots of ways to make mistakes in verilog. That
simply means that you need to add a tool that can catch  them.


John	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147039
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sat, 10 Apr 2010 20:03:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 8:04=A0pm, Jan Decaluwe <jandecal...@gmail.com> wrote:
> > As the proponents of agile programming languages (I love Python) will
> > point out, the sort of typing errors that you are describing are but a
> > small subset of the ways you can screw up your design. =A0Any reasonabl=
e
> > testbench will find these issues.
>
> I believe you are mixing up dynamic typing (Python) with
> weak typing (Verilog).

No, not at all.  Sure, Python will give you an error, if, for example,
you add an int to a string:

>>> 1 + '1'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'


But, Python will quite happily let you add an int to a float:

>>> 1 + 1.0
2.0

And, of course, it has no concept of unsigned numbers, etc.  Now, you
can use some modules that know about a few of these things, like the
array module.

Also, Verilog understands a few things about its types, such as the
fact that you can't do a continuous assignment to a register, for
example.

SO, while in principle I *agree* that Python is "dynamically" typed
instead of "weakly" typed, that doesn't alter the fact that in Python
I can bind anything to any identifier.

>>> x =3D 'a'
>>> x =3D 1
>>> x =3D 2.0

Oh, sure I can build my own objects to restrict this, but people who
do that are usually called "static typing weenies" by the Python
community.

So, no, I don't think I'm confused at all (I can't speak for my
readers; I often leave those confused, I'm sure) and I stand by my
assertion that one of the key principles of programming in Python is
that typing errors are typically the least of the possible errors in a
real program.

Regards,
Pat

Article: 147040
Subject: Re: Quartus: rpm: Command not found.
From: Anssi Saari <as@sci.fi>
Date: Sun, 11 Apr 2010 11:46:33 +0300
Links: << >>  << T >>  << A >>
d_s_klein <d_s_klein@yahoo.com> writes:

> It's part of Altera's 'check for updates'.
>
> Just install rpm and be done with it; that's what I did.

Isn't it easier to just symlink rpm to /bin/true?

Article: 147041
Subject: Re: ISE Timing Constraints
From: "Fredxx" <fredxx@spam.com>
Date: Sun, 11 Apr 2010 09:47:50 +0100
Links: << >>  << T >>  << A >>
Gabor wrote:
> On Apr 9, 11:45 am, "Fredxx" <fre...@spam.com> wrote:
>> "austin" <aus...@xilinx.com> wrote in message
>>
>> news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com...
>>
>>
>>
>>> f,
>>
>>> This is your lucky day:
>>
>>> Go read my new blog post:
>>
>>> http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b...
>>
>>> where TIG is discussed, and an example given how it can be used in a
>>> FROM-TO.
>>
>>> Since this design is completely synchronous to the 25 MHz clock, if
>>> properly constrained (and designed) there will be metastability
>>> issues at all.
>>
>>> Your Gray code and synchronizers may not be necessary at all.
>>> However, if you don't have the time (or knowledge) to do this
>>> properly, then having a two clocks that are almost (but not quite)
>>> synchronous can be a nightmare, and no amount of Gary coded
>>> counters, nor synchronizers will save you: you will be "almost
>>> always at the wrong point" so frequently that you have created the
>>> perfect storm for looking at metastable events.
>>
>>> The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
>>> boundaries, or the use of a FIFO from the core generator, is
>>> suggested: do not try to spin your own solution unless you are an
>>> expert in clock domain crossing -- this is not for "newbies" to try
>>> (unless they are trying to develop the skills to do it right).
>>
>>> You would be better off using the 125 MHz clock domain everywhere,
>>> and creating a clock enable that disables one 125 clock out of
>>> every five 125 clocks (for the 100 MHz domain processing). Then you
>>> will have no need to cross any clock boundaries, the design is
>>> simpler, more robust, and will likely just work.
>>
>>> If you then need to transfer data out at 100 MHz, that is where the
>>> FIFO is best used: once, at this boundary. The same is not true for
>>> transferring 100 MHz data into the 125 MHz domain, that is
>>> accomplished by just sampling at the right time (the four clocks not
>>> dropped every 5).
>>
>>> Austin
>>
>> Many thanks, I had made a syntax error where I wrote
>>
>> TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG;
>>
>> and when changed ito
>>
>> TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG;
>>
>> it all worked.
>>
>> I'm sure in my past designs I haven't had this problem, but I guess
>> using clocks which have a common sourse means that the timing
>> analyser has founf something to analyse!
>>
>> I take your point about the sourcing of clocks. For various reasons
>> I want the design to be flexible as possible, and willing to accept
>> the consequences. Also missing a clock every 5 will require a
>> tighter design in terms of timing.
>
> It always bothered me that time specs needed to start with "TS".  This
> is the syntax problem in the first version, not the quotes.

Thanks for pointing that out.  To be honest I don't dislike being forced to 
use a meaningful prefix, but I would have liked ISE to have warned me where 
I hadn't conformed.



Article: 147042
Subject: Microblaze Reset
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Sun, 11 Apr 2010 10:57:22 -0500
Links: << >>  << T >>  << A >>
Is it possible to define an internal reset for a microblaze system. Idealy
I would like it to come from the DCM locked signal. Do I need to define it
in the XBD file or is that just for external ports?

Thanks

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147043
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 11 Apr 2010 12:13:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 9:42=A0pm, "jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> Why do people keep comparing the checking that is inherent in VHDL with
> what is done in Verilog?

Are you suggesting that it is not a fair comparison of two things that
purport to fulfill the same need?  Just like any other competing
products, boosters of one will claim advantage over the weakness of
the other.

> There is a whole class of tools called rtl
> checkers that are designed to catch these language gotches before you run
> simulation.

There are almost always new products that pop up to fulfill any
shortcoming.  That's the marketplace in action.

While this will most likely be a misinterpreted analogy, the existence
of an additional tool such as a crutch is not a reason to prefer a
broken leg over an unbroken one.

> Yes there are lots of ways to make mistakes in verilog. That
> simply means that you need to add a tool that can catch =A0them.
>

Or ask yourself if the hassle of yet another tool (and possible
licensing costs) is worth it?  Maybe it is, maybe it's not, but that
'worth it' decision will most likely be an individual one unless the
tool is very, very good and near zero cost (product cost and learning
curve cost).  Generally speaking, most people would not prefer to use
'yet another' tool in the tool chain unless they feel it adds real
value...and dislike additional tools that fundamentally are there to
catch shortcomings...even if the tool is really good at what it does
and is free, open source.

Rickman's original point is that he thinks he can be  more productive
using Verilog than VHDL.  Whether or not *he* can be more productive
or not depends a lot on Rickman, his usage and frequency of usage of
any language, the types of design errors that he tends to make, etc.

In the end, Rickman learning Verilog likely increases his
marketability since he may master yet another skill that could be of
use in his career.  The actual increased or decreased productivity
that prompted him will in the end will probably be found to be very
low...probably much lower than the ability to work with both languages
(assuming that he can achieve relatively high skill in both languages,
rather than only be marginally skilled in either).

Kevin Jennings

Article: 147044
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sun, 11 Apr 2010 14:02:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 2:13=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Apr 10, 9:42=A0pm, "jt_eaton"
>
> <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> > Why do people keep comparing the checking that is inherent in VHDL with
> > what is done in Verilog?
>
> Are you suggesting that it is not a fair comparison of two things that
> purport to fulfill the same need? =A0Just like any other competing
> products, boosters of one will claim advantage over the weakness of
> the other.

Well, as you point out, comparisons will be made.  Then again, as I
tried to explain in an earlier post, typing errors are but a tiny
class of potential errors that can be made.

> > There is a whole class of tools called rtl
> > checkers that are designed to catch these language gotches before you r=
un
> > simulation.
>
> There are almost always new products that pop up to fulfill any
> shortcoming. =A0That's the marketplace in action.

<MeaninglessGoogleExample>
When I google for "vhdl rtl checker" I actually get more hits than
when I google for "verilog rtl checker".  What does it mean?  Who
knows?
</MeaninglessGoogleExample>

> While this will most likely be a misinterpreted analogy, the existence
> of an additional tool such as a crutch is not a reason to prefer a
> broken leg over an unbroken one.

While this will most likely be a misinterpreted analogy, the potential
existence of a car that will drive for you and automatically encase
you in foam in the event of an accident (like in "Demolition Man") is
not a reason to prefer cars over motorcycles.

> > Yes there are lots of ways to make mistakes in verilog. That
> > simply means that you need to add a tool that can catch =A0them.
>
> Or ask yourself if the hassle of yet another tool (and possible
> licensing costs) is worth it? =A0Maybe it is, maybe it's not, but that
> 'worth it' decision will most likely be an individual one unless the
> tool is very, very good and near zero cost (product cost and learning
> curve cost). =A0Generally speaking, most people would not prefer to use
> 'yet another' tool in the tool chain unless they feel it adds real
> value...and dislike additional tools that fundamentally are there to
> catch shortcomings...even if the tool is really good at what it does
> and is free, open source.

These are good points, but at least *some* people believe in the Unix
mindset of small, great, tools with a laser focus, instead of some big
monolithic black box that you shove code in one side and get a bit
file out the other side.

And the nice thing about (Verilog and VHDL) RTL checkers is that most
of them are quite configurable to a given company's design rules.

Having said all that, it is true that a lone developer might prefer a
cheap, all-in-one solution, and it might be that VHDL is closer to
that than Verilog, but it is certainly not a panacea, and as Rickman
is finding out, the cost of having the additional "safety" features
(in terms of difficulties trying to coax VHDL into letting you do a
few things that Verilog would let you do quite easily) might in some
cases outweigh the cost of not having those same safety features.

> Rickman's original point is that he thinks he can be =A0more productive
> using Verilog than VHDL. =A0Whether or not *he* can be more productive
> or not depends a lot on Rickman, his usage and frequency of usage of
> any language, the types of design errors that he tends to make, etc.

Absolutely agreed.

> In the end, Rickman learning Verilog likely increases his
> marketability since he may master yet another skill that could be of
> use in his career.

Also agreed.  Learning tools that can be useful for your job is always
a great thing.

>=A0The actual increased or decreased productivity
> that prompted him will in the end will probably be found to be very
> low...probably much lower than the ability to work with both languages
> (assuming that he can achieve relatively high skill in both languages,
> rather than only be marginally skilled in either).

We will have to see his anniversary report this time next year ;-)

BTW, slashdot had a verilog/vhdl question awhile back -- which one
should be taught as a first HDL?

http://ask.slashdot.org/article.pl?sid=3D09/05/31/187208

One of the commenters noted that the all the anecdotal evidence
provided by the other comments indicated that people who learned VHDL
first had no problem subsequently learning and working with Verilog,
but that the converse was not true, so *obviously* teaching VHDL was
the correct answer.

http://ask.slashdot.org/comments.pl?sid=3D1251483&cid=3D28160801

I agree with his observation of the provided anecdotes, but the
conclusion seems a bit stretched to me.  If I am allowed one more bad
analogy, it would be as if a study showed that people who learned how
to do basic math with Roman numerals had no problem adapting to Arabic
numerals, but people taught with Arabic numerals struggled with basic
math when they were later expected to use Roman numerals (so
*obviously* we should teach math with Roman numerals first).

Regards,
Pat

Article: 147045
Subject: Re: Debug multiple FPGAs using ChipScope via single JTAG chain
From: Speed <speedboy1211@gmail.com>
Date: Sun, 11 Apr 2010 20:03:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 9:55=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 8, 11:57=A0pm, Speed <speedboy1...@gmail.com> wrote:
>
> > Dear All,
> > =A0 We are planning to design a board with four FPGAs to emulate X86
> > CPU. The FPGA=92s JTAG ports are serially chained together. My problem
> > is that whether the Xilinx=92s ChipScope can support debugging multiple
> > FPGAs via a single JTAG chain at the same time? So we can set
> > different trigger conditions to different FPGA chips at the same time
> > and watch the sampled data from ChipScope.
>
> > Thanks in advance,
> > Speed.
>
> Yes, ChipScope can handle debugging in multiple FPGAs in the same
> chain. =A0Each of the ILA cores will be independent of each other.
>
> Ed McGettigan
> --
> Xilinx Inc.

Dear Ed

    Thanks for your replay


Article: 147046
Subject: Re: Debug multiple FPGAs using ChipScope via single JTAG chain
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 12 Apr 2010 10:13:05 +0100
Links: << >>  << T >>  << A >>
> "Speed" <speedboy1211@gmail.com> wrote in message 
> news:faa559c2-2ef8-440c-b9bc-3ccd212528fd@u31g2000yqb.googlegroups.com...
> Dear All,
>   We are planning to design a board with four FPGAs to emulate X86
> CPU. The FPGAs JTAG ports are serially chained together. My problem
> is that whether the Xilinxs ChipScope can support debugging multiple
> FPGAs via a single JTAG chain at the same time? So we can set
> different trigger conditions to different FPGA chips at the same time
> and watch the sampled data from ChipScope.


Speed,

I hope you'll forgive the 'advert' but depending on what you're trying to
look at in each of the FPGA's you might find my 1 Pin Interface useful...

http://www.1pin-interface.com/

There are five IO ports, the active one can be set on the fly so you could
use one module to access your 4 FPGAs. This gives high level register access
to the devices using just one unused user IO per device.

It might be easier to get up and running than 4 instances of chipscope.



Nial




Article: 147047
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jandecaluwe@gmail.com>
Date: Mon, 12 Apr 2010 02:23:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 5:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote:

> So, no, I don't think I'm confused at all (I can't speak for my
> readers; I often leave those confused, I'm sure) and I stand by my
> assertion that one of the key principles of programming in Python is
> that typing errors are typically the least of the possible errors in a
> real program.

As a thought experiment, imagine a Verilog revision based on a
pythonic mindset. Here's what would likely happen to Jonathan's
examples:

Issue: Most-significant bits silently lost when you copy a
wide vector into a narrow one.
New behavior: run-time or compile-time error.
Rationale: "Errors should never pass silently". (Python zen)

Issue: Signed values silently zero-filled to the width of a
wider target.
New behavior: Use sign bit extension instead.
Rationale: Obvious language design errors should be fixed. Verilog
designers are surprizingly tolerant to those, but a Python language
designer would never get away with this.

As a conclusion, your reference to Python to justify Verilog's
current behavior is rather unconvincing.

Jan

Article: 147048
Subject: Re: I'd rather switch than fight!
From: Chris Higgs <chiggs.99@googlemail.com>
Date: Mon, 12 Apr 2010 03:49:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 9:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:

> And BTW, (IMO) it's *much* easier to code a reasonable testbench in
> verilog than in VHDL. =A0But, obviously, your mileage varies.

I fail to understand why people don't code testbenches in a nice
dynamic language like python.

Limit the use of HDLs to describing the hardware and make use of a
high-level scripting language to read in files/generate stimuli, check
results and introduce errors/modify state dynamically. It's time to
move on from the immensely limited HDL fileIO testbench model.

Thanks,

Chris

Article: 147049
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 12 Apr 2010 04:12:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 6:49=A0am, Chris Higgs <chiggs...@googlemail.com> wrote:
> On Apr 9, 9:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
>
>
> I fail to understand why people don't code testbenches in a nice
> dynamic language like python.
>

Because it's just as productive to code models and deal with only one
language.

> Limit the use of HDLs to describing the hardware and make use of a
> high-level scripting language to read in files/generate stimuli, check
> results and introduce errors/modify state dynamically. It's time to
> move on from the immensely limited HDL fileIO testbench model.
>

Perhaps you should adjust your mindset and consider that testbench
models are in no way limited to 'fileIO testbench models'.
Testbenches can use real models of real devices, it's not that hard.
Error injection handled easily as well.  'High level' scripting
languages don't necessarily have any inherent advantages, they're just
different languages.

KJ



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
2017JanFebMarApr2017

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