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
2019JanFebMar2019

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 106100

Article: 106100
Subject: Re: FPGA : PCI-Xilinx Core, PC not booting
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Mon, 7 Aug 2006 12:56:53 -0700
Links: << >>  << T >>  << A >>
Hello Bijoy,

There is (unfortunately) an enormous number of things that could cause this
type of behavior -- most of which are not related to the IP core itself.  If
you have not already done so, I highly recommend that you submit a case to
the Xilinx support team.  They can help you debug the issue.  The support
team can be of most assistance if you are able to provide the schematics for
your board and detailed information about what IP core product/version you
are using.

Eric

"bijoy" <pbijoy@rediffmail.com> wrote in message
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: 106101
Subject: Re: How do I treat "default" case which is useless?
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 7 Aug 2006 13:02:06 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> KJ wrote:
> > > For example, if the statements in
> > > case 2 and 3 were swapped, it would still be covered, but produce a
> > > wrong result.  Is there a way to verify that the wrong result will be
> > > caught?
> >
> > If it doesn't, then this implies that either there was no 'assert'
> > to check that the design was working under those conditions or that the
> > testbench didn't exercise things adequately to uncover the inadvertant
> > 'case swap' or (somewhat unlikely) that cases 2 and 3 really are not
> > distinct and really are the same thing to the extent that they cause no
> > observable misbehaviour of the design.
>
> That is what I am referring to.  The fact that the statements were
> "exercised" is not the same thing as saying they were "tested" to work
> correctly.
That's correct.  The whole point of the assertion statements that get
added to the design code and the testbench code are to embed the
knowledge of what is 'correct' behaviour.

> If a tool can tell you if a statement was exercised under
> "all conditions", what exactly does that mean, "all conditions"?  I
> would assume it means all combinations of the signals that are inputs
> to the statement.
>
With Modelsim's Code Coverage the coverage options you get are:
- Statement coverage
- Branch coverage
- Condition coverage
- Expression coverage
- Finite state machine coverage
- 0/1 Toggle Coverage
- 0/1/Z Toggle Coverage

That is still somewhat short of 'all conditions' but I'd wager that it
would be darn difficult but probably not impossible to get 100%
coverage on all of those items and have assertion checking on all of
the outputs and still slip a bug through.

> I think it is still up to the test designer to determine if the test
> distinguishes failures in the code from working code.

I agree but I think assertion checking and code coverage (meaning more
along the lines of most or all of the above list not just 'statement
coverage') are pretty powerful tools at the disposal of the designer to
beat pretty heavily on the design without requiring the 'sharp eyes' or
the 'smart guy' to get the job reasonably done.  Not that such
resources shouldn't also be brought in when available though.  The
things that then get left on the table unchecked are the units of
measure that end up crashing probes on to the surface of Mars (at least
I thought that was the root cause of that little mishap).

Until someone comes up with an automagic way to convert a design
specification in to some sort of testbench I would agree with
you....which I'm guessing will be until my last dying breath.

KJ


Article: 106102
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 07 Aug 2006 13:02:59 -0700
Links: << >>  << T >>  << A >>
ZHI wrote:
> Thanks Mike Treseler
>  I am not reading a vhdl netlist.  I am reading a uart application
> codes. 

Maybe it is a vendor-specific example.
Here is a generic uart example that will work for any device:
http://home.comcast.net/~mike_treseler/uart.vhd

> For example, the input signal (RXD signal) of FPGA  firstly
> go through a IBUF then a BUFG. What's the uses of them respectively?

You could use them to sell devices
to customers who don't know synthesis.

> Why need use these buffers? When need use them?

I would never use them directly.
Let synthesis do its job.

> Or we actually don't need to care these buffers at all.

That's it.

         -- Mike Treseler

Article: 106103
Subject: Re: Who is your favourite FPGA guru?
From: burn.sir@gmail.com
Date: 7 Aug 2006 13:03:02 -0700
Links: << >>  << T >>  << A >>
Gurus just talk, I like DO-ers:


One guy from Germany: who could that be?

Two from Sweden (kind of): Gaisler, Bilsky

One dude from UK, his first name is Ken.

US: Is Jean Nicolle American? In any case, he is on my list for makeing
FPGAs fun!
And the guy at Lattice who wrote Mico8 and released it under GPL.

Oh, Cliff almost made it into the list...




-Bruns

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: 106104
Subject: Re: verilog versus vhdl
From: "Andy" <jonesandy@comcast.net>
Date: 7 Aug 2006 13:06:41 -0700
Links: << >>  << T >>  << A >>
As to which language will cause less issues with the Xilinx tools, I'm
not sure, but my gut tells me that (if there is any difference) they
may handle VHDL better because VHDL tends to be more used for FPGAs (at
least in the past, but verilog may be catching up?).  I remember a
Mentor Graphics presentation at an HDL conference 4-5 years ago, and
VHDL was the most used HDL for FPGA design, by a wide margin; Verilog
was third, behind PALASM!  Things have certainly changed since then,
but I don't know by how much.

But if you don't already know VHDL and the traps within it, perhaps
you'd be better off with verilog (depending on how well you know it)?
Whether you use VHDL or Verilog, you are probably just as likely to
encounter problems because of whichever one you choose!

Another thing to consider may be what IP you may be using, and what
language it is written in (synthesis and/or simulation), if any.  Most
synthesis tools can handle mixed languages at the module level, but
simulators that can do so may be more expensive.

Andy


Xesium wrote:
> Hi,
>
> All this information is very interesting. I didn't want to make a new
> thread for my question but I was wondering which of these languages can
> be used more error-freely while using Xilinx CAD tools ISE and EDK.
> Because I already know some Verilog however thinking that VHDL is a
> more widely used language!!, I didn't actually dare to use Verilog for
> my designs to do simulation or other things that I had to deal with low
> level HDL in the tools. I really prefer to use Verilog as I'm more
> comfortable with it and I don't want to spend much time learning VHDL
> at this time. But I'm afraid  that I have to deal with some errors in
> EDK or ISE or in my simulation because Verilog is not strongly
> supported by Xilinx tools. Do you have any idea about that?
> Will I probably face problems just because I'm using Verilog.
>
> Thanks,
>
> Amir
>
> Nicolas Matringe wrote:
> > I can't remember who in this newsgroup who knows both and, whichever
> > he's using at any given moment, always regrets he doesn't use the other
> > language.
> > 
> > Nicolas


Article: 106105
Subject: Re: DDR2 SRAM Stratix II questions
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 7 Aug 2006 13:26:43 -0700
Links: << >>  << T >>  << A >>

Thomas Entner wrote:
> > There is no such thing as DDR2 SRAM which implies that the original
> > post had a typo.
>
> Look at this: http://www.necel.com/memory/en/products/sram/ddr-18m.html ;-)
>
> Thomas

I stand corrected.

Although I must admit that if all we're talking about is a synchronous
SRAM controller then that is almost trivial to put together for
oneself....to the point that I wouldn't let the lack of an Altera
MegaCore function deter me from using the part if that's what one has
in mind.  Take an hour or two and write the code.

KJ


Article: 106106
Subject: Re: verilog versus vhdl
From: "Antti" <Antti.Lukats@xilant.com>
Date: 7 Aug 2006 13:31:12 -0700
Links: << >>  << T >>  << A >>
johnp schrieb:

> If your concern is how well Xilinx XST supports Verilog,
> I'd have to say it's pretty good.  I've been using the
> Xilinx tools with Verilog for a number of years now and
> it works fine.
>
> I'd say that picking VHDL or Verilog is not dependant
> on the tool support.  The tools usually will work fine
> with either language.  The choice should be made on
> which language will work best for YOU, not based
> on the Xilinx tools.
>
> John Providenza
>

yes, Xilinx verilog support has improved a great deal.

for ISE projects its almost no difference - for EDK
systems its still a little easier to deal with VHDL -
the way EDK propagates params down the hierachy
seems to work better for VHDL, also if you are trying
to create EDK peripherals where top-levels are in VHDL
and those include modules below that are imported
from other projects written in verilog, then if those
verilog modules use some includes then the all
thing doesnt want to compile so nicely any more.

the way EDK handles modules and directories -
the all verilog define and include concept doesnt
play nicely with it. If the EDK ip cores are written
in verilog for EDK (and use no includes) then they
work ok, also with parameter passing between
VHDL and verilog modules

Antti


Article: 106107
Subject: Re: DDR2 SRAM Stratix II questions
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 7 Aug 2006 13:40:53 -0700
Links: << >>  << T >>  << A >>
Ignore my previous post...I re-read the original post...time to stop
and put brain back in.

KJ


Article: 106108
Subject: Re: DDR2 SRAM Stratix II questions
From: John <news@sandpipers.com>
Date: Mon, 07 Aug 2006 13:53:31 -0700
Links: << >>  << T >>  << A >>
Thomas Entner wrote:
>>There is no such thing as DDR2 SRAM which implies that the original
>>post had a typo.
> 
> Look at this: http://www.necel.com/memory/en/products/sram/ddr-18m.html ;-)
> 
> Thomas 
> 
and at this [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=215&gid=5&fid=39&category=QDR-II%2B&showall=false]

Article: 106109
Subject: Re: DDR2 SRAM Stratix II questions
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Mon, 7 Aug 2006 23:10:15 +0200
Links: << >>  << T >>  << A >>

"KJ" <Kevin.Jennings@Unisys.com> schrieb im Newsbeitrag 
news:1154983253.794449.237460@m79g2000cwm.googlegroups.com...
> Ignore my previous post...I re-read the original post...time to stop
> and put brain back in.

Now I have re-read the original post again, too ;-)

Maybe one conclusion could be, that "no demand" is quite plausible, as you 
did not even believe they exist.

Regarding the bus-turnaround-time, which was one of the concerns of the OP, 
I think, I would recommend following:

Make a test-cirucit with the bi-dir DDR-IO-registers in Quartus and look 
what the timing-analyzer reports. I suppose that you will need 1 or 2 
"wait-states" for bus turn-around.

Thomas



Article: 106110
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: "ZHI" <threeinchnail@gmail.com>
Date: 7 Aug 2006 14:35:08 -0700
Links: << >>  << T >>  << A >>
OK, I see. Thank you , Mike Treseler.

By the way, I am using the Xilinx Virtex-II Pro board now. Could you
introuduce a good way to learn how to design FPGA? Is this a correct
way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide?
Many thanks!

Zhi

Mike Treseler wrote:
> ZHI wrote:
> > Thanks Mike Treseler
> >  I am not reading a vhdl netlist.  I am reading a uart application
> > codes.
>
> Maybe it is a vendor-specific example.
> Here is a generic uart example that will work for any device:
> http://home.comcast.net/~mike_treseler/uart.vhd
>
> > For example, the input signal (RXD signal) of FPGA  firstly
> > go through a IBUF then a BUFG. What's the uses of them respectively?
>
> You could use them to sell devices
> to customers who don't know synthesis.
>
> > Why need use these buffers? When need use them?
>
> I would never use them directly.
> Let synthesis do its job.
>
> > Or we actually don't need to care these buffers at all.
> 
> That's it.
> 
>          -- Mike Treseler


Article: 106111
Subject: Re: Counter status flags don't stay asserted not sure why?
From: "pinod01@sympatico.ca" <pinod01@sympatico.ca>
Date: 7 Aug 2006 14:36:46 -0700
Links: << >>  << T >>  << A >>
To Andy & Frank,

     I forgot some of the properties of the variable statement and
appreciate the feedback.  In fact this is exactly what I was trying to
remember as this helped solve the problem.  Thank you to both of you.
I've managed to change the signal assignments to variables and also
modified my reset condition so that one of the variable assignments
starts at "start_address - 1" instead of "start_address".  During the
first clock cycle it seemed that the variable was updated right away
and therefore caused my comparator to react and for the assertion of
the status flags earlier than I wanted it.

Cheers
Pino

Andy wrote:
> Frank Buss wrote:
> > pinod01@sympatico.ca wrote:
> >
> > > The section that is not functioning according to my description is the
> > > section in the VHDL code that has the IF statement that compares
> > > "updated_addr = comp_addr".   Can someone correct the piece of VHDL
> > > code below?
> >
> > I didn't analyze your code in detail, but if you change a signal in a
> > process, it will be not changed until the end of the process. Use
> > variables, if you need some sequential order.
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
>
> What Frank said, but with some additional info:
>
> Signal updates are postponed until the assigning process suspends,
> either at an explicit wait statement, or at the bottom of the process.
> Any signal assigned inside the clock-edge if/then clause in a clocked
> process infers a register. Any reference to that signal is a reference
> to the output of the inferred register, no matter when/where it occurs
> relative to any assignment.
>
> Variables update immediately upon assigment. A variable reference
> infers storage (i.e. a register in a clocked process) if the variable
> is read before it is written in a given execution of the process, in
> which case it must "remember" the state from the previous execution. If
> a reference to a variable executes after an assignment to it, then that
> reference infers a combinatorial path instead of a registered one.
> 
> Andy


Article: 106112
Subject: Re: How do I treat "default" case which is useless?
From: "Andy" <jonesandy@comcast.net>
Date: 7 Aug 2006 15:17:25 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> I don't follow this at all.  I am pretty sure that putting NULL in a
> when others clause will create a latch, no?  NULL is saying to do
> nothing which means hold your present state, ergo a latch.

Latches only happen in a combinatorial process!  I don't use those. I
only use clocked processes (aka single process description) for FSMs
(this is one of the main reasons why). In a clocked process, a null
would be implemented as a clock-disable, assuming it determined the
state was reachable in the first place.

On the other hand, they had their restrictions on ada code for SW; I'm
the one considering it for VHDL and HW, which has other issues to
consider (one of which is your issue in a combinatorial process)

> Only if the tool can determine that the condition is not "possible".
> Often the condition is a function of how a design is used rather than
> how it is built.  Given the constraints on the inputs, a condition may
> be "impossible" with no way for the tool to know that.

Naturally, there are cases where any input condition can happen (i.e. a
 CPU can access any address within the range binarily represented by
the number of bits), but most sythesis tools do simple reachability
analysis on state machines and  even on counters. With constrained
integer types, it is possible to tell them such information explicitly
(i.e. natural range 0 to 5 excludes possible 3 bit values for 6 and 7,
such that an equality comparison with 5 only takes two inputs, not
three), no matter where the info came from (i.e. an external 3 bit
port).  To what extent they use this depends on the tool provider.

You raise a very good point about unconstrained, loosely coupled
inputs. You may know that two input conditions are mutually exclusive,
but telling that to the tool is usually nontrivial.  One application I
have found is to make use of a tri-state bus type description, and then
tell the synthesis tool to convert tristates to muxes.  They
automatically assume that tristate enables are mutually exclusive
(otherwise the original circuit would not have worked).  I wish we had
a standard mutex function that we could call in an assertion statement,
and the synthesis tool would pick up on it and realize that the inputs
to the mutex function were in fact mutually exclusive.

Andy


Article: 106113
Subject: Re: Who is your favourite FPGA guru?
From: "bart" <bart.borosky@latticesemi.com>
Date: 7 Aug 2006 15:22:22 -0700
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:

> And the guy at Lattice who wrote Mico8 and released it under GPL.

> -Bruns
Do you have more input on open source IP's for FPGAs? Gordon Hands from
Lattice is looking for just that type of feedback on his blog. Gordon
was heavily involved in the Open IP cores licensing agreement and is
looking for more feedback...

Gordon writes: "I would be interested in reading comments from users on
this topic.  Does it make sense to have Open Source IPs for FPGAs?
Should Lattice be doing more of this?"

here's the link to his blog:
http://latticeblogs.typepad.com/frontier/author_gordon_hands/index.html

Regards,
Bart Borosky, Lattice


Article: 106114
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 07 Aug 2006 15:31:06 -0700
Links: << >>  << T >>  << A >>
ZHI wrote:

> By the way, I am using the Xilinx Virtex-II Pro board now. Could you
> introuduce a good way to learn how to design FPGA? Is this a correct
> way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide?

You only really need an editor and simulator to get started.
Once you know how to write and simulate HDL code for
synthesis, you can try the design in hardware.
Until then, all you can do with the board
is run the canned demos and flash the LEDs.

           -- Mike Treseler

Article: 106115
Subject: Open source Xilinx JTAG programmer with Digilent USB support
From: "fpgakid@gmail.com" <fpgakid@gmail.com>
Date: 7 Aug 2006 16:26:36 -0700
Links: << >>  << T >>  << A >>
I've written a Xilinx JTAG programmer. It runs on Win32 and Linux

Following cables are supported:

Parallel III
Digilent USB (on Linux it needs libusb, Win32 needs the original driver
from digilent, utilizes full USB transfer speed!)

Following chips are implemented:
Spartan-3 Family
XCF Family
Virtex-II Pro family

If it seems people are interested I'll clean up the code and put it up
on sourceforge.net.
The most interesting part is  the Digilent USB driver. It could be used
in other applications too :)


Article: 106116
Subject: Re: Open source Xilinx JTAG programmer with Digilent USB support
From: Eric Brombaugh <ebrombaugh.invalid.@earthlink.net>
Date: Mon, 07 Aug 2006 23:40:30 GMT
Links: << >>  << T >>  << A >>
fpgakid@gmail.com wrote:
> I've written a Xilinx JTAG programmer. It runs on Win32 and Linux
>
> If it seems people are interested I'll clean up the code and put it up
> on sourceforge.net.
> The most interesting part is  the Digilent USB driver. It could be used
> in other applications too :)

Yes - definitely interested!

Eric

Article: 106117
Subject: Re: Microblaze, EDK, Spartan 3 and Webpack
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 08 Aug 2006 12:07:40 +1200
Links: << >>  << T >>  << A >>
larwe wrote:
> Antti Lukats wrote:
> 
> 
>>>Goddamn, I hate Xilinx's software. Nowhere - NOWHERE in the
>>>documentation with the ML403 does it state that the license is limited
>>>to one year.
>>>
>>>Is the ISE installation similarly limited?
>>>
>>
>>ISE is also sold as 'time based license' yes.
> 
> 
> This is rampant bullshit, and it is PRECISELY why proprietary
> development tools are so dangerous. It is not disclosed anywhere on the
> purchasing/specifications page for the ML403 EDK bundle that all this
> software is time-limited crippleware. Likewise, it is not disclosed
> anywhere in the software or any installed documentation. It is ONLY
> mentioned on the web site in an unrelated and semi-buried page.
> 
> In this case it isn't much money - $500 per year isn't a whole lot, and
> it's tax deductible. But how much is EDK? And where do they disclose
> this information about the price, or is it a case of "if you have to
> ask, you can't afford it"?
> 
> I'm emailing Altera and Xilinx simultaneously; whichever one offers the
> better deal for someone who's going to write about their products and
> never field a design, that's the one that goes into my next book.
> Fortunately I wasn't working on this section of it yet!

I've crossposted this, so someone in Xilinx can comment on the
Details.

The link Antti gave does not mention webpack, or Microblaze,
and I believe the webpack does not expire ?

I would expect MB to be a one-time license,
"solely for use in developing designs for Xilinx Programmable devices."

You should also note that Xilinx's have 'separated from the pack' in 
that their latest webpack (free) does NOT support any of their newest V5 
devices, as a matter of policy.

-jg





Article: 106118
Subject: Re: Open source Xilinx JTAG programmer with Digilent USB support
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Mon, 07 Aug 2006 18:47:48 -0700
Links: << >>  << T >>  << A >>
On Mon, 07 Aug 2006 16:26:36 -0700, fpgakid@gmail.com wrote:

> I've written a Xilinx JTAG programmer. It runs on Win32 and Linux
> 
> Following cables are supported:
> 
> Parallel III
> Digilent USB (on Linux it needs libusb, Win32 needs the original driver
> from digilent, utilizes full USB transfer speed!)
> 

Could it support the FTDI-2232?

Peter Wallace

Article: 106119
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 07 Aug 2006 22:35:40 -0400
Links: << >>  << T >>  << A >>
ZHI wrote:
> Thanks Mike Treseler
>  I am not reading a vhdl netlist.  I am reading a uart application
> codes. For example, the input signal (RXD signal) of FPGA  firstly
> go through a IBUF then a BUFG. What's the uses of them respectively?
> Why need use these buffers? When need use them?
> Or we actually don't need to care these buffers at all.

BUFG is a buffer which drives a global clock network.
IBUF is a buffer from the input pin.

IBUF->BUFG would typically be used when an external pin is used to drive 
  a clock signal and the pin is NOT a dedicated clock input.

Ideally a synthesizer would handle this automatically. Sometimes the 
tool is not smart enough. Instantiating BUFG directly forces it to route 
the signal on a global clock net.

Having said that, treating a UART RXD signal as a global clock sounds 
rather bizarre.

-Jeff

Article: 106120
Subject: Re: FPGA : PCI-Xilinx Core, PC not booting
From: bijoy <pbijoy@rediffmail.com>
Date: Mon, 7 Aug 2006 22:35:36 -0700
Links: << >>  << T >>  << A >>
Hi, The board details are as follows. PCI-32 bit 33 MHz (so M66 is connected to GND) Master/Target functionality. The device does work along with other PCI devices. ( TV tuner card, PCI NIC card etc) Only memory space enabled. Only 1 BAR enabled. Decode speed : medium Clock : PCI clock going to dedicated GCLK pin. FPGA : XC3S200-144TQFP, with XCF01 (1 M flash) (PROM configuration speed is default (6MHz) )

What is this PDE ? Also what do you mean by BIOS speed contrary... ? i belive PCI decode speed is not settable in BIOS.

The exact symptoms are : Intel motherboards -> works fine (845, 865, 915 etc) VIA motherboard A7VBX-MX (AMD) -> PC does not even give the "all ok" single beep at power on. monitor, keyboard, mouse all appear dead. CPU fan keeps whirring but PC does not boot.

looks like we will have to open a webcase.

Thanks -Bijoy

Article: 106121
Subject: Re: verilog versus vhdl
From: fpga_toys@yahoo.com
Date: 7 Aug 2006 23:40:14 -0700
Links: << >>  << T >>  << A >>

JJ wrote:
> Myself I vote for the one that begins with V.
>
> Now if the C language would pick up some major extensions the likes of
> which we see in HDLs such as open ended bit sizes and the same notion
> of concurrency and nested modules I could probably do most everthing in
> a HDL C combined with regular C. If the compiler would spit out HDL for
> regular synthesis and allow HDL code to be simulated at C speeds, that
> would be neat.

Most of the C based HDLs offer some means to assign arbitrary bit
widths to objects, frequently in ways that break ANSI C compatability.
Bit fields do however existing in the language, and in ways that are
actually pretty useful for most applications. Still, one of my nits in
doing FpgaC is to carry a proposal to the ANSI committee to allow bit
fields that are larger than the native type, forcing the compiler to
handle a 200 bit or 64 bit object the same on both an 8bit micro and a
128 bit super computer. In FpgaC, I'm not sure there is a limit on the
width of an object, other than constants, which is something I'm
already working toward fixing.

As for concurrency, that is something that hardware guys miss
understand completely. Every compiler is free to shuffle/reschedule the
code produced, as long as the results have the expected serial
symantics. Out of order execution and multiple issue pipelines, ARE
concurrency. As are threads, pipes, processes, and many other
concurrent abstracts in what appears a sequential language.

In FpgaC everything in a statement group is completely concurrent.
Other C based HDLs offer other concurrency rules, from statement level
clock timing, to explict construction of parallelism using hardware HDL
semantics.

Synthesis in FpgaC is becoming better, actually better than
VHDL/Verilog, as I'm working on better technology mapping. My current
development copy of FpgaC does optimizations effectively, that
VHDL/Verilog can not do. The difference, is that with VHDL/Verilog you
describe the circuits that must be built, and the HDL is pretty much
obligated to build the circuits that are described. In high level
languages, the programmer describes the result wanted, and the compiler
is free to implement those results in the best way possible. In the old
days, you wrote in assembler to get exactly the code you wanted
executed, just as you write VHDL/Verilog to get exactly the hardware
you want. While some folks think this is "advanced" over schematic
designs, it's only advanced as assemblers are over programming directly
in binary. Because of the extensive timing and instantiation control in
the languages, the VHDL/Verilog synthesis tools are obligated to
implement the circuits as described ... and this will forever be a
handy cap.

With higher level languages, which avoid specific details about the
instantiation, then the compiler becomes free to choose whatever
hardware that will produce the described results, and optimize out
everything else that doesn't matter. Vhdl/Verilog really lack that
freedom, when the design description is as precise as what clock edge,
and what logic level, every object is at.

In my testing some new tech mapping a few months back, I described a
very very elaborate demo system that instantiated a very complex
control system filter combining 60 inputs which produced a single bit
output controlling a PWM driver. The synthesis result I thought was in
error, as none of the multipliers, adders, comparitors, or feedback in
the filter existed in the four term sum of products result .... four 30
variable AND terms OR'd togather, in just over 120 LUTs. However, the
optimized circuit simulated to the expected test vecors, just as did
the previous version of the design that was over 3,100 LUTs produced by
the stock Beta-2 release. The combinatorial depth of the original
synthesis was 47 LUTs deep which would have required extensive
pipelining and retiming, and only 6 deep after optimization. Another
crypto demonstration program is even better, which I will describe in a
paper this fall, as the results shatter expectations about the
strengths of certain cyphers, especially when large FPGA super
computers are available. There are simplifications and optimizations
available to bit structured machines, which are simply not possible for
most sequential word machine architectures, and from that comes a
different reality than "normally assumed" today.

While my interest in FpgaC is to build useful FPGA super computers in
the future, it's a love of both hardware design, and software design,
that enables that vision. That is not a reasonable vision, while the
only tools to program fpga designs, and at the bit and clock edge
level.  I suspect, that just as assembler, and even 'low level" C is no
longer in favor for complex designs today ... there will be an
evolution where high level HDL tools move away from detailed hardware
description at the clock and signal level detail, and move up so that
system level specification which includes the interface descriptions
and leaves the internal hardware description clearly to the tools to
optimize and produce. I'm not the brighest tool designer on the planet
... actually just a wet eared newbie ... so if I can get FpgaC to do
these things with a little magic, I'm certain the better guys on the
planet that do this for a living will blow some socks off with system
level C languages.  I'm actually looking foward to a SystemC tool based
on C++ sematics that has really good synthesis ... maybe a few years
from now?


Article: 106122
Subject: Re: Open source Xilinx JTAG programmer with Digilent USB support
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Tue, 8 Aug 2006 07:38:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
fpgakid@gmail.com <fpgakid@gmail.com> wrote:
> I've written a Xilinx JTAG programmer. It runs on Win32 and Linux

> Following cables are supported:

> Parallel III
> Digilent USB (on Linux it needs libusb, Win32 needs the original driver
> from digilent, utilizes full USB transfer speed!)

> Following chips are implemented:
> Spartan-3 Family
> XCF Family
> Virtex-II Pro family

> If it seems people are interested I'll clean up the code and put it up
> on sourceforge.net.
> The most interesting part is  the Digilent USB driver. It could be used
> in other applications too :)

Is is related to XC3Sprogs? The sourceforge site of xc3sprog has seen some
traffic now. Perhasp some things could be shared?

How did you derive the  Virtex-II Pro family programming algorithms?

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 106123
Subject: Re: Who is your favourite FPGA guru?
From: "Nial Stewart" <nial@NOSPAM.nialstewartdevelopments.co.uk>
Date: Tue, 8 Aug 2006 09:01:45 +0100
Links: << >>  << T >>  << A >>
I'm surprised no-one's mentioned Ray Andraka, he who mixes
the black arts (DSP stuff) with FPGAs and seems to know what he's
talking about ;-)

He and Peter Alfke would be my two nominations.



Nial




Article: 106124
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: "ZHI" <threeinchnail@gmail.com>
Date: 8 Aug 2006 01:45:50 -0700
Links: << >>  << T >>  << A >>
Thank you all.

I have a strange thing now. I implemented one algorithm into FPGA
board.
I sent data generated by Matlab from PC to FPGA board. And the results
are sent back to Matlab. Becuause I need caculate the bit error rate, I

tried it many times. I set the number of trials is 10000. It did work
in some trials at first but stopped at a random trial. The Matlab
always
show busy but not continue to next trial. I have to close Matlab and
try again. The phenomenon happens every time. Is this the problem of my

vhdl codes=EF=BC=9F But how can it successuflly work for some trials (even
reached 9883 trial)?  How to fix it?


Jeff Cunningham wrote:
> ZHI wrote:
> > Thanks Mike Treseler
> >  I am not reading a vhdl netlist.  I am reading a uart application
> > codes. For example, the input signal (RXD signal) of FPGA  firstly
> > go through a IBUF then a BUFG. What's the uses of them respectively?
> > Why need use these buffers? When need use them?
> > Or we actually don't need to care these buffers at all.
>
> BUFG is a buffer which drives a global clock network.
> IBUF is a buffer from the input pin.
>
> IBUF->BUFG would typically be used when an external pin is used to drive
>   a clock signal and the pin is NOT a dedicated clock input.
>
> Ideally a synthesizer would handle this automatically. Sometimes the
> tool is not smart enough. Instantiating BUFG directly forces it to route
> the signal on a global clock net.
>
> Having said that, treating a UART RXD signal as a global clock sounds
> rather bizarre.
>=20
> -Jeff




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
2019JanFebMar2019

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