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
Hi, > First use File/Main Properties to turn the Edit Mode to Read Write (it is Read > Only by default). I thought I had the 'read/write' selected when I tried doing my edits...because it let me add the block, so it must have been in read/write, right? I'll try this again... > Then zoom in to your CLB (Ctrl-Right Click - and by the way zoom out is > Shift-Ctrl-Right Click!) and select your CLB pin. I clocked on the CLB I wanted to add, and it highlighted, then I clicked 'add' and that worked (as it did before... >Then find your net in the > All Nets List (you can sort them by name) and Shith-Click to select it (if you > just Click the pin will be deselected). I just left click and it selects the net, and highlights it... > ress the add button and wait. OK..it comes back and said 'warning: FPGAEditor:132 = the add command did not find anything to add...you may have meant clock Shift-Click on the pin...so I'll try that...AH! That worked. This pisses me off though, that is NOT how the on-line documentation says it works. They list the procedure as follows: Adding Component Pins to an Existing Net To add component pins to an existing net follow these steps. In the Array window, select the component pins you want to add to the net. The selected pins must be on a placed component (not a site), and the selected pins must not belong to any other net. Select the net to which you will add the pins in one of the following ways. Display a list of nets in the List window, then select the net name from this list. Select any net pin, ratsnest line, or routed segment on the desired net. Enter the Select command in the Command Line toolbar. Select Edit Add. The selected pins are added to the net. When I do their procedure...it just doesn't work. How did you figure out how to do it? You certainly didn't follow their documentation! > Then > wait some more and when you least expect it your pin will be connected to that > net. Of course, you must first configure the CLB pin and then add it to the > net, otherwise it will just give you an error. It let me add the pin using your instructions, with no error, and the block isn't configured... > You can also add multiple pins > to a net this way (using Shift-Click). All set on adding nets now! It's that 'Shift' that did it! > Now for the CLB equation problem. Select the CLB, press the editblock button > and in the Block Editor window the F= toolbar button. Edit Feqn and Geqn and > press the Save Changes and Closes Window toolbar button. It works for me. I type "f4", "a4" and even the name of the net in the Feqn area...with no equation (to avoid any problems with what characters mean not, and, or etc.) and when I hit 'save' I get an error "not a valid value for the Feqn attribute". Anything aside from 0 or 1 gives me an error. This still appears to be broken for me...any suggestions? Even if this tools worked, and was documented correctly...is is vastly more difficult to use than the previous version...which worked quite well. Even the graphics in the new tool are 'difficult'. Thanks for all your help! Well, at least you got me able to add a pin to an existing net! That's a lot further than I was before! P.S. I am using 2.1i... Regards, AustinArticle: 18901
> I think Catalin gave you some good advice. I believe the procedure you > were using will let you add the pin to a new net. Since the net you > typed exists, it would not clobber the existing net. Yep, he did...I am not able to add a CLB pin to an existing net...but I still can't edit the equation in the CLB... > The tool was protecting you from yourself... AND being very obtuse. That wasn't the problem...it was I was following the documentation....which failed to mention the need to 'shift-click' to select the CLB pin (after selecting the net in the List window)... Obtuse is an understatement...I don't believe I ever had to read the documentation of the previous XACT Editor...it was just easy and intuitive to use....for once I read the documentation...and it appears it was wrong...it may have been wrong in the old version, but hey, I would have never known ;-) Thanks! AustinArticle: 18902
> Yep, he did...I am not able to add a CLB pin to an existing net...but I > still can't edit the equation in the CLB... Sorry, bad proof reading...that is NOW able to add a CLB pin...Article: 18903
If you're not trying to do anything fancy, like multiple bank activation, you can implement a SDRAM precharge controller in an Altera Max7128A-6 at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines. I'm also doing the address mux in the MAX, and using a GAL for the DQM decode. This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers. It's at the limit of the PLD right now with one-hot state machines. mar@tcelectronic.com wrote: > Hello Maciej > > Have a look at an article, published in EDN 020298: > > Analyzing and implementing SDRAM and SGRAM controllers, available at: > http://www.ednmag.com/reg/1998/020298/03df_04.htm > > You'll have to register at edn, to get access to the article. > > Regards, > Martin Roenne > TC Electronic > > In article <38303A31.6A89@et.put.poznan.pl>, > Maciej Bartkowiak <mbartkow@et.put.poznan.pl> wrote: > > Dear All > > > > Here, at the University, we are running a design project that involves > > interfacing the SDRAM modules with a custom FPGA-based system. We have > > to cope with severe problems related to the complexity of SDRAM > control. > > We badly need advice from experienced designers of uC systems and > would > > be truly thankful for some hints. We are looking for any > possibilities > > to contact such experts, so please let us know if you know any. > > > > thank you very much, > > > > m.b. > > > > -- > > > > Maciej Bartkowiak, PhD > > > ======================================================================== > > Institute of Electronics and Telecommunication fax: (+48 61) > 6652572 > > Poznan University of Technology phone: (+48 61) > 6652171 > > Piotrowo 3A email: > mbartkow@et.put.poznan.pl > > 60-965 Poznan POLAND > http://www.et.put.poznan.pl/~mbartkow > > > ======================================================================== > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 18904
Looking in the .MRP file (from MAP) is much easier than lurching around in FPGA Editor. Also, beware that Synplify is 'smart' enough to convert some register sequences to SRLs, which can _never_ be put into IOBs. When this happens you have to dance the attribute tango, or use explicit FF instantiation, to get the result you desire. In article <814j3o$6ai$1@bcrkh13.ca.nortel.com>, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: <snip> > I've checked this using the FPGA editor. The pads are only being > used as IBUF or OBUF. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18905
> For now, I am very happy with the Lucent parts. I got 221 IOs in a 256 > BGA package which is more than any of the Xilinx parts. The Xilinx > Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256 > pin package!!! Does 221 out of 256 leave enough power-ground pins? How about when you have a big bus switching? Do the Lucent parts have separate VCCs for core and IO? -- These are my opinions, not necessarily my employers.Article: 18906
Austin Franklin wrote: > Obtuse is an understatement...I don't believe I ever had to read the > documentation of the previous XACT Editor...it was just easy and intuitive > to use....for once I read the documentation...and it appears it was > wrong...it may have been wrong in the old version, but hey, I would have > never known ;-) > > Thanks! > > Austin I feel your pain. It has been a major point of contention with me over the years that although the tools have improved (even though you might argue that point ;) they are still a far cry from being user friendly. I don't spend much time in the chip editors except to verify the results of synthesis and placement. But I do spend a lot of time using constraints. As long as we are complaining, I think this is one of the top three areas where improvement is required. I guess a lot of the tools are not too hard to use after you come up the learning curve, but they can be such a pain to learn!!! I am now learning the Lucent Orca design tools and I don't think they are any better than the Xilinx tools and may well be somewhat worse. In both houses the documentation is left as a poor stepchild (it is written by engineers, ya know! ) and are very seldom redone when new stuff comes out in a new format. As a result there seems to be multiple places you have to check to get the info you need if it is available at all. And don't bother suggesting that some new documentation should be written. It is hard to find a champion among the FGPA vendors for that. Well, thanks for the opportunity to complain. I always enjoy sharing my misery with others... :) -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 18907
Hal Murray wrote: > > For now, I am very happy with the Lucent parts. I got 221 IOs in a 256 > > BGA package which is more than any of the Xilinx parts. The Xilinx > > Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256 > > pin package!!! > > Does 221 out of 256 leave enough power-ground pins? How about > when you have a big bus switching? > > Do the Lucent parts have separate VCCs for core and IO? > -- > These are my opinions, not necessarily my employers. I will let you know, but I don't think it will be a problem. I have a 32 bit data bus and when I add DMA to my design in a month or two I will also have a 24 bit address bus switching at the same time (maybe). Most of the problem is with ground bounce. It is a bit funny, but a 256 pin BGA has 270 pins. They add 16 pins (balls) in the center that are all grounds. I think this brings the total grounds to 29. There are 13 Vdd giving 17 IOs per power pin and about 7.5 IOs per ground pin. So I am not expecting any problem from ground bounce. I have put decoupling capacitors very, very close to the power pins, one per. So I don't expect a problem from the power side either. The OR3T family uses 3 volt Vdd for the whole chip. They make the IOs 5 volt tolerant. So the power is all on one set of Vdd pins. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 18908
Tom Davidson wrote: > > If you're not trying to do anything fancy, like multiple bank activation, > you can implement a SDRAM precharge controller in an Altera Max7128A-6 > at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design > to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines. > I'm also doing the address mux in the MAX, and using a GAL for the DQM decode. > This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers. > It's at the limit of the PLD right now with one-hot state machines. One suggestion, one-hot coding is not always the best or fastest way to go with a state machine. Basically to make a machine faster, you want to minimize the number of inputs (variables) to each bit of the state machine. One-hot encoding works well when you have a simple state diagram which has few entry paths to each state and those entry paths have few variables controlling them. If this is not the case and your machine has many paths into some states and/or you have a lot of different control variables on paths to a single term, you may be better off with an encoded machine. In that case you at least can represent any combination of states with the same number of variables (bits). So a machine with say, 6 different paths converging to the IDLE state won't need 6 state variables to the IDLE logic, just enough to encode the number of states. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 18909
Hello! We are evaluating the above two Synthesis tools for our FPGA and ASIC design. Anybody who has used these tools could you please tell me which tool we should be buying in order to design the FPGA and ASIC. Please note that our design will be 250,000 gates and FPGA would be Xilinx's virtex device XCV800. If possible could you highlight from your experience point of view whats the diff. between FPGA Express and FPGA Compiler II also. Thanks in advance for your comments, Best Regards, Abdul Rafeeq. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18910
Paul Oh wrote: > > Hi to all! > > My end-goal is to port my ISA card design to PCI. This ISA card is a > simple 8255-based I/O board. It's details if you are interested are at > http://www.boondog.com - see the Tutorials link. > > I have no PCI experience. My impression is that one needs a FPGA or other > programmable logic device (PLD) for PCI interfacing. > > I have no PLD experience but do know digital logic and digital system > design (I am mechanical engineer). > > Xilinx and Altera sell affordable ($100 range) development kits and > software (student versions). > > Q. For my stated end-goal which PLD should I begin my learning curve on? > Q. Are on-line PCI tutorials (in relation to my end-goal or porting > ISA designs to PCI) ? > > Much appreciated, > > Paul Oh If you are porting an existing ISA design, the easiest path is to use a standard PCI-interface chip. There are several companies which offer various solutions, including PCI-to-ISA. See PLX (www.plxtech.com) AMCC (www.amcc.com) and V3 (www.vcubed.com). PCI-cores for FPGAs are usually intended for complex FPGAs in which PCI interface is mandatory, but not a very large part of the design; they are also pretty expensive (NRE of $5K and above). There are also some FPGAs (QuickLogic, ORCA) which have a hard-wired PCI core built in. All are probably overkill for your application. Regards Assaf SarfatiArticle: 18911
Check Out The New Music At MP3.com CLICK HERE>http://artists.mp3s.com/artists/9/lightyear.htmlArticle: 18912
In article <383768EC.33B55D9F@yahoo.com>,
Rickman <spamgoeshere4@yahoo.com> wrote:
>Tom Davidson wrote:
>>
>> If you're not trying to do anything fancy, like multiple bank activation,
>> you can implement a SDRAM precharge controller in an Altera Max7128A-6
>> at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design
>> to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines.
>> I'm also doing the address mux in the MAX, and using a GAL for the DQM decode.
>> This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers.
>> It's at the limit of the PLD right now with one-hot state machines.
>One suggestion, one-hot coding is not always the best or fastest way to
>go with a state machine. Basically to make a machine faster, you want to
>minimize the number of inputs (variables) to each bit of the state
>machine. One-hot encoding works well when you have a simple state
>diagram which has few entry paths to each state and those entry paths
>have few variables controlling them.
>If this is not the case and your machine has many paths into some states
>and/or you have a lot of different control variables on paths to a
>single term, you may be better off with an encoded machine. In that case
>you at least can represent any combination of states with the same
>number of variables (bits). So a machine with say, 6 different paths
>converging to the IDLE state won't need 6 state variables to the IDLE
>logic, just enough to encode the number of states.
I think one-hot coding is still the best. The problems you mention can
almost always be fixed by using some combination of pipelining and parallel
state machines. For example, the problem of 6 different paths leading to
the IDLE state can be fixed by adding two flip flops. The input to each is
the OR of three of the 6 paths, but one cycle early. Now you have only two
paths from these flip flops (but you have more than one bit on at the same
time). Also I find that it is unwise to add unnecessary control logic just
to reduce the number of states. It is better to have duplicate states which
lack control logic and use output flip flops to merge these states into the
control signals that they generate. Most steps of my state machines reduce
to simple shift registers with no steering logic.
One other technique is helpful for this: break the problem into multiple
smaller parallel state machines. On the output side this often means using
synchronous set/reset flip flops to make extended pulses. Why OR 8 states
into a single control line which is on for 8 consecutive cycles, when all
you need is two? One for when it turns on and one for when it turns off.
On the input side, think subroutines. The main controller has IDLE and
BUSY states, and generates START signals for the subroutine state machines.
These give DONE signals back to the main controller to break it out of the
BUSY states.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 18913I'm a long-time Xilinx user but have been using Orca for the past year due to circumstances beyond my control. My overall opinion of the 3T and 3L devices is positive, but there many other reasons to choose Xilinx over Orca: 1. The Orca tools are not as comprehensive as the Xilinx tools. Orca has no floorplanner, for example. And the bug-fix cycle is much longer for Orca. The huge Xilinx cutomer base and the above-average sophistication of most long-time Xilinx customers give Xilinx a huge advantage in identifying tool bugs. And to Xilinx's credit, they take advantage of this to identify workarounds and distribute patches much faster than Lucent. 2. Lucent tech support is nowhere near the level of Xilinx. I've always found Xilinx FAE support excellent; the on-line answers database, app notes, etc., also excellent; the hot-line support is better than most, but I hesitate to call it excellent; the information available through users groups and forums like this ng is excellent due simply to the much larger Xilinx customer base. Lucent provides token FAE support and their on-line resouces are pitiful. 3. Lucent has poor IP support for Orca vs. Xilinx. They don't even own a PCI core that they can provide customers. There is a huge amount of IP available for Xilinx both directly and through 3rd-party partnerships. 4. Xilinx has a much more clear and agressive road map going forward. They're the clear technology leader in the FPGA space in my opinion. 5. The level of support from other tool vendors (Synplify, ModelTech, etc.) is much greater for Xilinx than for Orca. Just look at the number of Xilinx-specific app notes on these vendors' web sites for an indication of their priority. Again, this is due to the large number of Xilinx users vs. Orca. One other general comment. Xilinx's sole business is programmable logic. FPGAs is a very small part of Lucent's business, and it shows. If Lucent ever really threw significant development/support and marketing resources at Orca I think they could almost compete with Xilinx. But the commitment just isn't there. I think you would be much happier and successful as a Xilinx customer. Robert Sefton Rickman wrote: > > I have picked the Lucent ORCA FPGAs for the board I am currently > building due to IO count, part cost and support. I have noticed that > there are not many people discussing these devices in this newsgroup, > which I assume is because there are not a lot of people using them. Can > I ask why Xilinx parts are preferred over the Lucent devices? Other than > inertia, why did you pick the Xilinx devices? > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > 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: 18914
Is anyone actively using Altera's JAM technology? What are your experiences? I haven't heard anything about it for over a year and had assumed (probably incorrectly) that interest in it had faded away. Thanks, ErichArticle: 18915
Robert,
Just as an FYI, Lucent has had the EPIC floorplanner for quite some time. In
fact, they had EPIC before Xilinx had their M1 equivalent.
Adam
Robert Sefton wrote:
> I'm a long-time Xilinx user but have been using Orca for the past
> year due to circumstances beyond my control. My overall opinion of
> the 3T and 3L devices is positive, but there many other reasons to
> choose Xilinx over Orca:
>
> 1. The Orca tools are not as comprehensive as the Xilinx tools.
> Orca has no floorplanner, for example. And the bug-fix cycle is
> much longer for Orca. The huge Xilinx cutomer base and the
> above-average sophistication of most long-time Xilinx customers
> give Xilinx a huge advantage in identifying tool bugs. And to
> Xilinx's credit, they take advantage of this to identify
> workarounds and distribute patches much faster than Lucent.
> 2. Lucent tech support is nowhere near the level of Xilinx. I've
> always found Xilinx FAE support excellent; the on-line answers
> database, app notes, etc., also excellent; the hot-line support is
> better than most, but I hesitate to call it excellent; the
> information available through users groups and forums like this ng
> is excellent due simply to the much larger Xilinx customer base.
> Lucent provides token FAE support and their on-line resouces are
> pitiful.
> 3. Lucent has poor IP support for Orca vs. Xilinx. They don't even
> own a PCI core that they can provide customers. There is a huge
> amount of IP available for Xilinx both directly and through
> 3rd-party partnerships.
> 4. Xilinx has a much more clear and agressive road map going
> forward. They're the clear technology leader in the FPGA space in
> my opinion.
> 5. The level of support from other tool vendors (Synplify,
> ModelTech, etc.) is much greater for Xilinx than for Orca. Just
> look at the number of Xilinx-specific app notes on these vendors'
> web sites for an indication of their priority. Again, this is due
> to the large number of Xilinx users vs. Orca.
>
> One other general comment. Xilinx's sole business is programmable
> logic. FPGAs is a very small part of Lucent's business, and it
> shows. If Lucent ever really threw significant development/support
> and marketing resources at Orca I think they could almost compete
> with Xilinx. But the commitment just isn't there. I think you
> would be much happier and successful as a Xilinx customer.
>
> Robert Sefton
>
> Rickman wrote:
> >
> > I have picked the Lucent ORCA FPGAs for the board I am currently
> > building due to IO count, part cost and support. I have noticed that
> > there are not many people discussing these devices in this newsgroup,
> > which I assume is because there are not a lot of people using them. Can
> > I ask why Xilinx parts are preferred over the Lucent devices? Other than
> > inertia, why did you pick the Xilinx devices?
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > remove the XY to email me.
> >
> > 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.com
--
"Sometimes I think the surest sign that there's intelligent life on
other planets is that none of it has tried to contact us."
- Calvin, "Calvin and Hobbes"
Article: 18916
Workshop on Cryptographic Hardware and Embedded Systems 2000
(CHES '2000)
http://www.ece.WPI.EDU/Research/crypt/ches
Worcester Polytechnic Institute
Worcester, Massachusetts, USA
August 17 & 18, 2000
First Call for Papers
General Information
The focus of this workshop is on all aspects of cryptographic hardware
and embedded system design. The workshop will be a forum of new results
from the research community as well as from the industry. Of special
interest are contributions that describe new methods for efficient
hardware implementations and high-speed software for embedded systems,
e.g., smart cards, microprocessors, DSPs, etc. We hope that the
workshop will help to fill the gap between the cryptography research
community and the application areas of cryptography. Consequently, we
encourage submission from academia, industry, and other organizations.
All submitted papers will be reviewed.
This will be the second CHES workshop. The first workshop, CHES '99, was
held at WPI in August of 1999 and was very well received by academia and
industry. There were 170 participants, more than half of which were from
outside the United States.
The topics of interest include but are not limited to:
* Computer architectures for public-key cryptosystems
* Computer architectures for secret-key cryptosystems
* Reconfigurable computing and applications in cryptography
* Cryptographic processors and co-processors
* Modular and Galois field arithmetic architectures
* Tamper resistance on the chip and board level
* Architectures for smart cards
* Tamper resistance for smart cards
* Efficient algorithms for embedded processors
* Special-purpose hardware for cryptanalysis
* Fast network encryption
* True and pseudo random number generators
Mailing List
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to ches@ece.orst.edu.
Instructions for Authors
Authors are invited to submit original papers. The preferred submission
form is by electronic mail to ches@ece.orst.edu. Papers should be
formatted in 12pt type and not exceed 12 pages (not including the title
page and the bibliography). The title page should contain the author's
name, address (including email address and an indication of the
corresponding author), an abstract, and a small list of key words.
Please submit the paper in Postscript or PDF. We recommend that you
generate the PS or PDF file using LaTeX, however, MS Word is also
acceptable. All submissions will be refereed.
Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.
Workshop Proceedings
The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.
Important Dates
Submission Deadline: April 15th, 2000.
Acceptance Notification: June 15th, 2000.
Final Version due: August 1st, 2000.
Workshop: August 17th & 18th, 2000.
NOTES: The CHES dates August 17 & 18 are the Thursday & Friday preceding
CRYPTO '2000 which starts on August 20.
Invited Speakers
David Naccache, Gemplus, France.
"How to explain side channel leakage to your kids?"
Alfred Menezes, University of Waterloo, Canada.
TBA
Program Chairs
All correspondence and/or questions should be directed to either of the
Program Chairs:
Cetin Kaya Koc Christof Paar
Dept. of Electrical & Computer Dept. of Electrical & Computer
Engineering Engineering
Oregon State University Worcester Polytechnic Institute
Corvallis, Oregon 97331, USA Worcester, MA 01609, USA
Phone: +1 541 737 4853 Phone: +1 508 831 5061
Fax: +1 541 737 8377 Fax: +1 508 831 5491
Email: Koc@ece.orst.edu Email: christof@ece.wpi.edu
Program Committee
Gordon Agnew, University of Waterloo, Canada
Wayne Burleson, University of Massachusetts at Amherst, USA
Kris Gaj, George Mason University, USA
Peter Kornerup, Odense University, Denmark
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Patrice L. Roussel, Intel Corporation, USA
Christoph Ruland, University of Siegen, Germany
Joseph H. Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Colin D. Walter, Computation Department - UMIST, U.K.
Michael Wiener, Entrust Technologies, Canada
Location
WPI is in Worcester, the second largest city in New England. The city
is 80 km (50 miles) West of Boston and 280 km (175 miles) North-East of
New York City.
Worcester is home to a wealth of cultural treasures, many of which are
just a short distance from WPI. These include the historic Higgins
Armory Museum, which houses one of the world's largest collections of
armor; the EcoTarium (formerly New England Science Center), one of the
only museums in the country dedicated to environmental education; and
the beautifully restored Mechanics Hall, one of America's finest
concert halls. The Worcester Art Museum, holding one of the nation's
finest collections, and the world-renowned American Antiquarian
Society, with the largest collection of items printed during the
nation's colonial period, are within two blocks of the WPI campus.
Worcester is also well known for its ten colleges, which cooperate
through the Colleges of Worcester Consortium.
Recreation areas within easy driving distance include Boston and Cape
Cod to the east, the White and Green mountains to the north, and the
Berkshires to the west.
August weather in New England is usually very pleasant with average
temperatures of 20 C (70 F).
Workshop Sponsors
This workshop has received generous support from Intel, secunet AG, and
SITI. The organizers express their sincere thanks.
Article: 18917Andreas Sorry if this sounds dumb, but check the actions in the parameters you pass when you call jam.exe. Jam will happily do nothing (without complaint) if you don't include something like "DOCONFIGURE=1" with the parameters in the call. We use the Jam player to configure a 10K30A as part of a 3 device JTAG chain, through an "embedded" ByteBlaster and it has been working fine so far... Regards, Michael a_maier@my-deja.com wrote: > Hello All i want to configure a altera flex10k30e using the jtag-port and a > jam-player. I am using MAX+II vers. 9.30 and the update to 9.31 applied to > it. The jam-player i ported for my hardware is vers. 2.12. When running the > JAM/STAPL file of my design an error occurs (even with the original 16bit > jam-player jam.exe). The error is "Error on line 35: action name not found." > Is there anybody who has experience in configuring flex devices with JAM? > > Andreas > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 18918
EPIC is _NOT_ a floorplanner. It is an editor, and a PITA at that. I'd take the old the Xact 6.0 XDE and floorplanner over the current tools any day if they would support the current devices. Adam J. Elbirt wrote: > Just as an FYI, Lucent has had the EPIC floorplanner for quite some time. In > fact, they had EPIC before Xilinx had their M1 equivalent. > > Adam > -- -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: 18919
Sorry. Thids is not an FPGA question but I am sure you all use similar
tools.
Has anyone any comment on the PADS schematic capture tool as compared to say
Orcad or Protel.
I am looking for a good, reasonable cost, front end for PCB designs -
Win85/98 based.
Someting with good hierarchy support rather than "dumb" busses and blocks.
Anthony
--
LogicWorks - Electronic Development Services
Anthony Ellis
Cell: 082 4453285
Phone 27-(0)12 9988062
Article: 18920
======================================================================
ICDCS 2000 CALL FOR PAPERS
International Workshop on Distributed Real-Time Systems (IWDRS)
Taipei, Taiwan, Republic of China,
April, 10 - 13, 2000
http://calab.kaist.ac.kr/Conf/IWDRS2000
in conjunction with
The 20th International Conference on Distributed Computing Systems
(ICDCS 2000)
http://www.cis.ohio-state.edu/~icdcs20/
Workshop proceedings to be published by IEEE Computer Society Press
======================================================================
THEME
Recently, the distributed real-time systems are widely adopted in
various environments like process control systems, automatized
factories,
and even a car. IWDRS will be devoted to the presentation of new and
on-going projects in distributed real-time technology and applications.
The prime purpose of IWDRS is to provide researchers with an opportunity
to discuss their evolving ideas and results.Topics of interest include
but are not limited to:
o Distributed Real-Time Scheduling
o Distributed Real-Time Programming Language
o Distributed Multimedia Systems
o Distributed Resource Management
o Real-Time Kernel
o Real-Time Surveillance
o Networking, Fault Tolerance, and Security
o Plant and Process Control
o Telecommunications and Mobile Computing
o Space Systems, Air Traffic Control, Avionics, and Air Defense
IMPORTANT DATES
o Submission: December 1, 1999
o Notification of Acceptance: December 15, 1999
o Camera-ready Copies: January, 1, 2000
PAPER SUBMISSION
Authors are invited to submit research contributions representing
original, previously unpublished work. Submitted papers will be
carefully evaluated based on originality, significance, technical
soundness, and clarity of exposition. All papers will be refereed
by at least two members of the program committee. Accepted papers
will be published by IEEE Computer Society Press as proceedings of
the ICDCS 2000 workshops. All submitted papers MUST be formatted
according to the author guidelines provided by IEEE Computer
Society Press (two-column format) and MUST NOT be longer than
6 pages.
Electronic Submission
Please e-mail one PDF or PostScript version of your paper to the
Workshop Program Chair at hyoon@calab.kaist.ac.kr
Postal Submission
If, for some reason, you cannot send your paper by email,
ONLY THEN you may submit it as four hard copies to the following
address:
Prof. Hyunsoo Yoon
Dept. of Computer Science,
Korea Advanced Institute of Science and Technology,
373-1 Kusong-dong, Yusong-gu, Taejon 305-701, Republic of Korea
WORKSHOP CHAIR
Hyunsoo Yoon, Korea Advanced Institute of Science and Technology,
Republic of Korea
PROGRAM COMMITTEE
Sang Hyuk Son (Univ. of Virginia, USA)
Insup Lee (Univ. of Pennsylvania, USA)
Heung-Kyu Lee (KAIST, Korea)
Jae-Heon Yang (KAIST, Korea)
Kane Kim (U. C. Irvine, USA)
Al Mok (Univ. of Texas at Austin, USA)
Lui Sha (Univ. of Illinois at Urbana-Champaign, USA)
John Stankovic (Univ. of Virginia, USA)
Oleg Sokolsky (Univ. of Pennsylvania, USA)
Kwei-Jay Lin (U. C. Irvine, USA)
Sangyoul Min (Seoul National University, Korea)
Seongbae Eun (Hannam University, Korea)
Jinsoo Kim (Korea Telecom, Korea)
Tarek Abdelzaher (Univ. of Virginia, USA)
Tei-Wei Kuo (National Chung Cheng Univ., Taiwan)
Victor Lee (City Univ. of Hong Kong, Hong Kong)
Jane Liu (Univ. of Illinois at Urbana-Champaign, USA)
Kang Shin (Univ. of Michigan, USA)
Kinji Mori (Tokyo Inst. of Tech., Japan)
Article: 18921Hi Can you elaborate on the statement below which you wrote. "Most micros (PIC/8051 etc) have TCP/IP stacks freely available." Is it in the form of hardware module or software module. -----Original Message----- From: Austin Franklin [mailto:austin@darkr99oom.com] Posted At: 17 November 1999 23:40 Posted To: comp.arch.fpga Conversation: implementing TCP/IP on PLD Subject: Re: implementing TCP/IP on PLD > Forget 'simple' with a TCP/IP stack. > The simplest would be using datagrams (UDP protocol), which you might be > able to squeeze into about 1k of uP code if you are skilful. Full > implementations you are talking about 25K+ of code on a fast uP. One of the PIC implementation I have seen is only 512 'bytes' of code. > What you are trying to do is *very* difficult - to the extent that (AFAIK) > only one manufacturer is vending TCP/IP on a chip with no legal strings > attached, and that's a custom uP. Most micros (PIC/8051 etc) have TCP/IP stacks freely available. Also, there are a number of embedded chips that have TCP/IP stacks ON them that are available now. It's just not THAT difficult...but I guess it depends on what you think is difficult...Article: 18922
Where -----Original Message----- From: Jamie Lokier [mailto:spamfilter.nov1999@tantalophile.demon.co.uk] Posted At: 18 November 1999 01:14 Posted To: comp.arch.fpga Conversation: implementing TCP/IP on PLD Subject: Re: implementing TCP/IP on PLD Austin Franklin writes: > You can not implement a TCP/IP stack in just a PLD, there simply aren't > enough gates, so you must not mean PLD, but something else...possibly > microprocessor, FPGA. I heard it's been done on an FPGA, and not an especially large one either. -- JamieArticle: 18923
Ray Andraka wrote: > > EPIC is _NOT_ a floorplanner. It is an editor, and a PITA at that. I'd take the > old the Xact 6.0 XDE and floorplanner over the current tools any day if they > would support the current devices. Come on Ray, don't hold back. Tell us how you really feel!!! ;) -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 18924
Robert Sefton wrote: > > I'm a long-time Xilinx user but have been using Orca for the past > year due to circumstances beyond my control. My overall opinion of > the 3T and 3L devices is positive, but there many other reasons to > choose Xilinx over Orca: > > 1. The Orca tools are not as comprehensive as the Xilinx tools. > Orca has no floorplanner, for example. And the bug-fix cycle is > much longer for Orca. The huge Xilinx cutomer base and the > above-average sophistication of most long-time Xilinx customers > give Xilinx a huge advantage in identifying tool bugs. And to > Xilinx's credit, they take advantage of this to identify > workarounds and distribute patches much faster than Lucent. That is useful information. I have not worked with the current Orca tools long enough to find out about this yet. > 2. Lucent tech support is nowhere near the level of Xilinx. I've > always found Xilinx FAE support excellent; the on-line answers > database, app notes, etc., also excellent; the hot-line support is > better than most, but I hesitate to call it excellent; the > information available through users groups and forums like this ng > is excellent due simply to the much larger Xilinx customer base. > Lucent provides token FAE support and their on-line resouces are > pitiful. Again, I don't have enough experience with the Lucent tech support to rate them fully, but what I have experienced on the hot line is about the same a Xilinx, adequate, but in need of improvement. You are right about Lucent's online support, you can't complain about it, because they don't have any. I browsed their FTP site for about 10 minutes and I think I checked out everything they have. But I did find a couple of useful tutorials on the clocking in the OR3T parts which was very useful since they don't explain it well in the datasheet. > 3. Lucent has poor IP support for Orca vs. Xilinx. They don't even > own a PCI core that they can provide customers. There is a huge > amount of IP available for Xilinx both directly and through > 3rd-party partnerships. You may be right about this, but your example is not good. They likely don't have an IP for a PCI core because they want to sell you the FPIC (or whatever acronym they use) that contains a hardware PCI core and FPGA circuitry. I expect this is a much better way to go than IP anyway as it needs no consideration by the tools, is much more efficient in terms of $$ and die size and likely just plain works better at full speed. > 4. Xilinx has a much more clear and agressive road map going > forward. They're the clear technology leader in the FPGA space in > my opinion. I did not see a lot of difference in their products myself. Xilinx may talk about their future products more, but I just don't see much difference in their current products. The big reason I am using the Orca parts now is the difference in IO count for a given package. I consider this to be a significant reason to go with Lucent myself. Can you elaborate on why you feel Xilinx is the techology leader? > 5. The level of support from other tool vendors (Synplify, > ModelTech, etc.) is much greater for Xilinx than for Orca. Just > look at the number of Xilinx-specific app notes on these vendors' > web sites for an indication of their priority. Again, this is due > to the large number of Xilinx users vs. Orca. Yes, I would agree with this claim. I am not using HDLs, but that is likely in the future. Or not perhaps. I am giving the full schematic approach a try. Since Lucent provides Viewlogic as a frontend, I get a lot of nice heirarchical tools with it. I will see if I can emulate the success of Ray and a few others who won't give up their schematics. > One other general comment. Xilinx's sole business is programmable > logic. FPGAs is a very small part of Lucent's business, and it > shows. If Lucent ever really threw significant development/support > and marketing resources at Orca I think they could almost compete > with Xilinx. But the commitment just isn't there. I think you > would be much happier and successful as a Xilinx customer. I don't know that I agree with this. I remember when I spoke with the Lucent people in the past, they seemed very committed to making their products competitive to Xilinx and others. If you speak with the FPGA group, they will be just as narrowly focused on FPGAs as anyone at Xilinx. Then there are a lot of people elsewhere in the company who are also supporters of the Orca FPGAs. I know because I am working with one on this project. My DSP programmer (midnight consulting) works for Lucent and is very excited about getting his hands dirty with their FPGAs. But I will let you know how I feel after I finish this design. It will be an evolving effort with at least three stages on the current board. When I design the next board, I will reevaluate the then current products to see if Xilinx is the better product for my application. Thank you for your opinion. I think you are right in many respects. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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.com
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