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 116200

Article: 116200
Subject: Re: Multiplication operation
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 4 Mar 2007 12:47:23 -0800
Links: << >>  << T >>  << A >>
Matthew let me argue for peace:
It all depends on your roots.
If you started out as a logic designer (like I did), then you see the
FPGA as a wonderful way to design a production-worthy breadboard of
terrific complexity and very good performance. God's gift to the logic
designer, good-bye wire-wrap!
I think in terms of block diagrams, and use VHDL/Verilog to manage the
design process. I would never be in doubt about the choice of binary
vs decimal, or fixed vs floating point, because they have such
enenormous impact on the design efficiency.

If you start out as a computer programmer, then you design=program the
way this thread was started, totally oblivious of hardware constraints
and limittions. Let the synthesizer worry about those details! The
trouble is that these unworthy details can impact the design by an
order of magnitude in size=cost and performance.

You will never beat the urge for economy, performance, and design
elegance out of us hardware guys. Maybe one day FPGAs will become so
big and cheap and fast that it does not matter anymore.
Well, hopefully there will always be Social Security.
And St. Peter might show mercy with us former pip-pokers genus
schemato-saurus.
Peter Alfke


On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> First, to address the question, you're not really doing multiplication but
> performing division through multiplication with decimals.  ISE doesn't do
> division either way.  Like John_H said, scale your numbers up (refer to fixed
> point numbers) so multiplication is done with integers.  When done, just
> scale the result down by the same amount for the final answer.  A hint is
> to scale the numbers by a power of 2 so you just have to do bit shifts.
>
> Second, I would like to give my two cents on John_H's 1990's attitude.  You
> shouldn't tell someone to read up on vendor specific blocks when it is clear
> that they are just starting out, doesn't need an optimal implementation,
> and don't have a firm grasp on the basics.  You should give them a very simple
> and concise explanation at their level and a fix at their level.  The synthesizer
> is more than capable of handling the * symbol, the OP doesn't need to worry
> about what Xilinx puts on the hood.  If Xilinx were smart and had good programmers,
> which it seems they are trying to work towards, no one would need to know
> of any of the blocks under the hood.  People should be able to "program"
> the hardware.  The synthesis program should be smart enough to use the blocks
> under the hood to provide a near optimal implementation of the "program".
>  There is a reason why people use high level programming languages not assembly.
>  For everyone's sake, "designing" a system on an FPGA shouldn't be hard.
>
> ---Matthew Hicks
>
> > VHDL_HELP wrote:
>
> >> Hi every body ,
> >> i hope that you can help me , i want to do this operation:
> >> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1
> >> when i check the syntax , i have these errors
> >> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. *
> >> can
> >> not have such operands in this context.
> >> ---------------------------------------------------------------------
> >> ---------------------------------------------------------------------
> >> ----------------------
>
> >> library IEEE;
>
> >> use IEEE.STD_LOGIC_1164.ALL;
>
> >> use IEEE.STD_LOGIC_ARITH.ALL;
>
> >> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> >> entity operation is
> >> Port ( clk : in  STD_LOGIC;
> >> c1 : in  STD_LOGIC_VECTOR (7 downto 0);
> >> c2 : in  STD_LOGIC_VECTOR (7 downto 0);
> >> c 3: in  STD_LOGIC_VECTOR (7 downto 0);
> >> s: out  STD_LOGIC_VECTOR (7 downto 0);
> >> end operation;
>
> >> architecture Behavioral of operation is
>
> >> begin
>
> >> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ;
>
> >> end Behavioral;
>
> >> ---------------------------------------------------------------------
> >> ---------------------------------------------------------------------
> >> ----------------
>
> >> and thanks for your help
>
> > Can you tell me how the synthesizer will format your floating point
> > result in s so it maps to silicon?
>
> > Use scaled integers.  Use the precision available in the hardware
> > multipliers to get a rather precise approximation of s.  The digital
> > realm is binary, after all, not decimal.
>
> > Please read up on how the hardware multipliers perform and how best to
> > utilize them.  It's insanely sad to see someone trying to "program" an
> > FPGA rather than design it.



Article: 116201
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 05 Mar 2007 10:25:38 +1300
Links: << >>  << T >>  << A >>
Austin wrote:

> Marc,
> 
> Other than their odd name, they are extremely low impedance t-lines.
> 
> As such, they are basically falt at 1200 uF from DC to daylinght.
> 
> So, if you put a power supply at one end, and isolate the ground (in 
> other words, that is what the slit is for) you transfer power to the 
> other end (hot and ground) with a .001 ohm t-line (looks like that very 
> low impedance at frequencies up to a few hundred MHz).
> 
> So, now you see a AC short, looking either way:  from the power asupply 
> to the load, or from the load to the power supply.
> 
> The Playstation 3 uses 8 of them, they isolate each huge ASIC from the 
> other huge ASICs, and there are3 NO OTHER CAPS on the pcb....
> 
> Yes, that is right.
> 
> Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line 
> structures.
> 
> Do they work?  Well, millions of PS3 aren't chunking away happily for no 
> reason at all.
> 
> We are looking at these seriously to reduce the bypassing requirements 
> down to the PS3 limit:  a few of these, and NOTHING else (no other 
> bypass caps whatsoever).

To make best use of these, you may need to redo the power supply fanout
on the FPGAs.

Or, include them IN the package :)

I could, for example, see merit in allowing a BALL-Free area on the BGA,
designed to allow one of these to mount under the FPGA, on the opposite 
side.

> So, it seems the NEC-TOKIN part is the first really new invention in 
> bypassing in many many long years of people who just like to ignore that 
> power distribution is a real issue, and one that needs some creativity.
> 
> My hat is off to the engineers who created this wonder.

These are a SMD variant of T filter/feed thru networks, and a variant on 
3 terminal SMD capacitors.

In all those, the power is passed THRU the decoupling element (so they
have a mOhm spec as well ), and it means there is no series L that kills
most trace+via+cap decouplers.

Such feed-thru decouplers, are also very good at keeping noise where it 
belongs : their plots show very good localisation of the noise, but
also seem to show higher levels at 'die-central', than when using the
more distributed decoupling.
See my comment above, about using one of these underneath the BGA, on 
the rear of the PCB.

I also see their (impressive) impedance plots, are the devices 
themselves, and there is no mention of VIA patterns, or trace fanout limits.

-jg






Article: 116202
Subject: Re: xilinx block ram synthesis
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 04 Mar 2007 16:57:31 -0500
Links: << >>  << T >>  << A >>
Hi!

I have also been quite frustrated by XST BRAM inference in the past... 
and have yet to get XST to do what I want.

If you go check the XST "coding style guide" which contains VHDL 
templates for inferring most of the supported BRAM types, you might find 
exactly what you want.

In my case, I wanted to infer "True dual-port BRAMs" but copy-pasting 
the guide's template (ISE 8.1/8.2) consistently resulted in XST crashes. 
After wasting a week trying to work this out last summer, I decided to 
give up and used a coregen RAM.

More details about my experience with the true dual-port BRAM template:
- pasting the code in the module's VHDL causes unrecognized BRAM 
inference warnings, causing XST to attempt implementation with 
distributed RAM
- whipping up the template into its own module and synthesizing it as a 
top module works as advertised/expected
- instantiating the BRAM template module in an actual design crashes XST



S.T. wrote:
> Hi 
> 
> Thanks for your feedback. Unfortunately both suggestions didn't work :-(.
> When removing the Reset path the synthesized ram will get dual ported
> instead of single ported (see below). I tried to rewrite it and make the
> read and write enable signals explicit and decoupling the reset from ram.
> It also doesn't work i.e. it still gives distributed instead of block
> ram :-(.

> Synthesizing Unit <BRAM_test>.
>     Related source file
> is "/amd/iss1/users/ma/tstone/georg/bram/BRAM_test.vhd".
>     Found 1024x16-bit single-port distributed RAM for signal <RAM>.
>     -----------------------------------------------------------------------
>     | ram_style          | block                               |          |
>     -----------------------------------------------------------------------
>     | Port A                                                              |
>     |     aspect ratio   | 1024-word x 16-bit                  |          |
>     |     clkA           | connected to signal <CLOCK>         | rise     |
>     |     weA            | connected to internal node          | high     |
>     |     addrA          | connected to signal <addr>          |          |
>     |     diA            | connected to signal <di>            |          |
>     |     doA            | connected to internal node          |          |
>     -----------------------------------------------------------------------
> WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the RAM
> contents is read synchronously.
> 
> 
> 

Article: 116203
Subject: Re: Digital AM/FM Receiver
From: "morpheus" <saurster@gmail.com>
Date: 4 Mar 2007 14:43:22 -0800
Links: << >>  << T >>  << A >>
On Feb 9, 12:48 am, Johan Bernspang
<j.NOSPAMbernsp...@gNOSPAMmail.com> wrote:
> morpheus skrev:
>
>
>
> > Hi There!
> > I am designing adigitalAM/FMreceiverin a Vertex-4 FPGA. I have
> > designed the system blocks but have one question regardingdigital
> > filtering.
> >>From a systemic point of view, we are using the DDC approach to
> > convert IF 45MHz down to baseband. After this we are using a 40MSPS A/
> > D to sample and output parallel 12-bit I, Q data to the FPGA.
> > The FPGA front end has to have a LPF with a cut-off frequency of 5kHz.
> > After the LPF, AM andFMneed to be demodulated. I intend to do
> > demodulation as follows
> >FM-> (Q(n)I(n-1) - I(n)Q(n-1))/(I-Sq + Q-Sq)
> > AM -> (I-Sq + Q-Sq)
> > My question is:
> > I need to do some decimation (to make my life easier when it comes to
> > 5kHz LPF design)...what is the best way of doing this? I have read
> > some material and it seems to point towards cascaded CIC filters.
> > Please comment and also let me know if you notice any flaw in my
> > design methodology. Moreover, due to my inexperience in this field, I
> > wanted to know if decimation upstream would affect (adversely) my AM/
> >FMdemodulation process.
>
> > cheers
> > Morpheus
>
> Hi Morpheus,
>
> I designed adigitalAM/FMreceiveron a Virtex-2 FPGA a couple of years
> ago. Since I had a 210 Msps ADC (12 bits resolution) before the FPGA I
> did not do any DDC before the device. Instead I used a DDS internally
> and mixed the desired frequency down to baseband. For the decimation I
> used CIC filters in two stages and it worked good. I decimated the
> signal from ~200 MHz to about 128 kHz which was much more convenient for
> LP filtering. The CIC filters them selves has some LP properties too.
>
> To extract the amplitude and phase from the I and Q I used a Cordic.
> Then it was quite easy to calculate the phase difference, and the
> amplitude is given.
>
> Good luck!
>
> /Johan

Hey Johan,
I do get the architecture now. Most likely, I would follow the same
technique as you did. I haven't used CORDIC before and even though I
am reading up on it extensively, I was wondering if you could
elaborate more (biased towards implementation). I do understand that I
have to do this bit-serially and use the ARCTAN(x/y) function and
subtract the current phase with the previous phase, to generate the FM
signal. The AM can be generated though the Vector magnitude part of
the CORDIC core.
Any comments?
Thanks
MORPHEUS


Article: 116204
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Austin <austin@xilinx.com>
Date: Sun, 04 Mar 2007 15:29:06 -0800
Links: << >>  << T >>  << A >>

> How do you handle the multiple voltages? Are they expensive?

Tim,

Use more than one, one for each supply rail.

As for cost, it cn't be that bad:  if PS3 needs 8 to replace 300 0402 
0.1uF caps?

Austin

Article: 116205
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Austin <austin@xilinx.com>
Date: Sun, 04 Mar 2007 15:33:05 -0800
Links: << >>  << T >>  << A >>
Jim,

I think what is "new" is that these are true four terminal (two 
port)devices.

You think of them with S11, S22, and S21, S12 parameters.

The isolation goes both ways, and from either port, it looks like a dead 
AC short (which is better than a capacitor, which only looks like a dead 
short at one frequency where it is resonant).

They are actually built like a long t-line, with huge C per unit length, 
and a very tiny L per unit length, which leads to their extraordinary 
behavior.  The careful ratio of LC causes it to act, and appeaqr to be 
flat over the wide range of frequencies in terms of it Zo.

Austin

Article: 116206
Subject: Re: Boot uClinux from RAM without flash
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 05 Mar 2007 10:38:57 +1000
Links: << >>  << T >>  << A >>
Hi Lancer,

Lancer wrote:

> I'm trying to to put uClinux on my Spartan 3 Starter Board (it hasn't
> flash memory and it has only 1MB RAM).
> Finally I've made an uClinux < 1MB (986 KB :-P ).
> Now I've downloaded Microblaze on SP3 using XPS, but I want to know,
> do I need bootloader to startup uClinux from RAM?
> How to download image.bin on it and startup it? (I'm using XPS for Win
> XP).

You can use XMD's "dow" command to download the Linux image into 
MicroBlaze memory, and then "con" to start the CPU.

e.g,

$ xmd

% connect mb mdm
% rst
% dow -data /tftpboot/image.bin 0x22000000
% con 0x22000000

using the correct paths and addresses, of course.

Regards,

John


From taileb.mehdi@gmail.com Sun Mar 04 16:57:15 2007
Path: newssvr12.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!news.astraweb.com!border2.newsrouter.astraweb.com!news-out.readnews.com!news-xxxfer.readnews.com!postnews.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 04 Mar 2007 18:57:15 -0600
From: El Mehdi Taileb <taileb.mehdi@gmail.com>
Subject: Integrate custom cores within Core Generator
Newsgroups: comp.arch.fpga
User-Agent: Pan/0.125 (Potzrebie)
Message-Id: <pan.2007.03.05.00.57.08@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Sun, 04 Mar 2007 18:57:15 -0600
Lines: 5
X-Trace: sv3-42Uh9eQBWIMR91TLg/Sd4e17iCYp7MmhDnXudJ/jnPG2rsBDUW3+83YviebZkgvjOJiT7RECiS8zg4M!dEkYKylIyeTi7Lxy/u+uP2W40XyNvB8yHdGu2RsaSnD2IeJM29kDaamxo/o=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.34
Xref: prodigy.net comp.arch.fpga:127692

Is there a way to integrate custom cores into Core Generator. i.e develop 
the GUI etc etc???

Best Regards
Mehdi

From dave@comteck.com Sun Mar 04 17:51:34 2007
Path: newssvr12.news.prodigy.net!newsdbm05.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!uns-out.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!COMTECK.COM-a2kHrUvQQWlmc!not-for-mail
From: Dave <dave@comteck.com>
Subject: Re: Multiplication operation
Date: Sun, 04 Mar 2007 20:51:34 -0500
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2007.03.05.01.51.24.71748@comteck.com>
Newsgroups: comp.arch.fpga
References: <KtjGh.116$nU5.24@trnddc04> <b66e65222b828c92c7e41afc5c6@news.ks.uiuc.edu> <1173041243.206811.184650@8g2000cwh.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@usenetserver.com
Organization: UseNetServer.com
Lines: 29
X-Trace: e6efe45eb777de51d97ba02814
Xref: prodigy.net comp.arch.fpga:127693

On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote:

> If you started out as a logic designer (like I did), then you see the
> FPGA as a wonderful way to design a production-worthy breadboard of
> terrific complexity and very good performance. 
> ...
> If you start out as a computer programmer, then you design=program the
> way this thread was started, totally oblivious of hardware constraints
> and limittions. 
> ...
> You will never beat the urge for economy, performance, and design
> elegance out of us hardware guys. 
> ...

So where do us embedded systems half-breeds who have done both rank in
this comparison?  One could postulate that we get 95% of the efficiency
of the purebred HW and purebred programmer (rejecting the urge to try for
that last 5% which takes all the time), beating you both to market with a
design which is elegant, economical, and meets performance requirements
since we see from both sides.

   :-P     ;-))


     ~Dave~





Article: 116207
Subject: Re: Multiplication operation
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 05 Mar 2007 03:51:19 GMT
Links: << >>  << T >>  << A >>
Dave wrote:
> On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote:
> 
>> If you started out as a logic designer (like I did), then you see the
>> FPGA as a wonderful way to design a production-worthy breadboard of
>> terrific complexity and very good performance. 
>> ...
>> If you start out as a computer programmer, then you design=program the
>> way this thread was started, totally oblivious of hardware constraints
>> and limittions. 
>> ...
>> You will never beat the urge for economy, performance, and design
>> elegance out of us hardware guys. 
>> ...
> 
> So where do us embedded systems half-breeds who have done both rank in
> this comparison?  One could postulate that we get 95% of the efficiency
> of the purebred HW and purebred programmer (rejecting the urge to try for
> that last 5% which takes all the time), beating you both to market with a
> design which is elegant, economical, and meets performance requirements
> since we see from both sides.
> 
>    :-P     ;-))
> 
> 
>      ~Dave~

You go, Dave!
Being in this middle ground - in my opinion - give you exceptional 
insight into strong designs with better time to completion.

A programmer can become hardware aware and cross over enough to get the 
performance.  A hardware guy can get deep enough into the computing side 
to increase the algorithmic efficiency of the design.  It sounds like 
you're already squarely placed in this productive center.

Article: 116208
Subject: Re: Multiplication operation
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 4 Mar 2007 20:32:13 -0800
Links: << >>  << T >>  << A >>
This is one of the few threads that got better as it went on.
Rare excepton...
Peter Alfke

On Mar 4, 7:51 pm, John_H <newsgr...@johnhandwork.com> wrote:
> Dave wrote:
> > On Sun, 04 Mar 2007 12:47:23 -0800, Peter Alfke wrote:
>
> >> If you started out as a logic designer (like I did), then you see the
> >> FPGA as a wonderful way to design a production-worthy breadboard of
> >> terrific complexity and very good performance.
> >> ...
> >> If you start out as a computer programmer, then you design=program the
> >> way this thread was started, totally oblivious of hardware constraints
> >> and limittions.
> >> ...
> >> You will never beat the urge for economy, performance, and design
> >> elegance out of us hardware guys.
> >> ...
>
> > So where do us embedded systems half-breeds who have done both rank in
> > this comparison?  One could postulate that we get 95% of the efficiency
> > of the purebred HW and purebred programmer (rejecting the urge to try for
> > that last 5% which takes all the time), beating you both to market with a
> > design which is elegant, economical, and meets performance requirements
> > since we see from both sides.
>
> >    :-P     ;-))
>
> >      ~Dave~
>
> You go, Dave!
> Being in this middle ground - in my opinion - give you exceptional
> insight into strong designs with better time to completion.
>
> A programmer can become hardware aware and cross over enough to get the
> performance.  A hardware guy can get deep enough into the computing side
> to increase the algorithmic efficiency of the design.  It sounds like
> you're already squarely placed in this productive center.



Article: 116209
Subject: Re: Multiplication operation
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Mon, 5 Mar 2007 04:42:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter, I totally agree with your points and while writing my post I knew 
there would be a huge difference in perspective because of one, the generation(s) 
gap, as I am still in graduate school, and two, the background, as I have 
a C.S. degree.  However, my comments were more for beginners who shouldn't 
be overloaded in the infinite amounts of complexity possible with FPGAs (for 
an example just read one of Austin's posts).  Newbies who are probably working 
on some trivial project should get the fundamentals first (everything is 
binary, data flow, ...) and then work towards the actual optimized implementations 
gradually building in complexity, if constraints deem it necessary.  After 
all, you don't learn to swim in the ocean during a hurricane, you start in 
the kiddy pool.

Although, I still believe a lot of work needs to be done to synthesis engines 
so they can better abstract the low-level complexity away from the designer 
all the while resulting in an optimized implementation.  For a quick example, 
I still cannot believe you don't optimize across files during synthesis. 
 For the time being, I prefer the embedded systems point of view presented 
in Dave's response.


---Matthew Hicks


> Matthew let me argue for peace:
> It all depends on your roots.
> If you started out as a logic designer (like I did), then you see the
> FPGA as a wonderful way to design a production-worthy breadboard of
> terrific complexity and very good performance. God's gift to the logic
> designer, good-bye wire-wrap!
> I think in terms of block diagrams, and use VHDL/Verilog to manage the
> design process. I would never be in doubt about the choice of binary
> vs decimal, or fixed vs floating point, because they have such
> enenormous impact on the design efficiency.
> If you start out as a computer programmer, then you design=program the
> way this thread was started, totally oblivious of hardware constraints
> and limittions. Let the synthesizer worry about those details! The
> trouble is that these unworthy details can impact the design by an
> order of magnitude in size=cost and performance.
> 
> You will never beat the urge for economy, performance, and design
> elegance out of us hardware guys. Maybe one day FPGAs will become so
> big and cheap and fast that it does not matter anymore.
> Well, hopefully there will always be Social Security.
> And St. Peter might show mercy with us former pip-pokers genus
> schemato-saurus.
> Peter Alfke
> On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> 
>> First, to address the question, you're not really doing
>> multiplication but
>> performing division through multiplication with decimals.  ISE
>> doesn't do
>> division either way.  Like John_H said, scale your numbers up (refer
>> to fixed
>> point numbers) so multiplication is done with integers.  When done,
>> just
>> scale the result down by the same amount for the final answer.  A
>> hint is
>> to scale the numbers by a power of 2 so you just have to do bit
>> shifts.
>> Second, I would like to give my two cents on John_H's 1990's
>> attitude.  You
>> shouldn't tell someone to read up on vendor specific blocks when it
>> is clear
>> that they are just starting out, doesn't need an optimal
>> implementation,
>> and don't have a firm grasp on the basics.  You should give them a
>> very simple
>> and concise explanation at their level and a fix at their level.  The
>> synthesizer
>> is more than capable of handling the * symbol, the OP doesn't need to
>> worry
>> about what Xilinx puts on the hood.  If Xilinx were smart and had
>> good programmers,
>> which it seems they are trying to work towards, no one would need to
>> know
>> of any of the blocks under the hood.  People should be able to
>> "program"
>> the hardware.  The synthesis program should be smart enough to use
>> the blocks
>> under the hood to provide a near optimal implementation of the
>> "program".
>> There is a reason why people use high level programming languages not
>> assembly.
>> For everyone's sake, "designing" a system on an FPGA shouldn't be
>> hard.
>> ---Matthew Hicks
>> 
>>> VHDL_HELP wrote:
>>> 
>>>> Hi every body ,
>>>> i hope that you can help me , i want to do this operation:
>>>> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1
>>>> when i check the syntax , i have these errors
>>>> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. *
>>>> can
>>>> not have such operands in this context.
>>>> -------------------------------------------------------------------
>>>> --
>>>> -------------------------------------------------------------------
>>>> --
>>>> ----------------------
>>>> library IEEE;
>>>> 
>>>> use IEEE.STD_LOGIC_1164.ALL;
>>>> 
>>>> use IEEE.STD_LOGIC_ARITH.ALL;
>>>> 
>>>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>>>> 
>>>> entity operation is
>>>> Port ( clk : in  STD_LOGIC;
>>>> c1 : in  STD_LOGIC_VECTOR (7 downto 0);
>>>> c2 : in  STD_LOGIC_VECTOR (7 downto 0);
>>>> c 3: in  STD_LOGIC_VECTOR (7 downto 0);
>>>> s: out  STD_LOGIC_VECTOR (7 downto 0);
>>>> end operation;
>>>> architecture Behavioral of operation is
>>>> 
>>>> begin
>>>> 
>>>> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ;
>>>> 
>>>> end Behavioral;
>>>> 
>>>> -------------------------------------------------------------------
>>>> --
>>>> -------------------------------------------------------------------
>>>> -- ----------------
>>>> 
>>>> and thanks for your help
>>>> 
>>> Can you tell me how the synthesizer will format your floating point
>>> result in s so it maps to silicon?
>>> 
>>> Use scaled integers.  Use the precision available in the hardware
>>> multipliers to get a rather precise approximation of s.  The digital
>>> realm is binary, after all, not decimal.
>>> 
>>> Please read up on how the hardware multipliers perform and how best
>>> to utilize them.  It's insanely sad to see someone trying to
>>> "program" an FPGA rather than design it.
>>> 



Article: 116210
Subject: Re: Multiplication operation
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Mon, 5 Mar 2007 04:53:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
As a note, you can condense your binary stings by using their decimal value 
instead, the synthesizer should convert it for you.

So if I scaled your decimals up by multiplying the constants by 2^11=2048 
I would get (using the original equation):
s <= c1 * 410 + c2 * 1229 + c3 * 205 ;

then shift s right by 11 bits to get the final, correctly scaled answer. 
 Note that there is some error with this method, but you can choose your 
multiplier to get the desired error.


---Matthew Hicks


> On 4 mar, 21:12, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> 
>> First, to address the question, you're not really doing
>> multiplication but
>> performing division through multiplication with decimals.  ISE
>> doesn't do
>> division either way.  Like John_H said, scale your numbers up (refer
>> to fixed
>> point numbers) so multiplication is done with integers.  When done,
>> just
>> scale the result down by the same amount for the final answer.  A
>> hint is
>> to scale the numbers by a power of 2 so you just have to do bit
>> shifts.
>> Second, I would like to give my two cents on John_H's 1990's
>> attitude.  You
>> shouldn't tell someone to read up on vendor specific blocks when it
>> is clear
>> that they are just starting out, doesn't need an optimal
>> implementation,
>> and don't have a firm grasp on the basics.  You should give them a
>> very simple
>> and concise explanation at their level and a fix at their level.  The
>> synthesizer
>> is more than capable of handling the * symbol, the OP doesn't need to
>> worry
>> about what Xilinx puts on the hood.  If Xilinx were smart and had
>> good programmers,
>> which it seems they are trying to work towards, no one would need to
>> know
>> of any of the blocks under the hood.  People should be able to
>> "program"
>> the hardware.  The synthesis program should be smart enough to use
>> the blocks
>> under the hood to provide a near optimal implementation of the
>> "program".
>> There is a reason why people use high level programming languages not
>> assembly.
>> For everyone's sake, "designing" a system on an FPGA shouldn't be
>> hard.
>> ---Matthew Hicks
>> 
>>> VHDL_HELP wrote:
>>> 
>>>> Hi every body ,
>>>> i hope that you can help me , i want to do this operation:
>>>> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1
>>>> when i check the syntax , i have these errors
>>>> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. *
>>>> can
>>>> not have such operands in this context.
>>>> -------------------------------------------------------------------
>>>> --
>>>> -------------------------------------------------------------------
>>>> --
>>>> ----------------------
>>>> library IEEE;
>>>> 
>>>> use IEEE.STD_LOGIC_1164.ALL;
>>>> 
>>>> use IEEE.STD_LOGIC_ARITH.ALL;
>>>> 
>>>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>>>> 
>>>> entity operation is
>>>> Port ( clk : in  STD_LOGIC;
>>>> c1 : in  STD_LOGIC_VECTOR (7 downto 0);
>>>> c2 : in  STD_LOGIC_VECTOR (7 downto 0);
>>>> c 3: in  STD_LOGIC_VECTOR (7 downto 0);
>>>> s: out  STD_LOGIC_VECTOR (7 downto 0);
>>>> end operation;
>>>> architecture Behavioral of operation is
>>>> 
>>>> begin
>>>> 
>>>> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ;
>>>> 
>>>> end Behavioral;
>>>> 
>>>> -------------------------------------------------------------------
>>>> --
>>>> -------------------------------------------------------------------
>>>> -- ----------------
>>>> 
>>>> and thanks for your help
>>>> 
>>> Can you tell me how the synthesizer will format your floating point
>>> result in s so it maps to silicon?
>>> 
>>> Use scaled integers.  Use the precision available in the hardware
>>> multipliers to get a rather precise approximation of s.  The digital
>>> realm is binary, after all, not decimal.
>>> 
>>> Please read up on how the hardware multipliers perform and how best
>>> to utilize them.  It's insanely sad to see someone trying to
>>> "program" an FPGA rather than design it.
>>> 
> hi , thank you for your advices first of all ,
> then my equation to resolv is :
> y=0.299 * R + 0.587 *G + 0.114 * B
> for me what i tried to do is:
> ----------------------------------------------------------------------
> ----------------------------------------------
> entity rgb is
> Port ( clk : in  STD_LOGIC;
> R : in  STD_LOGIC_VECTOR (7 downto 0);
> G : in  STD_LOGIC_VECTOR (7 downto 0);
> B : in  STD_LOGIC_VECTOR (7 downto 0);
> Y : out  STD_LOGIC_VECTOR (31 downto 0);
> Cr : out  STD_LOGIC_VECTOR (31 downto 0);
> Cb : out  STD_LOGIC_VECTOR (31 downto 0));
> end rgb;
> architecture arch_rgb of rgb is
> signal yreg :  STD_LOGIC_VECTOR (31 downto 0);
> begin
> process (clk)
> begin
> if clk='1' and clk'event then
> yreg <=  "00111110100110010001011010000111" * R +
> "00111111000101100100010110100001"* G +
> "00111101111010010111100011010100"* B;
> Y <= yreg;
> end if;
> end process;
> end arch_rgb;
> ----------------------------------------------------------------------
> -----------------------
> 



Article: 116211
Subject: Ideas for Masters Project.
From: "RaKa" <rakesh.hemnani@gmail.com>
Date: 4 Mar 2007 21:23:15 -0800
Links: << >>  << T >>  << A >>
Hello Everybody,

I am looking for some interesting project ideas for a Masters Project.
An idea/project that can be implemented on a Xilinx/Altera board and
can be "seen" working.

I would appreciate any suggestions, at the least they would give me a
direction to think in.


Article: 116212
Subject: Re: Multiplication operation
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 05 Mar 2007 05:23:37 GMT
Links: << >>  << T >>  << A >>
VHDL_HELP wrote:
> 
> hi , thank you for your advices first of all ,
> then my equation to resolv is :
> y=0.299 * R + 0.587 *G + 0.114 * B
> for me what i tried to do is:
>  
> --------------------------------------------------------------------------------------------------------------------
> entity rgb is
>     Port ( clk : in  STD_LOGIC;
>            R : in  STD_LOGIC_VECTOR (7 downto 0);
>            G : in  STD_LOGIC_VECTOR (7 downto 0);
>            B : in  STD_LOGIC_VECTOR (7 downto 0);
>            Y : out  STD_LOGIC_VECTOR (31 downto 0);
>            Cr : out  STD_LOGIC_VECTOR (31 downto 0);
>            Cb : out  STD_LOGIC_VECTOR (31 downto 0));
> end rgb;
> 
> architecture arch_rgb of rgb is
> signal yreg :  STD_LOGIC_VECTOR (31 downto 0);
> begin
> process (clk)
> 	begin
> 
> 	if clk='1' and clk'event then
> 		yreg <=  "00111110100110010001011010000111" * R +
> "00111111000101100100010110100001"* G +
> "00111101111010010111100011010100"* B;
> 		Y <= yreg;
> 
> 							end if;
> 		end process;
> end arch_rgb;
> 
> ---------------------------------------------------------------------------------------------
 >
 > this program is with syntax correct but not synthetisable , what i
 > tried to d ois to convert the reals with binary ones

First, I'm worried you might not have the right VHDL libraries specified 
for your operation.

I'd suggest you

1) do a sample module with just one multiply, keeping the binary value 
to 17 bits.  If the one multiply - no addition - doesn't work, it's 
quite possibly a VHDL library issue.  I just know that they're touchy - 
I'm a Verilog guy myself, not VHDL.

2) if the one equation works, define intermediate values for your scaled 
R, scaled G, and scaled B.  Then add those scaled values together to get 
your result.

3) consider whether VHDL will have a problem assigning a nominally 
42-bit result to a 32-bit vector and give you synthesis problems if the 
results don't match in size.


Please keep in mind that multiplication with real numbers is abstracted 
in hardware.  When it's time to implement the operation, there are 
issues with precision and error that have to be understood whether 
you're using an 8-bit ALU or a dual-precision floating point unit.  You 
will have error.  The synthesizer doesn't know what to do with the error 
- round up? round down? truncate? do something else? - and you must 
decide what to do to make your math work out.  If you're in an 8-bit 
ALU, you can do operations that are much more precise than 8 bits.  You 
could cascade multiply/shift/add operations to get 8x24 bit multiplies, 
for instance.

Most of the Xilinx families can multiply 17-bit unsinged values using 
embedded multipliers.  Multiplying an 8-bit color value by a 32-bit 
constant seems like a bit of overkill.  Should the synthesizer perform 
two multiplies and add the intermediate results together to give you a 
40 bit result?  Perhaps.  Personally, I'm glad the synthesis doesn't try 
to implement things this way.

I suggested you "know your silicon" not because everyone using the FPGAs 
should become a down-in-the-transistors hardware guy but because the 
dedicated resources which will implement this rather resource-intensive 
operation has specifications on how it operates, just like the 
arithmetic units in a microprocessor or the single-precision real 
operation in the C language.

Bottom line: since math in many cases is an abstraction, you have to 
know how abstract your results will be.

Article: 116213
Subject: Re: Digital AM/FM Receiver
From: Eric Smith <eric@brouhaha.com>
Date: 04 Mar 2007 21:58:36 -0800
Links: << >>  << T >>  << A >>
"morpheus" wrote:
> I haven't used CORDIC before and even though I
> am reading up on it extensively, I was wondering if you could
> elaborate more (biased towards implementation). I do understand that I
> have to do this bit-serially

CORDIC doesn't have to be done bit-serially.  That's just one method
of implementing it.  You can also do a parallel implementation, and
in either case you can pipeline it or not.  It has the typical
tradeoffs of area and throughput.


Article: 116214
Subject: Re: V.34 Modem IP core
From: Eric Smith <eric@brouhaha.com>
Date: 04 Mar 2007 22:00:32 -0800
Links: << >>  << T >>  << A >>
"GX" <growxpert@gmail.com> writes:
> any IP vendor out there who supply hard/soft core for V.34 Modem?

V.34 is normally (probably always) implemented in software.  You could
put any DSP core (or RISC core with DSP capability) into your FPGA or
ASIC, and run a V.34 implementation on it.

Article: 116215
Subject: Re: Sources (products) for Cannibalizing FPGAs, PLDs, etc.
From: pbFJKD@ludd.invalid
Date: 05 Mar 2007 06:40:33 GMT
Links: << >>  << T >>  << A >>
msg <msg@_cybertheque.org_> wrote:
>msg wrote:
>> A list of consumer, industrial and mil. products, board names and part
>> numbers that contain reprogrammable array logic devices would be very
>> useful...

>A revised list:

>VENDOR           PART NUMBER                  DEVICE           PROGRAMMING     PACKAGE      COMMENTS
>------           -----------                  ------           -----------     -------      --------
>Waters           PCB 510000150 Rev.B   Altera EPM7064LC44-12   Vendor Prog.    44-pin PLCC  Medical related
>                                                                EEPROM

>Compaq           SP#136344-001 Remote  Xilinx xc9572xl         JTAG            100-pin TQFP Under daugherter bd
>                  Insight Board

>Matrox           706-02 Rev. A Video   Xilinx xc5204           Ser/Par/Jtag    144-pin TQFP p/o MIL2/RRSTN VGA
>                  Capture daughter bd.

>Radius           VideoVision Studio    Lattice pLSI1032-80LJ   Programmer      84-pin PLCC  Mac Video Capture
>                  NuBus 632-0156-02                             EEPROM


>Additions sought.

Your list should include 'model number' to it feasable to find the product
aswell.

Ie:
  Vendor:  Creative
  Model:   SoundBlaster X-Fi Elite Pro

Product introduction date also makes it easier.

Thoe I have to agree that the economics is doubtfull.


Article: 116216
Subject: is bluespec pupolar in industry?
From: "CMOS" <manusha@millenniumit.com>
Date: 5 Mar 2007 00:06:21 -0800
Links: << >>  << T >>  << A >>

is bluespec pupolar in industry? is it worth learning?

CMOS


Article: 116217
Subject: Re: Sources (products) for Cannibalizing FPGAs, PLDs, etc.
From: Ben Jackson <ben@ben.com>
Date: Mon, 05 Mar 2007 02:22:44 -0600
Links: << >>  << T >>  << A >>
On 2007-03-03, msg <msg@_cybertheque.org_> wrote:
> Waters           PCB 510000150 Rev.B   Altera EPM7064LC44-12   Vendor Prog.    44-pin PLCC  Medical related

The EPM7064 isn't ISP capable.  You need a special programmer.  I was
just given a handful and discovered this myself.  There are newer EPM7000
series parts that DO have JTAG and ISP.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 116218
Subject: Re: Potential problem in batch files for Xilinx
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 05 Mar 2007 08:47:55 +0000
Links: << >>  << T >>  << A >>
Martin Thompson <martin.j.thompson@trw.com> writes:

I remembered :-)

CR # 435345

Cheers,
Martin

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

Article: 116219
Subject: Re: Potential problem in batch files for Xilinx
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 05 Mar 2007 08:51:17 +0000
Links: << >>  << T >>  << A >>
"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> writes:

> On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>> "Patrick Dubois" <prdub...@gmail.com> writes:
>> > Hello,
>>
>> > I have been using batch files to handle the build process with a
>> > Xilinx flow for a while. Now I want to move to a more sophisticated
>> > approach to handle dependencies better.
>>
>> This has just reminded me of something I discovered recently:
>>
>> Neither PAR nor TRCE return an error if the design fails timing, so
>> any script/makefile which relies on the return code being non-zero as
>> an error (like... well... just about anything sane!) will carry on
>> through it's script as if everything is OK!
>>
>> You have to parse the PAR logfile for "No timing errors found" if you
>> want to be sure.
>>
>> I have a change request in to fix this, please add your weight to the
>> request (unless you think I'm bonkers for thinking that failing timing
>> is an error!)
>
> Failing timing is an error, but personally I don't want the tool to
> return an error code just because of timing errors:

OK< I can see people want to work in different ways, but to have the
*default* situation of "no error on error" is counter-intuitive!

> * I have seen people over-constraining designs. If par doesn't meet
> the over-constrained timing but meets the desired timing, I don't want
> my script to stop.

I do :-)  Why overconstrain?  If they want some margin on the design,
are they be happy with less margin than you asked for?

> * If I am in the lab debugging my design and want to quickly try out a
> few things, I don't want my script to stop just because one net failed
> timing by several ps.
>

Maybe, that's why one of my suggestions to Xilinx is that they return
the timing score, so you can decide how much failure is acceptable
(from "0" upwards).

Cheers,
Martin

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

Article: 116220
Subject: LCD code
From: "meshoshow" <riverofmusic@hotmail.com>
Date: 5 Mar 2007 01:32:02 -0800
Links: << >>  << T >>  << A >>
hey guys
i want a vhdl code for lcd ( 2 lines lcd ) please i want ur help !!!!
thnx


Article: 116221
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "colin" <colin_toogood@yahoo.com>
Date: 5 Mar 2007 02:38:09 -0800
Links: << >>  << T >>  << A >>
On 4 Mar, 17:22, Austin <aus...@xilinx.com> wrote:
> Marc,
>
> Other than their odd name, they are extremely low impedance t-lines.
>
> As such, they are basically falt at 1200 uF from DC to daylinght.
>
> So, if you put a power supply at one end, and isolate the ground (in
> other words, that is what the slit is for) you transfer power to the
> other end (hot and ground) with a .001 ohm t-line (looks like that very
> low impedance at frequencies up to a few hundred MHz).
>
> So, now you see a AC short, looking either way:  from the power asupply
> to the load, or from the load to the power supply.
>
> The Playstation 3 uses 8 of them, they isolate each huge ASIC from the
> other huge ASICs, and there are3 NO OTHER CAPS on the pcb....
>
> Yes, that is right.
>
> Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line
> structures.
>
> Do they work?  Well, millions of PS3 aren't chunking away happily for no
> reason at all.
>
> We are looking at these seriously to reduce the bypassing requirements
> down to the PS3 limit:  a few of these, and NOTHING else (no other
> bypass caps whatsoever).
>
> So, it seems the NEC-TOKIN part is the first really new invention in
> bypassing in many many long years of people who just like to ignore that
> power distribution is a real issue, and one that needs some creativity.
>
> My hat is off to the engineers who created this wonder.
>
> Austin

Ausin

Does this mean that xilinx are actively charactersing these devices
for your FPGAs and that we can get hold of the results sometime soon?

Colin


Article: 116222
Subject: Re: xilinx block ram synthesis
From: "nagaraj" <nagarajputti@gmail.com>
Date: 5 Mar 2007 02:48:38 -0800
Links: << >>  << T >>  << A >>
On Mar 5, 2:57 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> Hi!
>
> I have also been quite frustrated by XST BRAM inference in the past...
> and have yet to get XST to do what I want.
>
> If you go check the XST "coding style guide" which contains VHDL
> templates for inferring most of the supported BRAM types, you might find
> exactly what you want.
>
> In my case, I wanted to infer "True dual-port BRAMs" but copy-pasting
> the guide's template (ISE 8.1/8.2) consistently resulted in XST crashes.
> After wasting a week trying to work this out last summer, I decided to
> give up and used a coregen RAM.
>
> More details about my experience with the true dual-port BRAM template:
> - pasting the code in the module's VHDL causes unrecognized BRAM
> inference warnings, causing XST to attempt implementation with
> distributed RAM
> - whipping up the template into its own module and synthesizing it as a
> top module works as advertised/expected
> - instantiating the BRAM template module in an actual design crashes XST
>
> S.T. wrote:
> > Hi
>
> > Thanks for your feedback. Unfortunately both suggestions didn't work :-(.
> > When removing the Reset path the synthesized ram will get dual ported
> > instead of single ported (see below). I tried to rewrite it and make the
> > read and write enable signals explicit and decoupling the reset from ram.
> > It also doesn't work i.e. it still gives distributed instead of block
> > ram :-(.
> > Synthesizing Unit <BRAM_test>.
> >     Related source file
> > is "/amd/iss1/users/ma/tstone/georg/bram/BRAM_test.vhd".
> >     Found 1024x16-bit single-port distributed RAM for signal <RAM>.
> >     -----------------------------------------------------------------------
> >     | ram_style          | block                               |          |
> >     -----------------------------------------------------------------------
> >     | Port A                                                              |
> >     |     aspect ratio   | 1024-word x 16-bit                  |          |
> >     |     clkA           | connected to signal <CLOCK>         | rise     |
> >     |     weA            | connected to internal node          | high     |
> >     |     addrA          | connected to signal <addr>          |          |
> >     |     diA            | connected to signal <di>            |          |
> >     |     doA            | connected to internal node          |          |
> >     -----------------------------------------------------------------------
> > WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the RAM
> > contents is read synchronously.




Try this piece of code.....


library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity BRAM_test is
        port (CLOCK : in std_logic;
               -- reset : in std_logic;
                di : in std_logic_vector(15 downto 0);
                do : out std_logic_vector(15 downto 0));
end BRAM_test;

architecture syn of BRAM_test is

type ram_type is array (1023 downto 0) of std_logic_vector (15 downto
0);
signal RAM : ram_type;
attribute ram_style : string;
attribute ram_style of RAM: signal is "block";

type STATE_TYPE is (P1, P2, P3);
signal STATE : STATE_TYPE;

signal addr : std_logic_vector(9 downto 0);

begin
        main : process (CLOCK)
        begin
               -- if (RESET = '1') then
                 --       STATE <= P1;
                   --     addr <= (others => '0');
               if (CLOCK'event and CLOCK = '1') then
                        case STATE is
                                when P1 =>
                                        RAM(conv_integer(addr)) <= di;
                                         do<=di;
                                        STATE <= P2;
                                when P2 =>
                                        do <= RAM(conv_integer(addr));
                                        STATE <= P3;
                                when P3 =>
                                        addr <= addr + '1';
                                        STATE <= P1;
                        end case;
                end if;
        end process main;
end syn;


Article: 116223
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 5 Mar 2007 11:34:35 -0000
Links: << >>  << T >>  << A >>
Some in-line stuff about Proadlizer, my other comments at the end.

"Austin" <austin@xilinx.com> wrote in message
news:esev91$st1@cnn.xsj.xilinx.com...
> Marc,
>
> Other than their odd name, they are extremely low impedance t-lines.
>
> As such, they are basically falt at 1200 uF from DC to daylinght.
>

Unfortunately, once you mount them, they no longer work to infinity (or
beyond). As ever, the design is limited by the physical layout of the parts
and connections, not the devices.

>
> So, if you put a power supply at one end, and isolate the ground (in other 
> words, that is what the slit is for) you transfer power to the other end 
> (hot and ground) with a .001 ohm t-line (looks like that very low 
> impedance at frequencies up to a few hundred MHz).
>

I think this paragraph is wrong, Austin, there are no slits in the ground
plane in the designs shown at:-
http://www.nec-tokin.com:80/english/product/cap/proadlizer/test1.html.
The slots are only in the power planes. Ground isn't isolated, that would be
very bad indeed. You've got to get signals in and out as well as power.

But hold on a minute, I see on this site they show the thing used with a
slot in the ground plane.
http://www.chemi-con.co.jp/english/support_e/proadlizer_e.html
Ouch! What happens to all the signals going to and from the device?
I see here:-
http://www.nec-tokin.com/english/product/pdf_dl/proadlizer_e.pdf
they still mention the ground plane slot, claiming the ground plane slot
offers "more optimal performance" [sic]. My bullshit sense is tingling! I'd
suggest this is not true for a real system with signals traversing this
ground plane slot. It makes me wonder if they really know for what this
device should be used.

>
> So, now you see a AC short, looking either way:  from the power asupply to 
> the load, or from the load to the power supply.
>
> The Playstation 3 uses 8 of them, they isolate each huge ASIC from the 
> other huge ASICs, and there are3 NO OTHER CAPS on the pcb....
>
> Yes, that is right.
>
> Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line 
> structures.
>
> Do they work?  Well, millions of PS3 aren't chunking away happily for no 
> reason at all.
>
> We are looking at these seriously to reduce the bypassing requirements 
> down to the PS3 limit:  a few of these, and NOTHING else (no other bypass 
> caps whatsoever).
>
> So, it seems the NEC-TOKIN part is the first really new invention in 
> bypassing in many many long years of people who just like to ignore that 
> power distribution is a real issue, and one that needs some creativity.
>
> My hat is off to the engineers who created this wonder.
>
> Austin
>

OK, what these devices appear to be good at is isolating the power supply 
noise from the ASICs/FPGA and stopping it spreading over the board. They 
also provide bypassing for the ASICs/FPGA. It's kinda like a series ferrite 
and a parallel capacitance at the ASIC/FPGA end. The 'new' bit is that it's 
all integrated onto a nice low ESL package. Sadly, the end user then has to 
attach this to his circuit which will affect this impedance. The blurb on 
the site shows how they localise EMC problems, reducing emissions, more than 
what great bypass
capacitors they make.

I see these parts got a brief mention on SI-list back in Jan '04, so I'd
suggest they're not a 'miracle breakthrough' or we'd have heard more about
them already. I would tend to go for the X2Y stuff we discussed last week on
CAF.
http://www.googlefight.com/index.php?lang=en_GB&word1=proadlizer&word2=x2y+component
Or, perhaps slightly more seriously, :-
http://www.x2y.com/bypass/measure/comparative_device_only.pdf

Anyway, whatever else, it's nice to see people doing designs with tiny local
power planes for the FPGA, and not believing all the claptrap about plane
capacitance and resonances to help PDS for big BGA packages.

Cheers, Syms. 



Article: 116224
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 5 Mar 2007 12:09:16 -0000
Links: << >>  << T >>  << A >>
"Tim" <tim@nooospam.roockyloogic.com> wrote in message 
news:eses5g$sfo$1$8302bc10@news.demon.co.uk...
>
> On the plane-splitting point, you can read app notes advocating this 
> practice and app notes claiming that plane splitting is a discredited 
> practice from an earlier era. I get the sense that the current (sic) best 
> practice is that ground plane splitting is rarely a good idea and a degree 
> of VCC plane splitting may help on a noisy board, but much better would be 
> to find out why VCC is noisy and fix it. Again, gurus will set me 
> straight... Also, see Symon's recent posts on puddles.
>
> Tim

Hi Tim,
Separate ground planes are very rarely a good idea. AFA I can tell, they 
seem to have arisen because mixed signal parts, like ADCs, have separate 
analog and digital ground pins. The reason for this is because the package 
they are in has some impedance in the connection from the die to the circuit 
board. You don't want noisy digital ground currents travelling down the same 
connections as the analog ground current as you'll get noise injected into 
your analog circuitry. However, once the ground signals get out of the 
device and into your negligible-impedance ground plane, there's no problem. 
All the ground pins can be joined together. Here's a link:-
http://www.analog.com/analog_root/static/raq/moreInfo/raq_groundingClean.html

Here's a link about signals traversing slots in ground planes (there's tons 
of this stuff on t'internet) :-
http://www.hottconsultants.com/techtips/tips-slots.html
The same thing applies when signals travel from one reference (say 'analog 
ground') to another (say 'digital ground').

VCC is different because it's not generally used as a reference and modern 
devices have many different supplies. It's impractical to have a plane for 
every single one. You can achieve good performance by having small local 
planes adequately bypassed. The small local planes pool the capacitors 
together to achieve the characteristics required. It's also fairly easy to 
isolate ICs' supplies from each other this way.

Whenever thinking about this stuff, it's important to remember that the 
vias, connections to the package, and package impedance must ALL be taken 
into account. It's no help that a Proadlizer has 1pH of inductance if the 
vias have 2 orders of magnitude more impedance.

HTH, Syms.

p.s. Apologies for my multi-posts in this thread. My usenet provider told me 
it wasn't posting when I guess it really was. 





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