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
Check out the book by name VHDL for Programmable Logic by Kevin Skahill. Greg Vanslyke <gvanslyk@is2.dal.ca> wrote in message news:Pine.A41.3.95.991019131224.74538B-100000@is2.dal.ca... > > I'm a third year electrical engineering student about to venture on my > first of three co-op work terms. Many of the jobs I've been applying for > may require me to work with/test/design FGPAs. Basically all I know is > that FPGA stands for Field Programmable Gate Array and I have a vague > understanding of what they are used for. > > Can somebody recommend a website, book, newsgroup, etc. that I can use to > learn the very basics on FPGAs ? > > > Greg VanSlyke > Elec3 DalTech > gvanslyk@is2.dal.ca > >Article: 18376
The amazing delay before postings to this group get to deja.com is
making the discussion rather hard to follow, and I apologise in advance
if I am repeating stuff discussed in another (as yet unseen) post.
If you look in the latest Synplicity libs, you see this simulation idea,
which seems to fit the bill. It is also very efficient given that
the INIT string only has to be calculated once.
architecture lut of LUT2 is
attribute xc_map of lut : architecture is "lut";
signal b : std_logic_vector(1 downto 0);
signal tmp : integer range 0 to 7; -- should be 0 to 3
begin
b <= (I1, I0);
tmp <= conv_integer(b);
O <= To_StdULogic(INIT(tmp));
end architecture lut;
Also it is straightforward to translate an Expr string to an INIT
string. Just evaluate it for all possible input values - there are
only 16 possibilities. Something like this should do the trick for
both simulation and synthesis:
entity MyLut2 is generic(Expr : string := "(I0*I1)" );
port (I0,I1 : in std_logic := '0';
O : out std_logic);
end MyLut2;
architecture struct of MyLut2 is
attribute xc_map of struct : architecture is "lut";
constant bv : bit_vector(0 to 15) := InitEvalV(Expr);
signal sv : std_logic_vector(1 downto 0);
signal tmp : integer range 0 to 3;
begin
sv <= ( I1, I0);
tmp <= ToInteger( sv );
O <= To_StdULogic(bv(tmp));
end struct;
So I guess I have just agreed with both the quoted posters.
In article <380d8892.6166775@news.dial.pipex.com>,
eml@riverside-machines.com.NOSPAM wrote:
> On 16 Oct 1999 06:46:37 PDT, Ken McElvain <ken@synplicity.com> wrote:
>
> >The way Ray did it you can simulate. With your Expr generic method,
you
> >can't . A
> >compromise is to instantiate the luts directly with the LUT contents
as bit
> >string generic.
> >It is more cryptic but you can simulate it.
>
> agreed; as minor additions, it's worth remembering that:
>
> 1) the bit_vector generic doesn't have to be specified directly - one
> trick i use is to instead specify an attribute of the component, and
> then to use a function elsewhere to calculate a value for the
> attribute. this can make the INIT specification a lot more usable. if
> you're careful, the function can be arbitrarily complex; it's
> effectively treated as a compile-time constant calculation by the
> synthesiser. i'm not suggesting that you can turn an EQN into the INIT
> value directly, but it may be possible.
>
> 2) some synths can have a problem with the INIT specification, so you
> need a metacomment to comment out the generic map aspect.
>
> here's an example which i use frequently on another synth (not yours
> :)). it's in a 2-level generate, where the INT_INIT attribute is
> calculated by a function which turns a set of filter coefficients into
> a 16-bit integer to load into a rom element:
>
> UX : LUT4
> -- pragma translate_off
> -- required only for the xilinx simulation model; not in the
> -- synthesisable component
> generic map (
> INIT => bit_vector(to_unsigned(UX'INT_INIT, 16)))
> -- pragma translate_on
> port map (
> I0 => ADDR(i*4), I1 => ADDR(i*4+1),
> I2 => ADDR(i*4+2), I3 => ADDR(i*4+3),
> O => DATA(i)(j));
>
> evan
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18377Hello, Has anyone coded interleaver/deinterleaver modules in Verilog. I'm looking for information on interleavers/deinterleavers. Thanks in advance for anyones help. LorantArticle: 18378
In case anyone else is attempting to build carry chain RPM's in VHDL, I've posted an example of an XC4000/Spartan carry chain, built by instantiating the Xilinx primitives, at: http://members.aol.com/fpgastuff file: tc_test1.zip The code creates a pipelined two's complement CLB from the primitives, then places an array of them using RLOC's. Although cascading two's complements isn't terribly useful, it shows how to work around some of the tool quirks encountered when connecting and placing the carry primitives. The example was written for Synplify; check "readme.txt" in the zipfile for more info. Credits: Thanks to Evan for posting examples of synthesizable RLOC's, FMAP's, and EQN's at: http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm Comments: I view this method as more of a last resort than as part of the normal design flow; the large pile of code needed for this example could be replaced with a few lines of RTL code using inferred operators, plus possibly a couple of minutes in the floorplanner, with equivalent results. The technique is useful for repeated structures which need explicit mapping and placement for speed, and for building library components smart enough to size and place themselves; on the down side, it is tough to do pre-synthesis simulation ( e.g., you need an EQN model which can parse equation attribute strings.) Brian Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18379
:))Article: 18380
Hi, Has anybody been able to implement Partial Reconfiguration on the Virtex devices, I'm trying to do this, but it doesn't seem to work! If you've got it working, could you give me some info as to the command set you're using and the number and type of padding bits used etc... GordonArticle: 18381
Try the optimagic site for info: www.optimagic.com Scott McConnachie Alpha Data In article <380B0CC9.185BD5B8@dotcom.fr>, Nicolas Matringe <nicolas@dotcom.fr> wrote: > Hi all > > I remember some discussions about this topic. I thought I had read that > the best chips were Lucent's and Xilinx's but I can't find the message > in Deja News... I can't even find a thread that looks like a comparison. > If someone could give me some hints... > > Thanks in advance, > Nicolas MATRINGE DotCom S.A. > Conception electronique 16 rue du Moulin des Bruyeres > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE > Fax 00 33 1 46 67 51 01 FRANCE > -- Alpha Data Parallel Systems 58 Timber Bush Edinburgh EH6 6QH Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18382
I have heard that, as a general rule on Xilinx chips, data busses should be placed on the sides of the chip and control signals should be placed on the top and bottom. This has something to do with routing resources being used more efficiently. I have looked at Xilinx's web site but can't find any valid argument for or against this rule. Has anyone ever heard of this? Does anyone know where it came from? -- Jaime Villela jvillela@airmail.netArticle: 18383
Jamil Khaib wrote: > > Free ASIC course from synopsys is available online at > > http://www.dacafe.com/DACafe/ASICCOURSE/ > > use this referral ID when you register IC6916 > > Jamil Khatib > OpenIP Organization > http://www.openip.org or better use IC7223 as your referral ID ;-)Article: 18384
testArticle: 18385
testArticle: 18386
testArticle: 18387
A list of FPGA books can be found at the following URL... http://home.korax.net/~telic/books/asic.htm#FPGA On Wed, 20 Oct 1999 02:49:30 GMT, jjlarkin@highlandSnipSniptechnology.com (John Larkin) wrote: >On Tue, 19 Oct 1999 13:20:56 -0300, Greg Vanslyke ><gvanslyk@is2.dal.ca> wrote: >|Can somebody recommend a website, book, newsgroup, etc. that I can use to >|learn the very basics on FPGAs ? >| >| >|Greg VanSlyke >|Elec3 DalTech >|gvanslyk@is2.dal.ca >|Article: 18388
It comes from the fact that the carry chains run vertically. The data busses not only should be along the sides, but they should also be arranged so that the LSB is at the bottom. The reason is to keep the routing as short and simple as possible. jv wrote: > I have heard that, as a general rule on Xilinx chips, data busses should be > placed on the sides of the chip and control signals should be placed on the > top and bottom. This has something to do with routing resources being used > more efficiently. I have looked at Xilinx's web site but can't find any > valid argument for or against this rule. Has anyone ever heard of this? > Does anyone know where it came from? > > -- > Jaime Villela > jvillela@airmail.net -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18389
Hi,
more by accident I found the program XDL in my Alliance distribution.
XDL is a program that converts a XILINX design between ncd
(binary undocumented internal) and XDL an ASCII format.
Beside of two work around answers in the data base I have not yet found
any hint or documentation on this.
I think this is a great thing, because it is much easier
finding things, you can use grep/wc/perl what you like
to check things.
Without xdl the only way back to a processable text file is pre-map with
ngd2vhdl/ngd2edif and the like.
Only timing information can added.
I think that such open interfaces are a big win,
especially for reconfigurable computing because access
to very low end features are possible without re-engineered
bit-stream manipulation.
(Of course, meanwhile there is also JavaBits).
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medical University Luebeck, Germany
Home: http://www.iti.mu-luebeck.de/~doering
quiz, papers, VHDL, music
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 18390MAX7000S is 5V part but is also compatible with 3.3V I/O. VCCIO pins are the I/O voltage pins. VCCINT pins are the internal logic power pins. If your design use 5V only both of them will be connected to 5V. If you want interface to 3.3V parts, then you need connect VCCIO to 3.3V supply. In article <37FE7BBC.BCF86FCA@eng.umd.edu>, Moussa Ba <babs@eng.umd.edu> wrote: > The board I am using is the University Program Altera board that features a > MAX7000S as well as a FLEX10K chip. I did notice that on the pinout of the > MAX7000S it had a bunch of VCCIO, VCCINT and GND pins. In my pin description > file it mentions that these pins have to be connected to 5.0,5.0 and GND > respectively. I assumed that these pins were directly driven by the on-board > power supply. Is my assumption wrong? I did test out the pins and they provide > no Voltage. Do I have to provide that voltage? > > Moussa > Mike wrote: > > > Moussa Ba wrote in message <37FD1D45.848CC6A5@eng.umd.edu>... > > >Thank you for your reply. I forgot to mention in my email that I did use a > > TTL > > >crystal oscillator. And I still get a messed up signal as soon as I > > connect the > > > > > >clock to the clock input of the MAX chip. > > > > > > > Is it possible that you connect your clock to a wrong pin? Check how your > > pins were routed in your .rpt file. It sounds like you are connecting your > > clock to a pin configured as an output. > > > > Mikhail Matusov > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18391
jv wrote: > I have heard that, as a general rule on Xilinx chips, data busses should be > placed on the sides of the chip and control signals should be placed on the > top and bottom. This has something to do with routing resources being used > more efficiently. I have looked at Xilinx's web site but can't find any > valid argument for or against this rule. Has anyone ever heard of this? > Does anyone know where it came from? > > -- > Jaime Villela > jvillela@airmail.net I guess atleast all the carry chains are available only in the vertical direction. So I guess an adder placed horizontally would not be able to use any of the carry chains. And this would imply data busses placed horizontally across he chip and arithmetic opertaors on it running vertically. I guess number of routing lines in the two directions are also slightly different. Sarin.Article: 18392
sarin mathen wrote: > jv wrote: > > > I have heard that, as a general rule on Xilinx chips, data busses should be > > placed on the sides of the chip and control signals should be placed on the > > top and bottom. This has something to do with routing resources being used > > more efficiently. I have looked at Xilinx's web site but can't find any > > valid argument for or against this rule. Has anyone ever heard of this? > > Does anyone know where it came from? > > > > -- > > Jaime Villela > > jvillela@airmail.net > > I guess atleast all the carry chains are available only in the vertical > direction. > So I guess an adder placed horizontally would not be able to use any of the > carry > chains. correct. carry chains are vertical, with the LSB at the bottom on the more recent families > And this would imply data busses placed horizontally across he chip > and arithmetic opertaors on it running vertically. > I guess number of routing > lines > in the two directions are also slightly different. In the 4K, there is the pretty much the same amount of each type of routing horizontally and vertically. The only exceptions, I believe are the carry chain and the ability to use horizontal long lines as tristate lines.In virtex, the fast direct connects only run horizontally; they're useful for high speed designs. 150 MHz is not unreasonable in a virtex-4. Incidently, a second reason data should flow across the chip is that the tristate busses only run horizontally in both families.Someone asked offline what constitutes "up" on the chips. A good question, so I'll repeat the answer here. Up is what shows as up when you open the floorplanner. IIRC, the quad flatpacks have pin one on the top edge. The best way to make sure you get it right is to open the floorplanner for the chip and package you are using and look at the pin numbers - they are printed on the floorplan screen. This is also how you figure out which pins align with which rows/columns. > Sarin. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18393
On Thu, 21 Oct 1999 17:55:14 -0400, Ray Andraka <randraka@ids.net> wrote: [snip] >Someone asked offline what >constitutes "up" on the chips. A good question, so I'll repeat the answer here. >Up is what shows as up when you open the floorplanner. IIRC, the quad flatpacks >have pin one on the top edge. The best way to make sure you get it right is to >open the floorplanner for the chip and package you are using and look at the pin >numbers - they are printed on the floorplan screen. This is also how you figure >out which pins align with which rows/columns. I recently had to go through this very exercise. Does anyone know why this essential information isn't stated explicitly in the data book? Allan.Article: 18394
Depending on your requirements Quicklogics embedded PCI must rank at the top. Nicolas Matringe <nicolas@dotcom.fr> wrote in message news:380B0CC9.185BD5B8@dotcom.fr... > Hi all > > I remember some discussions about this topic. I thought I had read that > the best chips were Lucent's and Xilinx's but I can't find the message > in Deja News... I can't even find a thread that looks like a comparison. > If someone could give me some hints... > > Thanks in advance, > Nicolas MATRINGE DotCom S.A. > Conception electronique 16 rue du Moulin des Bruyeres > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE > Fax 00 33 1 46 67 51 01 FRANCEArticle: 18395
Ken McElvain wrote: Here is a more straightforward way of building your own F/HMAPs and placing them via Synplify. It is also simulatable. library ieee; use ieee.std_logic_1164.all; library synplify; use synplify.attributes.all; entity fmap_xor4 is port( z : out std_logic; a, b, c, d : in std_logic); end entity fmap_xor4; architecture lut of fmap_xor4 is -- tell synplify that this architecture is an "fmap" attribute xc_map of lut : architecture is "fmap"; begin z <= a xor b xor c xor d; end architecture lut; library ieee; use ieee.std_logic_1164.all; library synplify; use synplify.attributes.all; entity hmap_xor3 is port( z : out std_logic; a, b, c : in std_logic); end entity hmap_xor3; architecture lut of hmap_xor3 is attribute xc_map of lut : architecture is "hmap"; begin z <= a xor b xor c; end architecture lut; library ieee; use ieee.std_logic_1164.all; library synplify; use synplify.attributes.all; entity clb_xor9 is port (z : out std_logic; a, b, c, d, e, f, g, h, i : in std_logic); end entity clb_xor9; architecture clb of clb_xor9 is -- xc_uset will actually create an HU_SET which will be qualified -- by the hierarchy path. We could use U_SET as the attribute. attribute xc_uset of all : label is "myuset"; attribute xc_rloc of u1 : label is "R0C0.f"; attribute xc_rloc of u2 : label is "R0C0.g"; attribute xc_rloc of u3 : label is "R0C0.h"; signal fout, gout : std_logic; begin u1: entity fmap_xor4 port map (fout, a, b, c, d); u2: entity fmap_xor4 port map (gout, e, f, g, h); u3: entity hmap_xor3 port map (z, fout, gout, i); end architecture clb; brian_m_davis@my-deja.com wrote: > In case anyone else is attempting to build carry > chain RPM's in VHDL, I've posted an example of an > XC4000/Spartan carry chain, built by instantiating > the Xilinx primitives, at: > > http://members.aol.com/fpgastuff > > file: tc_test1.zip > > The code creates a pipelined two's complement CLB > from the primitives, then places an array of them > using RLOC's. Although cascading two's complements > isn't terribly useful, it shows how to work around > some of the tool quirks encountered when connecting > and placing the carry primitives. > > The example was written for Synplify; check > "readme.txt" in the zipfile for more info. > > Credits: > > Thanks to Evan for posting examples of > synthesizable RLOC's, FMAP's, and EQN's at: > > http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm > > Comments: > > I view this method as more of a last resort than > as part of the normal design flow; the large pile > of code needed for this example could be replaced > with a few lines of RTL code using inferred operators, > plus possibly a couple of minutes in the floorplanner, > with equivalent results. > > The technique is useful for repeated structures > which need explicit mapping and placement for speed, > and for building library components smart enough to > size and place themselves; on the down side, it is > tough to do pre-synthesis simulation ( e.g., you need > an EQN model which can parse equation attribute strings.) > > Brian > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 18396
Hi, I made a design with a mixed schematic/abel design entry. I am using internal tristate busses. Because myinternal bus is not always driven (by TBUFs), I added internal pullups to set the default level of undriven busses to high. This works fine, even in the programmed fpga. The only thing that I worry about are some warnings by the bit-file-generator: WARNING:x45dr:42 - Netcheck: net DOUT<8> has TBUF mode drivers and pullups, pullups are not typically requried when TBUF mode, as opposed to WIRED mode, drivers are used. I got such a worning for every pullup I added ! Can I ignore them ? What can I do, that these warnings disappear ? There aren't enough resources left to drive the bus over TBUFs to get an default level/state. Thanks for advise MatthiasArticle: 18397
In article <380fdc19.6028487@newshost.fujitsu.com.au>, Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote: >On Thu, 21 Oct 1999 17:55:14 -0400, Ray Andraka <randraka@ids.net> >wrote: > >[snip] >>Someone asked offline what >>constitutes "up" on the chips. A good question, so I'll repeat the >answer here. >>Up is what shows as up when you open the floorplanner. IIRC, the quad >flatpacks >>have pin one on the top edge. The best way to make sure you get it >right is to >>open the floorplanner for the chip and package you are using and look >at the pin >>numbers - they are printed on the floorplan screen. This is also how >you figure >>out which pins align with which rows/columns. > >I recently had to go through this very exercise. Does anyone know why >this essential information isn't stated explicitly in the data book? > >Allan. I feel your pain. I'm working on a project where the pin locations were decided and routed on a PCB on the opposite sides. I would have just turned the chip if it were not already soldered on! Tyrone -- -------------- thompson@eecis.udel.edu University of Delaware Tyrone Thompson EE Graduate StudentArticle: 18398
Hi all,
I am looking for (large) multi-FPGA application that (severely) suffer from pin limitation (= having insufficient I/O-pins, so you can only partly fill up the chip). Of course I would love (benchmark)
designed circuit in any form, but specifications of the kind of application on any level are welcome too.
Thanx,
Joni
--
Department of Electronics and Information Systems,
Faculty of Applied Sciences, University of Ghent,
St. Pietersnieuwstraat 41,
B-9000 Ghent, Belgium 99999
work phone: +32-9-264.34.09 9 o - 9
email: jdambre@elis.rug.ac.be 9 | 9
\_/
Article: 18399Check this out. If you are in the UK and you use an NT Workstation with any of the following applications M-CAD, Electronic Design, DCC, GIS, Financial Analysis, or Software Development. Go to: http://survey.mt01.com/idc/inwac.asp? There you will be asked to become a member of an ‘epanel’ and to give your views on these applications. It only takes a few minutes and after that you get sent a nice pen as a ‘thank you’ but better than that you get put into a draw for £600 and another draw for a Palm Pilot. Plus access to various reports etc. Let me know what you think about it.
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