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 All, Comments at end... > OK, got the specs back, sorry about the misinformation. > > Motherboard: > > The general gist is do what you want, as long as you meet the timing specs > with all sockets putting 10pf load on the lines: > > at 33MHz: > max allowed clock skew 2 ns, pin-to-pin between any two components, not sockets > max. allowed round trip delay (one reflection) for any signal 10ns > > You are allowed to lower the clock frequency if you want. > > Expansion board: > > See Keith's post for trace lengths, disregard my previous one. :^) > > You are not allowed to have more than one input (max 10pf) on any > signal, the impedance of your traces should be 60-100 Ohm and the trace > velocity is supposed to be 150-190 ps/inch. > Well we have one small problem in that the bus passes across power planes (3.3 & 5). I'v added 10pf Caps at these bodaryies between the power rails as per spaec recommendation - but don't seam to do much. The problem we are getting is hevay overshoot (some as much as +-1.5v) on the rise and fall - no knee!? We have added Scottkey diodes to the bus which has helped get ride of our bit errors and parity problem. But it don't look nice! We have a 32bit device that has its bus T'ed from the main 64bit bus which has two other devices + a bridge. Its hard to tell who is driving the bus and which way, but there is some defanent overshoot. Could this be a refelction from somthing close to the driver chip (total bus is 10 inch) as its not always there!? Thanks in advance. cyber_spook_manArticle: 31301
Peter Alfke <peter.alfke@xilinx.com> writes: >PREP was an unmitigated disaster. It started with the naive idea that the >capacity and speed of any and all programmable devices, from simple CPLDs >to big XC3090s, could be measured by implementing a design consisting >of concatenated MSI blocks. Then we underestimated the power of marketing, >and Altera's "creativity" ( I have a long list of dirtier words for it), >who claimed virtual designs with more than 100% utilization of the >existing circuitry. Made me lose all respect for them. It might just be the marketing department. I have seen that before. >Different from microprocessors, programmable logic comes in widely >different sizes and flavors, and is being used for widely differing >purposes. I stick with my original story that a single-number >measurement for capacity ( or speed ) is as meaningless as 38-24-36. Well, microprocessors come in a large range of sizes, but one doesn't always try to benchmark all sizes. SPEC has a variety of real programs, some fixed point, some floating point, for example. There have been problems there, with companies designing the compiler to optimize well the benchmark programs. I agree, concatenated MSI blocks doesn't sound very realistic. Though the problems I used to work on, systolic array processors, were not much more than linear arrays of MSI block. (16 bit adders, and 16 bit maximum of two numbers, mostly.) It could scale in both width and length to fit different sized chips. -- glenArticle: 31302
Tom Kaminski wrote: > > In the example below, a 5 state FSM is created. Synthesize it with FPGA > Express 3.5 and you will see (in the schematic viewer) all 5 registers used > to determine if fsm_state = fsm_2_state (whereas only one register should > have been used). This causes extra delay to occur. A workaround is to > assign the signals within the FSM case statement. However, I don't like > this coding style so I'm not gonna use it. (BTW, Altera MaxPlusII > synthesizes the code using a single state register compare). > > As a matter of curiosity why don't you like the coding style where the outputs are defined within the case ? Its my standard - Verilog - style so I'm interested in arguments against.Article: 31303
The attributes that we use for initial values, RLOCs and DCM or DLL setup are generally treated as user attributes by the synthesizer....In other words the synthesis does nothing but stick them into the EDIF netlist as attributes. It doesn't care what the attribute is named or assigned as long as the syntax is legal. Note, some of the lower end sythesis tools won't even pass the attributes (Xilinx's XST comes to mind) in which case you can't even do this much. BTW, the user attributes can be handy for putting RLOCs on primitives, setting initial values or even for defining timing groups. Srinivasan Venkataramanan wrote: > > Brian, > I am not an FPGA expert, but was rather interested in this > discussion. > > Brian Philofsky wrote: > > > > Meelis, > > > <SNIP> > > > As far as I know, > > VHDL attributes are ignored by most simulators and therefore can not pass > > information to simulation models however generics can. > > I think you are correct, but why can't a simulator "understand" > attributes - I remember reading that attributes are mainly used by > Synthesis tools, but essentially it is a VHDL compiler's job to > interpret these attributes - am I right? If so IMHO a simulator in > principle *CAN* understand attributes. They don't is a different > issue. > > Could someone explain if there is any problem with this? > > TIA > > Srini > > -- > Srinivasan Venkataramanan (Srini) > ASIC Design Engineer, > Chennai (Madras), India -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 31304
I'm a user of ModelSim PE/VHDL. For financial reasons beyond my control I am being asked to consider switching to modelsim XE. I recall seeing somewhere that XE is literally just a slowed down version of PE (something like 3x or 5x). Can anyone familiar with both products confirm this? Is the only difference how fast they run? Do you still get all the windows, the ability to set breakpoints, etc? It is not limited in the size of the source code or anything like that is it? Thanks in advance. JeffArticle: 31305
If you are using Synplify-Pro then you can just include both the VHDL and Verilog files in your project and let Synplify sort it out. No black boxes in this flow. What will probably work if you are doing separate compilation is to just use a component declaration, with no entity or architecture for the Verilog design being instantiated. The component should automatically turn into a black box when it doesn't find a binding. I suspect that the unused inputs message happened because of the empty architecture. Utku Ozcan wrote: > > Synplify v6.2 gives warnings for ports of instantiated black-box in a VHDL code: > > @W:?filename?:10:8:10:16:Input clock is unused > > The point is that the code to be instantiated in VHDL is actually Verilog but I have > created VHDL code with an empty ARCHITECTURE, like Verilog-style black-box module. > > I also used > > ATTRIBUTE syn_black_box OF ?module? : COMPONENT IS TRUE; > > ...inside VHDL top-level. > > What do you recommend when I want to instantiate a Verilog module in VHDL module? > Is it not the only way to synthesize Verilog module and create a VHDL black-box "wrapper" > to "cheat" the Synplify? > > Synplify still gives warnings that black-box pins are unused. > > Environment is Sun Solaris 2.6, Synplify v6.2, target is Xilinx XCV2000E. > > Synplify support is in USA, I'm in Europe, so I don't think I'll get support until next day, > therefore I am asking the question to you. > > Utku -- Ken McElvain, CTO Synplicity Inc. (408)215-6060Article: 31306
S.JULHES <sjulhes@free.fr> wrote in message news:3B02775C.9DCDFD5F@free.fr... > - Is the card fabrication more expensive due to BGA use ( process, > tools, mount, etc .... ) I have used BGAs on several designs and found them surprisingly robust, more so than TQFPs or their bretheren. The key is to use an experienced board house that has the proper soldering equipment and importantly an X-ray machine to inspect them with. They're inspected by looking at all four sides to make sure they are down flat on the board. The X-ray machine makes sure there are not solder bridges on internal pins. High pitch gull wing devices are more prone to solder shorts and since the pins are springy, it is easy for one to be pushed up and not really be connected. In contrast, if all four sides of a BGA are down flat, the inner balls will be contacting too. I have not had to resort to JTAG so far for testing.The main downside is that you are limited to assembly houses that have the X-ray machines. Also, a skilled technician with a needle tip iron can theoretically swap a TQFP, but you need the special machinery to swap a BGA. Some board houses will claim they can do BGAs without the X-ray machine, but I wouldn't trust them. The other downside of BGAs is that you can't easily have components on the back of the board under the BGA because the breakout vias for the internal pins form a thru hole grid like a pin grid array. JeffArticle: 31307
Guys, thanks a lot for responding!
Actually I am working on a USB transceiver that uses a 4x DPLL for clock
and data recovery.
The DPLL is available as a reference design at the following link
http://www.usb.org/developers/data/siewp.pdf
I wanted to know how to go about designing such a DPLL.
Regards,
Amey Hegde
Charles Gardiner <charles.gardiner@mchr2.siemens.de> wrote in message
news:3B03C9CD.308C7AF7@mchr2.siemens.de...
Hi,
for an asynchronous data stream, oversampling at a factor of 4 or even 8
is probably not enough. If you look at any data-sheets, such as the
Infineon C166 Architecture, you will usually find that the over-sample
rate for an asynchronous interface is usually 16. The best value to
chose is dependent on your frame size. The idea is that you start
sampling in the middle of a bit-window and the oversampling should be
high enough so that the sample time is still within the bit-window at
the end of the frame, allowing for clock drift between the nominal
interface speed and your internal clock speed. You can of course
re-adjust at each edge in the data stream. Many telco applications
actually use an oversample rate of 40 or more.
An example (in VHDL) of serial channels (rcv/xmit) suitable for a UART
can be found at our page
http://www.eda-services.de/SiSoCKit/index.html
The steps involved are:
1) Synchronise the incoming signal
2) Take three consecutive synchronised samples and do a two-out-of-three
election to determine stable value (glitch suppression)
3) When the start condition is recognised (e.g. falling edge for UART
interface) start your deframer-FSM.
Hope this helps.
Best regards,
Mit freundlichen Grüßen,
Charles Gardiner
-------------------------------------------------------------
Charles Gardiner, B.E.
Program Manager, Silicon IP
Siemens AG
Dept: I&S IT PS 8 Mch
Otto-Hahn-Ring 6
D-81730 Muenchen
Email: mailto:charles.gardiner@mchr2.siemens.de
Phone: Office +49 89/636 42969, Mobile (0)171/867 2732
Fax : Office +49 89/636 44595
Homepage : http://eda-services.atd.siemens.de/gardiner
(Siemens Intranet only)
I&S Homepage: http://www.atd.siemens.de/it-dl/eda
Siemens I&S - Munich's ARM approved Design Centre
Article: 31308hay i want to write a bitstream into the eeprom wich is connected to a fpga via jtag. i want to generate the jtag signals does anybody have a core for this or do you have other solutions thanx a lot mikeArticle: 31309
Thankyou for taking an interest in my problem. I have now developed my design further - and it seems to fit with the full 'memory' array using the default process options. I still have my code which would not fit, so I've tried those suggestions on it - I set the Pterm limit to 16, Input limit to 16 and block input limit to 38, the design still wouldn't fit. I have recieved an email from Jennifer Jenkins, an Applications Engineer at Xilinx, who I have now sent my code to look at. I also copied it to you Mark. Alan Mark Ng wrote: > > Hello Alan, > > Since I do not have your design file, I cannot tell you exactly why your design > is not fitting. > But, by looking at the fitter report you attached, it seems as though you are > using a decent amount of P-terms and registers. I would guess that your design > is not fitting because of fan-in limitations. A certain node/equation probably > requires a bunch of P-terms. However, we can tweak this -- > > By default , the WebPack software does not allow the user to utilize all > available resources. This gives the designer some fan-in to spare, should he > need it later. i.e. It allows the designer to add more logic late in the game > without going having to go to a higher density part. > > With that said, I would suggest that you try changing your design implementation > options to: > > Collapsing Pterm Limit = 16 (default 28) > Collapsing Input Limit = 16 (default 32) > Block Input Limit = 38 (default 36) > > (Just in case, you can acces these options by right clicking on Implmentation, > then left clicking on Properties. Then go to the Optimization tab.) > > Try those options, and let me know how they work. If it still doesn't work, I > would be happy to look into it further. > > Regards, > > Mark > > Alan Glynne Jones wrote: > > > I'm using the XCR3256XL from the Coolrunner XPLA3 family. One of the > > features of this family is that it should be 100% routable. I'm using > > WebPack Project Navigator with the WebPack XPLA fitter to implement my > > design. In order to test parts of my design I have defined an array of > > 8, 8 bit wide standard logic vectors to act as memory locations. When I > > try to implement this design I get the messages below. > > > > Parsing... > > > > Parsing file test_epp_int.blx ... > > > > Synthesizing and Optimizing... > > > > Fitting... > > > WARNING 6342 Cannot assign signal 'led4' to pin/node '140=FB9_15'. > > > WARNING 6342 Cannot assign signal 'led4' to pin/node '140=FB9_15'. > > > WARNING 6342 Cannot assign signal 'led4' to pin/node '140=FB9_15'. > > > Cannot preassign signals. > > > ERROR 4060 Cannot fit the design into the chip. You may want to try > > a larger device or split the design into sub-designs. > > > > %% ERROR count: 1 WARNING count: 3 > > > > By setting the Use Design Location Constraints option to "try" the > > implementation process will complete successfully but is unable to > > assign the above signals to the required pins, it generates the resource > > summery below. > > > > $DEVICES XCR3256XL-10TQ144 fit (9 sec) > > > > --------------------------------------------------- > > | Total Device Resource Summary | > > --------------------------------------------------- > > | RESOURCE AVAIL. USED UTILIZATION | > > --------------------------------------------------- > > | Clock Inputs 4 1 25.00% | > > | Global C-Terms 4 3 75.00% | > > | Func Blocks 16 10 62.50% | > > | I/O Pins 116 29 25.00% | > > | Macro Cells 256 139 54.30% | > > | PLA P-Terms 768 322 41.93% | > > | PLA S-Terms 256 137 53.52% | > > | Block C-Terms 128 14 10.94% | > > | Fbk Nands 0 0 0.00% | > > --------------------------------------------------- > > > > If I halve the size of my 'memory' array it passes through the > > implementation process successfully, I assume this means that the fitter > > tool is unable to utilise the 100% routable feature of the taget. > > > > My question is, can I get around this? I have tried fiddling with the > > process options for systhesis and implementation but have had no luck. > > > > AlanArticle: 31310
Ken McElvain wrote: > If you are using Synplify-Pro then you can just include both the > VHDL and Verilog files in your project and let Synplify sort > it out. No black boxes in this flow. Yes! I hadn't been using Synplify Pro but Synplify. Now mixed-HDL synthesis is w/o any problem. > What will probably work if you are doing separate compilation > is to just use a component declaration, with no entity or architecture > for the Verilog design being instantiated. The component should > automatically turn into a black box when it doesn't find a binding. > > I suspect that the unused inputs message happened because of > the empty architecture. Yes, ARCHITECTURE was empty. That's what it is done in Verilog? When instantiating a black box in Verilog, normally we use either an empty module with port declarations or translate_on/translate_off statements. I thought I could as well done that method in VHDL. Thank you very much for your contribution. UtkuArticle: 31311
Hi to all ! I would like to announce, that there is PCI IP Core specification, Rev 0.2 AVAILABLE on OpenCores web: http://www.opencores.org/cores/pci/ This web page is also updated with TO DO list for PCI core. Anyone interested can subscribe to PCI mailing list and is welcome to comment, contribute and also to DOWNLOAD. Regards, Tadej.Article: 31312
Hello, I'm using a Xilinx PCI core (33Mhz, 32bits) in a Spartan 200 FPGA on a specific PCI board. When i am using this board in "old" computers (Pentium 200MMX for example), everything works correctly: The computer detects the board and maps its memory and I/O as asked in the macro (256 bytes of I/O and 512Kb of memory). But when i'm trying to use the board in recent computers (Pentium III), i have some problems: first some computers cannot boot. If i change the amount of I/O (256 -> 64 bytes), then the computer can boot, the I/O are mapped but the memory is not mapped. I'm wondering if the problem comes from the computer (Bios an PnP) or if it comes from the Xilinx PCI core: May be this core is not supported by recent PCI chipset used in recent computers. Regards. -- Sent by dugas.alain from freesbee piece of fr This is a spam protected message. Please answer with reference header. Posted via http://www.usenet-replayer.com/cgi/content/newArticle: 31313
Thanks All for the info posted here. I finally have Verilog documentation and a Verilog simulator running on Windows 2000. I'm going through the Verilog manual now and when I'm done with that start looking for an FPGA development kit to experiment with. "Tony Burch" <tony@BurchED.com.au> wrote in message news:3b03d167@news1.idx.com.au... > Dave, > > For a low cost (< US$120) FPGA board with a 200K gate ( ! ) > Xilinx Spartan II device, you may wish to consider > the B3-SPARTAN2+ board from Burch Electronic Designs. > http://www.burched.com.au/bedspartan2.html > We also have various plug-on modules that you > can use to expand the board with resources such > as SRAM, PC-connectors, 7 segment displays, > dip-switches, etc. > Importantly, it works with the free Xilinx WebPACK > software (Verilog and VHDL entry supported), which > you can download from the Xilinx website. > > Best regards > Tony Burch > http://www.BurchED.com.au > Lowest cost, easiest-to-use > FPGA prototyping kits! > > "Dave Feustel" <dfeustel@mindspring.com> wrote in message > news:9dm31v$vek$1@nntp9.atl.mindspring.net... > > I am a longtime system sw programmer with some hardware experience and > > an armchair background in computer architecture suddenly very interested > > in FPGAs. I would like to program a couple of virtual machines > (implemented > > in C) into FPGAs on a commercially produced FPGA development board and > > then play with those VMs under Windows 2000. I've pretty much settled on > > Xilinx parts and Verilog as the implementation language but I have no > FPGA hw/sw > > tools yet. What is the best way to get started along this path? > > > > Thanks, > > > > Dave Feustel > > > > > > > > > >Article: 31314
Richard, Thanks for the info. I'm interested in implementing the virtual machines for Icon, Unicon, and Snobol4. I'm interested too in your Java VM. I'm checking out your website right now. "Richard Meester" <rme@quest-innovations.com> wrote in message news:3B03909E.3118D2D6@quest-innovations.com... > Dave, > > What kind of Virtual Machines are you going to implement? Java? we have an FPGA board > available for prototyping, and next come out with an add-on board with SRAM and > flash. We use a JEMcore java processor which runs on the FPGA. > > Check out our site, we will have a new product anouncement in 1/2 weeks, with the > sram/flash boards, and will setup a kit which can be bought that includes both the > FPGA board as well as the sram board. The sram board also has an ethernet interface > on board which can be used from the fpga. > > Richard > > Dave Feustel wrote: > > > I am a longtime system sw programmer with some hardware experience and > > an armchair background in computer architecture suddenly very interested > > in FPGAs. I would like to program a couple of virtual machines (implemented > > in C) into FPGAs on a commercially produced FPGA development board and > > then play with those VMs under Windows 2000. I've pretty much settled on > > Xilinx parts and Verilog as the implementation language but I have no FPGA hw/sw > > tools yet. What is the best way to get started along this path? > > > > Thanks, > > > > Dave Feustel > > -- > Quest Innovations > tel: +31 (0) 227 604046 > http://www.quest-innovations.com > >Article: 31315
Rick Filipkiewicz <rick@algor.co.uk> wrote in <3B045925.4802DAFC@algor.co.uk>: > > >As a matter of curiosity why don't you like the coding style where the >outputs are defined within the case ? Its my standard - Verilog - style >so I'm interested in arguments against. > I don't like assigning output signals in the FSM case contruct because it makes the FSM a huge chunk of code that become progressively harder to maintain as more states are added. Furthermore, I think the sole purpose of the FSM case construct is to simple define the state transitions. It is more readible if outputs are assigned in their own process. My opinion. Tom KaminskiArticle: 31316
An advantage of the mixed language Synplify-Pro flow is that budgeting and optimization happens on the cross language paths. Separate compilation gets in the way of good results. Utku Ozcan wrote: > > Ken McElvain wrote: > > ? If you are using Synplify-Pro then you can just include both the > ? VHDL and Verilog files in your project and let Synplify sort > ? it out. No black boxes in this flow. > > Yes! I hadn't been using Synplify Pro but Synplify. Now mixed-HDL synthesis > is w/o any problem. > > ? What will probably work if you are doing separate compilation > ? is to just use a component declaration, with no entity or architecture > ? for the Verilog design being instantiated. The component should > ? automatically turn into a black box when it doesn't find a binding. > ? > ? I suspect that the unused inputs message happened because of > ? the empty architecture. > > Yes, ARCHITECTURE was empty. That's what it is done in Verilog? > When instantiating a black box in Verilog, normally we use either an empty > module with port declarations or translate_on/translate_off statements. > I thought I could as well done that method in VHDL. > > Thank you very much for your contribution. > > Utku -- KenArticle: 31317
Tom Kaminski wrote:
>
> Rick Filipkiewicz <rick@algor.co.uk> wrote in
> <3B045925.4802DAFC@algor.co.uk>:
>
> >
> >
> >As a matter of curiosity why don't you like the coding style where the
> >outputs are defined within the case ? Its my standard - Verilog - style
> >so I'm interested in arguments against.
> >
>
> I don't like assigning output signals in the FSM case contruct because it
> makes the FSM a huge chunk of code that become progressively harder to
> maintain as more states are added. Furthermore, I think the sole purpose
> of the FSM case construct is to simple define the state transitions. It is
> more readible if outputs are assigned in their own process.
>
> My opinion.
>
> Tom Kaminski
I agree about the readability. And while I also agree that what you had
SHOULD work, it doesn't seem to with FPGA express. But this does, and
keeps the FSM case construct separate, at the price of a lot of extra
typing:
state_actions: process(fsm_state, some_input, another_input) is
begin
some_output <= '0';
case fsm_state is
when fsm_2_state =>
if ( some_input = '1' or another_input = '1') then
some_output <= '1';
end if;
when others =>
null;
end case;
end process;
Article: 31318
---------------------------------------------------------------------
MICRO-34 Call for Papers
The 34th International Symposium on Microarchitecture
Austin, Texas, Dec. 1-5 2001
---------------------------------------------------------------------
IMPORTANT DEADLINES:
Paper submission: June 15, 2001
One-week extension June 22 (Midnight EST, USA), 2001
Workshop/Tutorial Proposals: June 15, 2001
Author Notification: August 13, 2001
The MICRO-34 organizing committee is pleased to announce that MICRO-34
will take place in Austin, Texas. MICRO continues to be the premier
technical forum for microarchitecture. It is well attended by both
academics and industry people whose expertise is in the design,
understanding, and tradeoffs of microprocessors. Austin is unique: a
focal point of high tech industry, a world-class university, and a
cultural center known for its live music, diversity, and
restaurants. Austin provides a spectacular and enjoyable location for
Micro-34. Plan to enjoy a profound technical program, but also this
unique location.
The International Symposium on Microarchitecture continues to be the
premier technical forum for presenting the latest developments in
microarchitecture research. The 34th Microarchitecture (MICRO-34)
Symposium will be held in Austin, Texas from Dec. 1 to Dec. 5, 2001.
Authors are invited to submit full papers on microarchitecture
research and related topics.
Areas of interest include:
* ILP architectures and designs: Superscalar, VLIW, EPIC
* Compiler techniques for instruction-level parallelism
* Multithreaded processors and compilation
* Architectures and compilers for embedded processors
(imaging, graphics, speech recognition, low power, etc.)
* Dynamic optimization, emulation, and code translation
* Advanced software and hardware speculation and prediction
* Hardware/compiler techniques for improving memory performance
* Hardware/software techniques for efficient SOC designs
* Hardware/software techniques for fine-grain parallel processing
You will find all information related to the conference at the
official MICRO-34 web site:
http://www.microarch.org/micro34
SUBMISSION INFORMATION:
Please check the Micro-34 web site for upcoming paper submission
procedures. Paper submissions should not exceed 6,000 words. Papers
that exceed the length limit may not be reviewed. The official
submission receipt deadline is June 15, 2001. An automatic extension
of one week, until June 22, 2001 (Midnight EST, USA) will be given
without request. However, no further extensions will be given. Papers
may be submitted for blind review at the option of the authors. Please
indicate whether the paper is a student paper for best student paper
nominations.
WORKSHOP INFORMATION:
The MICRO-34 symposium is currently taking Workshop/Tutorial
proposals. Information on workshop/tutorial proposals can be found at
the Micro-34 web site:
http://www.microarch.org/micro34/Workshops/
MICRO-34 Call For Workshop/Tutorial Proposals
Dec 1-2, 2001, Austin, TX
--------------------------------------------
Due the popularity and success of the workshops/tutorials at last
years MICRO, this year at MICRO-34 we are planning to expand from 1
day to 2 days of pre-conference workshops and tutorials. They will
take place in Austin, TX on Saturday and Sunday, Dec 1 and 2, 2001
before the main conference on Dec 3-5, 2001.
Last year, there were 4 workshops and 1 tutorial:
o 3rd ACM Workshop on Feedback Directed and Dynamic Optimization
o 2nd Workshop on Media Processors and DSPs
o Workshop on Multithreaded Execution, Architecture and Compilation
o Kool Chips Workshop
o Tutorial on Dynamic Binary Translation and Optimization
With the expansion to 2 days, we invite proposals from those
interested in organizing a new tutorial or workshop to be held in
conjunction with the conference. They may be either a half day or a
full day. The range of interesting topics includes most areas of
computer architecture, microarchitecture, and compilers, but use the
MICRO-34 call for papers as a rough guide. While we are especially
interested in complementing the existing workshops with new tutorials
of interest to the MICRO community, we will also consider proposals
for new workshops.
Those who are interested in submitting a proposal, please send email
to the workshop/tutorial chair (Scott Mahlke, mahlke@hpl.hp.com). The
proposal should include:
o Title
o Short description or abstract
o List of organizers
o Contact name, email address, and telephone number
o Preferred length (half or full day)
Submission deadline is June 15, 2001. Note that there is a limited
amount of time/space and we hope to devise a broad program of interest
to the MICRO community, so the number of accepted proposals will
depend on these issues.
GENERAL INFORMATION:
GENERAL CHAIR
Yale Patt, University of Texas at Austin
PROGRAM CHAIRS
Josh Fisher, HP Labs
Paolo Faraboschi, HP Labs
WORKSHOP CHAIR
Scott Mahlke, HP Labs
LOCAL ARRANGEMENTS
Steve Keckler, University of Texas at Austin
PUBLICITY CHAIR
Dan Connors, University of Colorado
PUBLICATION CHAIR
Kevin Skadron, University of Virginia
STEERING COMMITTEE
Richard Belgard, Consultant, Chairman
Tom Conte, NC State
Kemal Ebcioglu, IBM
Matt Farrens, UC-Davis
Wen-mei Hwu, University of Illinois
Yale Patt, University of Texas at Austin
Ronny Ronen, Intel
Mike Schlansker, HP Labs
Andy Wolfe, SONICblue
PROGRAM COMMITTEE CHAIR
Saman Amarasinghe, MIT
Krste Asanovic, MIT
David Bernstein, IBM Israel
Geoff Brown, Ironbridge
Francky Catthoor, IMEC
Bob Colwell, Intel
Tom Conte, NCSU
Henk Corporaal, TU Delft
Kemal Ebcioglu, IBM
Antonio Gonzalez, UPC
Jim Goodman, U.Wisconsin/Intel
Thomas Gross, ETH
Rajiv Gupta, University of Arizona
Wen-Mei Hwu, University of Illinois
David Kaeli, Northeastern
Steve Keckler, University of Texas at Austin
Geoff Lowney, Compaq
Bill Mangione-Smith, UCLA
Hans Mulder, Intel
Walid Najjar, UC at Riverside
CJ Newburn, Intel
Bob Rau, HP Labs
Andre Seznec, IRISA/INRIA
Carol Thompson, HP
Nigel Topham, Siroyan
Mateo Valero, UPC
Andy Wolfe, SONICblue
Donald Yeung, Univeristy of Maryland
Cliff Young, Lucent Bell Labs
Thank you for your time in reading this message. I apologize in
advance for any repeated mailings. If you wish to be removed from the
MICRO-34 email list, please email me with the address or addresses you
wish removed from the list.
Dan Connors
Micro-34 Publicity Chair
University of Colorado, Boulder, CO
dconnors@colorado.edu
Article: 31319
Technical Assistance Bureau, Inc
11469 Olive Boulevard, Suite 108 St. Louis, MO 63141
Division of Resource Development
Toll Free Voice:888-547-5124 Toll Free Fax: 888-738-4539 URL:
http://www.tabexperts.com email: joegentile@tabexperts.com
MEMORANDUM FROM JOSEPH GENTILE
RE: Altera v. Xilinx
We are a professional services corporation providing consulting services to
lawyers and insurance companies when technical expertise is required to
resolve matters in litigation.
We have a client/lawyer in San Francisco who represents Altera in a patent
infringement case against Xilink, who needs someone with a background in
programmable logic array chip design (architecture not fabrication) relating
to the inclusion of RAM memory. to consult and hopefully serve as an expert
witness someday on behalf of Altera.
The following patents are involved:
US Patent # 5260610
Programmable logic element interconnections for programmable logic array
integrated circuits
Abstract
A programmable logic array integrated circuit has a plurality of
programmable logic elements grouped into a plurality of mutually exclusive
groups. Each group includes signal conductors uniquely associated with that
group for conveying signals between the programmable logic elements in that
group. Other signal conductors are provided for conveying signals between
the groups. Multiplexers can be used in various ways to reduce the number of
programmable interconnections required between signal conductors.
US Patent # 5970255
System for coupling programmable logic device to external circuitry which
selects a logic standard and uses buffers to modify output and input signals
accordingly
Abstract
A programmable input/output device for use with a programmable logic device
(PLD) is presented comprising an input buffer, an output buffer and
programmable elements. The programmable elements may be programmed to select
a logic standard for the input/output device to operate at. For instance, a
given set of Select Bits applied to the programmable elements may select TTL
logic, in which case the input and output buffers would operate according to
the voltage levels appropriate for TTL logic (e.g., 0.4 volts to 2.4 volts).
For a different set of Select Bits, the GTL logic standard would be applied
(e.g., 0.8 volts to 1.2 volts). The invention enables a single PLD to be
used in conjunction with various types of external circuitry.
If you are interested in this matter, we would like to have a copy of your
resume and fee schedule for consultation, investigation, travel, deposition
and trial appearance which you may submit either as an email attachment in
any format or via fax transmission.
Upon receipt, we will arrange for a telephone conference with our client,
so that you will be able to get complete details and decide if you want to
proceed further, and if you do, we will then secure and pay you an
appropriate sum of money for you to do the initial necessary work.
It should also be noted that Technical Assistance Bureau is a
commercial enterprise, and in order to provide for our overhead and profit,
we will markup the fees you charge us. The exact markup we will charge to
our clients will be submitted to you for your approval, in another memo
which will follow immediately upon receipt of your fee schedule.
In the event you are not available, a referral to a colleague would be most
appreciated.
Article: 31320
Jeff Cunningham wrote:
>
> I'm a user of ModelSim PE/VHDL. For financial reasons beyond my control I am
> being asked to consider switching to modelsim XE. I recall seeing somewhere
> that XE is literally just a slowed down version of PE (something like 3x or
> 5x).
I think so. Why not download an eval and run it on your own code.
-Mike Treseler
Article: 31321I notice the address is overseas from U.S. International money orders are expensive. What other forms of payment are accepted? Thanks. "Jamil Khatib" <khatib@ieee.org> wrote in message news:3B0586B9.D742BB40@ieee.org... > If you are looking for more than 150 open source free electronics > design tool or more than 70 open source hardware design check the > OpenTech cdom at > www.opencores.org/OIPC/projects/OpenTech/ > > OpenTech package includes several open source EDA tools from most of > electronics fields. It has lot of Open Source hardware designs range > from simple HDL examples and up to CPUs and boards > > The OpenTech is a project of www.OpenCores.org > > For more information visit our site > www.opencores.org/OIPC/projects/OpenTech/ > >Article: 31322
If you are looking for more than 150 open source free electronics design tool or more than 70 open source hardware design check the OpenTech cdom at www.opencores.org/OIPC/projects/OpenTech/ OpenTech package includes several open source EDA tools from most of electronics fields. It has lot of Open Source hardware designs range from simple HDL examples and up to CPUs and boards The OpenTech is a project of www.OpenCores.org For more information visit our site www.opencores.org/OIPC/projects/OpenTech/Article: 31323
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3B045925.4802DAFC@algor.co.uk...
> Tom Kaminski wrote:
> >
> > [....deleted....] A workaround is to
> > assign the signals within the FSM case statement. However, I don't like
> > this coding style so I'm not gonna use it.
>
> As a matter of curiosity why don't you like the coding style where the
> outputs are defined within the case ? Its my standard - Verilog - style
> so I'm interested in arguments against.
Sometimes the optimum encoding style is not known at the time the initial
piece of code is written. In FPGAs there are actually still some occasions
where one-hot encoding is not the optimum choice... In instances where one
needs to have a fully decoded state machine (where all invalid states
auto-magically take the machine back into a legal state), whether or not
one-hot coding, binary or some hybrid of the two will be most resource
efficient, or meet even performance goals, is not always clear at the
outset.
One might think that this is an "academic" answer, without practical
application. If designing a system that is more tolerant of radiation, i.e.
space based applications, protecting aginst a state-machine going off into
an illegal state is important. In an application where it just isn't
possible to have a reset signal one needs to fully decode the state machine.
The other reasons that I don't assign signals in the FSM case statements:
Easier to read
Easier to add and delete states
For all but the occasional special cases, a single default encoding
style (one-hot) will do.
My synthesis tool will encode the machine as I tell it to (and it will
actually do what I tell it)
The significance of the last statement is:
If the tool (in this case Synplicity) will do exactly what I want it to
(and I have verified this to my satisfaction) by merely specifing the
encoding style, why should I go out of my way to tell the tool exactly how
to code it signal by signal?
Some answers to that question:
Explicitly calling out the FSM states and signals make it much easier to
find signals when using embedded logic analyzers, doing post synthesis
simulation or static timing analysis and the like... it is much easier to
find something when you know exactly what it is called at all stages of the
game. It is in the late stages of the game, that having the signals named
in an easy to decode fashion, is most helpful.
Secondly, it is occcasionally useful to use a hybrid coding scheme that
is somewhere between one-hot and binary, and the synthesis tools, smart as
they are, don't yet recognize these opportunities that often.
Regards,
Erik Widding.
--
Birger Engineering, Inc. -------------------------------- 781.481.9233
38 Montvale Ave #260; Stoneham, MA 02180 ------- http://www.birger.com
Article: 31324Hi there! Anyone can point me to a good and sufficient tutorial (in the internet) in the FPGA to start with it from zero to the top (basics, design,.. etc)?
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