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 35600

Article: 35600
Subject: [Spartan-XL] Driving a BUFGS from a std. IO ...
From: "Markus Meng" <meng.engineering@bluewin.ch>
Date: Thu, 11 Oct 2001 17:55:59 +0200
Links: << >>  << T >>  << A >>
Hi all,

is it possible - in VHDL - to connect the signal from a
std./normal IO-Pin with one of the internal BUFGS Clock
driver??

markus






Article: 35601
Subject: Re: High level synthesis will never work well :)
From: husby_d@yahoo.com (Don Husby)
Date: 11 Oct 2001 09:07:10 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3BC4C920.7BB7FA99@algor.co.uk>...
> 
> On the specific point you are right in that Synplify doesn't appear to
> be using resources efficiently in this case. Esp since it does the reset
> function by first inverting the reset input and then feeding the
> inverted value into the adder LUTs - missing a clear opportunity to
> optimise. The MAP program may do this for you later on.

It would have been somewhat impressive if it managed to work
the reset function into the adder LUTs.  At least this wouldn't
have cost anything in terms of size.  Instead, it inserted
the reset logic after the adder carry chain.  The mapper isn't
(and shouldn't be) smart enough to fix this.

> A work-around is to use an async reset.

It would have taken me longer to restructure my logic
to use an async reset than it would to simply instantiate
the 56 flip-flops.  Besides, async resets bring bad luck. :)

> On the more general case IMO you are missing some of the idea behind
> synthesis from HDLs. This is to get the results you need from the most
> portable/maintainable/reuseable/retargetable source format.

I'm not missing the point.  I'd dearly like to beleive the 
dogma, but time and time again, I've found that it doesn't
even pay to try it.  The reality is that the design entry
is about 20% of the job for a high speed FPGA design.
Far more time is spent trying to figure out how to convince the
tools to implement it sensibly.  Usually this involves instatiating
technology-specific library components.  I've found that
the fastest way to do a design is to throw away any illusions
of portability, etc., and code in a way that allows good control
of mapping and placement if needed later.  And it WILL be needed
for some small percentage of the design.

(If you doubt the 20% number, take the example I gave.  It takes
less than a minute to describe a 56-bit counter.  It takes tens
of minutes to compile the design, find out that the counter isn't
meeting spec, push into the chip editor or floorplanner
to find out why, and then hack at the code to fix it.  Of course
this doesn't count the extra time spent whining about it on
comp.arch.fpga)

> This is very much in the spirit of the `C' vs. Assembler
> debate of long ago.

It's similar, but not the same thing.  For an FPGA design,
there is usually a hard performance limit.  There is a fixed
clock rate, and a fixed number of resources.  When the design
violates those limits, it doesn't work.  Software has soft
limits.  It has nearly unlimited virtual memory, and time
limited only by the user's patience.  A factor of 2 performance
hit doesn't break the software.

> Again IMO the question you need to ask is whether the synth'ed result
> meets your needs in terms of speed/timing. If not then the second level
> question is whether, in a time2market dominated industry, going up a
> speed grade is better than spending a lot of time hand-tuning the logic.
> Its always possible to hand-craft technology specific logic that goes
> faster - the question is whether its worth it. YMMV.

Article: 35602
Subject: Use of Global in Altera FLEX 10KA
From: byrne@ddc-web.com (Stephen Byrne)
Date: 11 Oct 2001 09:07:41 -0700
Links: << >>  << T >>  << A >>
Hello All,

I've inherited a design from a departed employee who was kind enough
to route all of his 23 (yes, 23!!!) FPGA clock signals on general
routing resources in an Altera FLEX 10KA.  Of course, I saw this and
attempted to re-architect the clocking scheme and place all clocks on
GLOBAL buffers.  Apparently, the use of a GLOBAL in 10KA requires
availability of the associated pin.  Unfortunately, all 4 of the pins
associated with GLOBALs are already being used for standard I/O.  I've
been told board-level mods are out of the question for the features
I'm adding to the FPGA, so swapping pins at this point is not an
option.  My question is this:  Does placing an internal signal on a
GLOBAL macro cause the associated pin to be driven by that internal
signal or is the pin just tri-stated and unavailable for use?

Thanks,

Stephen Byrne

Article: 35603
Subject: Re: qpsk clock recovery
From: eric.jacobsen@ieee.org (Eric Jacobsen)
Date: Thu, 11 Oct 2001 16:07:50 GMT
Links: << >>  << T >>  << A >>
On 11 Oct 2001 05:12:33 -0700, eas@bi.net.tr (eas) wrote:

>"Bhaskar Thiagarajan" <bhaskart@my-deja.com> wrote in message news:<9q1sqq$loqqh$1@ID-82263.news.dfncis.de>...
>> Clock recovery is a very important part of receivers and is discussed pretty
>> much in every communications text. There are various methods to perform this
>> function, but some of the common methods are well described (Ray just
>> described one using PLLs).
>> If you want to perform this block in real time at that kind of data
>> rates...FPGAs/ASICs are your only choice. But if you can store a large
>> amount of data and post process this, you can probably do this on a DSP.
>> Search for key words like clock recovery, Costas Loop, etc. I doubt if you
>> will find detailed examples of implementation other than descriptions on how
>> this is typically done.
>> --
>> Cheers
>> Bhaskar
>> Note: I do *not* check the listed email address.
>> 
>
>OK. Now I have to ask some question:
>1. Where can I find the basic building blocks examples to perform the
>clock recovery in FPGA?

Can't help ya there.

>2. Some texts explain clock recovery for NRZ data, How should I
>process IQ data to put in a suitable form?

You need to find a suitable phase detector for your data, but it only
needs to be applied to either I or Q, not necessarily both.

>3. I read a text that DPLL is suitable for data rates <10Mbps. Is this
>true?

It depends on the implementation.   Usually a DDS (aka NCO) is used to
generate the recovered clock, and if the input system clock to the DDS
is not sufficiently higher than the symbol rate, you may wind up with
an unacceptably jittery output clock.   Since it is not uncommon to
clock DDS blocks, even in FPGAs, at hundreds of MHz now, it shouldn't
be tough to go well beyond 10Mbaud.  How high you can get will still
depend on your implementation.


Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://home.earthlink.net/~ejacobsensprint

Article: 35604
Subject: Tool qualification for airborne hardware, DO-254
From: "A. de Boer" <adeboer_THANKYOUFORNOTSPAMMINGME_@nlr.nl>
Date: Thu, 11 Oct 2001 18:08:54 +0200
Links: << >>  << T >>  << A >>
Hi all,

For an airborne hardware project, we are considering the use of FPGA's. The product must be designed in accordance with DO-254/ED-80 "Design assurance guidance for airborne electronic hardware", which is, as you may know, the relatively new hardware counterpart of DO-178B. Part of the design for which an FPGA seems a good technical solution, is considered to be level A. The DO-254 requires any tools used for development of such parts to be qualified, to minimise the risk of introduction of errors by the design tool. Tool qualification is apparently far from trivial, and therefore not an option to perform as part of the project. Does anyone know whether DO-254-qualified design tools (e.g. synthesizer, mapper) exist at all?

Thanks in advance for your help,
Alte

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Note: when replying by email, please remove
      the spam block from my e-mail address

Article: 35605
Subject: Re: High level synthesis will never work well :)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 11 Oct 2001 16:25:19 GMT
Links: << >>  << T >>  << A >>
Unfortunately, it does not seem to recognize the use of GSR.  If you put a global
reset on everything, it stays in your design.  TO get it to come out, you then put a
ROC or startup component (black box) on the global reset and the mapper will take it
out....If you put the global reset on all inferred registers.   As Allan points out,
if you need to preset registers, you need the global reset in there, otherwise
everything clears on start up.  The only work around I have found to date is to
instantiate FDR's when I need them.  Not too clean.

It is a basic problem that stems from the primitive models I think, since there is
no global reset pin on them the global reset can't be shown as a net in the HDL.
The work around has been to put the GSR into the reset pin on the FFs, which works
only if your local reset is also async (the synthesis ORs them).

Allan Herriman wrote:

> On Thu, 11 Oct 2001 13:56:02 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >If you have a global reset in your design, synplicity won't also use the reset
> >input to the FF because it doesn't recognize the global reset as being a hidden
> >dedicated net.  I still have not found a satisfactory work around for this.
>
> Hi Ray,
>
> It used to recognise the global reset.  This led to a problem with
> 6.0.0 in that it would remove the redundant reset from the EDIF which
> in turn meant that it didn't retain the reset value (0 or 1) that you
> had asked for.  The back end tools would substitute the default (0).
>
> Bad luck if you wanted 1.
>
> AFAIK I was the first user to report this bug (and it took some weeks
> to convince them that it was a bug).  I wonder if the fix in more
> recent versions of Synplify involved removing the ability to recognise
> the use of GSR?
>
> Regards,
> Allan.
>
> >Andrew Brown wrote:
> >
> >> The designers code was very clear and stated exactly what he wanted !  Maybe
> >> synthesis vendors forget that their tools should synthesis out code - we
> >> won't code to suit them.  Code should be oriented toward fast and efficient
> >> simulation where most designer time is spent.  I wouldn't change code just
> >> to make synthesis work a little better (back to the point about not minding
> >> a few extra gates).  But i do expect synthesis tools to learn how to
> >> implement the code better - as for the architecture - the origional post
> >> didn't specify the device (xilinx infered?) so i don't know if an explicit
> >> synchronous reset is available - i assume it is - in which case it should
> >> have been used.
> >>
> >> A.
> >>
> >> P.S. since we started on coding style :? is outlawed in C these days - it
> >> should probably so the same way in verilog !
> >>
> >> "Lähteenmäki Jussi" <jusa@cc.tut.fi> wrote in message
> >> news:9q3saf$hqh$1@news.cc.tut.fi...
> >> > Don Husby <husby_d@yahoo.com> wrote:
> >> >
> >> > I dont know that much about verilog, but what I see in your
> >> > code is (in my opinion :) ) a synchronous reset, which ofcourse can
> >> > not be fed directly to the asynchronous reset inputs of the flip-flops.
> >> >
> >> > So the counter is actually very optimized, its the designer who is not
> >> > in this case :) Furthermore, counters synthesize very efficiently in
> >> > todays tools, if used properly (the hdl code is clear). In any
> >> > commercial product I would advise to construct all counters from smaller
> >> > counters, say 4-bit counters. It eases the final production testing.
> >> >
> >> > cya,
> >> > juza
> >
> >--
> >--Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930     Fax 401/884-7950
> >email ray@andraka.com
> >http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> >  temporary safety deserve neither liberty nor safety."
> >                                          -Benjamin Franklin, 1759
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35606
Subject: Re: High level synthesis will never work well :)
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 11 Oct 2001 18:57:21 +0200
Links: << >>  << T >>  << A >>
Rick Filipkiewicz schrieb:
> 
> much in the spirit of the `C' vs. Assembler debate of long ago. Memory
> got bigger and cheaper, uPs got faster, and compilers got better =>
> Assembler went Dodo for all but a handful of special cases. Similarly
> FPGA and ASICs are getting bigger and faster so the inefficiencies of
> synthesised code will become less important [synth tools are getting
> better as well, as are FPGA/ASIC P&R tools].

Sadly, you are right. BUT my inner voice says

DONT LETS THOSE SOFTWARE-CRAP BE YOUR GUIDE.

I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP.
I wont complain about a few LUTs or FF wasted, an for many design the
speed limit of the FPGA is far higher than required, but in general I
would like to do good, fast and slim designs. Not this loser C++ crap
;-)

-- 
MFG
Falk



Article: 35607
Subject: Re: High level synthesis will never work well :)
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 11 Oct 2001 18:58:44 +0200
Links: << >>  << T >>  << A >>
Don Husby schrieb:
> 
> It would have taken me longer to restructure my logic
> to use an async reset than it would to simply instantiate
> the 56 flip-flops.  Besides, async resets bring bad luck. :)

Simply synchonize it, so its synchronus again but uses the advantages of
the asynchronous inputs.

-- 
MFG
Falk



Article: 35608
Subject: Re: [Spartan-XL] Driving a BUFGS from a std. IO ...
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 11 Oct 2001 19:08:52 +0200
Links: << >>  << T >>  << A >>
Markus Meng schrieb:
> 
> Hi all,
> 
> is it possible - in VHDL - to connect the signal from a
> std./normal IO-Pin with one of the internal BUFGS Clock
> driver??

AFAIK yes, bacaus in the XL, the buffers can be driven from any internal
net. But the delay pad-buffer will be different, so the timing at the IO
is different.

-- 
MFG
Falk



Article: 35609
Subject: Re: High level synthesis will never work well :)
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 11 Oct 2001 17:10:57 GMT
Links: << >>  << T >>  << A >>
On Thu, 11 Oct 2001 10:29:35 +0000 (UTC), Lähteenmäki Jussi <jusa@cc.tut.fi>
wrote:
>Don Husby <husby_d@yahoo.com> wrote:
>
>	I dont know that much about verilog, but what I see in your
>code is (in my opinion :) ) a synchronous reset, which ofcourse can
>not be fed directly to the asynchronous reset inputs of the flip-flops.
>Furthermore, we cannot implement such a huge counter with only 56 LUTs. 
>Normally, LUTs are say 4 input memory blocks, in which case we can do 
>any logical function of four inputs and one output. However, the highest 
>bit of the 56-bit counter needs the 55 lower bits in its enable input 
>plus the one used for enabling the actual counter. This is true for all 
>the bits, which increases the number of LUTs signicantly. I would bet 
>that 8-bit counter of the same type would consume about 12 LUTs (without
>knowing the targer device).

I dont know much about anything, but what I see in your answer
(in my opinion :) ) is that you dont know much about common current
FPGAs . 

While Don did not mention which FPGAs he is targetting, almost all
FPGAs with 4 input LUTs have something called Carry-Logic, which
means that they can implement a counter at a cost of 1 LUT per bit.

In Xilinx Virtex, Virtex-E, Virtex-EM, Virtex-II, and Spartan-II parts, all
the flipflops include synchronous or asynchronous reset capability.

Your following recomendation of cutting the counter up into little 4
bit pieces might make sense if you were still playing with 74161
type devices, but it has not been true of RAM based FPGAs ever!
(May still be appropriate for antifuse FPGAs, but no-one uses them).

(in my opinion :) )

Philip

>So the counter is actually very optimized, its the designer who is not
>in this case :) Furthermore, counters synthesize very efficiently in 
>todays tools, if used properly (the hdl code is clear). In any 
>commercial product I would advise to construct all counters from smaller
>counters, say 4-bit counters. It eases the final production testing.
>
>cya,
>juza 

Philip Freidin
Fliptronics

Article: 35610
Subject: Re: Virtex-2 maximum clock speed
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 11 Oct 2001 19:27:26 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:
> >
> I hope you (soon) encounter a requirement where Virtex II is a suitable
> choice.

I hope too. BUT, in a current design (got a V200-E on it) it was a
really HARD fight to convince the other guys (especially our customer)
to use the FPGA and not an ASSP, they all were afraid of the development
failure (or at least heavy delay) possibility. Finally they could not
reject the FPGA, because space was absolutely not available (unless we
start soldering the BGAs vertically ;-)

Again, does anyone have some pointers to ressources regarding DDR
Xmission (not just Xilinx papers). I had a look at some JEDEC standards,
but this is not that valueable.

-- 
MFG
Falk


Article: 35611
Subject: Re: High level synthesis will never work well :)
From: NotMe <not-given@invalid.com>
Date: Thu, 11 Oct 2001 20:20:49 GMT
Links: << >>  << T >>  << A >>
As someone who has several years experience writing complex designs in 
VHDL and C++, in a friendly way I urge you to consider that as your 
experience grows you may come to see the meaning of 'good', 'fast' and 
'slim' in different ways.

If C++ or VHDL allows a good, fast, and slim - and solid, reusable - 
specification of your design at that high level, that may be worth a 
hundred times over any wasted gates and slow speed in the result, so 
long as its implementation performance is adequate.  In that sense then, 
your design continues to be good, fast and slim, probably more so than 
ever before.

Specifically on C++, it really is worth persuing the tenets of that 
faith before writing it off - it may change your view of things.

However, if you take heed or not, best of luck!

|Sadly, you are right. BUT my inner voice says
|
|DONT LETS THOSE SOFTWARE-CRAP BE YOUR GUIDE.
|
|I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY 
CRAP.
|I wont complain about a few LUTs or FF wasted, an for many design the
|speed limit of the FPGA is far higher than required, but in general I
|would like to do good, fast and slim designs. Not this loser C++ crap
|;-)
|
|-- 
|MFG
|Falk
--
Posted using Nographer - News in your Browser
http://www.nographer.com - free, open source, and smart


Article: 35612
Subject: Re: Linking components in VHDL
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Thu, 11 Oct 2001 21:21:45 GMT
Links: << >>  << T >>  << A >>
> Andrew Gray wrote:
> 
> Here is my code:
> --------------------------------------------------------------------------------
> -- Specify Libraries.
> --------------------------------------------------------------------------------
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.std_logic_arith.all;
> use IEEE.std_logic_unsigned.all;
> use IEEE.std_logic_signed.all;

DON'T use both std_logic_unsigned and std_logic_signed in the same
entity.  Things get mighty confused re: operator overload.

Use numeric_std instead.

--a

Article: 35613
Subject: Re: contract assembler for BGA based board???
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Thu, 11 Oct 2001 17:47:40 -0400
Links: << >>  << T >>  << A >>
TEAC Inc. www.teacinc.com successfully does BGA placement for our company.

Regards,
  Alex

"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
news:3BC45F0F.76249EF@egr.msu.edu...
>     Can anyone recomend a contract assembler for a few small printed
> circuit boards that will contain a BGA based package?  The production
> quantities will be quite small (10 pieces for the first run, no more
> than 50 pieces for subsequent runs) but I cannot assemble or inspect BGA
> packages.  I am especially interested in manufacturers in the midwestern
> USA and especially in Michigan.
>
> Thanks,
> Theron Hicks
>
>



Article: 35614
Subject: Re: Virtex-2 maximum clock speed
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Thu, 11 Oct 2001 23:59:02 +0100
Links: << >>  << T >>  << A >>

"Falk Brunner" <Falk.Brunner@gmx.de> wrote

> Again, does anyone have some pointers to ressources regarding DDR
> Xmission (not just Xilinx papers). I had a look at some JEDEC standards,
> but this is not that valueable.

Try the Micron site and the Advanced Memory Systems (AMS.org????) site.




Article: 35615
Subject: Re: High level synthesis will never work well :)
From: husby_d@yahoo.com (Don Husby)
Date: 11 Oct 2001 16:32:13 -0700
Links: << >>  << T >>  << A >>
Thanks for the defense, but please be careful
with attributions.  You made it look like I wrote that
nonsense instead of Lähteenmäki Jussi.


Philip Freidin <philip@fliptronics.com> wrote in message news:<9vjbst4i5ma5f3jn08vtqds10dvrnkhtjb@4ax.com>...
> On Thu, 11 Oct 2001 10:29:35 +0000 (UTC), Lähteenmäki Jussi <jusa@cc.tut.fi>
> wrote:
> >Don Husby <husby_d@yahoo.com> wrote:
> >
> >	I dont know that much about verilog, but what I see in your
> >code is (in my opinion :) ) a synchronous reset, which ofcourse can
> >not be fed directly to the asynchronous reset inputs of the flip-flops.
> >Furthermore, we cannot implement such a huge counter with only 56 LUTs. 
> >Normally, LUTs are say 4 input memory blocks, in which case we can do 
> >any logical function of four inputs and one output. However, the highest 
> >bit of the 56-bit counter needs the 55 lower bits in its enable input 
> >plus the one used for enabling the actual counter. This is true for all 
> >the bits, which increases the number of LUTs signicantly. I would bet 
> >that 8-bit counter of the same type would consume about 12 LUTs (without
> >knowing the targer device).
> 
> I dont know much about anything, but what I see in your answer
> (in my opinion :) ) is that you dont know much about common current
> FPGAs . 
> 
> While Don did not mention which FPGAs he is targetting, almost all
> FPGAs with 4 input LUTs have something called Carry-Logic, which
> means that they can implement a counter at a cost of 1 LUT per bit.
> 
> In Xilinx Virtex, Virtex-E, Virtex-EM, Virtex-II, and Spartan-II parts, all
> the flipflops include synchronous or asynchronous reset capability.
> 
> Your following recomendation of cutting the counter up into little 4
> bit pieces might make sense if you were still playing with 74161
> type devices, but it has not been true of RAM based FPGAs ever!
> (May still be appropriate for antifuse FPGAs, but no-one uses them).
> 
> (in my opinion :) )
> 
> Philip
> 
> >So the counter is actually very optimized, its the designer who is not
> >in this case :) Furthermore, counters synthesize very efficiently in 
> >todays tools, if used properly (the hdl code is clear). In any 
> >commercial product I would advise to construct all counters from smaller
> >counters, say 4-bit counters. It eases the final production testing.
> >
> >cya,
> >juza 
> 
> Philip Freidin
> Fliptronics

Article: 35616
Subject: Re: I need free PCI-Core (vhdl)!!
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 11 Oct 2001 16:44:12 -0700
Links: << >>  << T >>  << A >>
No one seem to make any comments about this topic, so I will chip in
my two cents.
OpenCores.org (http://www.opencores.org) seems to be working on a PCI
IP core of their own (http://www.opencores.org/cores/pci/), but it
doesn't look like it is done, and it is written in Verilog.
According to the OpenCores.org PCI IP core project page under "Links
to related sites and documents"
(http://www.opencores.org/cores/pci/pci_links.shtml) a company called
MaxLock (http://www.maxlock.com) used to offer a free PCI IP core in
VHDL, but it seems like it no longer does.
So, in my opinion, there is no free lunch in this world.
        From my own experience developing (still not done completely)
a PCI IP core in Verilog using Xilinx ISE WebPack, it takes some time
(several months working part-time on this) to do the RTL part of it.
After the RTL part is done, you have to do Place & Route (P&R) to fit
the design into the chip, but I think that is where things get tough.
In 33MHz PCI, Tsu (setup time) has to be within 7ns, and Tval
(Clock-to-Output Valid) has to be within 11ns.
For P&R, I only used only User Constraint File (.UCF), and didn't use
Floorplanner.
After P&R, the input pin that had the worst Tsu was around 9ns, and
the output pin that had the worst Tval was around 15ns.
Those results were for Xilinx Spartan-II 150K system gates part speed
grade -5, and if I used speed grade -6 (which is not an option in my
case), the input pin that had the worst Tsu came down to around 7.7ns,
and the output pin that had the worst Tval came down to around 12ns.
Speed grade -5 violated about 75 constraints compared to about 58 for
speed grade -6.
So, at least in my case, my HDL-based PCI IP core cannot meet the
timings of 33MHz PCI for Spartan-II speed grade -5 or -6 with only
automatic P&R.
Therefore, from my experience, just because you got a synthesizable
PCI IP core from somewhere doesn't mean that such IP core can meet PCI
timings.
I used Insight Electronics Spartan-II PCI development board which has
Xilinx Spartan-II 150K system gates part (XC2S150, speed grade -5, 208
pin PQFP package) on it with 8MB of SDRAM on board for only $145
without Xilinx PCI LogiCORE license.
Very nice board considering the price, but I guess I wish they used
speed grade -6 instead of -5.
        Although, I keep emphasizing that it is hard to meet timings
of 33MHz PCI, and I am sure other people will say something similar,
what I have noticed was that violation of up to 5ns doesn't seems to
matter that much if the objective is to just to get the PCI board to
"barely" work.
I tested my own PCI IP core with Insight Electronics Spartan-II PCI
development board, and the board worked fine at PCI running at 33MHz
with both Intel 430TX chipset and SiS 5598 chipset.
The user logic I attached to the PCI IP core was a very simple one
that responds only to I/O cycles, and not memory cycles because I can
access I/O ports through real or V86 mode, but I will have to do a lot
of software writing to access a memory-mapped device that is located
near the top of the 4GB memory space.
Of course, the PCI IP core supported configuration cycle, too.
The worst Tsu was I think around 10 or 11ns, and the worst Tval was
around 15.5ns, and I think it was TRDY#.
I do understand that a lot of people reading comp.fpga.arch will
criticize me for writing something like, "my design worked fine even
though I didn't meet the timings required by the specification," but
the board somehow worked.
I don't have the money to buy an oscilloscope or a logic analyzer, or
know someone who will let me use them, so I really don't know what is
going on the PCI bus.
The most accurate data I got was from post-place & route simulation I
did with ModelSim XE-Starter.
I have absolutely no intention to advocate violating timing
specification, and if someone were to sell a PCI card, that person has
to make sure that timings are met.
But I suppose for a student project (I am guessing), barely working
(not meeting timings) is probably acceptable since the student never
has enough time to complete the project.
        So, my conclusion here will be that you may have to develop
your own PCI IP core which can take months, and it will be tough for a
synthesizable PCI IP core without using Floorplanner to meet 33MHz PCI
timings, but if your objective is to make it barely work somehow, then
violating 33MHz PCI timings may not be a big issue.




Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)



"Ras Sim" <simsek@rhrk.uni-kl.de> wrote in message news:<49a92f681fea693317ee5a82213a3519.32396@mygate.mailgate.org>...
> Hi folks!
> I'm a student and i need a free PCI-Core wich is written in vhdl.
> Where could I download it ?
> 
> Greets
> Rasit

Article: 35617
Subject: Re: Virtex-2 maximum clock speed
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Fri, 12 Oct 2001 00:59:17 +0100
Links: << >>  << T >>  << A >>
I wrote

> "Falk Brunner" <Falk.Brunner@gmx.de> wrote
>
> > Again, does anyone have some pointers to ressources regarding DDR
> > Xmission (not just Xilinx papers). I had a look at some JEDEC standards,
> > but this is not that valueable.
>
> Try the Micron site and the Advanced Memory Systems (AMS.org????) site.
>

AMS is here:

http://www.ami2.com/online_info.asp



Article: 35618
Subject: Re: High level synthesis will never work well :)
From: vitaliyt@xillix.com (Vitaliy Tkachenko)
Date: 11 Oct 2001 19:57:59 -0700
Links: << >>  << T >>  << A >>
husby_d@yahoo.com (Don Husby) wrote in message news:<35802095.0110101232.6249a107@posting.google.com>...
> More wacky synthesis results from Synplicity:
> 
> (Note that this sort of thing isn't specific to
> Synplicity.  Leonardo does a lot of wacky things too.
> Sadly, Synplicity is probably the better tool.)
> 
> You'd think a simple 56-bit counter would be no
> problem.  The code below should synthesize to
> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
> Instead, Synplicity adds an extra 57 LUTs and an extra
> level of logic.
> 
>   module Cnt56(K, CE, R, Out);
>     input         K, CE, R;
>     output [55:0] Out;
>     reg    [55:0] Q;
>     assign Out= Q;
>     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
>     // if (R)       Q <= 0;    // This doesn't work either
>     // else if (CE) Q <= Q+1;
>   endmodule
> 
> Why?  Instead of running the R signal directly to the
> reset pin of the flip flop, Synplicity merges it into
> the equations for Q and CE.  So we get:
> 
>   module Cnt56(K, CE, R, Out);
>     input         K, CE, R;
>     output [55:0] Out;
>     reg    [55:0] Q;
>     assign Out= Q;
> 
>     wire [55:0] Q_plus_1 = Q+1;
>     wire [55:0] Q_and_R = R ? Q_plus_1 : 0; 
>     wire        CE_or_R = CE | R;
> 
>     always @(posedge K) if (CE_or_R) Q <= Q_and_R;
>   endmodule
> 

The tool does precisely what you ask for - it implements a synchronous
reset since R is not in the sensitivity list.
If you need to reset the counter asynchronously, you must use "an
always statement whose event list contains edge events representing
the clock and asynchronous control variables".

Try this. 

module Cnt56(K, CE, R, Out);
  input         K, CE, R;
  output [55:0] Out;
  reg    [55:0] Q;
  assign Out= Q;
  always @(posedge K or posedge R)
    if (R)       Q <= 0;
    else if (CE) Q <= Q+1;
endmodule

I do not have Synplicity, but with Leonardo it works perfectly well.
And the global reset is another issue. A tool may recognize it or not,
depending on the code and the tool capabilities. So it may be either
the global (chip wide) reset, or just an asynchronous reset, which can
be assigned to an IO pin, or used locally.

Regards,
Vitaliy

Article: 35619
Subject: Re: High level synthesis will never work well :)
From: ()
Date: Fri, 12 Oct 2001 04:09:30 -0000
Links: << >>  << T >>  << A >>
In article <a03b733b.0110111857.60281841@posting.google.com>, vitaliyt@xillix.com wrote:
>husby_d@yahoo.com (Don Husby) wrote in message news:<35802095.0110101232.6249a107@posting.google.com>...
>> More wacky synthesis results from Synplicity:
>> 
>> (Note that this sort of thing isn't specific to
>> Synplicity.  Leonardo does a lot of wacky things too.
>> Sadly, Synplicity is probably the better tool.)
>> 
>> You'd think a simple 56-bit counter would be no
>> problem.  The code below should synthesize to
>> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
>> Instead, Synplicity adds an extra 57 LUTs and an extra
>> level of logic.
>> 
>>   module Cnt56(K, CE, R, Out);
>>     input         K, CE, R;
>>     output [55:0] Out;
>>     reg    [55:0] Q;
>>     assign Out= Q;
>>     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
>>     // if (R)       Q <= 0;    // This doesn't work either
>>     // else if (CE) Q <= Q+1;
>>   endmodule
>> 
>> Why?  Instead of running the R signal directly to the
>> reset pin of the flip flop, Synplicity merges it into
>> the equations for Q and CE.  So we get:
>> 
>>   module Cnt56(K, CE, R, Out);
>>     input         K, CE, R;
>>     output [55:0] Out;
>>     reg    [55:0] Q;
>>     assign Out= Q;
>> 
>>     wire [55:0] Q_plus_1 = Q+1;
>>     wire [55:0] Q_and_R = R ? Q_plus_1 : 0; 
>>     wire        CE_or_R = CE | R;
>> 
>>     always @(posedge K) if (CE_or_R) Q <= Q_and_R;
>>   endmodule
>> 
>
>The tool does precisely what you ask for - it implements a synchronous
>reset since R is not in the sensitivity list.
>If you need to reset the counter asynchronously, you must use "an
>always statement whose event list contains edge events representing
>the clock and asynchronous control variables".
>
>Try this. 
>
>module Cnt56(K, CE, R, Out);
>  input         K, CE, R;
>  output [55:0] Out;
>  reg    [55:0] Q;
>  assign Out= Q;
>  always @(posedge K or posedge R)
>    if (R)       Q <= 0;
>    else if (CE) Q <= Q+1;
>endmodule
>
>I do not have Synplicity, but with Leonardo it works perfectly well.
>And the global reset is another issue. A tool may recognize it or not,
>depending on the code and the tool capabilities. So it may be either
>the global (chip wide) reset, or just an asynchronous reset, which can
>be assigned to an IO pin, or used locally.
>
>Regards,
>Vitaliy


Article: 35620
Subject: Re: High level synthesis will never work well :)
From: husby_d@yahoo.com (Don Husby)
Date: Fri, 12 Oct 2001 04:38:09 GMT
Links: << >>  << T >>  << A >>
On 11 Oct 2001 19:57:59 -0700, vitaliyt@xillix.com (Vitaliy Tkachenko)
wrote:
>The tool does precisely what you ask for - it implements a synchronous
>reset since R is not in the sensitivity list.
>If you need to reset the counter asynchronously, you must use "an
>always statement whose event list contains edge events representing
>the clock and asynchronous control variables".

Apparently, more than 1 person is under the impression that I wanted
an asynchronous reset.  What I wanted  (and what I got) was a
synchronous reset.  Unfortunately, the synchronous reset was
implemented using  57 LUTs and an extra level of logic instead of
simply routing the reset signal to the synchronous reset input of the
flip flops.

Sorry I didn't make this clear the first time.



Article: 35621
Subject: Block RAMs
From: gautam_awasthi@yahoo.co.in (Gautam)
Date: 11 Oct 2001 22:05:36 -0700
Links: << >>  << T >>  << A >>
Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs.
What are the advantages & disadvantages of each of them from the Users
perspective?

Article: 35622
Subject: Re: Block RAMs
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 12 Oct 2001 06:04:57 GMT
Links: << >>  << T >>  << A >>
Xilinx has 4Kbit BlockRAMs in Virtex and Virtex-E, and 18Kbit BlockRAMs
in Virtex-II.
The advantage of either must be very applications-dependent. Obviously,
the user can concatenate several small RAMs into a large one, but that
wastes performance and area.
Obviously, a large RAM appears wasteful when you need a little one, but
Xilinx can always offer the 16-bit distributed RAMs that Altera does not
have. I found good use for the larger, and especially wider BlockRAM (
512 x 36, and dual-ported on top! ) for unconventional applications.
Your mileage may vary...
Peter Alfke

Gautam wrote:

> Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs.
> What are the advantages & disadvantages of each of them from the Users
> perspective?


Article: 35623
Subject: Re: Block RAMs
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 12 Oct 2001 06:17:07 GMT
Links: << >>  << T >>  << A >>
One more thing:
If you need more, but smaller RAMs, you can always make two fully
independent single-port RAMs out of one dual-ported RAM ( Tie address MSB
High in one port, Low in the other )
Pretty simple, but often overlooked.

Peter Alfke
===========================
Gautam wrote:

> Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs.
> What are the advantages & disadvantages of each of them from the Users
> perspective?


Article: 35624
Subject: Re: Linking components in VHDL
From: kbkrishnan@tataelxsi.co.in (balakrishnan)
Date: 12 Oct 2001 00:02:07 -0700
Links: << >>  << T >>  << A >>
hi,
check whether your component entity declartion and entity you have
placed in your top level match.check for signal type also. from your
package declartion you can remove ieee.std_logic_signed.all
can you post code for your component?
regards
bala



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