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 106050

Article: 106050
Subject: Re: FPGA : PCI-Xilinx Core, PC not booting
From: "Donato Pace" <donatopace@infinito.it>
Date: Mon, 7 Aug 2006 10:45:32 +0200
Links: << >>  << T >>  << A >>
Hello,

i have a problem to realize the PCI interface.....



can you help me????

how can i do??


i have ML455 board VIRTEX4 PCI

how can i do to comunicate with bus PCI??  i have bought the CORE but i 
don't know how can i use it and how create a driver..

please help me.












"bijoy" <pbijoy@rediffmail.com> ha scritto nel messaggio 
news:ee9d6b3.-1@webx.sUN8CHnE...
> Hello all,
>
> We have made a PCI board using Xilinx PCI core. with master and target 
> capabilities. It works well with intel PCs, but with AMD PCs if i plug the 
> card the PC will not boot.
>
> Does any one had similar expereince ? Any pointers for the cause will be 
> helpful for me
>
> Thank you bijoy 



Article: 106051
Subject: Re: How do I treat "default" case which is useless?
From: "Mr. Ken" <Mr. Ken@asdf>
Date: Mon, 7 Aug 2006 16:47:45 +0800
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> wrote in message
news:tMyBg.7003$qw5.1533@trnddc06...
> Mr. Ken wrote:
> > I need to use only 5 out of the 8 cases, but for completeness's sake,
> > a default case is needed in order to avoid unwanted latches. This
default
> > case isn't covered by simulation. As a result, it will bring the
coverage
> > down
> > from 100% to 99%. It's kinda annoying to explain this 1% to customer.
> >
> > How do I treat this situation?
>
> Could you leave the default case blank (but still include the default)
> and get better coverage numbers?  If there's a statement saying "clear
> the register" that will never be executed, it's still a statement that's
> not covered.  If it's blank, will the simulation coverage still have a
> problem that the emty branch was never entered?

Thank you.

For safety's sake, in the default case, I set the registers/variables to
zero.
The reason is that, without this statement, design compiler will infer a
latch
for it if it's not a clocked statement.

I could have put "//synopsys case full_case" but client's FPGA/ASIC
synthesizer
might get into problem.




Article: 106052
Subject: Re: verilog versus vhdl
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Mon, 7 Aug 2006 10:03:55 +0100
Links: << >>  << T >>  << A >>

"Markus Zingg" <m.zingg@nct.ch> wrote in message
news:vdj9d2hnlfdprab5q048vv0si9qiplrnf6@4ax.com...
> Hi Group
>
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages.

Doesn't seem that obvious to me... learn both! Your life will then be much
easier. :-)

For my part, I prefer the "look" of Verilog but the "feel" of VHDL, if that
makes sense. Both languages have good points and bad points, but on the
whole I like VHDL best. I'd say it has a longer learning curve than Verilog,
but once you've got to the top of it the view is much nicer.

Cheers,

        -Ben-



Article: 106053
Subject: Re: How do I treat "default" case which is useless?
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Mon, 7 Aug 2006 11:16:11 +0200
Links: << >>  << T >>  << A >>
>I need to use only 5 out of the 8 cases, but for completeness's sake,
> a default case is needed in order to avoid unwanted latches. This default
> case isn't covered by simulation. As a result, it will bring the coverage
> down
> from 100% to 99%. It's kinda annoying to explain this 1% to customer.
>
> How do I treat this situation?
>
What about taking the 5th case as the default case. That means
having 4 selects and the default covers the 5th case and
6th to 8th.

Martin 



Article: 106054
Subject: Re: How do I treat "default" case which is useless?
From: "Symon" <symon_brewer@hotmail.com>
Date: 7 Aug 2006 11:38:59 +0200
Links: << >>  << T >>  << A >>
Hi Ken,
I know you're using Verilog, but in VHDL I might try defining the thing 
which does the selection as an integer of range 0 to 4 and see if that 
helped prevent the latch inference.
HTH, Syms.

"Mr. Ken" <Mr. Ken@asdf> wrote in message 
news:44d6aa86$1@news.starhub.net.sg...
>I need to use only 5 out of the 8 cases, but for completeness's sake,
> a default case is needed in order to avoid unwanted latches. This default
> case isn't covered by simulation. As a result, it will bring the coverage
> down
> from 100% to 99%. It's kinda annoying to explain this 1% to customer.
>
> How do I treat this situation?
>
>
> 



Article: 106055
Subject: WHAT SITUATION I NEED A BUFFER
From: "ZHI" <threeinchnail@gmail.com>
Date: 7 Aug 2006 03:02:04 -0700
Links: << >>  << T >>  << A >>
I am a newer for FPGA. I am reading some vhdl codes of others. I find
they often use some buffers in design, such as IBUF, OBUF, FDCE,
FDCE_1,etc.I have checked these buffer function but still not very sure
the reason why these buffers put there. Is there anybody kindly tell me
what situation we need a buffer? Or just give me some materials of it.
I can check it by myself. Thanks


Article: 106056
Subject: Re: DDR2 SRAM Stratix II questions
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 07 Aug 2006 10:34:43 GMT
Links: << >>  << T >>  << A >>

"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:1154368574.396239.245890@b28g2000cwb.googlegroups.com...
> Mike Treseler wrote:
>> eric.amundsen@gmail.com wrote:
>>
>> > We would really like to use a DDR2 SRAM (for reasons I don't
>> > want to go into), but Mega-core doesn't support it.
>>
>> Anything wrong with this one?
>> http://www.altera.com/literature/ug/ug_ddr_sdram.pdf
>
> SRAM != SDRAM :-)
>
Perhaps you should at least base your reply on the title of the document 
instead of the name of the link....or even better on more than just the 
title.

In any case, Altera's MegaCore (see link above) supports both DDR and DDR2 
memories.  I'm kind of missing why the original poster is not seeing this as 
well.

KJ 



Article: 106057
Subject: Re: verilog versus vhdl
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 07 Aug 2006 11:39:03 +0100
Links: << >>  << T >>  << A >>
Markus Zingg <m.zingg@nct.ch> writes:

> Hi Group
> 
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages. I got the impression that europe seems to be more
> vhdl centric whereas verilog seems to be more popular in the US but
> this argument alone is for reasons beond the scope of this question
> not so important to me. I have a strong background in C programming
> (should that matter anyhow) and in general experience with embedded
> systems, but FPGAs are new to me. I'm otherwise completely open and
> alas wonder what you guys suggest I should choose. I'm mostly
> interested in replies from people which know both languages cause
> otherwise I fear that this thread ends up in some sort of religious
> war...
> 

I've seen this description on comp.lang.vhdl:
http://groups.google.co.uk/group/comp.lang.vhdl/browse_thread/thread/ecda44d121d1905c/a1df8e111cd1fbd7?lnk=st&q=&rnum=1&hl=en#a1df8e111cd1fbd7

"Verilog was designed by a bunch of hardware guys who didn't know a
thing about designing software. We had to beat on it before we could
make any real work with it.

VHDL was designed by a bunch of software guys who didn't know a thing
about designing hardware. We had to beat on it before we could make
any real work with it."

Not that it helps you any!

Personally, I prefer VHDL because the strong-typing means the compiler
can catch lots of problems for you.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 106058
Subject: Re: Xilinx ISE 8.2 implementation problem
From: heinerlitz@gmx.de
Date: 7 Aug 2006 04:10:50 -0700
Links: << >>  << T >>  << A >>
Try to convert back to ISE 8.1. I had the same problems with ise 8.2
where I had some bugs in the design and 8.2 stopped PAR without giving
any information about the problems. With 8.1 I experienced the same
problems but at least got an error message which helped me solve the
problem.

heiner


Matthieu Cattin schrieb:

> Hi,
>
> I'm using ISE 8.2.01i and Synplify 8.6.1 as synthesis tool.
> For one of my project, I can synthesize but when I try to launch
> implementation it stops quite imediatly WITHOUT ANY ERROR MESSAGE !!!
> 
> Does anyone already have such a problem?
> 
> Thanks for your help.


Article: 106059
Subject: Re: DDR2 SRAM Stratix II questions
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: 7 Aug 2006 04:32:46 -0700
Links: << >>  << T >>  << A >>

KJ wrote:
> "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message
> news:1154368574.396239.245890@b28g2000cwb.googlegroups.com...
> > Mike Treseler wrote:
> >> eric.amundsen@gmail.com wrote:
> >>
> >> > We would really like to use a DDR2 SRAM (for reasons I don't
> >> > want to go into), but Mega-core doesn't support it.
> >>
> >> Anything wrong with this one?
> >> http://www.altera.com/literature/ug/ug_ddr_sdram.pdf
> >
> > SRAM != SDRAM :-)
> >
> Perhaps you should at least base your reply on the title of the document
> instead of the name of the link....or even better on more than just the
> title.
>
> In any case, Altera's MegaCore (see link above) supports both DDR and DDR2
> memories.  I'm kind of missing why the original poster is not seeing this as
> well.

Yes but the link is for SDRAM (Synchronous Dynamic RAM) while the O.P.
asked about
SRAM (Static RAM)


   Sylvain


Article: 106060
Subject: 3.3V configuration of Spartan-3?
From: Evan Lavelle <eml@nospam.uk>
Date: Mon, 07 Aug 2006 13:00:14 +0100
Links: << >>  << T >>  << A >>
I've got a Spartan-3 which is configured (in master serial mode) from
an XCF04S, and which is also in a JTAG chain which looks like this:

connector -> Serial PROM/XCF04S -> XC3S1000 -> 3.3V device ->-
connector <---------------------------------------------------|

The problem is that bank 4 on the Spartan-3 must have a VCCIO of 3.3V,
and the dedicated JTAG and configuration pins on the Spartan-3 are
powered on VCCAUX, at 2.5V. The last device in the chain is also a
3.3V-only device.

I've read Kim Goldblatt's appnote on this (XAPP453), and the obvious
answer is to use a 3.3V JTAG/programming connector, and to set the I/O
voltage on the PROM to 3.3V. There are 4 inputs on the Spartan-3 which
are overdriven (PROG_B, TMS, TCK, TMI) so they need limiting resistors
on them.

The problem is, I don't really like this. There are 4 (or maybe just
3) input-protection diodes in the Spartan-3 which are almost
permanently on, at about 9.5mA each. The Spartan-3 data sheet says
that the inputs won't be damaged if the input voltage is kept below
about 3.1V, but the last thing I want is a 676-pin package with blown
inputs which can't be configured. Am I just being paranoid? The other
problem is that my VCCAUX regulator now has to potentially supply
~120mA instead of ~80mA.

So, my plan B is to run JTAG and configuration at 2.5V instead. This
means that VCCJ and VCCO on the XCFO4S are at 2.5V instead of 3.3V,
and:

1 - the DIN input on the Spartan-3 has reduced noise immunity (2.5V
input, 3.3V buffer), but this should be Ok

2 - the 4 JTAG inputs on the other 3.3V device in the chain also have
reduced noise immunity; again, should be Ok

3 - the TDO from the 3.3V device gets back to the programming
connector as 3.3V, instead of 2.5V. I can handle this with a 74AHC14
buffer (a spare from the JTAG drivers at the connector)

4 - INIT_B at the Spartan has an internal pullup to 3.3V, but the
XCF04S has a 2.5V INIT_B input. However, the XCF04S data sheet says
that the inputs are at least 3.6V-tolerant for VCCO at a nominal 2.5V.
So, I can just pull up INIT_B to 3.3V anyway.

At first sight, it seems to me that plan B is much better than plan A.
Any thoughts?

Thanks -

Evan

Article: 106061
Subject: Who is your favourite FPGA guru?
From: "Tony Burch" <tony@burched.com.au>
Date: Mon, 7 Aug 2006 22:18:47 +1000
Links: << >>  << T >>  << A >>
Hi all,

I was just pondering the idea of "gurus" & I thought the following questions 
may hopefully make some interesting & entertaining discussion.

Including people in this newsgroup & others working in the field, whom do 
you consider to be the present-day "gurus" in FPGA system design? ...I mean 
the people who are well known & highly respected for their work & 
contributions in this field.

Who is your favourite guru & why?

:) Tony



Article: 106062
Subject: Re: How do I treat "default" case which is useless?
From: "Gabor" <gabor@alacron.com>
Date: 7 Aug 2006 05:37:05 -0700
Links: << >>  << T >>  << A >>

Mr. Ken wrote:
> "John_H" <johnhandwork@mail.com> wrote in message
> news:tMyBg.7003$qw5.1533@trnddc06...
> > Mr. Ken wrote:
> > > I need to use only 5 out of the 8 cases, but for completeness's sake,
> > > a default case is needed in order to avoid unwanted latches. This
> default
> > > case isn't covered by simulation. As a result, it will bring the
> coverage
> > > down
> > > from 100% to 99%. It's kinda annoying to explain this 1% to customer.
> > >
> > > How do I treat this situation?
> >
> > Could you leave the default case blank (but still include the default)
> > and get better coverage numbers?  If there's a statement saying "clear
> > the register" that will never be executed, it's still a statement that's
> > not covered.  If it's blank, will the simulation coverage still have a
> > problem that the emty branch was never entered?
>
> Thank you.
>
> For safety's sake, in the default case, I set the registers/variables to
> zero.
> The reason is that, without this statement, design compiler will infer a
> latch
> for it if it's not a clocked statement.
>
> I could have put "//synopsys case full_case" but client's FPGA/ASIC
> synthesizer
> might get into problem.

You can get the same thing as full_case by assigning X to all outputs
in the default, but this again leaves the choice up to the synthesizer
which means any simulation coverage will not be 100%.  I like the
idea of setting the default case outputs to one of the previously
defined states better.

Just my 2 cents,
Gabor


Article: 106063
Subject: Re: 100m JTAG cable
From: Daniel O'Connor <darius@dons.net.au>
Date: Mon, 07 Aug 2006 22:14:05 +0930
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:
> End of June Eric(?) told that he had not had time yet to put something
> into
> the project he  put on sourceforeg. Hopefully things change.

There's code there now.
(I checked it out from SVN and submitted a patch to get it to build under
FreeBSD)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 106064
Subject: Re: verilog versus vhdl
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Mon, 07 Aug 2006 08:46:00 -0400
Links: << >>  << T >>  << A >>
On Sat, 05 Aug 2006 19:02:31 +0200, Markus Zingg wrote:

> Hi Group
> 
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages. I got the impression that europe seems to be more
> vhdl centric whereas verilog seems to be more popular in the US but
> this argument alone is for reasons beond the scope of this question
> not so important to me. I have a strong background in C programming
> (should that matter anyhow) and in general experience with embedded
> systems, but FPGAs are new to me. I'm otherwise completely open and
> alas wonder what you guys suggest I should choose. I'm mostly
> interested in replies from people which know both languages cause
> otherwise I fear that this thread ends up in some sort of religious
> war...
> 
> TIA
> 
> Markus

I strongly prefer Verilog. It's C like which makes it much easier to read
for a C programmer. It's very concise which also makes it easier to read
and write. Like C it's easy to write very efficient code with Verilog. On
the downside it's missing a lot of C's important features like structures
and procedures. Verilog has simple functions and a weak task mechanism
instead of C's procedures. However I haven't found that limiting. 

VHDL is a much more complex language than Verilog. VHDL code is very
verbose, painfully so. However it does have capabilities that Verilog
doesn't have. Where Verilog errs on the side of being to simple, VHDL errs
on the side of being to complex.


Article: 106065
Subject: Re: Who is your favourite FPGA guru?
From: "Guru" <ales.gorkic@email.si>
Date: 7 Aug 2006 05:51:23 -0700
Links: << >>  << T >>  << A >>
I think Antti Lukats is one of them.

Cheers,

Ales

Tony Burch wrote:
> Hi all,
>
> I was just pondering the idea of "gurus" & I thought the following questions
> may hopefully make some interesting & entertaining discussion.
>
> Including people in this newsgroup & others working in the field, whom do
> you consider to be the present-day "gurus" in FPGA system design? ...I mean
> the people who are well known & highly respected for their work &
> contributions in this field.
> 
> Who is your favourite guru & why?
> 
> :) Tony


Article: 106066
Subject: Re: Xilinx USB Blaster FX2 firmware and CPLD replacement under GPL released
From: Daniel O'Connor <darius@dons.net.au>
Date: Mon, 07 Aug 2006 22:23:45 +0930
Links: << >>  << T >>  << A >>
Antti wrote:

> http://inisyn.org/src/xup/
> 
> its already done! I was kind of hoping someone does it,
> and voila, done...

Have you (or anyone else) tried it with the Platform USB cable? I'd imagine
it would be almost identical to the stuff that's on the S3E starter board
but you never know how bloody minded some hardware companies can be ;)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 106067
Subject: Re: virtex ppclinux files
From: "Guru" <ales.gorkic@email.si>
Date: 7 Aug 2006 05:57:28 -0700
Links: << >>  << T >>  << A >>
Thank Antti for uploading them to your site.
What is the difference between the uploaded PPClinux and Hydra PPlinux?

Guru

Antti wrote:
> Hi
>
> I have uploaded the files once available from Pauls website at the
> university in Australia
>
> http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=select&id=11
>
> the archive contains all that I fetched from the web when it was
> available. I do not know exact reasons why the original pages are
> vanished, but for me the files from there have been a big help to get
> ppc linux working on Virtex-4
> 
> Antti


Article: 106068
Subject: Re: How do I treat "default" case which is useless?
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 7 Aug 2006 06:09:46 -0700
Links: << >>  << T >>  << A >>
In the real hardware, anything could happen and the other 3 cases could
be hit. I think you should leave that 1% alone because it simply
indicates that your simulation doesn't handle error recovery. Any
reasonable person wouldn't make a big deal of it if it's well
explanined and documented. If you really want 100% coverage, I would
suggest you think of a way to inject errors instead of playing with the
semantics.

HTH,
http://home.comcast.net/~jimwu88/tools/


Mr. Ken wrote:
> I need to use only 5 out of the 8 cases, but for completeness's sake,
> a default case is needed in order to avoid unwanted latches. This default
> case isn't covered by simulation. As a result, it will bring the coverage
> down
> from 100% to 99%. It's kinda annoying to explain this 1% to customer.
> 
> How do I treat this situation?


Article: 106069
Subject: Re: How do I treat "default" case which is useless?
From: "Symon" <symon_brewer@hotmail.com>
Date: 7 Aug 2006 15:19:08 +0200
Links: << >>  << T >>  << A >>
"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> wrote in message 
news:1154956186.805032.46370@h48g2000cwc.googlegroups.com...
> If you really want 100% coverage, I would
> suggest you think of a way to inject errors instead of playing with the
> semantics.
>
Hi Jim,
Yeah, that would work. You could force the simulation to set the case 
selector to the illegal values. This would give the 100% coverage needed.
Cheers, Syms. 



Article: 106070
Subject: Re: verilog versus vhdl
From: "radarman" <jshamlet@gmail.com>
Date: 7 Aug 2006 06:41:32 -0700
Links: << >>  << T >>  << A >>
Josh Rosen wrote:
> On Sat, 05 Aug 2006 19:02:31 +0200, Markus Zingg wrote:
>
> > Hi Group
> >
> > I have to implement a design which requires an FPGA, but to do so
> > among other things I obviousely first have to learn one of the two
> > mentioned languages. I got the impression that europe seems to be more
> > vhdl centric whereas verilog seems to be more popular in the US but
> > this argument alone is for reasons beond the scope of this question
> > not so important to me. I have a strong background in C programming
> > (should that matter anyhow) and in general experience with embedded
> > systems, but FPGAs are new to me. I'm otherwise completely open and
> > alas wonder what you guys suggest I should choose. I'm mostly
> > interested in replies from people which know both languages cause
> > otherwise I fear that this thread ends up in some sort of religious
> > war...
> >
> > TIA
> >
> > Markus
>
> I strongly prefer Verilog. It's C like which makes it much easier to read
> for a C programmer. It's very concise which also makes it easier to read
> and write. Like C it's easy to write very efficient code with Verilog. On
> the downside it's missing a lot of C's important features like structures
> and procedures. Verilog has simple functions and a weak task mechanism
> instead of C's procedures. However I haven't found that limiting.
>
> VHDL is a much more complex language than Verilog. VHDL code is very
> verbose, painfully so. However it does have capabilities that Verilog
> doesn't have. Where Verilog errs on the side of being to simple, VHDL errs
> on the side of being to complex.

First off, I learned VHDL because that is what my employer uses - which
I suspect most people end up doing. That said, I'm presently trying to
learn Verilog, in order to be more versatile. I was trained in digital
logic, so I found VHDL fairly trivial to learn. Verilog doesn't appear
to be all that difficult either. Note, I'm not talking about being an
expert in all of the nuances - I'm still learning those - I'm talking
about being able to get busy designing hardware.

Also, the verbosity of VHDL can be managed. A lot of the stuff people
complain about is optional. For example, you don't have to put the
process/architecture/package/etc. name at the end. You can just "end"
it. Same goes for a lot of other structures. You can also declare
subtypes and types that reduce a lot of typing, and make things more
clear.

Yes, you do need to be fairly intimate with the language to get to this
point, but once you do, you can describe hardware pretty darn quick.

I will admit, there are still things in VHDL that bug me. Semicolon
use, for example, almost seems arbitrary. I've gotten used to it, but I
still occasionally foul up with semicolons.


Article: 106071
Subject: Re: Who is your favourite FPGA guru?
From: "Hans" <hans64@ht-lab.com>
Date: Mon, 07 Aug 2006 13:59:41 GMT
Links: << >>  << T >>  << A >>
I would say my top 4 are Rich Katz(Nasa) for anything to do with FPGA's in 
space and general design issues. For languages and programming I would 
definitely say Jonanthan Bromley(Doulos, there are more guru's at Doulos but 
he seems to be the uber guru :-) For complex core development I would choose 
Jiri Gaisler since his Leon core worked first time (he never prototyped it 
before I tried it out!) and last but not least I read all postings from 
Peter Alfke since he is one of the great expert in the field.

Hans
www.ht-lab.com

"Tony Burch" <tony@burched.com.au> wrote in message 
news:44d72fa7$0$5107$afc38c87@news.optusnet.com.au...
> Hi all,
>
> I was just pondering the idea of "gurus" & I thought the following 
> questions may hopefully make some interesting & entertaining discussion.
>
> Including people in this newsgroup & others working in the field, whom do 
> you consider to be the present-day "gurus" in FPGA system design? ...I 
> mean the people who are well known & highly respected for their work & 
> contributions in this field.
>
> Who is your favourite guru & why?
>
> :) Tony
>
> 



Article: 106072
Subject: Re: How do I treat "default" case which is useless?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 7 Aug 2006 07:02:13 -0700
Links: << >>  << T >>  << A >>
Mr. Ken wrote:
> I need to use only 5 out of the 8 cases, but for completeness's sake,
> a default case is needed in order to avoid unwanted latches. This default
> case isn't covered by simulation. As a result, it will bring the coverage
> down
> from 100% to 99%. It's kinda annoying to explain this 1% to customer.
>
> How do I treat this situation?

The proper method is to cover all cases explicitly.  As mentioned
earlier, combining case #5 with any other cases into the 'when others '
branch is an acceptable approach that would also guarantee 100% code
coverage.

Designing to cover that last 1% is not just annoyance, it's helping to
insure that each line of code in the design actually has been tested in
simulation which should be a bare minimum to strive for in test
coverage anyway.  It's not saying that each line has been tested under
each condition that it may encounter but at least each line has been
hit.

Depending on just what exactly you have in your source code there might
very well be very good reasons for making sure your design has every
base covered that you're not even considering.  Not knowing what your
code is I'm guessing that the signal that is the target of the case is
probably one of the following forms:

1. An integer subtype (i.e. signal X: natural range 0 to 7)
2. A std_logic_vector subtype (i.e. signal X: std_logic_vector(2 downto
0)

Since you're using 5 of the 8 explicitly in your design what happens if
it powers up in states #6, 7 or 8?  Presumably you have a reset that
will move it out of that state but you can also have a 'when others'
that takes you to a known state as well.  Adding code to handle this
doesn't necessarily impact your code coverage.  For example, if your
code is of form #2 then the simulator will initialize the vector to
'UUU' and your 'when others' cause will in fact get executed.  If your
code is of form #1 then the 'when others' code will not get exectured
because X will get initialized to 0.  But before you think that this is
a 'good' thing, consider
- The underlying real hardware may not be giving you that same
initialization of X to 0.
- If you (or somebody else) goes to reuse this code in some other
design than their underlying hardware may not give that same
initialization.

In both of these situations you're setting yourself up for a situation
where simulation does not match reality which can be difficult to
debug.  In that sense code using code of form #1 is less robust than
that using form #2 since it is relying on a quirk of simulation that is
not present in the underlying hardware.

Making your design and testbench code cover that last 1% may seem
annoying but in fact it does make your design more robust and possibly
reusable and is good design practice.  The fact that the tool is
showing you that you have a potential logic error that you haven't
considered is a good thing.

KJ


Article: 106073
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 07 Aug 2006 07:34:39 -0700
Links: << >>  << T >>  << A >>
ZHI wrote:
> I am a newer for FPGA. I am reading some vhdl codes of others. I find
> they often use some buffers in design, such as IBUF, OBUF, FDCE,
> FDCE_1,etc.I have checked these buffer function but still not very sure
> the reason why these buffers put there. 

Maybe you are looking at a vhdl netlist.
Creating a netlist of buffers registers
and luts from vhdl source code is the
job of synthesis.

     -- Mike Treseler

Article: 106074
Subject: Re: 3.3V configuration of Spartan-3?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 7 Aug 2006 07:37:19 -0700
Links: << >>  << T >>  << A >>
Evan Lavelle wrote:
> I've got a Spartan-3 which is configured (in master serial mode) from
> an XCF04S, and which is also in a JTAG chain which looks like this:
>
> connector -> Serial PROM/XCF04S -> XC3S1000 -> 3.3V device ->-
> connector <---------------------------------------------------|
>
> The problem is that bank 4 on the Spartan-3 must have a VCCIO of 3.3V,
> and the dedicated JTAG and configuration pins on the Spartan-3 are
> powered on VCCAUX, at 2.5V. The last device in the chain is also a
> 3.3V-only device.
>
> I've read Kim Goldblatt's appnote on this (XAPP453), and the obvious
> answer is to use a 3.3V JTAG/programming connector, and to set the I/O
> voltage on the PROM to 3.3V. There are 4 inputs on the Spartan-3 which
> are overdriven (PROG_B, TMS, TCK, TMI) so they need limiting resistors
> on them.
>
> The problem is, I don't really like this. There are 4 (or maybe just
> 3) input-protection diodes in the Spartan-3 which are almost
> permanently on, at about 9.5mA each. The Spartan-3 data sheet says
> that the inputs won't be damaged if the input voltage is kept below
> about 3.1V, but the last thing I want is a 676-pin package with blown
> inputs which can't be configured. Am I just being paranoid? The other
> problem is that my VCCAUX regulator now has to potentially supply
> ~120mA instead of ~80mA.
>
> So, my plan B is to run JTAG and configuration at 2.5V instead. This
> means that VCCJ and VCCO on the XCFO4S are at 2.5V instead of 3.3V,
> and:
>
> 1 - the DIN input on the Spartan-3 has reduced noise immunity (2.5V
> input, 3.3V buffer), but this should be Ok
>
> 2 - the 4 JTAG inputs on the other 3.3V device in the chain also have
> reduced noise immunity; again, should be Ok
>
> 3 - the TDO from the 3.3V device gets back to the programming
> connector as 3.3V, instead of 2.5V. I can handle this with a 74AHC14
> buffer (a spare from the JTAG drivers at the connector)
>
> 4 - INIT_B at the Spartan has an internal pullup to 3.3V, but the
> XCF04S has a 2.5V INIT_B input. However, the XCF04S data sheet says
> that the inputs are at least 3.6V-tolerant for VCCO at a nominal 2.5V.
> So, I can just pull up INIT_B to 3.3V anyway.
>
> At first sight, it seems to me that plan B is much better than plan A.
> Any thoughts?

There are a lot of details there that will take some real work to
understand.  I just dealt with configuring a Spartan 3 and dealt with
the whole thing by just using a separate JTAG port for the FPGA.  I
have spent some significant time looking into using JTAG for both
development purposes and for boundary scan.  The one thing I got from
all corners is that you are much better off avoiding the various
problems you may encounter (not just interface voltage issues) in a
single scan chain by not connecting everything in one chain.  Our
in-house boundary scan expert does not like using the Xilinx parts
because of various problems when doing the tests, even though they are
not in the same scan chain.  I have been told by nearly every chip
vendor that they don't support chaining their product with other brands
of chips if they support chaining at all!

I think Xilinx software may actually be a bit better behaved when
working with other chips in the scan chain, but I still would not
recommend this depending on the other chips.  TI says they support scan
chains in their literature and was a major proponent a decade or so
ago.  But when I contacted support about using their DSP chip emulation
software in a scan chain they recommended not to.

It seems to be a common practice to disregard the chaining capabilities
of JTAG unless you really have to save the board space.  Instead give
each chip a separate connector.  During development this will let you
use multiple tools at the same time and if you need boundary scan in
manufacturing they make tools that will drive multiple chains.




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