Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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. MarcArticle: 116226
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. PatrickArticle: 116227
"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. MarcArticle: 116228
"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
"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
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
colin, Yes. AustinArticle: 116232
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, PabloArticle: 116233
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 luckArticle: 116234
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
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 :) MichaelArticle: 116236
"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
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, MichaelArticle: 116238
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
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, MichaelArticle: 116240
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, MichaelArticle: 116241
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: 116242Symon, 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. AustinArticle: 116243
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' thenArticle: 116244
"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
Anyone knows when we will be seeing this? Thanks, /MikhailArticle: 116246
http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3an_fpgas/index.htmArticle: 116247
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 youArticle: 116248
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 . -jgArticle: 116249
"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:
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