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 116225

Article: 116225
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Mon, 5 Mar 2007 14:32:26 +0100
Links: << >>  << T >>  << A >>

"Austin" <austin@xilinx.com> wrote
>
> 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.

OK for the power supply but a ground island looks like a rather bad thing 
for the signal lines. So unless I missed something, I will keep my precious 
ground planes with no slits or islands. ;-)

[...]
> 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.

Yes, this is really cool. I'm trying to get some but they seem rather hard 
to find.

The only drawbacks I see with them is their size and the huge number of vias 
you need to put to link to the planes with a low inductance that can block 
the signals routing.

Marc



Article: 116226
Subject: Re: SCons build tool as an alternative to makefiles
From: "Patrick Dubois" <prdubois@gmail.com>
Date: 5 Mar 2007 05:38:21 -0800
Links: << >>  << T >>  << A >>
Just to come back on the subject of Scons for a minute... Any input on
that tool? Or does anyone have another suggestion for a make
alternative?

Thanks.

Patrick


Article: 116227
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Mon, 5 Mar 2007 14:42:14 +0100
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote

> 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

Very interesting.

> 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.

In fact this was my original question: power islands vs. large power planes. 
When I look at the diffrent app notes, there seem to be a consensus on the 
use of large planes rather than islands. (excepted this new proadlizer 
thing). So is there some apps notes/ paper comparing these different ways to 
do a PDS.

> 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.

If you look at boards using them, it seems that they are used with a great 
number of vias to keep the inductance low (cf photo 2):
http://www.nec.co.jp/techrep/en/journal/g06/n05/t060514.pdf

This can potentially block a large number of routes though.

Marc



Article: 116228
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 5 Mar 2007 14:42:01 -0000
Links: << >>  << T >>  << A >>
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message 
news:Sr6dnXrgTOezg3HYRVnyvwA@giganews.com...
>
> "Symon" <symon_brewer@hotmail.com> wrote
>
>>
>> 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.
>
> In fact this was my original question: power islands vs. large power 
> planes. When I look at the diffrent app notes, there seem to be a 
> consensus on the use of large planes rather than islands. (excepted this 
> new proadlizer thing). So is there some apps notes/ paper comparing these 
> different ways to do a PDS.
>
Hi Marc,
Yeah, there does seem to be a lot of folks designing with large planes. They 
do work well, but I think they're an expensive solution to the problem. (An 
FPGA has Vccint 1.2V, maybe 2 Vccos, 3.3V and 2.5V, a Vccaux, and maybe MGT 
power supplies. Where do you draw the line?)
Now that FPGA circuits are moving into the sub-ns rise time region, I think 
designers would do well to look at the solutions used by microwave engineers 
over the past decades, rather than try and take the traditional digital 
designs into this frequency region. IME, microwave designers eschew power 
planes in favour of more ground planes! Of course, on the other hand, they 
don't have to worry about 1000 ball BGA packages.
>
>
> If you look at boards using them, it seems that they are used with a great 
> number of vias to keep the inductance low (cf photo 2):
> http://www.nec.co.jp/techrep/en/journal/g06/n05/t060514.pdf
>
> This can potentially block a large number of routes though.
>
> Marc
>
>
Right, and no matter how many vias you use, you've still got to get the 
current to the BGA through vias and balls. I think that the X2Y caps on the 
backside of the FPGA are still a good solution.
Cheers, Syms. 



Article: 116229
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 5 Mar 2007 14:43:04 -0000
Links: << >>  << T >>  << A >>
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message 
news:h5-dnS91q8p4hnHYnZ2dnUVZ8t2snZ2d@giganews.com...
>
>
> OK for the power supply but a ground island looks like a rather bad thing 
> for the signal lines. So unless I missed something, I will keep my 
> precious ground planes with no slits or islands. ;-)
>
...and so will I! I agree with this 100%.
Syms. 



Article: 116230
Subject: Nios II Multiprocessor Collection run in command line
From: Ewa <biedrone@wytnijto.o2.pl>
Date: Mon, 05 Mar 2007 16:07:27 +0100
Links: << >>  << T >>  << A >>

Hi All,

is there any chance to run Nios II Multiprocessor Collection in command 
line?

I have the system with 2 cpus. I've tried to run the programs 
separately, but in that case mutex doesn't work properly. Perhaps smth 
wrong with cpu's ID value.

Note: from Nios II IDE it works fine, when I use Nios II Multiprocessor 
Collection.

Best regards,

Ewa.

Article: 116231
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 05 Mar 2007 07:31:14 -0800
Links: << >>  << T >>  << A >>
colin,

Yes.

Austin

Article: 116232
Subject: Ise foundation and Ise Webpack
From: "Pablo" <pbantunez@gmail.com>
Date: 5 Mar 2007 08:04:02 -0800
Links: << >>  << T >>  << A >>
Hi, does anyone know the difference between Ise Foundation and Ise
Webpack?. I have Ise Webpack installed in my PC and now I have some
software which needs Ise Foundation and I don`t know if there is some
difference.

Although I have to install Xilinx System Generator. Is it on Ise
Foundation? Is another module of Xilinx? Is free?

Regards, Pablo


Article: 116233
Subject: Re: Ideas for Masters Project.
From: "wallge" <wallge@gmail.com>
Date: 5 Mar 2007 08:18:03 -0800
Links: << >>  << T >>  << A >>
On Mar 5, 12:23 am, "RaKa" <rakesh.hemn...@gmail.com> wrote:
> 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.

how about real time video/image processing.
You can get an altera dev kit and and then
attach an NTSC daughter card (http://www.altera.com/products/devkits/
altera/kit-daughtercard.html)
to it, then plug that to a basic video camera.
You can send the processed output from the fpga to a vga
converter and plug it into a monitor.

You can implement all sorts of image processing and computer vision
algorithms
then see the results in real time on your monitor.

There are lots of daughtercards available for the altera dev kits
which can
facilitate more IO options... (http://www.altera.com/products/devkits/
kit-daughter_boards.jsp)
They mostly use altera's santa cruz interface for connection to the
parent fpga board.

Here are some other interesting daughter cards:
http://www.bitec.ltd.uk/products.html




good luck


Article: 116234
Subject: Re: LCD code
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Mon, 5 Mar 2007 17:56:37 +0100
Links: << >>  << T >>  << A >>
Ok, first off, take a look at the datsheets for the standard LCD 
microcontrollers.  As far as I remember they only come in a few flavours and 
are all based on the same principles (Data bus, address bus, read /write 
etc) Part of the challenge is setting up the display, it's tricky to do all 
the different initialisation routines they needyou to wait for a severla 
milliseconds at a time and they lend themselves very well to a 
microprocessor.

Buy a S3E starter kit, and go through the picoblaze examples from the Xilinx 
web-site.

Then come back with some better questions - it's no good asking "do my whole 
work for me" better to get stuck in and ask when there's a specific problem 
that we can help with.

Just my 2p
Ben
"meshoshow" <riverofmusic@hotmail.com> wrote in message 
news:1173087122.626934.37040@h3g2000cwc.googlegroups.com...
> hey guys
> i want a vhdl code for lcd ( 2 lines lcd ) please i want ur help !!!!
> thnx
> 



Article: 116235
Subject: Re: Sources (products) for Cannibalizing FPGAs, PLDs, etc.
From: msg <msg@_cybertheque.org_>
Date: Mon, 05 Mar 2007 11:01:27 -0600
Links: << >>  << T >>  << A >>
Ben Jackson wrote:

> 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.

Indeed -- that's what I meant by 'Vendor Prog.' in the list; the 'S'
versions are ISP though and from that vintage.

Thanks for the reply :)

Michael

Article: 116236
Subject: Re: Ise foundation and Ise Webpack
From: <steve.lass@xilinx.com>
Date: Mon, 5 Mar 2007 10:01:46 -0700
Links: << >>  << T >>  << A >>

"Pablo" <pbantunez@gmail.com> wrote in message 
news:1173110642.168498.288220@t69g2000cwt.googlegroups.com...
> Hi, does anyone know the difference between Ise Foundation and Ise
> Webpack?.

The only difference is the devices that are included.

> I have Ise Webpack installed in my PC and now I have some
> software which needs Ise Foundation and I don`t know if there is some
> difference.
>
> Although I have to install Xilinx System Generator. Is it on Ise
> Foundation? Is another module of Xilinx? Is free?

No, System Generator is a seprate option and is not free.

Steve
>
> Regards, Pablo
> 



Article: 116237
Subject: Re: Ideas for Masters Project.
From: msg <msg@_cybertheque.org_>
Date: Mon, 05 Mar 2007 11:06:35 -0600
Links: << >>  << T >>  << A >>
RaKa wrote:

> 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.
> 

I would like to see a software defined radio framework with the
'software' written in 'C' for the target DSP/microcontroller
(avoid any object oriented languages or libraries).  The
Sandbridge ISA and project looked very interesting along these
lines and the front ends could be put on the FPGA.

Regards,

Michael


Article: 116238
Subject: Re: Instance Name Being Removed?
From: "Brandon Jasionowski" <killerhertz@gmail.com>
Date: 5 Mar 2007 09:07:53 -0800
Links: << >>  << T >>  << A >>
On Mar 3, 2:46 pm, "John McCaskill" <junkm...@fastertechnology.com>
wrote:
> On Mar 3, 8:27 am, "Brandon Jasionowski" <killerhe...@gmail.com>
> wrote:
>
>
>
> > On Mar 3, 8:25 am, Sean Durkin <news_ma...@durkin.de> wrote:
>
> > > Brandon Jasionowski wrote:
> > > > It's really bothering me that the instance is maintained in the ngc,
> > > > but not after Translate. What is going on exactly? Is there anything
> > > > else I can do?
>
> > > Unused logic is not removed until translate or par (can't remember now).
> > > In the schematic view even those things show up that get optimized away
> > > later.
>
> > > If your instance is not there after translate/map, then it was probably
> > > removed completely for some reason. Maybe because it was never used,
> > > produces only constant outputs or something.
>
> > > --
> > > My email address is only valid until the end of the month.
> > > Try figuring out what the address is going to be after that...
>
> > Well, I dont' believe the the logic is being removed because the input
> > and output registers of that instance still persists in floorplanner
> > under "Primitives", not under it's instance name. There's some other
> > LUTs that have those jibberish names like "_and00001",
> > "Mcompar__cmp_gt0001_lut", etc. The i/o net names of these primitives
> > sometimes correspond to the internal net names of the entity in
> > question, which further leads me to believe the logic is still all
> > there.
>
> > I'm not sure if this is common or not, because I wouldn't normally
> > care about instances being dissolved, as I rarely put constraints on
> > INSTances. Now that I'm working with BUFRs, I'm finding I need to
> > assign AREA_GROUP constraints to anything clocked by them, this
> > instance being one of them...
>
> > Thanks.
>
> What I have done on my designs that use BUFRs is to put an HU_SET
> attribute on the module that contains the BUFR clock domain, then use
> that to create the area group.
>
> Another way that you can constrain the logic that uses the BUFR clock
> is to form a timing group from the clock net, then create an area
> group from the timing group.  Take a look at the area group section of
> the constraints guide.  Here is an example from page 104 of the 8.2
> version of the constraints guide:
>
> For example, assume you have the following UCF constraints:
> NET "clk" TNM_NET="clock";
> TIMESPEC "TS_clk" = PERIOD "clock" 10 MHz;
> TIMEGRP "clock" AREA_GROUP="clock_area";
>
> I have not tried doing it this way yet. It would be nice if the tools
> would just do this for you automatically.
>
> Regards,
>
> John McCaskillwww.fastertechnology.com

Thanks. Creating Area Groups from Timing Groups did the trick! I can't
believe I didn't see that part in the CGD...


Article: 116239
Subject: Re: Sources (products) for Cannibalizing FPGAs, PLDs, etc.
From: msg <msg@_cybertheque.org_>
Date: Mon, 05 Mar 2007 11:14:04 -0600
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:

> On Mar 2, 4:43 pm, msg <msg@_cybertheque.org_> wrote:
> 
> 
>>A list of consumer, industrial and mil. products, board names and part
>>numbers that contain reprogrammable array logic devices would be very
>>useful;

<snip>

> Recycling programmable logic doesn't make a lot of sense to me, unless
> perhaps you find a way to use it on the board it's already on, perhaps
> to improve the original device... that, could indeed be fun.
> 

I agree that RE of a peripheral board with programmable logic to permit
reuse or improvement is always interesting and useful.  For many folks
it is also true that scrounging for parts of even modest density is
cheaper than small quantity purchases even considering time involved
in depopulating and remounting on breadboard fixtures.

I am exploring the reuse of ceramic PGA (old CPUs) as a carrier for
large pin count flat packs; the ZIF sockets are in abundance from
old mainboards and using a cutoff wheel on a radial arm, one may
open the PGA packages to expose the pins for soldering.

Regards,

Michael

Article: 116240
Subject: Re: Sources (products) for Cannibalizing FPGAs, PLDs, etc.
From: msg <msg@_cybertheque.org_>
Date: Mon, 05 Mar 2007 11:15:19 -0600
Links: << >>  << T >>  << A >>
pbFJKD@ludd.invalid wrote:

> 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...

<snip>
> 
> 
> 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.

Agreed, whenever known that data would be helpful.

Regards,

Michael

Article: 116241
Subject: Re: Multiplication operation
From: "VHDL_HELP" <abaidik@gmail.com>
Date: 5 Mar 2007 09:39:06 -0800
Links: << >>  << T >>  << A >>
On 5 mar, 06:23, John_H <newsgr...@johnhandwork.com> wrote:
> VHDL_HELP wrote:
>
> > hi , thank you for your advices first of all ,
> > then my equation to resolv is :
> > y=3D0.299 * R + 0.587 *G + 0.114 * B
> > for me what i tried to do is:
>
> > -----------------------------------------------------------------------=
----=AD-----------------------------------------
> > 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=3D'1' and clk'event then
> >            yreg <=3D  "00111110100110010001011010000111" * R +
> > "00111111000101100100010110100001"* G +
> > "00111101111010010111100011010100"* B;
> >            Y <=3D yreg;
>
> >                                                    end if;
> >            end process;
> > end arch_rgb;
>
> > -----------------------------------------------------------------------=
----=AD------------------
>
>  >
>  > 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.
First of all thank you
-------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity rgb is
    Port ( clk : in  STD_LOGIC;
           r : in  STD_LOGIC_VECTOR (10 downto 0);
           g : in  STD_LOGIC_VECTOR (10 downto 0);
			  b : in  STD_LOGIC_VECTOR (10 downto 0);
           y : out  STD_LOGIC_VECTOR (21 downto 0);
			  cb: out  STD_LOGIC_VECTOR (21 downto 0);
			  cr: out  STD_LOGIC_VECTOR (21 downto 0));
end rgb;

architecture Behavioral of rgb is
signal yr,yg,yb,crr,crb,crg,cbr,cbb,cbg:STD_LOGIC_VECTOR (19 downto
0);
signal yy,cr1,cb1:STD_LOGIC_VECTOR (21 downto 0);
begin
process(clk)
begin
	if clk'event and clk=3D'1' then
-- how to get Y
			yr <=3D "0100110010" * r;
			yg <=3D "1001011001" * g;
			yb <=3D "0001110100" * b;
			yy <=3D yb + yg + yr;
-- how to get cr
			crr <=3D  r
			crg <=3D  "0110101101" * g;  -----> it told me that there is an error
here
			crb <=3D  "0001010011" * b;
			cr1 <=3D crr - crg - crb;
-- how to get cb
			cbr <=3D "0010101101" * r;
			cbg <=3D "0101010011" * g;
			cbb <=3D  b
			cb1 <=3D cbb - cbr - cbg; -----> it told me that there is an error
here
--- mise en sortie des calculs
			y <=3D yy;
			cr <=3D cr1;
			cb <=3D cb1;
		end if;
end process;
end Behavioral;
---------------------------------------------------------------------------=
---------------------
it is the error for the 2lines: parse error, unexpected IDENTIFIER,
expecting SEMICOLON
i hope that you can help me , please i  m really a beginner
thank you


Article: 116242
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 05 Mar 2007 09:41:20 -0800
Links: << >>  << T >>  << A >>
Symon,

I agree that a slit in the ground plane is going to be an impedance
discontinuity for signals that cross the split.

For that reason, I would probably have any signals that cross the split
have a continuous ground underneath them.  That little bit of ground
that now connects the "isolated" ground plane to the rest of the ground
plane is also a DC short across the NEC-Tokin device, but from an AC
traveling wave point of view, it is an open, as the power and ground
currents return to the power supply, and are unlikely to return over a
small bridge between two planes.

I admit that designing this way requires thinking of the DC conditions,
then the AC conditions, on both the power, and the IO.  It means you
have all kinds of opportunities to make mistakes, and have worse
behavior, too.  Far simpler to stay with one good ground, and isolate
only the power planes (or better yet, don't even isolate the power
planes).  But, does "simple" work?

Using the two port by just shorting the two ports together, and putting
it on the far side of the pcb right under the FPGA also is a use model
that might make sense.  The issue there is how to connect it to the
power and ground planes with as low an inductance (impedance) as possible.

I could not see the internal layers of the PS3 pcb, but I suspect they
spent a lot of time thinking about this.  For them, not only is their
performance to worry about, but also EMI/RFI requirements for the many
regions they wish to sell into (FCC Part 15, etc.).

Most engineers would rather just forget the power until the very end of
their design and layout, and never have to really analyze the power
distribution system (PDS).  The PSD for the user's guide for V5 takes a
"here is the BOM" approach:  just use these caps, place them like this,
and you are done.  The solution offered may be overkill for some
designs, but will generally be adequate for 99% of the applications.
Those that take PSD design much more seriously, will do their own
engineering, and provide their own solution.

Austin

Article: 116243
Subject: Re: Multiplication operation
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Mon, 5 Mar 2007 17:54:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Check the end of the preceeding lines.  You forgot to end the statements 
with a semi-colon, like the error message stated.


---Matthew Hicks


> On 5 mar, 06:23, John_H <newsgr...@johnhandwork.com> wrote:
> 
>> 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.
>> 
> First of all thank you
> -------------------------------------------------------------
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> entity rgb is
> Port ( clk : in  STD_LOGIC;
> r : in  STD_LOGIC_VECTOR (10 downto 0);
> g : in  STD_LOGIC_VECTOR (10 downto 0);
> b : in  STD_LOGIC_VECTOR (10 downto 0);
> y : out  STD_LOGIC_VECTOR (21 downto 0);
> cb: out  STD_LOGIC_VECTOR (21 downto 0);
> cr: out  STD_LOGIC_VECTOR (21 downto 0));
> end rgb;
> architecture Behavioral of rgb is
> signal yr,yg,yb,crr,crb,crg,cbr,cbb,cbg:STD_LOGIC_VECTOR (19 downto
> 0);
> signal yy,cr1,cb1:STD_LOGIC_VECTOR (21 downto 0);
> begin
> process(clk)
> begin
> if clk'event and clk='1' then



Article: 116244
Subject: Re: Multiplication operation
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 5 Mar 2007 10:01:30 -0800
Links: << >>  << T >>  << A >>
"VHDL_HELP" <abaidik@gmail.com> wrote in message 
news:1173116345.883356.301410@30g2000cwc.googlegroups.com...
<snip>

> -- how to get cr
> crr <=  r
> crg <=  "0110101101" * g;  -----> it told me that there is an error here

<snip>

> cbb <=  b
> cb1 <= cbb - cbr - cbg; -----> it told me that there is an error here

<snip>
> ------------------------------------------------------------------------------------------------
> it is the error for the 2lines: parse error, unexpected IDENTIFIER,
> expecting SEMICOLON
> i hope that you can help me , please i  m really a beginner
> thank you


Look at the lines above where the error is flagged.
You need to have a semicolon (;) after the crr <= r and the cbb <= b lines. 



Article: 116245
Subject: EDK 9.1 when?
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 5 Mar 2007 13:13:39 -0500
Links: << >>  << T >>  << A >>
Anyone knows when we will be seeing this?

Thanks,
/Mikhail 



Article: 116246
Subject: Xilinx: it's about time!
From: "Andy Peters" <google@latke.net>
Date: 5 Mar 2007 10:53:16 -0800
Links: << >>  << T >>  << A >>
http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3an_fpgas/index.htm


Article: 116247
Subject: Re: Multiplication operation
From: "VHDL_HELP" <abaidik@gmail.com>
Date: 5 Mar 2007 10:55:23 -0800
Links: << >>  << T >>  << A >>
On 5 mar, 19:01, "John_H" <newsgr...@johnhandwork.com> wrote:
> "VHDL_HELP" <abai...@gmail.com> wrote in message
>
> news:1173116345.883356.301410@30g2000cwc.googlegroups.com...
> <snip>
>
> > -- how to get cr
> > crr <=3D  r
> > crg <=3D  "0110101101" * g;  -----> it told me that there is an error h=
ere
>
> <snip>
>
> > cbb <=3D  b
> > cb1 <=3D cbb - cbr - cbg; -----> it told me that there is an error here
>
> <snip>
>
> > -----------------------------------------------------------------------=
----=AD---------------------
> > it is the error for the 2lines: parse error, unexpected IDENTIFIER,
> > expecting SEMICOLON
> > i hope that you can help me , please i  m really a beginner
> > thank you
>
> Look at the lines above where the error is flagged.
> You need to have a semicolon (;) after the crr <=3D r and the cbb <=3D b =
lines.

thanks you , it really was a very small mistake and i didnt got it
thank you


Article: 116248
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 06 Mar 2007 08:00:43 +1300
Links: << >>  << T >>  << A >>
Symon wrote:
> 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.

I think they focus solely on the Powersupply, and forget about
things like ground bounce ( that does not appear in S21 )
- so from an attenuation viewpoint, dual splits would work,
and could maybe help if that section of the FPGA was internal only, and
had no Pin-drive signals [rare, but not impossible]

I was pondering going even further, by taking a device along these 
lines, and assembling into a cavity in the PCB (object is to remove the 
vias), but I think that would have problems with getting solder paste 
into the cavity ?

Of course, the ideal is to have Xilinx put this into the BGA carrier .

-jg


Article: 116249
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 5 Mar 2007 19:49:09 -0000
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:45ec68c8@clear.net.nz...
>
> Of course, the ideal is to have Xilinx put this into the BGA carrier .
>
Hi Jim,
Right.
I wonder if some of those interposer materials might offer a solution in the 
future? Some sort of bypass circuit in between the BGA and the PCB somehow?
Dunno, Syms.





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