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 Kemmeth, Thank you again for your help. What is the part number of the SDRAM chip you are using. Maybe the difference is that I am simulating a different (Maybe slower) chip. Zohar "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10lqi8vegegit29@news.supernews.com>... > Hi Zohar, > > My system is running at 75 MHz right now. My fmax is 90+ so I may try a > little higher too. > I didn't simulate, but I used SignalTapII to verify that I was indeed > dma'ing the contents of an external fifo into sdram at a rate of 1 clock per > 32bit word. (480 words in ~485 cpu clocks) > This was while my system was running out of the same sdram and operating on > other sdram data simultaneously - so very good results! > > I'd like to add that I got these perfect results with the help of the Altera > Nios team. I'll be posting this setup on the IP section of the Nios Forum. > > This was *writing* to sdram, and I haven't really looked at reads yet. > Hopefully I'll be just as pleased with those results. In my case reads are > not quite as critical as writes, as the data streaming in is real time and > waits for no one. > > Ken > > > "zg" <zohargolan@hotmail.com> wrote in message > news:e24ecb44.0409301615.7b8bccaf@posting.google.com... > > Hi Ken, > > > > Thank you for your response. > > What frequncy are you running the NIOS? I tried simulating at 72MHz > > and I got only 2 words bursts. > > Are you using NIOS II? > > > > Regards, > > Zohar > > > > "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message > news:<10lg0aca67jseaa@news.supernews.com>... > > > "zg" <zohargolan@hotmail.com> wrote in message > > > news:e24ecb44.0409241455.340ba130@posting.google.com... > > > > Hi All, > > > > > > > > I am trying to use the SDR SDRAM controller that is comming with the > > > > NIOS II development package. In the simulation it looks like this core > > > > supports only 2 words bursts. I couldn't find anything in the > > > > documentations. > > > > Am I correct? > > > > If this core supports bigger bursts then 2 words, any ideas what am I > > > > doing wrong? > > > > > > > > Thank you all > > > > Zohar > > > > > > Zohar, > > > > > > I'm working on a design that uses one 16MB sdram chip for most of its > > > instruction and data memory. I rely heavily on dma and other burst > reads > > > and writes (ie cache) to get the performance I need. > > > > > > The sdram controller you're talking about is good enough to burst 480 32 > bit > > > words in under 485 cpu clocks. It's a beautiful thing to watch in > Signal > > > Tap as I get this performance. (Haven't explored the lenght limits > above > > > 480 - my external fifo's AlmostFull level) > > > > > > I'm hammering that sdram (through the Altera sdram controller) nines > ways to > > > Sunday and it performs flawlessly. > > > > > > I have some serious issues with the whole NiosI/II chain, but the sdram > > > controller has been a champ. > > > > > > KenArticle: 74126
hi, I have a doubt on using inout ports in FPGA design. I am implementing an application on FPGA, that should be interfaced to SHT71(Sensirion humidity and temperature sensor). My FPGA gets the value of temperature and humidity from the sensor and calculates moisture(output) using certain equations. I have designed the arithmetic unit required to calculate the moisture value in VHDL, and synthesized on to FPGA. But now I have to interface this unit to the sensor(SHT71), and the sensor needs to have a controller(any microcontroller as specified in the SHT71 datasheet) to control its operations and get the values of temperature and humidity. The sensor has a bidirectional data signal as one of the ports, and that should be connected to the controller to send and receive data. I want to implement the controller also on the same FPGA itself. But is it possible? Is it possible to handle a bidirectional port from an FPGA to send and receive data? I am using Virtex XCV800 HQ240I. Or is it suggestible to use any standard microcontroller as an interface between sensor and FPGA? Any suggestion on this is highly appreciated. ThanksArticle: 74127
"Dave" <gretzteam@hotmail.com> wrote in message news:yt2dnW1FjtkfzsLcRVn-jg@comcast.com... > Ok I understand...but isn't it better to have a reset for all our flip flop? > If something goes wrong - or when I press the reset button...- the > controller can always reset everything to zero before we start again... > > Thanks, > David If something goes wrong - or when you press the reset button...- would you be willing to wait for the FPGA to reprogram itself? If you design the system to boot the FPGA from a PROM or reprogram it from the processor, the "clean" state would be guaranteed after the system reset and would allow proper "initialization" or SRL and BlockRAM contents. The async resets are more a leftover from ASIC designs than a sincere need for FPGAs.Article: 74128
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:cjqu87$pf2$1@bunyip.cc.uq.edu.au... > Antti, > > Antti Lukats wrote: > > > the M*Blaze/uCLinux has already received first donation offers, but more > > donations are welcome of course, specially in form of FPGA development > > hardware. > > > PS I am not the author of the open-source M*Blaze, neither is the M*Blaze > > IP-Core downloadable from openchip, the primary download location for the > > M*Blaze IP-Core is the opencores website, project name aeMB. > > You are also not the author of a single line of source code in the > microblaze-uclinux project. You are right that there is no source from me in the uCLinux project, except that I wrote and made available for free to anyone a bootloader from SystemACE for uCLinux image, there is also source code to test the system to mbvanilla compliance, both source codes are available for downloads http://xilinx.openchip.org/index.php?page=3&action=category&cat_id=9 since february 2004, I also have ported uCLinux/MicroBlaze to different FPGA platforms and helped others in such porting. If that doesnt count as contributing to the project in your eyes so be it. > I would appreciate it if you did not make > comments that could be misunderstood as representing me or any other > contributor to that project. I have not made such comments, I am not stupid you know. Besides uCLinux is not your project. I want to see aeMB based system to be mbvanilla compliant, thats all ! If I cant use uCLinux in that context then I will use uC*Linux if that pleases you? > There is no such thing as M*Blaze. The author of aeMB has wisely avoided > any direct reference to Microblaze. If the Leon core had been called > SP*RC, it would have lasted about 10 minutes before Sun jumped on it. sure there is no M*Blaze so why get upset? > Please let the people who do the work, speak for themselves. Did I disturb you doing your work? Sorry if I did wasnt my intent. > Thanks, gee John, sorry to get you upset! That really was not my intent! have abreak have kit-kat take look at the bright side :) anttiArticle: 74129
Thanks for your help, I have updated the file as you said, but unfortunately
I have still the same problem, I only get 0 values thats so strange...
Cheers
Roger
"Goran Bilski" <goran@xilinx.com> wrote in message
news:cjrovc$ihq2@cliff.xsj.xilinx.com...
> Hi,
>
> The problem is that the Write signal is not a ready signal for MicroBlaze
> but it's a write signal into a FIFO.
> So what you have done is to write new values EVERY clock cycle into the
> FIFO which will get full very fast.
>
> If you only want to write back the value that you read, then you should do
> this instead.
> FSL0_M_Write <= FSL_S_Read_i;
>
> This will ensure that you only write when you have valid input data.
>
> Göran
>
> Roger Planger wrote:
>
>>Hello Everybody.
>>
>>First of all thanks antti for your FSL File, now I understand the Read in
>>Process.
>>
>>http://xilinx.openchip.org
>>
>>But for me also very important is to write the data out after the
>>calculation is finished. Here is my actual
>>VHDL Code, so the readin should be okay, and then I only assign the output
>>value the input value after this
>>valid. Then I want to read it out, but unfortunately I always get Output =
>>0, althought I write different values from 1 up to 5 at the data input
>>port!
>>So can perhaps someone give me a hint what is wrong here? Antti do you
>>have a solution for this perhaps?
>>
>>begin -- architecture IMP
>> FSL0_S_Read <= FSL_S_Read_i;
>> FSL_S_Read_i <= FSL0_S_Exists;
>> FSL0_M_DATA <= FSL0_S_Data; -- Output = Input
>> FSL0_M_Write <= '1'; -- Indicates Data is
>> available for reading
>>end architecture IMP;
>>
>>Test Code
>>
>>int data_to_local_link[] = { 1,2,3,4,5 };
>>int data_back_local_link[5];
>>
>>for (k=0;k<5;k++){
>> microblaze_nbwrite_datafsl(data_to_local_link[k],0);
>> microblaze_nbread_datafsl(data_back_local_link[k],0);
>> xil_printf("Testvalue :%x\n\r",data_back_local_link[k]);
>>
>>Output:
>>
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>
>>Cheers
>>Roger
>>
>>
>>
>>
>
Article: 74130> From: rickman <spamgoeshere4@yahoo.com> > Reply-To: john@bluepal.net > Newsgroups: comp.arch.fpga > Date: Sun, 03 Oct 2004 00:28:04 -0400 > Subject: Re: FPGA vs ASIC area > > > > Austin, Peter sends me private emails asking me to ignore your > nonsense. This is a blatant lie (plus a breach of confidence). I had only asked Rick to make peace with Austin, and accept the fact that he has a different style than mine.. Nobody will push a wedge between me and Austin. We are neighbors, partners, and friends, and complement and help each other every day in many ways. This thread seems to have run its course. The original question about the area ratio between ASICs and FPGA was (as I wrote) meanigless and cute. Which one is smaller, uses which process, and takes how long to test is all reflected in one single number, the price charged by the vendor. And there is intense competition which keeps us all on our toes... The user (that is most of the people in this newsgroup) should only be interested in cost, performance, power consumption, design effort, reprogrammability, time to market, availability, and general risk. Smart engineers will know how to make a rational choice. ASICs will be the right choice sometimes, FPGAs will be the right choice in most cases. But we know that in spite of less than 2000 new ASIC designs worldwide per year(!), the high-volume ASIC business is still much larger than the FPGA business. That gives FPGAs a tremendous opportunity to grow. We like that! Peter AlfkeArticle: 74131
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:415F7FD4.F74A300C@yahoo.com... > austin wrote: > Austin, Peter sends me private emails asking me to ignore your > nonsense. He tells me you are a valuable asset to this group because > you have significant knowledge. But your BS is enormous. This comment > is the sort of thing that is not welcome in the group, at least by me. > If you want to discuss the issues, then leave the crap at home. I find > you to be a very unprofessional representative for Xilinx and I have > even told my local sales people that. I don't know if this ever makes > it back to your managers, but I sincerly hope that I never have to > depend on you for any sort of support. In fact, you personally are one > of the reasons that I keep looking at the solutions offered by Altera, > and have ended up filling at least one of the sockets on our boards with > an Altera part. rickman, As one of the many people that see the convesations back and forth between the two of you, please consider that you *may* be predisposed to consider Austin's comments as argumentative. It is the view of this engineer that Austin's behavior on this board is very professional and only suffers occasionally from the frustrations of the inability to communicate clearly what he knows whether due to the limitations of written communications or the receptiveness of the audience. Please try to make your points, not argue them. It's typical of your posts to others to be informative as it is with Austin's. If either of you come to a post by the other as a challenge to his manhood, the conversation won't be productive for anyone. It takes two to tango. Respectfully, John_HArticle: 74132
Jock wrote: > Is it possible to take the FPGA.hex file, for example and given that you > know the device, reverse-engineer it into either it's CLB map or back to > it's high-level HDL code? > > Austin replies: In a word, yes. Given that with the FPGA_Editor tool you can create test designs (a single input through a LUT to a single output), you can eventually map every bit to its corresponding function. The question here is time. Once you have a hardware FPGA_Editor view of the design, you still do not have the HDL representation. The HDL is similar to a high level programming language like c++, but it is dissimilar in that synthesis tools perform logic optimization. The original HDL to the bitstream is a 'many to one' mapping. Many different HDL designs could result in an identical bitstream. So one can then examine the FPGA_Editor 'schematic' and reverse engineer a HDL representation. One then verifies the HDL by synthesizing it, and seeing how it matches the FPGA_Editor view. Since there is no security in obscurity, the bistream in unencrypted form is not considered secure. If someone wants to reverse engineer the design, it might now be possible to do it without expending a lot of time and money. If the obective is to clone the design without analyzing it, or performing only enough analysis to change one or two parameters (ie the clock divisor in the DCM) is quite simple. But to steal the IP for a core, so you could implement it in an ASIC, would be a difficult task to be sure. Do-able, but pretty tough. Might be easier to just re-engineer the core and use the FPGA version to verify it. That, at least, is legal. It is almost certainly true that the reverse engineered HDL would not look at all like the original source code, so copyright on the source would be unenforceable. Copyright on the bitstream (or in China, a mask), would be an enforceable way to take legal action against a clone. Legal action is the last and worst remedy, so I suggest using encryption if the IP is worth protecting. There are a number of companies out there, who do reverse engineering for a living. Sometimes it is for legal reasons (to see if a competitor is infringing on a patent), and sometimes it is done because a company loses its original design, and has to continue maintaining it. These companies do not reverse engineer a design for illegal purposes (otherwise they might be held liable in a lawsuit). I would very much like to be able to apply a cost to reverse engineering a FPGA, however, no one is willing to step up and state how much time (or money) it took to reverse engineer a particular design. I can only speculate. Others on this board have proposed that there are better and faster methods to get the design which I will refer to as 'social engineering'. AustinArticle: 74133
Followup to: <ca4d800d.0408251537.2cf96975@posting.google.com> By author: sdatta@altera.com (Subroto Datta) In newsgroup: comp.arch.fpga > > Hi Manfred, > > Can you elaborate some more. When you say there is a Link, where is > the link and how did your create it? I have the following entries for > my environment variables > > PATH %QUARTUS_ROOTDIR%\bin; > QUARTUS_ROOTDIR D:\quartus41 > > I have been double clicking on qpf's and launching Quartus II 4.1 > without any problems. Also the Quartus II shortcut on my desktop > points to D:\quartus41\bin\quartus.exe. > I've seen this same problem. If I clock on the .qpf file it tries to open the wrong application; trying to change which application is bound to this extension shows a list of applications which doesn't include Quartus; specifying the Quartus path directly via the browse interface doesn't work either. This is with WinXP SP2 (spit.) -hpaArticle: 74134
Hi,
Sorry I didn't look careful enough on your C code.
You are using the nonblocking version of the FSL macros but in this case
you should do the blocking versions.
use "microblaze_bread_datafsl" instead of the "microblaze_nbread_datafsl".
Could you also share the .mhs file so I could see that everything is
connected correctly?
Göran
Roger Planger wrote:
>Thanks for your help, I have updated the file as you said, but unfortunately
>I have still the same problem, I only get 0 values thats so strange...
>
>Cheers
>Roger
>
>"Goran Bilski" <goran@xilinx.com> wrote in message
>news:cjrovc$ihq2@cliff.xsj.xilinx.com...
>
>
>>Hi,
>>
>>The problem is that the Write signal is not a ready signal for MicroBlaze
>>but it's a write signal into a FIFO.
>>So what you have done is to write new values EVERY clock cycle into the
>>FIFO which will get full very fast.
>>
>>If you only want to write back the value that you read, then you should do
>>this instead.
>>FSL0_M_Write <= FSL_S_Read_i;
>>
>>This will ensure that you only write when you have valid input data.
>>
>>Göran
>>
>>Roger Planger wrote:
>>
>>
>>
>>>Hello Everybody.
>>>
>>>First of all thanks antti for your FSL File, now I understand the Read in
>>>Process.
>>>
>>>http://xilinx.openchip.org
>>>
>>>But for me also very important is to write the data out after the
>>>calculation is finished. Here is my actual
>>>VHDL Code, so the readin should be okay, and then I only assign the output
>>>value the input value after this
>>>valid. Then I want to read it out, but unfortunately I always get Output =
>>>0, althought I write different values from 1 up to 5 at the data input
>>>port!
>>>So can perhaps someone give me a hint what is wrong here? Antti do you
>>>have a solution for this perhaps?
>>>
>>>begin -- architecture IMP
>>> FSL0_S_Read <= FSL_S_Read_i;
>>> FSL_S_Read_i <= FSL0_S_Exists;
>>> FSL0_M_DATA <= FSL0_S_Data; -- Output = Input
>>> FSL0_M_Write <= '1'; -- Indicates Data is
>>>available for reading
>>>end architecture IMP;
>>>
>>>Test Code
>>>
>>>int data_to_local_link[] = { 1,2,3,4,5 };
>>>int data_back_local_link[5];
>>>
>>>for (k=0;k<5;k++){
>>> microblaze_nbwrite_datafsl(data_to_local_link[k],0);
>>> microblaze_nbread_datafsl(data_back_local_link[k],0);
>>>xil_printf("Testvalue :%x\n\r",data_back_local_link[k]);
>>>
>>>Output:
>>>
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>
>>>Cheers
>>>Roger
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
Article: 74135> From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com> > Newsgroups: comp.arch.fpga > Date: Mon, 04 Oct 2004 16:51:12 +0200 > To: David <david.lamb@gmail.com> > Subject: Re: Asynchronous reset timing problem > > > One solution would be to synchronize your asynchronous reset by one > flip-flop with his D input connected to the VCC and his RST input > connected to your actual asynchronous reset, and the Q output is your > new pseudo-asynchronous reset of your actual design. > > Larry > www.amontec.com The objective is to eliminate the effect of a long and uncertain delay in the asynchronous reset driven throughout the chip. One single flip-flop might help, but I would augment it with an SRL16 delay of 16 clock ticks, which effectively is free, using the LUT in front of the flip-flop. Peter AlfkeArticle: 74136
(In a discussion about reset and SRL16) Ray Andraka wrote: > Depends on your design and what you are willing to settle for. Technically > speaking, all you really need to do is provide a way of clearing stuff in your > design tht is inside hardware loops. For example, a state machine or an IIR > filter have a 'loop' that needs to be broken in order to bring the hardware to a > known state. In many cases, it is perfectly acceptable to clear only key points > in the design, and sometimes even require the reset be asserted for some minimum > number of clock cycles to achieve a known state. Yes, the easy methodology is > to reset every flip-flop, but it is not necessary and can cost you dearly in > terms of both gates and reset signal fan out (and therefore delay). I believe it is important for testing purposes that a known state be reached with a known combination of reset, clocks, and other signals. It might be that a design would work perfectly well in any of the possible reset states, but it wouldn't be testable. Well, that is mostly for ASICs where test vectors need to be supplied to the fab. For FPGAs it might not be necessary, though test vector sets are nice to have. -- glenArticle: 74137
Bidirectional communications are fine. You probably don't need a full-blown microcontroller for the implementation, you just need the intelligence in the FPGA to perform the proper setup and interrogation over the link. You could probably interface the sensor to the smallest CPLDs available with a simple state machine. Your FPGA choice is fine. "Viswan" <viswan_1981@hotmail.com> wrote in message news:c9cb3993.0410040849.608c9f4f@posting.google.com... > hi, > > I have a doubt on using inout ports in FPGA design. I am implementing > an application on FPGA, that should be interfaced to SHT71(Sensirion > humidity and temperature sensor). My FPGA gets the value of > temperature and humidity from the sensor and calculates > moisture(output) using certain equations. > > I have designed the arithmetic unit required to calculate the moisture > value in VHDL, and synthesized on to FPGA. But now I have to > interface this unit to the sensor(SHT71), and the sensor needs to have > a controller(any microcontroller as specified in the SHT71 datasheet) > to control its operations and get the values of temperature and > humidity. The sensor has a bidirectional data signal as one of the > ports, and that should be connected to the controller to send and > receive data. I want to implement the controller also on the same > FPGA itself. But is it possible? Is it possible to handle a > bidirectional port from an FPGA to send and receive data? I am using > Virtex XCV800 HQ240I. Or is it suggestible to use any standard > microcontroller as an interface between sensor and FPGA? > > Any suggestion on this is highly appreciated. > > ThanksArticle: 74138
Hi david, Apperently we have similar problems. I am designing my own peripheral that needs to read/Write a word in every clock cycle. This peipheral is connected to the SDRAM controller as a master on the Avalon bus. What I see in simulation, when I am connecting to the SDRAM controller, is bursts of 2 words and then 2 or 3 clocks delay etc. I think the difference between my application (and I guess yours too) and Kenneth's, is that Kenneth is using a DMA to burst data whereis we are using a simple master to slave transactions. Maybe by instantiating the DMA in the SOPC builder, the SDRAM contoller is configured to longer bursts. I started develpoing my own SDRAM controller that will support full page bursts, but if I will find a way the SDRAM controller is working, I might return to it. Zohar "David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cjrh8o$ck5$1@news.netpower.no>... > "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message > news:10lnrtjlg7sff75@news.supernews.com... > > > > "Markus Meng" <meng.engineering@bluewin.ch> wrote in message > > news:aaaee51b.0409290819.a6020e5@posting.google.com... > > > Hi all [SOPC users], > > > > > > is there a way a can configure the read burst length of the > > > standard SDRAM controller within SOPC 4.1? > > > > > > Best Regards > > > Markus > > > > Hi Markus, > > > > You might try asking this over on the Nios Forum (www.niosforum.com). I'd > > like to know the answer as well. I looked through the controller's > > class.ptf file and even the verilog source and don't see anything. > > > > On writes however, I'm getting bursts of at least 480 long words at one > > clock per word. (my system is running at 75MHz) > > > > Did you have to do anything special to achieve that? I have a custom > peripheral that is writing as fast as it can to the sdram, but I'm getting > one 32-bit write every 3 clocks. With the prototype system I have at the > moment, that's good enough, but I'd like to improve on it when we start > making the real thing. When reading, I'm getting one read every 2 clocks - > again, it's not ideal but it works. I'd expect one read/write per clock for > most of the burst, with some waits while changing banks or refreshing. > > Also, my reader and writer peripherals are independant, so sometimes they > coincide. The Avalone bus arbitration apparently cannot take bursting into > account, and swaps between the two accesses. Is there any way this can be > improved upon, or do I have to implement my own mini-arbitrator to control > the two peripherals?Article: 74139
david.lamb@gmail.com (David) wrote in message news:<4b5ddf5.0410040548.21c08f01@posting.google.com>... > When I perform a post-place and route simulation, I get some timing > errors depending on when I de-assert 'resetb' in the testbench. If it > is too close to a rising clock edge, everything becomes red in the > waveform. I understand there are some setup/hold conditions, but I > wonder what will happens in real life since at 200Mhz, it looks like I > get timing errors most of the times...actually, I need to de-assert > resetb very close to the falling edge of the clock. Anywhere else > gives errors. Are there any solutions to this? I have always used asynchronous resets with an "asynchronous assert / synchronouse de-assert" circuit. This makes timing of the reset release deterministic and allows asynchronous assertion. For timing analysis it is most straightforward to just synchronize the signal and feed your async flop resets with the synchonrous reset.Article: 74140
"Thomas Reinemann" <thomas.reinemann@masch-bau.uni-magdeburg.de> wrote in message news:cjr0r2$jf4$1@fuerst.cs.uni-magdeburg.de... > Hello, > > according Xilinx Homepage > http://www.xilinx.com/products/tables/fpga.htm#v2 my FPGA (XC2V1000) > should have 720 kbit Block-RAM. But if I look into it, using the FPGA > Editor a Blockram has two units each 2048*9 bits e.g. furthermore the > whole FPGA has 4x10 RAM blocks. This results in > 2048*9 * 2 * 4 * 10 = 1440 kbit, of course twice of Xilinx' > specification. Since 4 columns and 10 rows are surely right, the > presumption of 2 units per block has to be wrong. > > Please point me out where I'm wrong! > > Bye Tom. blockram has 2048*9 bits that look like to blocks because its dual ported ram, the amount of bits is 2048*9 what makes the math match again right? anttiArticle: 74141
David wrote: > Hello everyone, > I have a very basic master state machine that is clocked at 200Mhz in > a virtexII-pro. It has an asynchronous reset input that comes from a > push-button on the board. Code looks like this: > > always @ (posedge mclk or negedge resetb) > begin > if (~resetb) begin > state <= rst; > end > else begin > case(state) > rst : > begin > state <= rstInputStage; > etc... > > When I perform a post-place and route simulation, I get some timing > errors depending on when I de-assert 'resetb' in the testbench. If it > is too close to a rising clock edge, everything becomes red in the > waveform. I understand there are some setup/hold conditions, but I > wonder what will happens in real life since at 200Mhz, it looks like I > get timing errors most of the times...actually, I need to de-assert > resetb very close to the falling edge of the clock. Anywhere else > gives errors. Are there any solutions to this? > Thanks, > David There are two issues here: a design issue and a tool issue. To address the tool issue, if you are using ModelSim, you probably want to use the -notimingchecks option. Look this up in the documentation. This will prevent setup errors from being propagated as X's. -KevinArticle: 74142
iceman wrote: > ei anyone can help me with the algorithm on how to control a > servomotor... cause we are gonna use it on our thesis... by the it's > called "FPGA based intravenous infusion monitoring and control system" > > can anyone help us out on how to control a servomotor...will be using > the servomotor to clamp the tube of an I.V.(intravenous) tube... the > flow of the algorithm will bw this... first a personnel will input how > many dosage a patient gets and then the servomotor will clamp the I.V. > tube so that the desired dosage is achive... by the way will be using > optical sensors to monitor the drops of the I.V. fluid i will be > placed at the outside of the drip chamber... > > but we have a problem what if the drip of the fluid change how will > the servomotor adjust it so that the dosage will be maintained...will > use a feedback but how are we gonna implement it on FPGA.. > > got any suggestion on the algorithm... or any sites that can help us > solve this problem Is the volume of a drop constant no matter the drip rate? Controlling R/C servomotors is pretty easy. There is lots of info on the web. I think the position is controlled by the length of an input pulse. Maybe a better method would be to use a stepper motor connected to a wormscrew clamp. Then you could control the absolute position (rather than relative) better. -KevinArticle: 74143
"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:_6KdnS3Cx_w3m8PcRVn-iQ@rogers.com... > Hi Martin, [snip] > > > Both devices used are the fastest speed grade available. Is the Cyclone, > > although 'older', faster than the Spartan-3? > > Yes. This performance result is actually pretty poor as far as Cyclone vs. > Spartan-3 goes. We see an average of 80% better performance -- yes, that's > 1.8X Fmax -- when comparing the fastest speed grades of the two chips with > default "push-button" results from Quartus & ISE over a suite of 49 designs. > Another way of looking at it is the slowest Cyclone speed-grade out-performs > the fastest Spartan-3 speed-grade by a considerable margin. See > http://www.altera.com/products/devices/performance/lowcost_performance/per-lowcost_performance_fpga.html > for details. Danger, Danger, Will Robinson, my B.S. sensors have detected significant marketing content. :-) As made famous by Philip Freidin (www.fliptronics.com), "There are four kinds of lies. 1. Lies 2. Damn lies 3. Statistics 4. Benchmarks <--- ***** and in a category all by themselves, 'expense reports'". Like Altera, Xilinx marketing has a benchmark suite showing that Spartan-3 performs better than Cyclone (shocking, I know). My own personal suite uses more typical customer designs and shows a healthy mix of wins and losses, very much depending on the characteristics of the design. If Cyclone were _really_ 80% faster on _average_ than Spartan-3 comparing fastest to fastest speed grades, do you _really_ think that this real-world customer design, using out-of-the-box, default "push-button" settings, is all that pathological? The two out-of-the-box results were roughly the same when you compare the slowest speed grades for each family. Cyclone -8 speed grade (slowest speed grade): 77.5 MHz Spartan-3 -4 speed grade (slowest speed grade): 77.8 MHz This is further borne out when you consider that Xilinx chose to have only two speed grades for Spartan-3. For Xilinx devices, a speed grade represents about a 15% speed difference. Cyclone -6 speed grade (fastest of 3 speed grades): 98 MHz Spartan-3 -5 speed grade (fastest of 2 speed grades): 82 MHz 15% over Spartan-3 -5 would result in 96.5 MHz The comments about tweaking the default settings is very appropriate. Changing a few of the default settings can have dramatic effect. Likewise, small changes in coding can shave a layer or two of logic in a critical clock path. We cover some of these techniques at the upcoming Programmable World seminar series. (Danger, danger, Marketing content follows!) Programmable World 2004 http://www.xilinx.com/events/pw2004/ In specific, check out Workshop 3 in the Logic track. Workshop 3: Spartan-3 and Low-Cost FPGA Design Techniques. http://www.xilinx.com/events/pw2004/tracks/logic.htm --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 74144
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:sjA7d.330096$vG5.66679@news.chello.at... > > As a quick aside, Cyclone has three speed grades, Spartan-3 only two. > In > > general, a speed grade represents about a 15% difference in > performance. > > > > Slowest vs. slowest speed grade would be interesting. > > Ok, here it is: > Cyclone slowest (-8): 77.5MHz > Spartan slowest (-4): 77.8MHz > Looks now better for X.... Thank you. The results were about what I expected. > And now let's throw in some price numbers. Prices are single units from > arrow.com and avnet.com, both devices in the same package (tqfp144): > Cyclone: EP1C6T144C6: $41.60 > Cyclone: EP1C6T144C8: $27.70 > Spartan-3: XC3S200-4TQ144C: $19.93 > no price for -5 speed grade > > And relate the price to density and speed in a 'funny' way: > price / 1000 LCs / MHz: > > EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz > EP1C6-8: 5.98 cent / kLC /MHz > XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz > and now it looks again better for A... [snip] Be careful with this kind of analysis. Yes, it's helpful from an academic point. However, the Spartan-3 XC3S1000 offers a sweet spot on cost per logic cell. Does this mean that everyone should use the XC3S1000 when a smaller part will do? No, you want to choose the lowest cost part that gets the job done. BTW, nice job on the Java processor! Very cool. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 74145
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:wBG7d.6267$mZ2.556191@news02.tsnz.net... > Martin Schoeberl wrote: > > Btw, does somebody know why the lead free devices are more expensive. I > > did'n know up to now that semiconductors contain lead. I only know that > > it's part of the solder and when it's forbidden will probably increase > > production cost of PCBs. > >>The alloid used are more complex and uses more precious metals. (for > >>the solder balls and solder plating of terminal) > >>Sn/Pb before > >>and now, like Nickel/Palladium > > > > > > Solder balls ok, but that difference in QFP packages? > > That's an easy one : because they can. > It's a good place to do a little cost recovery/price racking, > as users will have designed in the devices, and are thus captive > by both the legistation and the layout, plus many do not > compare Pb/PbFree prices, so that's the ideal time to nudge the > prices! There are two reasons behind the price difference between the standard Sn/Pb packages and the Pb-free packages. The number one price difference is due to volume. I don't have specific data at my fingertips but the Sn/Pb packages are produced in significantly larger quantities. In the semiconductor business, bigger volumes mean lower unit cost. The Pb-free packages are a relatively recent addition. I would expect that prices will drop to a certain extent as these packages become more the norm. The second reason is content. Sn and Pb are inexpensive. The Ag and Cu in the Pb-free alloy is more expensive. For more information, check out the following Xilinx application note. Note that the standard and Pb-free packages may require different assembly techniques. XAPP427: Implementation and Solder Reflow Guidelines for Pb-Free Packages http://www.xilinx.com/bvdocs/appnotes/xapp427.pdf Also, just FYI for those that care, all Spartan-3 devices are available in Pb-free versions of all supported package types. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 74146
> Did you have to do anything special to achieve that? I have a custom > peripheral that is writing as fast as it can to the sdram, but I'm getting > one 32-bit write every 3 clocks. With the prototype system I have at the > moment, that's good enough, but I'd like to improve on it when we start > making the real thing. When reading, I'm getting one read every 2 clocks - > again, it's not ideal but it works. I'd expect one read/write per clock for > most of the burst, with some waits while changing banks or refreshing. > > Also, my reader and writer peripherals are independant, so sometimes they > coincide. The Avalone bus arbitration apparently cannot take bursting into > account, and swaps between the two accesses. Is there any way this can be > improved upon, or do I have to implement my own mini-arbitrator to control > the two peripherals? Hi David, There are a number of factors that affect SDRAM performance in the general sense. Typically you'll achieve best performance (approaching one clock per word read or write) if the accesses to SDRAM that are presented by your peripheral are burst-like. That is, you are reading from or writing to sequential accesses without interruption; this applies to our SDRAM controller. Even when transactions are optimal, you'll still face the occasional bank-switch delay when your address causes a bank changes, and of course, the inevitable refresh delay every so often. By contrast "thrashing" SDRAM, like thrashing a microprocessor cache, will have negative performance consequences... by thrash I mean accesses that are all over the place, requiring the SDRAM controller to take time switching banks continuously. To address your concerns: first, we have some enhancements to Avalon in the works that will address a lot of these problems for the case you present (wanting to achieve burst-performance between multiple peripherals). If the results you're getting are good enough for now, I'd suggest waiting for the next SOPC Builder release as it will include these Avalon enhancements. If you need better performance right now with your setup, feel free to send me an email and I'd be happy to give you a few pointers (about avalon arbitration and a couple other things) that may help. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 74147
Kenneth Land wrote: > > "Markus Meng" <meng.engineering@bluewin.ch> wrote in message > news:aaaee51b.0409290819.a6020e5@posting.google.com... >> Hi all [SOPC users], >> >> is there a way a can configure the read burst length of the >> standard SDRAM controller within SOPC 4.1? >> >> Best Regards >> Markus > > Hi Markus, > > You might try asking this over on the Nios Forum (www.niosforum.com). I'd > like to know the answer as well. I looked through the controller's > class.ptf file and even the verilog source and don't see anything. > > On writes however, I'm getting bursts of at least 480 long words at one > clock per word. (my system is running at 75MHz) > > Ken Have you guys looked at increasing the arbitration priority for the SDRAM controller? The NIOS needs to fetch opcodes every once in awhile. BenArticle: 74148
Steven K. Knapp wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message > news:wBG7d.6267$mZ2.556191@news02.tsnz.net... > >>Martin Schoeberl wrote: >> >>>Btw, does somebody know why the lead free devices are more expensive. I >>>did'n know up to now that semiconductors contain lead. I only know that >>>it's part of the solder and when it's forbidden will probably increase >>>production cost of PCBs. >>> >>>>The alloid used are more complex and uses more precious metals. (for >>>>the solder balls and solder plating of terminal) >>>>Sn/Pb before >>>>and now, like Nickel/Palladium >>> >>> >>>Solder balls ok, but that difference in QFP packages? >> >> That's an easy one : because they can. >>It's a good place to do a little cost recovery/price racking, >>as users will have designed in the devices, and are thus captive >>by both the legistation and the layout, plus many do not >>compare Pb/PbFree prices, so that's the ideal time to nudge the >>prices! > > > There are two reasons behind the price difference between the standard Sn/Pb > packages and the Pb-free packages. > > The number one price difference is due to volume. I don't have specific > data at my fingertips but the Sn/Pb packages are produced in significantly > larger quantities. <snip> I thought one of the targets of PbFree was to try and get a package/alloy solution that could be used in either flow ( and so the Pbfree would be phased in, to replace the older ones ) Is that turning out to not be practical ? Also IIRC 'PbFree' actually means < 0.1% by weight ? -jgArticle: 74149
Peter Alfke wrote: > > > From: rickman <spamgoeshere4@yahoo.com> > > Reply-To: john@bluepal.net > > Newsgroups: comp.arch.fpga > > Date: Sun, 03 Oct 2004 00:28:04 -0400 > > Subject: Re: FPGA vs ASIC area > > > > > > > > Austin, Peter sends me private emails asking me to ignore your > > nonsense. > > This is a blatant lie (plus a breach of confidence). Which is it, a lie or a breach of confidence??? Besides, I don't recall you asking that I keep it a secret. You just asked me not to argue with him. > I had only asked Rick > to make peace with Austin, and accept the fact that he has a different style > than mine.. Perhaps I didn't get the words exactly right, but you acknowledge the concept. My point was that even you understand that he goes beyond the norm in his posts. > Nobody will push a wedge between me and Austin. We are > neighbors, partners, and friends, and complement and help each other every > day in many ways. No one is trying to spilt you two up. You can sit next to each other as much as you want. > This thread seems to have run its course. The original question about the > area ratio between ASICs and FPGA was (as I wrote) meanigless and cute. > Which one is smaller, uses which process, and takes how long to test is all > reflected in one single number, the price charged by the vendor. And there > is intense competition which keeps us all on our toes... > > The user (that is most of the people in this newsgroup) should only be > interested in cost, performance, power consumption, design effort, > reprogrammability, time to market, availability, and general risk. > Smart engineers will know how to make a rational choice. Yes, that is the opinion I have stated exactly. The end user does not care about the details of how results are obtained since there are far too many details for any one to be an indicator. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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