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 Fri, 18 Sep 1998 17:56:49 +0100, Jonathan Bromley <jsebromley@brookes.ac.uk> wrote: >As a follow-up, I would be extremely intrigued to hear views >from experienced designers and employers about how successfully >the universities provide (or not!) the right skill-set in >fresh-from-college EE graduates. Very good point. In the last 15 years, I don't think that I have *ever* met an EE (or any other) graduate who would be remotely useful as a paid engineer in any company that I've worked for (however, I have met a few recent science or maths graduates who were very good softies). I don't think the problem has been education, but simply intelligence and experience (or lack of them). You need much more experience to be a good engineer than to be a good programmer. And education isn't that important - one of the best engineers I know doesn't even have a degree. But, while we're on the subject of what you should actually teach an undergraduate, I've noticed that a lot of courses now involve something along the lines of learning some VHDL, learning some tools, and doing a design in an FPGA. This is a complete waste of time, and is rather like teaching an author to use a typewriter - the skill isn't in how you type, but what you type. I don't need a graduate who knows how to drive Foundation/Max Plus/whatever - the tools will be completely different in a couple of years. You might as well just teach them Word for Windoze. What *would* be useful, however, is a graduate who knows how to get a clock from one end of a PCB to another, who knows how to build a state machine (clocked or otherwise) using only a pencil and paper, and who can do some basic design with 7400-series logic. But, of course, you don't need to spend three years learning this - I did most of the basics in a few weeks while doing a Physics degree. EvanArticle: 11926
In article <6tumal$62u@src-news.pa.dec.com>, Stefan Ludwig <ludwig@pa.dec.com> writes >You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles >and are just wonderful. Micron, Motorola and IDT make them. > Interfacing to ZBT rams using Xilinx 4000 series FPGA's is complicated by possible data bus contention when changing from a write to a read cycle. The Xilinx tristates the data bus much later (clock to hi-Z) about 10 ns) than the ram drives the bus (clock to lo-Z about 2 ns). The Micron web-site has articles about this, and the implications on increased power-dissipation. In the new 4000XLA devices, the IOB's have a registered tri-state, which helps a lot. NB, Cypress make almost pin-compatible versions called NOBL (NO Bus Latency), and i think also ISSI. -- Edward MooreArticle: 11927
Rickman, The APS-X84 manual which is available on line at our website, has information, and C code examples for doing this. Our website is http://www.associatedpro.com. The code is loading the FPGA from the ISA BUS but it should be the same process. Hope this helps. Rickman wrote: > I remember there being some posts on info from the Xilinx web site on > the configuration process. Can someone repost where I can find that > data. I have searched using their search tool and can't find what I am > looking for. All I can find is the section out of the data book on > configuration. I thought there was an app note on downloading from a uC. > > I need to put together a clear enough description that the software > developer can code it. That can be quite a job sometimes. ;) > > -- > > Rick Collins > > redsp@XYusa.net > > remove the XY to email me. > -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11928
All of the one's you mentioned are good tools. You might also look at Accolade's PeakVHDL suite. It can handle all the vendors you mentioned and is a very good buy. I have used all the vendors you have mentioned. We sell Accolade and the XILINX Foundation Series (FPGA Express). We also sell FPGA Test Boards which are very helpful for algorithm development and overall testing. Simulation is great, but you can't beat actuals. As far as ASICs, if that is going to be a major emphasis, you may want to look at the Exemplar stuff again. One of their main strong points is ASIC retargeting. The Accolade suite is nice, in that it includes a VHDL simulator. MINC, also uses Accolades VHDL simulator. Accolade is the small guy on the block, but they have some really nice features. The simulator and synthesis tool are integrated, and the price their entire suite is usually about the price of a one VENDOR synthesis (with no simulator) from the other guys. Exemplar, Synplicity, and Synopsys FPGA Express are all priced very close to each other. They are a bit pricier but you will happy with them. Synopsys didn't have VHDL 93 support, but they do now. Anyway our website is at http://www.associatedpro.com You can get a free Accolade software download there. Also if you are just starting in FPGAs and are sticking with just one vendor, you can't beat the XILINX Foundation kits, The VHDL and VERILOG synthesis and ROUTER tools, VHDL editor and VHDL tutorial are all packaged together. And through APS you also get an FPGA test board with priceless app notes. Our prices on the Foundation kits are usually lower than you can get elsewhere, and you can only get the FPGA board from us. Anyway, hope all this helps. Contact me if I can be of further help. Ronald Hakola wrote: > Our company is just starting to think in terms of VHDL. My task is to > decide which tools we will be using. Have looked at Exemplar Leonardo > Spectrum and Synplicity's Synplify for synthesizing. Aldec's VHDL simulator > and Model Sim. for simulators. Also planning on looking at Minc and FPGA > Express. Any other suggestions?? Any comments on the quality of these > programs from the users. Design goal is FPGAs: Xilinx, Orca, and Actel for > a start, possibly ASICs in the future. > > Thanks for all comments. > -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11929
When I last looked at the ZBT's for an application where I had interleaved read writes there was an issue on the timing. I don't recall for sure, but I think there was a dead cycle caused by the way I needed to access it. I'll look into my notes and let you know what the issue was. Whatever it was, in that particular case it was an expensive solution that didn't quite fix the problem. (I was looking at the IDT parts, and that was right after they were introduced). Stefan Ludwig wrote: > You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles > and are just wonderful. Micron, Motorola and IDT make them. > > Stefan -- -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: 11930
In article <3602DEA7.1C47@dial.pipex.com>,
Mark Purcell <map@dial.pipex.com> wrote:
>What about SRAM based FPGAs causing glitches? For example, a classic
>combinatorial feedback loop like the following:
>OUT = START | HOLD & OUT;
>may not work due to the gates themselves being implemented using SRAM
>lookup tables. The output may glitch or even fail to latch at all (to
>see this think what happens when the logic latches - once latched it
>should be invariant to transitions on START, but since it's an SRAM
>there is a settling time when OUT will be invalid as the new 'address'
>is looked up. This invalid state is fed back causing more invalid
>states). Also using gray coded signals and ORing them to form glitch
>free outputs can also cause problems. SRAM based FPGAs such as Xilinx
>4000 type devices should be avoided if the design contains any
>combinatorial logic that is to remain glitch free (this goes for clock
>domain resynchronizing too if gray coded FIFO flags are decoded and used
>for resynchronization).
This is not true. The SRAM in all SRAM-based FPGAs is not used in the way
that you think. I.E., logic block inputs are not the same as conventional
glitchy SRAM address line decoders. Instead they are the select lines for
something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a
4-input logic block. The 16:1-MUX inputs are connected to the configuration
SRAM bits. The result is that a single input transition on a select line is
guarenteed to generate either a single glitch-free output transistion or a
glitch-free non-transition. The actual circuit used is balanced (probably
with different buffer sizes driving each level of 2:1 MUX or something) and
tries to give roughly equal propogation delay for each select line.
Combinatorial latches like your example work just fine. They are generally
not used because the built-in flip-flops are faster and not subject to
routing delays. However, they are sometimes useful because the global reset
line does not effect them. You can use this trick to distinguish between
warm or cold boot, for example.
--
/* 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: 11931Joseph H Allen wrote: > > In article <3602DEA7.1C47@dial.pipex.com>, > Mark Purcell <map@dial.pipex.com> wrote: > > >What about SRAM based FPGAs causing glitches? For example, a classic > >combinatorial feedback loop like the following: > > >OUT = START | HOLD & OUT; > > >may not work due to the gates themselves being implemented using SRAM > >lookup tables. The output may glitch or even fail to latch at all (to > >see this think what happens when the logic latches - once latched it ...snip... > This is not true. The SRAM in all SRAM-based FPGAs is not used in the way > that you think. I.E., logic block inputs are not the same as conventional > glitchy SRAM address line decoders. Instead they are the select lines for > something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a > 4-input logic block. The 16:1-MUX inputs are connected to the configuration > SRAM bits. The result is that a single input transition on a select line is > guarenteed to generate either a single glitch-free output transistion or a > glitch-free non-transition. The actual circuit used is balanced (probably > with different buffer sizes driving each level of 2:1 MUX or something) and > tries to give roughly equal propogation delay for each select line. > > Combinatorial latches like your example work just fine. They are generally > not used because the built-in flip-flops are faster and not subject to > routing delays. However, they are sometimes useful because the global reset > line does not effect them. You can use this trick to distinguish between > warm or cold boot, for example. I have heard this from somewhere else, I believe, but are you sure that there are no glitches? In general, a mux is not guaranteed to be glitch free when a single select line changes. A mux is just a collection of AND gates followed by an OR gate. Only one of the AND gates will have all of its inputs true at any given time. As one select line changes, the currently selected AND gate is deselected and the next AND gate is selected. If there is any difference in prop delay for the two paths, there can be a glitch on the output. You (Xilinx) might be able to prevent a glitch by making one edge faster than the other. Your (Xilinx's) mux could be constructed with a buffer and an inverter from each select input feeding all of the AND gates. The prop delay of the buffer and the inverter should match closely. The delay for the rising edge to the AND gate should be less than the delay for the falling edge by more than the tolerance of the delays. Then you could always guarantee that one AND gate is enabled before the other was disabled. This would provide glitch free operation. Or it could be possible to make the prop delays match closely enough that a slow output on the OR gate would act as a glitch filter. But this may not be desirable. Someone (I don't remember his name) who works for (used to work for) Xilinx has posted about some internal design issues before. That was on the reasons behind the limitations on the dual ported ram. Perhaps he could answer this one??? Or maybe Peter A.??? -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11932
ems@nospam.riverside-machines.com wrote: ...snip... > But, while we're on the subject of what you should actually teach an > undergraduate, I've noticed that a lot of courses now involve > something along the lines of learning some VHDL, learning some tools, > and doing a design in an FPGA. This is a complete waste of time, and > is rather like teaching an author to use a typewriter - the skill > isn't in how you type, but what you type. I don't need a graduate who > knows how to drive Foundation/Max Plus/whatever - the tools will be > completely different in a couple of years. You might as well just > teach them Word for Windoze. What *would* be useful, however, is a > graduate who knows how to get a clock from one end of a PCB to > another, who knows how to build a state machine (clocked or otherwise) > using only a pencil and paper, and who can do some basic design with > 7400-series logic. But, of course, you don't need to spend three years > learning this - I did most of the basics in a few weeks while doing a > Physics degree. > > Evan I agree with much of what you say. I think that a lot of "pratical" skills were left out of my education that I then had to learn OJT. All of the things that you mention would have been useful. But some of them typically are taught. I learned state machine design. Of course it was by means of present state/next state (PS/NS) tables and hand calculations. But state machine design nontheless. I was also taught a lot about general logic design. That was the focus of both my undergraduate as well as my graduate classwork. The graduate work was in multivalued logic design which was really a thinly disguised Math course in Post Algebra. Not much use for that even now. But I feel strongly that students should be taught not just the basics of signal propagation, but should be taught fully what happens when you move signals across a board, across a backplane and even between chassis. I assume that the schools feel that the core classes give you the tools to solve these problems. But the real world is full of unusual problems, practical solutions and just plain suprizes. I do disagree on the usefulness of learning an FPGA development tool. Even if the student did not learn the tool you are using, he is better off to have learned A tool and to have learned the FPGA design process. It is especially useful to have learned the limitations of FPGA design, both in the tools and in the chips. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11933
In article <360490B7.B04231A5@yahoo.com> Rickman <spamgoeshere4@yahoo.com> writes: >Joseph H Allen wrote: >> >> This is not true. The SRAM in all SRAM-based FPGAs is not used in the way >> that you think. I.E., logic block inputs are not the same as conventional >> glitchy SRAM address line decoders. Instead they are the select lines for >> something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a >> 4-input logic block. The 16:1-MUX inputs are connected to the configuration >> SRAM bits. The result is that a single input transition on a select line is >> guarenteed to generate either a single glitch-free output transistion or a >> glitch-free non-transition. The actual circuit used is balanced (probably >> with different buffer sizes driving each level of 2:1 MUX or something) and >> tries to give roughly equal propogation delay for each select line. >> >> Combinatorial latches like your example work just fine. They are generally >> not used because the built-in flip-flops are faster and not subject to >> routing delays. However, they are sometimes useful because the global reset >> line does not effect them. You can use this trick to distinguish between >> warm or cold boot, for example. > >I have heard this from somewhere else, I believe, but are you sure that >there are no glitches? In general, a mux is not guaranteed to be glitch >free when a single select line changes. Joseph is absolutely right about the glitch free nature of the LUTs when a single input changes, and the condition of other inputs makes the change not have any effect on the output. The muxes that follow the LUT are glitch free for single input transitions where the before and after values are the same. More details on how this works in next para. >A mux is just a collection of AND gates followed by an OR gate. Not in a Xilinx FPGA following the LUT memory cells. It is a tree of pass transistors, and the outputs of the LUT bits are static, and have pre-charged the tree up to the FETs that will change when you change a single input signal to the LUT. Since the eqn for before and after the change have the same value ( for the cases where you are worried about the glitch), when the change occurs, you are switching from one copy of the value to another. There is nothing in the area that could swing it to the other value. The change is very fast (probably sub nanosecond in current products). Here are the two scenarios: 1) Turn off is faster than turn on: The parasitic capacitance on the the output node will hold the level till the second fet turns on. There is no static current drawn on this node so there is no motivation for it to change to the other level. The load is either another similar mux, or the high impedance of an inverter. 2) Turn off is slower than turn on: Since both paths have the same value, for a short while (sub nanosecond) both sides of the mux drive the output with the same value. >Only one of the AND gates will have >all of its inputs true at any given time. As one select line changes, >the currently selected AND gate is deselected and the next AND gate is >selected. If there is any difference in prop delay for the two paths, >there can be a glitch on the output. True description of a gate based mux, but not relevant for this case. >You (Xilinx) might be able to prevent a glitch by making one edge faster >than the other. Your (Xilinx's) mux could be constructed with a buffer >and an inverter from each select input feeding all of the AND gates. The >prop delay of the buffer and the inverter should match closely. The >delay for the rising edge to the AND gate should be less than the delay >for the falling edge by more than the tolerance of the delays. Then you >could always guarantee that one AND gate is enabled before the other was >disabled. This would provide glitch free operation. As you can see above, there is a far simpler way to get it to be glitch free. No need for fancy delay matching either. >Or it could be possible to make the prop delays match closely enough >that a slow output on the OR gate would act as a glitch filter. But this >may not be desirable. >Someone (I don't remember his name) who works for (used to work for) >Xilinx has posted about some internal design issues before. That was on >the reasons behind the limitations on the dual ported ram. Perhaps he >could answer this one??? Or maybe Peter A.??? Who could it be ???? All the above information is pubicly available. With some effort, you can actually find out a lot about the detailed internals of these devices, because of the very large number of patents that have been filed by all the FPGA companies. To see the gory details of the above, there are many patents that show the detailed schematics. An example would be 5,566,123, but there are many others. My favorite site for this is http://patent.womplex.ibm.com Philip FreidinArticle: 11934
Matthew Robinson wrote in message <6tpdfh$388$1@supernews.com>... >So am I going crazy or is a -3 Spartan part slower than a -4, whereas in the >4K series, the -3 was the faster part? > >Curiuosly, >Matthew > Matthew, The response that Ed McCauley gave you tells it all. I just wish that Xilinx had stuck with the XL family way of describing speed. I do not care if 09 or 08 means 900 or 800 picoseconds, I can handle that. I think that the time through a 4 variable LUT (or some well established circuit) is a good measure of how fast a design will be, if you know how to use that parameter. Giving an FPGA a meaningless number like the Spartan family has makes it more difficult to determine how fast a design will be. In fact, I always used to tell the Orca guy that they should change their way of gauging a part's speed to the way Xilinx did it! -Simon RamirezArticle: 11935
Philip Freidin wrote: > A major advantage of using this batchfile to process your designs, is that > unlike Xilinx's design manager, it doesn't litter your disk with 10's > (or 100's ) of megabytes of unwanted files in \rev and \ver directories. > I continue to be amazed that Xilinx's design manager goes to so much > effort to maintain all these directories of files for different revisions > and versions of your design, all of which could be recreated from the > original design, but the one thing that it won't manage is the revisions > of the design it-self, which is the only thing that actually needs > revision control. > *****Check the M1.5 Design Manager there is now a a feature to allow copying of extra files i.e. the design files with each new version/revision. Menu Design=>Properties =>Version List. You are right a rev with out a source is useless. But now one can save the source as well. Have FUN!!! Nick > Hope your project goes well. > > Philip Freidin.Article: 11936
Stefan Rave wrote in message <35FFDBFD.41C67EA6@LS12.cs.uni-dortmund.de>... >What is the best choice for use with an XC4000XL FPGA: synchronous or >asynchronous SRAM? What's the advantage of synchronous SRAM, anyway? Stefan, The best choice of SRAM can only be answered by you, because only you know what the application is. You have constraints and parameters that we do not know about; therefore, only you are capable of answering that question. The advantage of synchronous SRAM is that it breaks up the total path of delays into two paths of delay. These two paths have less time associated with them than the longer path used by asynchronous SRAM, which makes the design faster. For example, assume that in your design the FPGA is generating the address and using the data provided by the SRAM during a read cycle. If you are using asynchronous SRAM, you have the clock to address out time (FGPA), then the access time of the SRAM (data valid after address valid), then the setup time of the FPGA to capture the data. If you use a synchronous SRAM, you have the clock to address out time (FPGA) and setup time (SRAM) for the first clock cycle. This path is less than the path described in the above paragraph for the asynchronous SRAM. The second path is clock to data valid out (SRAM) and setup time (FPGA) for the second clock cycle. This path also is less than the path described above. While you can run the clock cycles faster, it takes two clock cycles to get one piece of data out, right? What if you want burst data out of the SRAM? Then it takes three clock cycles to get two pieces of data, four cycles to get three pieces of data, etc. So if you burst 256 pieces of data, you need 257 clock cycles. The advantage of synchronous SRAM is that these clock cycles are much faster than clock cycles of the asynchronous clock cycles. Also, the reason that Bob Perlman thought that you were talking about synchronous SRAMs in FPGAs is because this is an FPGA newsgroup! Fortunately for all of us, Xilinx and others gave us the ability to use internal SRAM, synchronous and asynchronous. So naturally I can see where he assumed that you were talking about internal SRAM. I hope this helps. -Simon RamirezArticle: 11937
The latest revision of David Black's LOGSCAN utility is now available
in the Qualis Library. David's LOGSCAN was a big hit at the
1998 Synopsys User Group (SNUG) meeting. You can download it at:
http://www.qualis.com/cgi-bin/qualis/libObject.pl?object=tr012
For those of you unfamiliary with LOGSCAN, here's an excerpt from
the README file:
-----
A common problem facing most EDA tools users is how to filter through
hundreds of lines of EDA tool output and quickly focus on the important
information. Tools such as Synopsys Design Compiler or Quad Design Motive
Static Timing analyzer produce messages classified as "errors", "warnings",
or "information" in great volumes. Typically, there are simple methods to
suppress one or more of these messages. Unfortunately, suppression often
leads to ignoring important information. On the other hand, reading every
line of a long report is very error prone. Some engineers choose to use
various forms of the UNIX 'grep' utility to solve their problems; however,
it tends to be limited to single line errors. Frequently, multi-lines of
information are necessary to realize there is a problem and understand what
needs fixing. Finally, some errors or lines are expected/required (e.g.
the Thankyou message at the end of a synopsys session).
With the above framework in mind, I developed tools over the years that
address this very issue. The remainder of the paper demonstrates a
successful solution implemented with PERL. The script itself,
independently developed, is made available as charity-ware via the
Internet the EDA community via the Qualis Web site <http://www.qualis.com/>.
-----
Check it out in the Qualis Library for more information about LOGSCAN.
Michael
Qualis Design
http://www.qualis.com/
Article: 11938In part of article <35f8827c.4654371@newshost>, Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> writes >2. Not pin compatible. (more VCC pins, which is a good thing) >I recently translated a design from a 4020E-3 to an XCS40-3. There >were no (VHDL) source code changes needed except for the pin >numbering. Allan, I've got the XCS30 and XC4013 pin-out tables in front of me and for the PQ240 package at least, the VCC and GND pinouts look identical. ie apart from configuration pins, they look pin-compatible. Have I missed something ?. Also, how do you percieve the marketing of the Spartan parts ?. We have almost been discouraged to use them. Less profit margins for Xilinx perhaps ? -- Edward MooreArticle: 11939
Simon Ramirez wrote: > Matthew, > The response that Ed McCauley gave you tells it all. > I just wish that Xilinx had stuck with the XL family way of describing > speed. I do not care if 09 or 08 means 900 or 800 picoseconds, I can handle > that. I think that the time through a 4 variable LUT (or some well > established circuit) is a good measure of how fast a design will be, if you > know how to use that parameter. Giving an FPGA a meaningless number like > the Spartan family has makes it more difficult to determine how fast a > design will be. In fact, I always used to tell the Orca guy that they > should change their way of gauging a part's speed to the way Xilinx did it! > -Simon Ramirez I agree, except that Xilinx wasn't very forward looking with the -09 style. They should have gone to a -900 notation which would have carried them all the way down to 1 ps delays (-001)! i Think that would have held them for a couple of years before they had to change again. ;) -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11940
Philip Freidin wrote: ...snip... > Here are the two scenarios: > 1) Turn off is faster than turn on: The parasitic capacitance on the > the output node will hold the level till the second fet turns on. > There is no static current drawn on this node so there is no motivation > for it to change to the other level. The load is either another > similar mux, or the high impedance of an inverter. > 2) Turn off is slower than turn on: Since both paths have the same value, > for a short while (sub nanosecond) both sides of the mux drive the > output with the same value. For case 1, you will have both glitch free and contention free operation. But in case 2, how do you prevent contention when the two paths have different values? ...snip... > All the above information is pubicly available. With some effort, you can > actually find out a lot about the detailed internals of these devices, > because of the very large number of patents that have been filed by all > the FPGA companies. To see the gory details of the above, there are many > patents that show the detailed schematics. An example would be 5,566,123, > but there are many others. My favorite site for this is Public perhaps. But rather than dig through patents (which may or may not be implemented in a given device), it would be very nice if Xilinx (and others) made answers to questions like this easily available on their web sites. I couldn't find anything after doing a search at Xilinx. Thanks Philip, I knew you would pull through for us! -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11941
On Fri, 18 Sep 1998 15:37:47 -0400, Rickman <spamgoeshere4@yahoo.com> wrote: >I remember there being some posts on info from the Xilinx web site on >the configuration process. Can someone repost where I can find that >data. I have searched using their search tool and can't find what I am >looking for. All I can find is the section out of the data book on >configuration. I thought there was an app note on downloading from a uC. > >I need to put together a clear enough description that the software >developer can code it. That can be quite a job sometimes. ;) I think the doc you're looking for is 'bus_conf.pdf' - you can find it by doing a search on 'processor'. I had the same problem a few months ago, but I found this doc to be too specific to be of any use to a programmer. I ended up just copying out the relevant bits of the databook - :< EvanArticle: 11942
TITLE: Hardware Eng : ASIC/FPGA
REF #: HW-datacom-309-98 ** MUST reside in the US **
LOCATION: MA/TX/VA/MD/IL/AL/WI, other areas available too...call me to find
out more
REQUIREMENTS: 2+ yrs; MULTIPLE POSITIONS (Jr & Sr)
Prior exp with some or all of the following: ATM, SONET, high-performance
microprocessors, distributed control architectures, or large switching
systems.
Various positions in chip level & circuit design. 2+ yrs designing FPGA &
ASICs for high-speed application (60 MHz+). VHDL, synopsis, ViewLogic,
Xilinx, SONET/SDH telecom equipment. Architecture to detailed circuit
design positions for DS1, DS3, E1-E4. Designs from 1.5 to 140 Mb/s,
HDSL,/ADSL modem, hardware, DSP, high-speed network technologies.
___________________________________________________________
Call: Mike DeLaney - Specializing in the communications industry
800-248-7020 x260
Fax 716-248-3077
National Engineering Search
http://www.nesnet.com
"Engineers placing Engineers"
Email (text resume) to: mdelaney@servtech.com
____________________________________________________________
See what your skills are worth...CALL for a FREE salary survey.
____________________________________________________________
National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with degreed engineers, dedicated exclusively to
placing Engineers nationwide. If this position doesn't fit your
requirements, call me with your specific search criteria.
€ NES can identify SELECT engineering opportunities based on your
background, interests, and geographic requirements.
€ What makes us better...We are Engineers placing Engineers, We are not a
generalist, We are very focused in a technical arena ONLY. And we know it
better than anyone else.
Article: 11943Another engineer at work wants to build a state machine that watches for a particular sequence of words and then trigger an output. E.g., set an output active after receiving 0x5555,0xaaaa,0x0000,0xffff in that particular order. The compare sequence needs to be configurable by a microcontroller (but only as an "offline" operation on a very occasional basis). He was thinking of using the wide address decoders around the perimeter of the XC4000 series FPGAs to do this decoding, but they have the obvious drawback that reprogramming the compare sequence would require completely reprogramming the FPGA. That would be acceptable, but our understanding is that this isn't feasible since Xilinx doesn't publish the configuration bitstream specification due to security concerns about copied designs. Instead of using the wide edge decoders, one could use CLBs. Since each CLB has two four input LUTs, each CLB one could do 4 bits worth of a comparison (...against some register's compare value that a microcontroller could write to). Multiple CLBs outputs could then be ANDed together in another CLB to generate the match output. So by my calculations, a 32 bit configurable compare would require 9 CLBs. My questions are: -- Am I correct about Xilinx's policy on the bitstream? I've read that some parts of it actually are published -- would that include the wide edge decoder configuration bits? -- Assuming no, is there a better way to do this than what I've proposed in the second paragraph? -- How much slower will the CLB approach be than the wide edge decoder approach? Thank you for your help. ---Joel Kolstad Joel.Kolstad@USA.NetArticle: 11944
Please find enclosed the call for participants for ICCD '98:
International Conference on Computer Design 1998.
Kindly forward this Announcement to your colleagues.
Best regards.
Chin-Long Wey,
Publication Chair, ICCD '98
****************************************************************************
C A L L F O R P A T I C I P A N T S
****************************************************************************
INTERNATIONAL CONFERENCE ON COMPUTER DESIGN, ICCD '98
October 5 - 7, 1998
Marriott Hotel at the Capitol, Austin, Texas
Sponsored by: IEEE Circuits and Systems Society and The IEEE Computer
Society; In Cooperation with: IEEE Electron Devices Society
The International Conference on Computer Design encompasses a wide range
of topics in the design and implementation of computer systems and their
components. ICCD's multi-disciplinary emphasis provides an ideal
environment for developers and researchers to discuss practical and
theoretical work covering system and computer architecture, verification
and test, design and technology, and tools and methodologies. This
year's program includes three invited sessions on the latest processor
developments, two embedded tutorials, two panel discussions, two advance
technology forums, and 21 technical sessions with 69 scheduled paper
presentations. During the poster session on Monday night wine and cheese
will be served. IBM and Motorola will sponsor the lunches on Monday and
Tuesday, respectively. Murray Campbell, IBM Thomas J. Watson Research
Center will give the Keynote Speech. Three plenary sessions provide
leaders in the field the opportunity to present the latest developments
and visions of future progress in key ICCD subject areas.
Up-to-date information on ICCD '98 is available on the World Wide Web---
http://domino.watson.ibm.com/iccd98/iccd98.nsf/Program.html
**************************************************************************
ICCD '98
General Chair: Bing Sheu, University of Southern California, USA
Technical Program Chair: Andreas Kuehlmann, IBM T.J. Watson Research
Center, USA
Publications Chair: Chin-Long Wey, Michigan State University, USA
Treasurer: Tim Brodnax, IBM Corporation, USA
Industry Liaison: Nasr Ullah, Motorola Inc., USA
Local Arrangements: Dan Elgin, University of Texas at Austin, USA
Architecture and Algorithms Track
Co-Chair: Craig Chase, University of Texas at Austin, USA
Co-Chair: David Witt, Advanced Micro Devices, USA
Integrated Systems Track
Co-Chair: Rajesh K. Gupta, University of California, USA
Co-Chair: John Trotter, Lucent Bell Laboratories, USA
Verification and Test Track
Co-Chair: Warren A. Hunt, Jr, IBM Corporation, USA
Co-Chair: Wolfgang Kunz, University of Frankfurt, Germany
Design and Technology Track
Co-Chair: Sandip Kundu, Austin Research Lab, USA
Co-Chair: Sarma Vrudhula, University of Arizona, USA
Tools and Methodology Track
Co-Chair: Joel Grodstein, Digital Equipment Corporation, USA
Co-Chair: Kenneth L. Shepard, Columbia University, USA
===========****============****===========****==================
Dr. Chin-long Wey, Professor
Department of Electrical Engineering
Michigan State University, East Lansing, MI 48824-1226
Phone: 517-353-0665; Fax: 517-353-1980; E-mail: wey@egr.msu.edu
URL: http://www.egr.msu.edu/~wey
Article: 11945
Please find enclosed the call for participants for ICCD '98:
International Conference on Computer Design 1998.
Kindly forward this Announcement to your colleagues.
Best regards.
Chin-Long Wey,
Publication Chair, ICCD '98
****************************************************************************
C A L L F O R P A T I C I P A N T S
****************************************************************************
INTERNATIONAL CONFERENCE ON COMPUTER DESIGN, ICCD '98
October 5 - 7, 1998
Marriott Hotel at the Capitol, Austin, Texas
Sponsored by: IEEE Circuits and Systems Society and The IEEE Computer
Society; In Cooperation with: IEEE Electron Devices Society
The International Conference on Computer Design encompasses a wide range
of topics in the design and implementation of computer systems and their
components. ICCD's multi-disciplinary emphasis provides an ideal
environment for developers and researchers to discuss practical and
theoretical work covering system and computer architecture, verification
and test, design and technology, and tools and methodologies. This
year's program includes three invited sessions on the latest processor
developments, two embedded tutorials, two panel discussions, two advance
technology forums, and 21 technical sessions with 69 scheduled paper
presentations. During the poster session on Monday night wine and cheese
will be served. IBM and Motorola will sponsor the lunches on Monday and
Tuesday, respectively. Murray Campbell, IBM Thomas J. Watson Research
Center will give the Keynote Speech. Three plenary sessions provide
leaders in the field the opportunity to present the latest developments
and visions of future progress in key ICCD subject areas.
Up-to-date information on ICCD '98 is available on the World Wide Web---
http://domino.watson.ibm.com/iccd98/iccd98.nsf/Program.html
**************************************************************************
ICCD '98
General Chair: Bing Sheu, University of Southern California, USA
Technical Program Chair: Andreas Kuehlmann, IBM T.J. Watson Research
Center, USA
Publications Chair: Chin-Long Wey, Michigan State University, USA
Treasurer: Tim Brodnax, IBM Corporation, USA
Industry Liaison: Nasr Ullah, Motorola Inc., USA
Local Arrangements: Dan Elgin, University of Texas at Austin, USA
Architecture and Algorithms Track
Co-Chair: Craig Chase, University of Texas at Austin, USA
Co-Chair: David Witt, Advanced Micro Devices, USA
Integrated Systems Track
Co-Chair: Rajesh K. Gupta, University of California, USA
Co-Chair: John Trotter, Lucent Bell Laboratories, USA
Verification and Test Track
Co-Chair: Warren A. Hunt, Jr, IBM Corporation, USA
Co-Chair: Wolfgang Kunz, University of Frankfurt, Germany
Design and Technology Track
Co-Chair: Sandip Kundu, Austin Research Lab, USA
Co-Chair: Sarma Vrudhula, University of Arizona, USA
Tools and Methodology Track
Co-Chair: Joel Grodstein, Digital Equipment Corporation, USA
Co-Chair: Kenneth L. Shepard, Columbia University, USA
===========****============****===========****==================
Dr. Chin-long Wey, Professor
Department of Electrical Engineering
Michigan State University, East Lansing, MI 48824-1226
Phone: 517-353-0665; Fax: 517-353-1980; E-mail: wey@egr.msu.edu
URL: http://www.egr.msu.edu/~wey
Article: 11946I happen to have dropped by http://www.despotovic.net and I couldn't believe what I saw. A complete case online with over 48 pictures, 3 police reports and more!!! Regards. P.S.- The website address is http://www.despotovic.netArticle: 11947
On Sun, 20 Sep 1998 17:30:00 +0100, Edward Moore <edmoore@edmoore.demon.co.uk> wrote: >>2. Not pin compatible. (more VCC pins, which is a good thing) >>I recently translated a design from a 4020E-3 to an XCS40-3. There >>were no (VHDL) source code changes needed except for the pin >>numbering. > >Allan, I've got the XCS30 and XC4013 pin-out tables in front of me and >for the PQ240 package at least, the VCC and GND pinouts look identical. >ie apart from configuration pins, they look pin-compatible. Have I >missed something ?. No, I did. As another poster pointed out, the compatibility problem was only for the PQ208 package. This just happened to be the only one I've used so far... >Also, how do you percieve the marketing of the Spartan parts ?. We have >almost been discouraged to use them. Less profit margins for Xilinx >perhaps ? Our local distributor is recommending them for all new designs. I believe that may have something to do with competition with Altera in this particular market. They are aware of our application and what we are willing to pay, so they know that they either sell at a particular price, or lose market share. One advantage of working for a big company is that you get to watch the component suppliers squirm, not the other way around. [ This rather appeals to my sadistic side.] I could go on, but company policy prevents me from saying more, sorry. >Edward Moore Regards, Allan.Article: 11948
ems@nospam.riverside-machines.com wrote: > On Fri, 18 Sep 1998 11:37:01 +0200, "Sten Søgaard" <soeg@kom.auc.dk> > wrote: > > >I know that Xilinx > >has had a guided layout option for some time now, but whenever I have > >tried to use it, it results in a "Dr. Watson"-fault of some kind, I > >don't remember. > > I thought this had been fixed recently (a few months ago?), but I > haven't tried the patches on the website. > > >Has anyone else tried to use the Floorplaner with succes, is the > >Floorplanner still a beta version, or is it my who are using it wrong ? > > I asked Xilinx for a beta a few months ago, but they said I should > wait for the 'proper' release in 1.5, so I guess (hope) it's not beta > any more. I can't help, since I haven't got 1.5 yet, but I would be > interested to hear some more about what you're doing: I don't doubt that Xilinx believe that it is an official release they have made, it is just me who are referring to the floorplanner as a beta version. > 1) What synthesiser are you using? Leonardo > 2) After you've changed your entity, how much of the design do you > re-synthesise? Just that one entity/all dependent entities/all 20 > entities? Well, I have to admit that I do a complete re-synthesis (I have build a nice script file that handles all the synthesis from bash). But I keep the hierarchy during synthesis. The modifications I have tried to make are very minor, e.g. change the terminal count if an incrementer in the FSM, I haven't inserted new signals in my design, so I hope that should keep Leonardo from changing other entities. > 3) You say you remove the modified entity from the floorplan. How do > you do this? Have you already floorplanned so that the entity is in > one section of the device, or do you have to remove parts of the > entity from all over the device? I copy the placement of an previous version of the design, and then remove the entity that I have changed since then. It is quite easy with the Floorplanner, as it shows an hierarchical design tree. When you mark a entity in the design tree, it automatically selects all cells in that entity in the placement file. From this layout the floorplanner generates an .fnf and .mfp file (I only use the .mfp file - the guide file) First couple of lines in the mfp file. CARRY R48C1 COUT0 th/bc/ix2354_cout0 COUT th/bc/ix2354_l1_l0_c_int(0) A1 th/bc/q(1) A0 th/bc/q(0) CIN BEL_th/bc/q(1).POWER.1 ; CARRY R47C1 COUT0 th/bc/ix2354_cout0_dup_359 COUT th/bc/ix2354_l1_l0_c_int(1) A1 th/bc/q(3) A0 th/bc/q(2) CIN th/bc/ix2354_l1_l0_c_int(0) ; . . . > 4) If you had to re-synthesise any other entities, do you know if the > XNF/EDIF signal names in those entities changed? As I mentioned, I keep the hierarchy and I don't include new signals. > I guess that the success of a guided or floorplan mapping will depend > very much on how many signal names have changed (this is presumably > why guided mapping is not recommended for synthesis designs). Mapping > will be a problem if a small change in an entity results in name > changes throughout the entity (which will happen with some > synthesisers) - is this happening in your case? I don't know, but this is also why I use "Guided FloorPlanning", with emphasis on guided. Shouldn't it be possible to use a floorplan as the starting point of the placement iterations in the placement&route step. It does not lock the cells to specific locations. Even if the should be some deviations between the signal names in the floorplan, and the signal names in the design, why can't it just ignore these deviations, and only use the valid guides. \StenArticle: 11949
In article <6u45du$grs$1@supernews.com>, "Joel Kolstad" <Joel.Kolstad@USA.Net> wrote: > Another engineer at work wants to build a state machine that watches for a > particular sequence of words and then trigger an output. E.g., set an > output active after receiving 0x5555,0xaaaa,0x0000,0xffff in that particular > order. The compare sequence needs to be configurable by a microcontroller If you are using compare with a large/dynamic pattern, my suggestion is to use a RAM/ROM lookup table, each CLB of the XC4K family can take an 5 input address with one bit output or 4 input with two bit output. in your example 2,5 CLB's can be used to match every possible combination. (2 CLB's for matching and one lut for AND) The best feature is that the RAM match pattern can be write via uC I/F. /Goran Bilski -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
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