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
On Sun, 30 Jul 2000 21:47:47, Andrew Cannon <ajc@gmx.net> wrote: > K.Orthner wrote: > > > > You're welcome. I learnt something today too: nobody seems able to > > > explain me why left and right are inverted in a mirror but not top > > > and bottom ;-) > > > > You're eyes are on the left and right sides of your face. If they were, > > say, in the top and bottom of your face, then a mirror would invert top & > > bottom! > > > > (Aren't I full of answers today!) > > > So what does a person with one eye see in a mirror? I've always been told that a mirror inverts front to back. That's kept my interest in such mirror-aculous things happy. ---- KeithArticle: 24226
Ray Andraka wrote: > > rickman wrote: > > > I forgot to make a point that shows how silly this Viewlogic restriction > > is. I long ago figured out that you can bring any VL schematic into any > > VL workstation by creating a file with the same name and extracting the > > key line. Copy this line into the file you are trying to move and it > > will work on the new workstation! > > > > It is just the fact that I will have to do this every time I want to > > send out a design to a customer that ticks me off. Then the first time I > > forget, I will have lots of calls from people saying that they can't > > read the files!!! > > Which, if your customers are like mine might be two revisions of the tools > later :-) > > Is the FPGA only thing even an issue anymore, now that VL isn't being > packaged with the FPGA tool suites from the vendors? I do remember what a > PITA it was. That is what Lucent provides. But I may be switching to Xilinx Spartan II with my next board design. If so, I may still want to use Viewlogic for both. Doesn't Viewlogic still sell FPGA only systems? I looked on the web site and found separate products for board level design and FPGA. They don't have much information to go on so it is hard to tell. I am sending them an email. We'll see how they respond to the issue. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24227
It sounds like you are doing most of what you need to do. I assume from what you say that you are meeting the setup and hold times on the rising edge of CCLK. I also assume that you are strobing CS and WRITE low for only one clock cycle. You seem to be saying that when you strobe PRGM, INIT goes low for a bit and then goes high. I believe there is a short waiting period after INIT goes high before you can write data out. I can't find that value in the datasheet, it might be in app note 138. Or it might not be required in the Virtex series. Once you have loaded the bit file you may also have to load a few FF bytes. This was needed in the older families to get through the startup phase, but may also no longer be required. Otherwise you seem to be doing it correctly. Alun wrote: > > I'm downloading an xcv1000 from a CPU but get no change on the DONE or > INIT_L pins ie they stay at 0 and 1 respectively. INIT_L responds OK to a > pulse on PROGRAM_L. > > I've checked the data on a logic analyser and the start and end look correct > (I haven't checked all words). The data is bit swapped compared to a .bit > file as per Xilinx app note. > > I am strobing CS_L and WRITE_L so that the config is done in two byte > bursts. Both CS_L and WRITE_L strobe to 0 to write a byte, and both are 1 > when not writng. CCLK is 30.72MHz. BUSY is n/c since CCLK is <50-MHz. Should > BUSY be tied high? I don't see why, it's output only according to the data > sheet. The startup clock is CCLK. > The programming mode is SelectMAP. I can configure OK with JTAG. > I'm going mad and need ideas. This is the worst thing to debug since I > programmed a Zilog SCC back in 1987 - nothing happens until everything is > perfect. > > thanks > Alun -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24228
rickman wrote: > Maybe I am just a contrarian, but I saw the licensing working the other way. I > would *only* buy the FPGA workstations since I needed to be able to support the > FPGA stations. Using a board station would make the design incompatible with the > rest of the world of FPGA stations. Well, I think I understand what you said. However, having to run the board netlister, do multiple FPGA types, and do ASIC designs requires the unrestricted VL license. While it doesn't make sense to have all of the VL licenses be unrestricted, practically it does make sense to upgrade them so files can be easily passed between co-operating engineers in both directions. The other alternative is to buy extra restricted licenses and shuffle the dongles carefully, as even reading a schematic with the unrestricted license, IIRC, contaminates it from being worked on by the restricted license. > Does anyone know if Viewlogic has fixed this problem? I guess I could > ask Viewlogic. Not that I am aware of. They should fix it, in my opinion. ---------------------------------------------------------------------- rk History will remember the twentieth stellar engineering, ltd. century for two technological stellare@erols.com.NOSPAM developments: atomic energy and Hi-Rel Digital Systems Design space flight. -- Neil Armstrong, 1994Article: 24229
rk wrote: > Well, I think I understand what you said. However, having to run the board > netlister, do multiple FPGA types, and do ASIC designs requires the unrestricted VL > license. While it doesn't make sense to have all of the VL licenses be > unrestricted, practically it does make sense to upgrade them so files can be easily > passed between co-operating engineers in both directions. The other alternative is > to buy extra restricted licenses and shuffle the dongles carefully, as even reading > a schematic with the unrestricted license, IIRC, contaminates it from being worked > on by the restricted license. I am not doing ASIC designs, and I am trying to determine if it is best for me to use Viewlogic for board designs or to continue using Orcad or even to switch to someother package such as Aldec (am I nuts?!) > > Does anyone know if Viewlogic has fixed this problem? I guess I could > > ask Viewlogic. > > Not that I am aware of. They should fix it, in my opinion. You may be right. I have sent an email off to Innoveda asking about this. I agree that they should fix it. But every conversation that I have had with Viewlogic support or sales was along the lines of "we are just trying to protect our revenue". They just don't seem to get it that this hurts them. Or maybe not. If it makes the customers buy extra seats or buy upgraded seats then it is a plus for Innoveda. But this will completely keep me away as there is no fix for me other than supplying my customers with full viewlogic seats. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24230
"K. Orthner" a écrit : > > In the Spartan FPGAs, you can use the free-running oscillator used > for configuration inside your design with the 'OSC4' primitive. > > It's a very inaccurate oscillator, but good enough for what I'm > doing. > > I'd like to know if it's possible to do the same thing in a > spartan-II device. > > I've tried simply retargeting the Spartan-II device, without changing > the VHDl code at all, but I get a "the OSC4 symbol is not supported > in the spartan2 architecture. ..." error during translation. Hi I had a look at this last week. The XC4000/Spartan data sheets clearly state that the internal oscillator output is available, whereas Virtex/SpartanII) DS don't say a word about it. I don't think you can use it. -- Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel +33 1 46 67 51 11 F-92400 COURBEVOIE - FRANCE Fax +33 1 46 67 51 01 http://www.dotcom.fr/Article: 24231
--------------DFE21A3765D20E834E03DE3C
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Dear Sirs/Madams,
o Would you please tell me some good books/webs about learning FPGA?
I have a very fundamental question: I know that to do
FPGA hardware design, one writes pseudo codes.
o if there is a program in C/C++ written by somebody, is it easy to
rewrite it in FPGA pseudo code?
(Here "easy" means that just by translation without really
understand what the orginal C/C++ code is doing. Is this
possible?)
Thanks, kctang
--------------DFE21A3765D20E834E03DE3C
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Dear Sirs/Madams,</tt>
<br><tt></tt> <tt></tt>
<p><tt>o Would you please tell me some good books/webs about learning FPGA?</tt>
<br><tt></tt> <tt></tt>
<p><tt> I have a very fundamental question:
I know that to do</tt>
<br><tt> FPGA hardware design, one writes
pseudo codes.</tt><tt></tt>
<p><tt>o if there is a program in C/C++ written by somebody, is it easy
to</tt>
<br><tt> rewrite it in FPGA pseudo code?</tt>
<br><tt> (Here "easy" means that just by translation
without really</tt>
<br><tt> understand what the orginal C/C++
code is doing. Is this</tt>
<br><tt> possible?)</tt>
<br><tt></tt> <tt></tt>
<p><tt>Thanks, kctang</tt></html>
--------------DFE21A3765D20E834E03DE3C--
Article: 24232Keith R. Williams wrote: > > On Sun, 30 Jul 2000 21:47:47, Andrew Cannon <ajc@gmx.net> wrote: > > > K.Orthner wrote: > > > > > > You're welcome. I learnt something today too: nobody seems able to > > > > explain me why left and right are inverted in a mirror but not top > > > > and bottom ;-) > > > > > > You're eyes are on the left and right sides of your face. If they were, > > > say, in the top and bottom of your face, then a mirror would invert top & > > > bottom! > > > > > > (Aren't I full of answers today!) > > > > > > So what does a person with one eye see in a mirror? > > I've always been told that a mirror inverts front to back. > That's kept my interest in such mirror-aculous things happy. > Well that's right... The fact is that in order to see yourself in the face you would have to turn around and look in the other direction, and the usual way of doing that is to turn in the horizontal plane, which swaps left and right. The mirror just helps you to do that. If you stood on your head to look in the other direction then top and bottom would be inverted instead;-) ...Andrew > ---- > KeithArticle: 24233
Peter, Thanks for telling us about the dynamic nature of current consumption in CMOS devices. Now, how about the actual formula to calculate it? Michael Peter Alfke wrote: > > Laurent Gauch wrote: > > > <snip> > > > In limit case, what is the current max for the VCCINT of Spartan-II > > XC2S200? > > In limit case, what is the current max for the VCCO of Spartan-II > > XC2S200? > > > > In limit case, what is the current max for the VCCINT of Virtex-E > > XCV1600E. > > In limit case, what is the current max for the VCCO of Virtex-E > > XCV1600E. > > > > There is no meaningful answer to this question. The supply currents are all > the result of dynamically charging ( and discharging ) internal or external > capacitances. So the current is proportional to frequency, and depends > totally on your design type and size. > The "limit case" would be an unrealistic amount of current if you implement > a max size toggling shift register and clock it at 200+MHz. > > BTW, don't forget that the forward drop of an appropriately large silicon > diode can generate 2.5 V from 3.3 V, or 1.8 V from 2.5 V, but it is of > course up to you to figure out the worst-case scenario... > > Peter Alfke, Xilinx Applications -- ***************************************************************** * Michael J. Kelly, Vice-President, Engineering and Marketing * * * * Cogent Computer Systems, Inc. tel: (401) 295-6505 * * 1130 Ten Rod Rd., Suite A-201 fax: (401) 295-6507 * * North Kingstown, RI 02852 web: www.cogcomp.com * * * * CMA - Development Platforms for 32 and 64-Bit Microprocessors * *****************************************************************Article: 24234
In figure 10 of Xilinx app note 132 (xapp132), is shown a method to de-skew a board level clock (clock is input to two DLL's, the output of the first DLL is driven outside the chip back to other external devices as well as back internal to the first DLL feedback pin; the second DLL is used to generate the clock to be used internal to the chip). My question is, what does this method of using two DLL's gain you over using just one DLL in the standard implementation and driving the externally generated clock to the Xilinx part as well as the other external chips? I don't see any benefit. (I do see a benefit if you had to multiply or divide the original clock source - but that is not my case). Am I missing anything? ----------------------------------------------------------- Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.comArticle: 24235
Thanks for your help But still I have some problems nullandvoid wrote: > >How can I do a shifter shifts the register contents by an amount > that is > >resulted from another operation. > > > >For example > > > >Shift right (A, by b+c) > >shift contents of register 'A' b+c bits to the right in a single > clock. > > > > > >Regards > >Jamil Khatib > > > > if your register is of type bit_vector and you're using > VHDL'93, you can use the srl (shift-right logical) command like > so: > > register_name := register_name srl (b + c); > I tried this but it gives me syntax error > > or you could try a function similar to the following: > > function shift_right ( > A : std_logic_vector; > num_shift : natural) return std_logic_vector is > begin > for i in num_shift downto 0 loop > A := '0' & A(A'left downto (A'right + 1)); > end loop; > return A; > end function shift_right; > This does not work for synthesis, it gives non constant bound Should I do a burrel shifter manually? > > you might also want to add a check for num_shift being less than > 0 which would mess up the loop. > > anyway, FWIW. > > ciao, > > NaV > > ----------------------------------------------------------- > > Got questions? Get answers over the phone at Keen.com. > Up to 100 minutes free! > http://www.keen.com Regards Jamil KHatibArticle: 24236
rickman wrote: > rk wrote: > > Well, I think I understand what you said. However, having to run the board > > netlister, do multiple FPGA types, and do ASIC designs requires the unrestricted VL > > license. While it doesn't make sense to have all of the VL licenses be > > unrestricted, practically it does make sense to upgrade them so files can be easily > > passed between co-operating engineers in both directions. The other alternative is > > to buy extra restricted licenses and shuffle the dongles carefully, as even reading > > a schematic with the unrestricted license, IIRC, contaminates it from being worked > > on by the restricted license. > > I am not doing ASIC designs, and I am trying to determine if it is best > for me to use Viewlogic for board designs or to continue using Orcad or > even to switch to someother package such as Aldec (am I nuts?!) If you are working in schematics, Orcad and Aldec are going to feel vrey toy-like once you use VL. On the otherhand, viewlogic's VHDL tools are second rate at best when compared to the superb VHDL/verilog tool suite offered by Aldec. > > > > > > Does anyone know if Viewlogic has fixed this problem? I guess I could > > > ask Viewlogic. > > > > Not that I am aware of. They should fix it, in my opinion. > > You may be right. I have sent an email off to Innoveda asking about > this. I agree that they should fix it. But every conversation that I > have had with Viewlogic support or sales was along the lines of "we are > just trying to protect our revenue". They just don't seem to get it that > this hurts them. Or maybe not. If it makes the customers buy extra seats > or buy upgraded seats then it is a plus for Innoveda. But this will > completely keep me away as there is no fix for me other than supplying > my customers with full viewlogic seats. > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 24237
Go to the power estimator on Xilinx's website. The formula for computing the exact power is difficult to use becuase it requres you to know the activity of each node in the design. One could compute the exact worst case power (or typical power for that matter) if you have an exact model of the circuit operation along with the routing and the power for various cirucit configurations. The circuit configuration power is estimated by characterisation, however without the detailed knowledge of your circuit it is not very useful. "Michael J. Kelly" wrote: > Peter, > > Thanks for telling us about the dynamic nature of current consumption in > CMOS devices. Now, how about the actual formula to calculate it? > > Michael > > Peter Alfke wrote: > > > > Laurent Gauch wrote: > > > > > <snip> > > > > > In limit case, what is the current max for the VCCINT of Spartan-II > > > XC2S200? > > > In limit case, what is the current max for the VCCO of Spartan-II > > > XC2S200? > > > > > > In limit case, what is the current max for the VCCINT of Virtex-E > > > XCV1600E. > > > In limit case, what is the current max for the VCCO of Virtex-E > > > XCV1600E. > > > > > > > There is no meaningful answer to this question. The supply currents are all > > the result of dynamically charging ( and discharging ) internal or external > > capacitances. So the current is proportional to frequency, and depends > > totally on your design type and size. > > The "limit case" would be an unrealistic amount of current if you implement > > a max size toggling shift register and clock it at 200+MHz. > > > > BTW, don't forget that the forward drop of an appropriately large silicon > > diode can generate 2.5 V from 3.3 V, or 1.8 V from 2.5 V, but it is of > > course up to you to figure out the worst-case scenario... > > > > Peter Alfke, Xilinx Applications > > -- > ***************************************************************** > * Michael J. Kelly, Vice-President, Engineering and Marketing * > * * > * Cogent Computer Systems, Inc. tel: (401) 295-6505 * > * 1130 Ten Rod Rd., Suite A-201 fax: (401) 295-6507 * > * North Kingstown, RI 02852 web: www.cogcomp.com * > * * > * CMA - Development Platforms for 32 and 64-Bit Microprocessors * > *****************************************************************Article: 24238
hey, what are the advantages and disadvantages from using TBUFs( e.g : for multiplixer purpose ) anticipated thanks --Erika Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24239
Dave Vanden Bout wrote: > > We use a CPLD and a 16 Mbit Flash on our XSV Boards. The CPLD controls > the programming of the Flash and then the configuration of the Virtex > FPGA from the Flash. Xilinx provides an app-note that shows how the > CPLD controls the configuration process. > > You can get an 8051 in a 44-pin package for about $1 and a 1 Mbit Flash > device for about $1.50. The 8051 will have enough I/O to drive the > address and control lines of the Flash and the configuration clock of > the FPGA. I'm not sure how much pinout you can get from a PIC for $1. > We at Raytheon have done something similar, in a multiple board system, the FPGA's configuration is stored in the same large Flash that the Boot control processor code is stored. The FPGA comes up and waits for the control processor to write the code to the FPGA. This was mostly done to simplify in system configuration control, and field reprograming of the FPGA's, without having to have an external interface to the board. It also saves space of course. We usually at least provide an option in every board(except maybe the main control Processor) so that an external serial PROM could be used as an alternative. If all you want to do is to use a cheaper(?) parallel PROM/EPROM, we also used a design based off a Xilinx application note. Though if you have a processor or multiple FPGA's, you can like save money by combining multiple FPGA and/or processors code into one bigger storage device, and then chosen on of the devices to be the Master that distributes the code to all the slaves. Its costs some I/O, code space and increases boot time, but it can be much cheaper. A big bonus for Military or other systems requiring somewhat undefined future upgrades is that by combining several code data bases together you can allow for expansion of of code space requirements for any subset of them at a much lower cost than by upping the NVRAM requirements of each unit. While it is pretty for sure that some processor or FPGA will require more NVRAM space, it is unlikely that you would double(or whatever expansion you support) all of the requirements without a total redesign. However, you might increase a single processors requirements by 3x. An most likely unneeded example. Say you have 10 processors that require 100k of NVRAM space each. This means you need 1 Meg of NVRAM in the first production run. To meet the military's normal 50% reserve, you would require 10 Meg of NVRAM. You could either double each board's NVRAM and all you would get is the upgrade ability, or you could combine all the memories into 1 large NVRAM. Muddy > Stuart J Adams wrote: > > > Can anyone recommend low-cost alternatives to > > what seems to be pretty costly serial config > > eproms/proms for FPGAs ?? We are looking at > > Spartan-II and the 1MBit config eprom is about > > the same price as the FPGA. > > > > For my current application I can't load the FPGA > > from the microprocessor. > > > > I was thinking about maybe using a regular byte-wide > > Flash device and CPLD or PIC instead (maybe a $5 > > solution instead of $15) > > > > -- Stuart > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 24240
In article <8F81AFF46korthnerhotmailcom@158.202.232.7>, korthner@hotmail.nospam.com (K. Orthner) wrote: > >> You're eyes are on the left and right sides of your face. If they > >> were, say, in the top and bottom of your face, then a mirror would > >> invert top & bottom! > > > >The mirror /doesn't/ invert left and right (or up and down or anything > >else). The /user/ of the mirror does. Think about it. > > That was pretty much my point. Que? The position of your eyes makes no difference at all. If you want to see top/bottom inversion, stand on your head before looking in the mirror! There is no objective difference between the two methods of looking at yourself, although one is undoubtedly more convenient than the other :-) -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 24241
Hi Bernardino.... Can you give a reference pointer for the statement: >One of the four inputs of the LUTs in the FLEX family is faster than the >three others. I have not come across this little gem before........ Eric Pearson Bernardino León wrote in message ... >Suppose we have a function like Y = A AND B AND C AND D, that fits in a >LUT... And suppossing that there isn't any timing constrain in any of the >inputs >Is there any way to know - BEFORE compiling - which one of the four inputs >will be assigned the fastest of the four inputs? > >Thanks >Bernardino Leon >bleon@lander.es > > >Article: 24242
I have a design that currently uses a PLX 9080, and I need to move it to a 64 bit and/or 66MHz PCI interface... PLX does not currently offer a solution, that I can find...neither does AMCC. Any suggestions for off the shelf chips to do this, or any experience with the QuickLogic QL5064 interface chip? Thanks!Article: 24243
In article <39855D80.F8380868@gmx.net>,
Andrew Cannon <ajc@gmx.net> wrote:
> Keith R. Williams wrote:
> >
> > On Sun, 30 Jul 2000 21:47:47, Andrew Cannon <ajc@gmx.net> wrote:
> >
> > > K.Orthner wrote:
> > >
> > > > > You're welcome. I learnt something today too: nobody seems
able to
> > > > > explain me why left and right are inverted in a mirror but not
top
> > > > > and bottom ;-)
> > > >
If your mirror happens to have a hinge such that you can
arrange the mirrors like this:
/\
/ \
/ \
()()
you can get really confused trying to comb your hair!
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24244Yes. I think that if you read that app note (it's not right in front of me, but memory says this is there) it explains that you can only drive a single device with the output of a Virtex DLL. You can drive either a BUFG for an internal clock, or an IOB for an external clock. Of course, you could always drive an IOB out from the output side of the BUFG, but then you don't get synchronous edges inside and outside the chip. The external one would be lagging the internal clock by one IOB delay time (+/- the slight skew of the global clock routing tree, which is small). Ben seamus wrote: > > In figure 10 of Xilinx app note 132 (xapp132), is shown a method > to de-skew a board level clock (clock is input to two DLL's, the > output of the first DLL is driven outside the chip back to other > external devices as well as back internal to the first DLL > feedback pin; the second DLL is used to generate the clock to be > used internal to the chip). > > My question is, what does this method of using two DLL's gain you > over using just one DLL in the standard implementation and > driving the externally generated clock to the Xilinx part as well > as the other external chips? I don't see any benefit. (I do see > a benefit if you had to multiply or divide the original clock > source - but that is not my case). Am I missing anything? > > ----------------------------------------------------------- > > Got questions? Get answers over the phone at Keen.com. > Up to 100 minutes free! > http://www.keen.comArticle: 24245
On Mon, 31 Jul 2000 11:05:36, Andrew Cannon <ajc@gmx.net> wrote: > Keith R. Williams wrote: > > > > On Sun, 30 Jul 2000 21:47:47, Andrew Cannon <ajc@gmx.net> wrote: > > > > > K.Orthner wrote: > > > > > > > > You're welcome. I learnt something today too: nobody seems able to > > > > > explain me why left and right are inverted in a mirror but not top > > > > > and bottom ;-) > > > > > > > > You're eyes are on the left and right sides of your face. If they were, > > > > say, in the top and bottom of your face, then a mirror would invert top & > > > > bottom! > > > > > > > > (Aren't I full of answers today!) > > > > > > > > > So what does a person with one eye see in a mirror? > > > > I've always been told that a mirror inverts front to back. > > That's kept my interest in such mirror-aculous things happy. > > > > > Well that's right... > > The fact is that in order to see yourself in the face you would have to > turn around and look in the other direction, and the usual way of doing > that is to turn in the horizontal plane, which swaps left and right. > > The mirror just helps you to do that. > > If you stood on your head to look in the other direction then top and > bottom would be inverted instead;-) No. Top and bottom, nor left/right need apply. When you look in a mirror you are looking at yourself as if you were a mere shell, looking at yourself from behind. All symetry works looking at it this way. When I finally realized this, mirrors were no longer any mystery. Any lines of symetry I've inherated don't matter either (we aren't symetrical at all - as left-right proves). I can have two axis of symetry and the mirror is still a front-back inversion. ---- Keith P.S. Sorry, comp.lang nor vhdl aren't on my server.Article: 24246
On Mon, 31 Jul 2000 22:57:34, hiennguyen@my-deja.com wrote: > In article <39855D80.F8380868@gmx.net>, > Andrew Cannon <ajc@gmx.net> wrote: > > Keith R. Williams wrote: > > > > > > On Sun, 30 Jul 2000 21:47:47, Andrew Cannon <ajc@gmx.net> wrote: > > > > > > > K.Orthner wrote: > > > > > > > > > > You're welcome. I learnt something today too: nobody seems > able to > > > > > > explain me why left and right are inverted in a mirror but not > top > > > > > > and bottom ;-) > > > > > > > If your mirror happens to have a hinge such that you can > arrange the mirrors like this: > /\ > / \ > / \ > > ()() > you can get really confused trying to comb your hair! A corner reflector. That confused me too, until I realized I was doing a double front-to-back. ---- KeithArticle: 24247
I think you are missing something. The clock started as an external signal and the DLL should compensate for the IOB delay on the input. So the *incoming* external clock and the internal clock should be inphase. So why would you need to route it back out again at all? Ben Sanchez wrote: > > Yes. I think that if you read that app note (it's not right in > front of me, but memory says this is there) it explains that you > can only drive a single device with the output of a Virtex DLL. > You can drive either a BUFG for an internal clock, or an IOB for > an external clock. Of course, you could always drive an IOB out > from the output side of the BUFG, but then you don't get > synchronous edges inside and outside the chip. The external one > would be lagging the internal clock by one IOB delay time (+/- > the slight skew of the global clock routing tree, which is > small). > > Ben > > seamus wrote: > > > > In figure 10 of Xilinx app note 132 (xapp132), is shown a method > > to de-skew a board level clock (clock is input to two DLL's, the > > output of the first DLL is driven outside the chip back to other > > external devices as well as back internal to the first DLL > > feedback pin; the second DLL is used to generate the clock to be > > used internal to the chip). > > > > My question is, what does this method of using two DLL's gain you > > over using just one DLL in the standard implementation and > > driving the externally generated clock to the Xilinx part as well > > as the other external chips? I don't see any benefit. (I do see > > a benefit if you had to multiply or divide the original clock > > source - but that is not my case). Am I missing anything? > > > > ----------------------------------------------------------- > > > > Got questions? Get answers over the phone at Keen.com. > > Up to 100 minutes free! > > http://www.keen.com -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24248
For low fan in multiplexors they are slow and consume a lot of long lines (one per bit). But for high fan in muxes, they are pretty good. You need to decode the select lines. But this can make it easier to utilize unique select setups such as a 1 of N select. I have used TBUF muxes when I needed to make an unusual mux which allowed me to pack a variable sized data word into 32 bit data words. The size was preselected, but ranged from 1 to 8 bits. I used a 5 bit counter and a decoder to give me the 1 of 8 select to enable the different tristate enables. This was pipelined to give speed so that the 8 enables changed on every clock edge. The slow path then was the enable register output through the tristate buffer onto the long line and to the data register D input. It ran at the needed 50 MHz in an XC4013XL. The real beauty is that it used *no* CLBs for the actual mux and only 4 CLBs for the decodes. Not bad for an 8 to 32 mux array. It worked so well that I used another, similar TBUF array for the inputs to the register which controlled the CE on the data register. This one was a little more complicated to figure out, but the decode was purely static. erika_uk@my-deja.com wrote: > > hey, > > what are the advantages and disadvantages from using TBUFs( e.g : for > multiplixer purpose ) > > anticipated thanks > > --Erika > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24249
FINAL CALL FOR PAPERS
CASES 2000
International Conference on
Compilers, Architectures and Synthesis for Embedded Systems
http://www.capsl.udel.edu/conferences/cases2000
November 17-19, 2000
Doubletree Hotel
San Jose, CA, USA
Submission deadline: August 14, 2000
CONFERENCE OBJECTIVES
The purpose of this working conference, the third in the series,
is to provide a forum for discussing emerging technology themes in
embedded computing system design.
Over the past decade, substantial research has gone into the
design of general-purpose microprocessors embodying parallelism at
the instruction-level, as well as aggressive compiler optimization
and analysis techniques for harnessing this parallelism. Growing
demand for high performance in embedded systems is creating new
opportunities to leverage technologies such as instruction-level
parallelism (ILP) or Explicitly Parallel Instruction Computing (EPIC).
Examples of application areas with the need for high performance and
application specific embedded computing include set-top boxes,
hand-held games, mobile and web appliances, and advanced automotive
systems.
However, several novel challenges have to be overcome in order
to harness the opportunities offered by emerging technologies in the
context of embedded systems. Constraints on cost, code size, weight,
power consumption and real-time requirements place stringent
requirements on processors and the software they execute. In addition,
design time is an important issue because of the growing demand for
rapid time-to-market.
Technical as well as position papers espousing significant novel
ideas and technical results are solicited. Conference topics include
(but are not limited to) the following:
* Novel architectures and micro-architectures for embedded
systems based on ILP.
* Automated design and synthesis of application or domain
specific processors.
* Application or domain specific designs.
* Light-weight languages for temporal specification.
* Optimizing compilers for ILP exploitation in the presence of
novel constraints.
* Synergy between extant parallel computing technologies, such as
notations for expressing concurrency, and instruction level
parallel processing.
* Harnessing the interaction between the hardware and software
layers, spurred by innovations in reconfigurable or adaptive
computing systems.
* Characterizing the need of research infrastructure development
for embedded systems based on adaptive technologies.
* Compiler Controlled Memory Hierarchy Management and Smart Caches.
* System-on-a-Chip architectures/compilers and embedded software
including heterogeneous multiprocessor embedded systems.
* Compiler optimizations and synthesis for improved exploitation of
power versus performance tradeoffs.
In addition to presentations, the conference will feature
* Two keynote lectures by experts:
Amir Pnueli, The Weizmann Institute and New York University
B. Ramakrishna (Bob) Rau, Hewlett-Packard Labs
* A panel on the following topic:
System on a Chip: Hardware Dream or Software Nightmare?
INFORMATION FOR AUTHORS:
Please submit either one electronic copy of the paper in postscript
format to the following email address, or FIVE hard copies to the program
chair at the address given below. There is no page limit, but the paper
must not exceed 4000 words in length. The proceedings will be
published by ACM Press. All papers must be submitted in the ACM format
as specified at http://www.acm.org/sigs/pubs/proceed/template.html
E-mail address for submission: CASES@capsl.udel.edu
Mail address for submission:
CASES 2000
School of Electrical and Computer Engineering
Georgia Institute of Technology
801 Atlantic Drive
Atlanta, GA 30332-0250
USA
IMPORTANT DATES:
Papers due: August 14, 2000
Author notification: September 10, 2000
Camera ready copy due: October 5, 2000
ORGANIZING COMMITTEE
Steering Committee:
James R. Boddie, Lucent Technologies
Guang R. Gao, University of Delaware
Vinod Kathail, Hewlett-Packard Labs
Edward Lee, University of California Berkeley
Reid Tatge, Texas Instruments
Conference Chair:
Krishna Palem, Georgia Institute of Technology and New York University
Local Arrangements Vice-Chair:
Praveen Murthy, Angeles Design Systems
Panels Vice-Chair:
Jack Davidson, University of Virginia
Publications Vice-Chair:
Jaime Moreno, IBM T.J. Watson Research Center
Publicity Vice-Chair:
Vincent Mooney, Georgia Institute of Technology
Program Committee:
Shuvra S. Bhattacharyya, University of Maryland
Henk Corporaal, Delft University of Technology
Srinivas Devadas, Massachusetts Institute of Technology
Christine Eisenbeis, INRIA Rocquencourt
Antonio Gonzalez, Universitat Politecnica de Catalunya
Rajesh Gupta, University of California at Irvine
Nevin Heintze, Lucent Bell Laboratories
Kathryn S. McKinley, University of Massachusetts, Amherst
Lothar Thiele, ETH Zurich
Frank Vahid, University of California at Riverside
Wei Zhao, Star Core
--
Vincent Mooney
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: eefacvmn@prism.gatech.edu
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