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
Why don't you have a look at a common VHDL book ? There are so many simple examples which show how to describe a state machine ... You could design your state machine on a piece of paper first,=20 later try to describe in VHDL ... Rgds Andr=E9Article: 98326
John, (or should I call you Mr. Bass?) Sorry to hear you are this upset, John. I will promise not to shorten your name (or alias) in the future. My posting was a news item, of LSI dropping their structured ASIC offering. My second posting was to direct you to the subject of the first posting (you seemed to be wandering somewhere that I could not follow). My opinion (no secret) is that ASICs are moving into an area where only a few can afford to develop them, and as such, the number of design starts has fallen off. But, the amount of money has actually increased (due to their getting more expensive to develop, and those that do get done, covering huge new markets - like gaming consoles). Not counting microprocessors, and memories, Xilinx is now the second largest vendor of "logic" (which includes ASICs, per Gartner-DataQuest). It has been great to have the ASIC vendors treat FPGAs with such disdain, and contempt. While they basked in their obvious unassailable superiority, we just ate their lunch. With great margins, too. Will ASICs go away? Of course not. Will they continue to be the growth industry they were? In my opinion, that sun already set. Will they continue to make a lot of money? Of course. At least until the customers get tired of paying too much, for too little. I recommend you look into the story of steel mills in the US. They ruled the world. Then these little mini-mills started competing, and the US super mills said "our steel is so high quality, we will give the low grade steel business to the mini-mills. Won't even notice the drop in volume, and we will make more money." Then, after a while, the mini-mills made better steel. The big guys said, "well, that wasn't as profitable as it used to be, so what the heck." We all know what happened. The US steel business collapsed. I see ASICs in the same boat. I can see the ASIC board room discussion, "we will let the FPGAs have those sockets: they were getting too tough to win anyway. No profit left in it. They can't do what we do, so we don't have to worry. We will just go on to the more profitable markets..." AustinArticle: 98327
Manish, Are you referring to corss-talk internally? We do that as part of the FPGA IC design, so you do not have to. If you are referring to signal integrity work with the IOs of the FPGA, there are many tools for that. My favorite is Montor Graphics Hyperlynx. Austin Manish wrote: > How exactly is crosstalk analysis performed on a FPGA (in particular > Xilinx Virtex series). Are there particular tools available for a > particular FPGA or a single tool can be used to perform crosstalk > analysis on various FPGAs. Also, in industry currently what tools are > used to perform this analysis. > > Thanks regards, > Manish >Article: 98328
cs_posting@hotmail.com wrote: > Gary Pearman wrote: > > Does anybody know where I can get hold of a cheap Xilinx development > > board that has an FPGA with 5v I/O? > > For many purposes though, you may be able to use a spartan 3 kit ($100) > with series resistors to protect the FPGA input protection diodes from > overcurrent. The FPGA outputs should be valid 5v TTL levels (though > not valid 5v CMOS), though perhaps not as high a noise margin as you > want. Why wouldn't it be valid 5V CMOS? Doesn't it just have to be above 1/2 the supply voltage (ie. 2.5V)? Or are there CMOS inputs that really expect you to hit the rail? Alan NishiokaArticle: 98329
Alan Nishioka wrote: > Why wouldn't it be valid 5V CMOS? > Doesn't it just have to be above 1/2 the supply voltage (ie. 2.5V)? > Or are there CMOS inputs that really expect you to hit the rail? "native" 5v CMOS has a higher input threshold, which even 5v TTL may not reliably achieve - ie, it works on your breadboard but not in production, etc. But a lot of 5v CMOS parts are made with a TTL compatible (2.4v I think) threshold, these are the ones with a "T" in their part number somehwere near the "C" - ie,"HCT", etc.Article: 98330
In a perfect world, it would be 2.5 V. In an imperfect world you need to accomodate non-symmetries. And you might like some noise immunity. Threfore 3 V should be the minimum High voltage, and 3.5 V is better. Peter AlfkeArticle: 98331
I've been bitten several times by XST producing sub-optimal results by
trying to use the flip-flop enable when it doesn't need to. We all
know the priority of Reset/Set/Enable to ensure that the flip-flop
pins can be used, but if you need to violate this, then XST may
create stupid logic.
For example:
always @(posedge Clk10 or posedge reset)
if (reset)
timeout_intr_reg <= #1 1'b0;
else if (lc_intr_reg_wr)
timeout_intr_reg <= #1 db_wr_data_r2[6];
else if (intr_db_timeout)
timeout_intr_reg <= #1 1'b1;
Produced logic that tried to use the Enable pin, thus it added logic
to drive the enable using since there was no one signal that could
directly drive the enable. The code can't be re-ordered because
of the required priority.
Note that, excluding reset, there are 4 signals involved in the logic.
Thus all the logic could fit into one LUT driving the D pin to the
flip flop, no need to use the enable at all.
Identical functionality:
if (reset)
timeout_intr_reg <= #1 1'b0;
else
timeout_intr_reg <= #1 lc_intr_reg_wr ? db_wr_data_r2[6] :
(timeout_intr_reg | intr_db_timeout);
This second version synthesized nicely and gave me the margin
I needed to meet timing. It's not as clear as the original, however.
Can XST be made to recognize cases like this? Just because you have an
enable pin on the flip-flops doesn't mean you have to use it!
Anyone else seeing this?
John Providenza
Article: 98332You had better look at your DSP data sheet and see what clock the external bus timing parameters are referenced to. In my design (similar to yours), there were no timing specs between the DSP bus signals and the DSP clock input; the specs referred to the DSP's bus clock output. So I had to send the oscillator to the DSP clock input, and the DSP clock output to the FPGA. "Marco" <marco@marylon.com> wrote in message news:1141806772.500591.65390@j33g2000cwa.googlegroups.com... > Hi, > for my project I'd like to use the same 25MHz clock signal (coming from > an external oscillator) for both the DSP and my Spartan3. A pll inside > the DSP creates the 600MHz clock from the 25MHz. I still don't know how > fast I'll let the FPGA work, so I was supposed to acquire the 25MHz > clock and through a DCM bring it to the level, i.e. 50MHz or 60Mhz, > that optimizes my design. In such a way I would have the same clock for > both my devices, syncronized and each with its proper frequency. > Can I do that or should I avoid this way of working? > Is it a common way to work? > Suggestions? > Thanks, Marco >Article: 98333
if you are trying to learn vhdl by asking simple questions to this group you'll never learn. Download a good tutorial from the web and start working with the provided examples. Aurash laura_pretty05@yahoo.com.hk wrote: > Now, I used the state machine to apply to VHDL. In my case, there are > two states, S0 and S1. > When I press a button, S0 is transit to S1 such that the LED display > some of the segments,like segment a,b,c. And press this button again, > S1 is back to S0. How can I present in VHDL so that the LED display in > segment a,b,c ? Thanks!! >Article: 98334
I have not a bus, just a serial connection between DSP and FPGA. I think it could be fine if they do both generate their internal clock from a common crystal source. MarcoArticle: 98335
I am new to FPGA's and its programming language VHDL. I am working on an Computer Science senior project and have a few questions. 1.) is it possible to connect a USB device (ie a digital camera) to the Spartan 3 FPGA? 2.) If it is possible, could someone give a quick overview or a good resource for me to research. 3.) If not, any good suggestions on how i would go about accomplishing my objective (see below) My main goal is to implement a mini security system for our department. It is kind of like one those home security system you can monitor monitor yourself from the internet. I would like to connect a Digital camera directly to the FPGA board to get a picture from the camera. Next, once I have the picture some how email or send the picture over a network to another computer. I have an ethernet card that can connect to the Spartan 3. But I was informed by digilent that "Manually accessing the Net1 module via a TCP connection with manual packet transfer is not supported." So as of right now I have no idea on how to email or transfer the picture over the network. I know this is alot. So any information or insight would be greatly appreciate. Thanks in advance!! AaronArticle: 98336
<fpga_toys@yahoo.com> wrote in message news:1141824014.067825.151340@u72g2000cwu.googlegroups.com... > > Actually, Austin has addressed replys to me as John back in Jan. And > despite my objections, or specifically because I objected, he's choosen > to push the toy button as well as other much more direct attacks. I > was polite and firm asking that he stop. > > Two, or three, or more can play his game. As I suggested quiet some > time ago, if he wants to play nasty that way, then he becomes > responsible for setting the tone and nature in which others can, and > will, interact with him as well. Dude, Change your handle here to something that can't be "nicknamed" to something *you* find offensive and you won't get pissed off by someone using part of your name to address you. When I see "fpga_toys" in an "fpga" newsgroup, the only thing that isn't redundant is that which follows the underscore. Austin pisses you off, you piss me off with your ranting. I won't bother you further when your emails "obviously" are derogatory to others on this forum. - John HandworkArticle: 98337
Hi All, Having a few problems implementing readback on a Xilinx SpartanIIE device. We have a uP programming via the parallel port, this works OK. However, the documentation and timing diagrams for parallel readback seem to be a little sketchy. It seems that data is both captured by the SpartanIIE on a rising CCLK edge, and also clocked out on a rising CCLK edge. I assume this means we should latch our data maybe on the falling edge when reading? Anyone got parallel readback to work? Thanks, Mark.Article: 98338
Marco, just concentrate on the communication between the two devices, ignore the 600 MHz, since you will never see that in the interface. You have to be able to grab the (serial?) data coming from the DSP, and synchronize it to the FPGA clock. Everything else seems to be irrelevant. So, determine the DSP output clock and make sure it is synchronous to the circutry in the FPGA that receives the data. Otherwise you are in to complicated data movements across asynchronous clock domains. Avoid that! Peter AlfkeArticle: 98339
Believe it or not, every other component seems to work. I wrote a working UART and was able to send data to and from a terminal no problem, as well as all the LEDs and Switches work. I've been talking to Digilent, and they have been working with me in trying to figure out what's causing it. Only thing that doesn't seem to work is the SRAM when programming via a .bit file. Everything else is fine, which is why I hadn't noticed a problem until I tried to use the SRAM. cs_posting@hotmail.com wrote: > Scott M. Kroll wrote: > > > It's very strange, but here's what I meant: I am using Digilent's JTAG > > utility (it's called Export) to program the FPGA via JTAG. Using IMPACT > > to create the .bit file, and then program the FPGA with the .bit. > > Digilent's Export tool only supports .bit and .svf files. If I program > > the FPGA via the .bit file, the SRAM never writes, and feeds back random > > garbage, never writes correctly. > > Okay, let me see if I understand this correctly - the digilent > programmer does not seem to be able to make a .bit file work, but if > you use the xilinx tool to turn .bit into .svf, the digilent programmer > can load that. > > Your only evidence of working/not working to date is the ram test. But > it's probably that the programming more generally fails? > > Anyway, my impression is that a .bit file is just data, while a .svf > file is data expanded into explicit instructions for how to wiggle the > jtag lines to program it into a xilinx part - all the thinking is > already done, only the execution remains. This suggests that your > problem is that the digilent programmer is not using (is not configured > to use) the right programming algorithm for the part in question. When > it's mindlessly executing the .svf instructions things work, when it's > taking responsibility for figuring out how to program a .bit, it fails. > > You could either take that up with digilent, or if you want to > streamline your intermediate step, the xilinx tools can be run > command-line style from scripts to do your translation.Article: 98340
AaronDBenson@gmail.com wrote: > I am new to FPGA's and its programming language VHDL. I am working on > an Computer Science senior project and have a few questions. > 1.) is it possible to connect a USB device (ie a digital camera) to > the Spartan 3 FPGA? It might be possible, but it is very difficult. Most projects concentrate on the device side interface of USB, but you need to be the host side so that you can talk to the device. Thus you need either a USB host chip and somewhere to run the protocol software, or a microcontroller that has USB host capabilities. Can you get your image another way? Perhaps find an older digital camera from before USB became the universal solution? > Next, once I have the picture some how email or send the picture over a > network to another computer. > > I have an ethernet card that can connect to the Spartan 3. But I was > informed by digilent that "Manually accessing the Net1 module via a TCP > connection with manual packet > transfer is not supported." So as of right now I have no idea on how to > email or transfer the picture over the network. Not sure quite what they mean, but it is very hard to do TCPIP without using software for the stack. Perhaps not impossible, but to make your project reasonable you need a processor you can run your network software on, either in addition to the FPGA or impelmented inside the FPGA. Taking a step back, what you are describing is really an application for an embedded processor with host-side USB and ethernet capability where most of the work will be writing software; it is not really an FPGA project at all, though you might with moderate to severe difficulty manage to make an FPGA emulate the chips that you should be using. > > > I know this is alot. So any information or insight would be greatly > appreciate. > Thanks in advance!! > > AaronArticle: 98341
Mark, just from curiosity why do you want to read back? Aurash markp wrote: > Hi All, > > Having a few problems implementing readback on a Xilinx SpartanIIE device. > We have a uP programming via the parallel port, this works OK. However, the > documentation and timing diagrams for parallel readback seem to be a little > sketchy. It seems that data is both captured by the SpartanIIE on a rising > CCLK edge, and also clocked out on a rising CCLK edge. I assume this means > we should latch our data maybe on the falling edge when reading? Anyone got > parallel readback to work? > > Thanks, > > Mark. > >Article: 98342
I want to know which VHDL book is better for learning...??Article: 98343
Austin Lesea wrote: > My opinion (no secret) is that ASICs are moving into an area where only > a few can afford to develop them, and as such, the number of design > starts has fallen off. But, the amount of money has actually increased > (due to their getting more expensive to develop, and those that do get > done, covering huge new markets - like gaming consoles). > <snip> > > Will ASICs go away? Of course not. Will they continue to be the growth > industry they were? In my opinion, that sun already set. Will they > continue to make a lot of money? Of course. At least until the > customers get tired of paying too much, for too little. Yess... OK, until you start to drift a little in the last sentence... > I recommend you look into the story of steel mills in the US. They > ruled the world. Then these little mini-mills started competing, and > the US super mills said "our steel is so high quality, we will give the > low grade steel business to the mini-mills. Won't even notice the drop > in volume, and we will make more money." Then, after a while, the > mini-mills made better steel. The big guys said, "well, that wasn't as > profitable as it used to be, so what the heck." We all know what > happened. The US steel business collapsed. I see ASICs in the same > boat. I can see the ASIC board room discussion, "we will let the FPGAs > have those sockets: they were getting too tough to win anyway. No > profit left in it. They can't do what we do, so we don't have to worry. > We will just go on to the more profitable markets..." I love Austin on a roll..... :) Take a deep breath, and read what you wrote above: ASICs will NEVER go away. Points to ponder : ** An FPGA is also an ASIC - remember "Application Specific Integrated Circuit" Some very big players have large revenue streams in targeted silicon. (ASICs) As soon as any given market gets large enough, they can afford to take the performance gain of an ASIC. ** look at this news item http://www.eet.com/news/design/showArticle.jhtml;jsessionid=NO4FYXLJXNB0EQSNDBCSKHSCJUMEKJVN?articleID=181501574 ** look at the devices comming from ST ** Ponder that the mini-mills just might be Lattice and Actel, and Xilinx might be the larger insular, belligerant model. I think it was my Gran used to say "Pride comes before a fall" ? -jgArticle: 98344
In article <dun1n1$ar211@xco-news.xilinx.com>,
austin@xilinx.com says...
[ ... ]
> My posting was a news item, of LSI dropping their
> structured ASIC offering.
I hope you'll pardon my jumping in, but I think this is
where things started to go wrong. While this may arguably
be related to the FPGA business in general, it seems
pretty clear to me that it's not related to anything like
architecture or development.
Other than as an ego boost, it's pointless anyway: given
that this newsgroup is devoted specifically to FPGAs to
start with, the only people here to see the post are
already reasonably convinced that FPGAs are/can be
useful, and most of use use them more or less regularly
already.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 98345
Hello,
A good source of information is the tutorial EVITA
(http://www.aldec.com/products/tutorials/) and
(http://www.vhdl-online.de/tutorial/). Also, you can use the google to
find others. I started using the book "VHDL starter's guide"
Fabio
laura_pretty05@yahoo.com.hk wrote:
> I want to know which VHDL book is better for learning...??
>
Article: 98346Hi, I'm trying to debug an application. I downloaded the .elf file to the board, and then started XMD. I followed the instruction in the EDK reference, and typed the following commands: powerpc-eabi-gdb -nw executable.elf target remote localhost:1234 Then I got the following messages: Remote debugging using localhost:1234 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote targe Malformed response to offset query, timeout I've tried to put both the host computer and target on the same server, or connected them together locally. I also made sure the firewall is turned off. Am I missing something here? Thanks plenty! -EricArticle: 98347
"Aurelian Lazarut" <aurash@xilinx.com> wrote in message news:dun6l2$o7l1@cliff.xsj.xilinx.com... > Mark, > just from curiosity why do you want to read back? > Aurash > markp wrote: I want to be able to continually check the FPGA to verify the logic hasn't been changed or corrupted in any way e.g. hard errors, radiation induced errors etc.. This is primarily to satisfy a customer's concern. It should be possible to read back the configuration (after masking the relevant bits) and check it's still intact. Mark.Article: 98348
Austin Lesea wrote: > John, (or should I call you Mr. Bass?) either is fine. Actually the name thing was a minor nit ... regaining respectful discourse simply required being firmer about the alternatives. > I will promise not to shorten your name (or alias) in the future. I assume this implies the personal attacks are likely to cease too ... which is great progress. > My posting was a news item, of LSI dropping their structured ASIC offering. > > My second posting was to direct you to the subject of the first posting > (you seemed to be wandering somewhere that I could not follow). The point, is that ASIC foundry services are tied to operating a fab, as a side product to sell unused capacity. Worked a while for Symbios Logic before LSI took them over and closed the local Fort Collins fab (leaving the ASIC center). With LSI getting out of the fab business, that pretty much dictates they will soon be out of the ASIC business too. The globalization and migration of fabs changes business strategies over time, but isn't the ASIC vs. FPGA issue you suggest. > It has been great to have the ASIC vendors treat FPGAs with such > disdain, and contempt. While they basked in their obvious unassailable > superiority, we just ate their lunch. With great margins, too. > > Will ASICs go away? Of course not. Will they continue to be the growth > industry they were? In my opinion, that sun already set. Will they > continue to make a lot of money? Of course. At least until the > customers get tired of paying too much, for too little. Interesting you discuss both "great margins" and "paying too much, for too little" as they are related, and create the same mini-mill dynamics you suggest below: > I recommend you look into the story of steel mills in the US. They > ruled the world. Then these little mini-mills started competing, and > the US super mills said "our steel is so high quality, we will give the > low grade steel business to the mini-mills. Won't even notice the drop > in volume, and we will make more money." Then, after a while, the > mini-mills made better steel. The big guys said, "well, that wasn't as > profitable as it used to be, so what the heck." We all know what > happened. The US steel business collapsed. I see ASICs in the same > boat. I can see the ASIC board room discussion, "we will let the FPGAs > have those sockets: they were getting too tough to win anyway. No > profit left in it. They can't do what we do, so we don't have to worry. > We will just go on to the more profitable markets..." Domestic Steel and Domestic Fabs have a lot in common regarding their history and future. First, while history records the sequence of events, the cause and effect will be argued for decades, if not centuries. With US steel, globalization was a major factor ... the shifting of production (IE Consuption) combined with huge problems with domestic supply (from strip mining to labor). As the US transitioned to building with concrete and got out of building heavy equipment and boats, the demand for finished steel in the US softened -- in part due to rising prices of production across the board. Globalization however, determined why US steel production fell as moot, just as Globalization in the silicon industry has seen our fabs and production shift off shore. We import finished goods, not raw materials. History says that where goes production, also goes design and the jobs. A number of industry leaders have argued that point for some time, citing both US Steel and the home entainment industry as clear examples. They argue that we need the fabs to stay here. However, the market presures caused by competing with fabless companies, set the course. The end of that course is that where the fabs went, is where the finished products will come from, including FPGAs. As the fabs gain design talent, they will start producing their own competitive products, and slowly raise prices on fab services till fabless companies are required to resell those goods rather than market their own. We've seen this cycle over and over including with radios and TV's. First the base components, then tuners, chasis, and tubes, then finished goods cheaper than the sum of the parts. It's with this perspective that domestic FPGA vendors could easily disappear off the map as quickly as GE, RCA, Magnavox, Packard Bell, Motorola, and other US TV and Radio suppliers did from 1965 to 1970 when domestic production pretty much stopped. Xilinx doesn't control it's means of production, and with that, it also does not control it's fate. As FPGAs become a comodity building block for all electronics, as it seems it will during this decade, then every major fab on the planet will be producing them ... frequently with the fabs own design and logo. Since early US patents are set to expire this decade, that is almost a given. Those same fabs producing FPGAs are very likely to offer discounted ASIC facilities based on their netlists ... so I see the structured ASIC market as long term, at all levels.Article: 98349
Hi, I learn VHDL. I got text: " Compiling 'komp.vhd' in 'H:\PROGRAMY\WARP\BIN'. VHDL parser (h:\programy\warp\bin\vhdlfe.exe V4 IR x66) Library 'work' => directory 'lc16r4' Library 'ieee' => directory 'h:\programy\warp\lib\ieee\work' Using 'h:\programy\warp\lib\ieee\work\stdlogic.vif'. High-level synthesis (h:\programy\warp\bin\tovif.exe V4 IR x66) Synthesis and optimization (h:\programy\warp\bin\topld.exe V4 IR x66) Design optimization (dsgnopt) Equation minimization (minopt) Design optimization (dsgnopt) Device fitting (pla2jed) Error: Polarity specified for LHS signal y must be Active Low. " Code I was trying to synthes is: "library ieee; use ieee.std_logic_1164.all; entity komparator is port (a,b,c: in std_logic; y: out std_logic); end komparator; architecture komparator of komparator is begin yiuyuiku:process(a,b,c) begin y <= (a and b and c); end process; end komparator;" What is the problem? Regards, Wojtek
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