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
Dear everybody, I have developed a NIOS II based project which must run on a Cyclone with speed grade 7. The project contains only a NIOS II/f configuration which includes the following pheriperals: - SRAM interface designed with user custom logic - common flash interface - one interval timer - three uarts - two tightly coupled on-chip memory blocks - one on-chip memory block used as boot ROM The input clock is 100 Mhz (derived by 25 MHz FPGA input clock multiplied by PLL). The compilation flow runs successfully except for the timing analyzer which issues a critical warning says the timing requirements are not met. Taking a look at the timing analyzer summary report I see that the fmax of the project is 74.56 MHz (against my desidered fmax of 100 MHz). I have tried to get timing analyzer run successfully by changing some fitter options but the results are the same. At the end of the compilation flow the summary reports that the resources needed by the project are 32 % of the device. First question: is 74.56 MHz a fmax limit of NIOS II/f integrated on a Cyclone device ? Second question: is there a way to improve the fmax in order to match my desidered frequency ? Best Regards /Alessandro StrazzeroArticle: 94676
On a sunny day (16 Jan 2006 01:15:40 -0800) it happened "al82" <yscdi62k001@sneakemail.com> wrote in <1137402939.962474.326660@o13g2000cwo.googlegroups.com>: > >> >> Some info in this presentation particularly with respect to long-life >> critical systems. >> > >Don't worry. > >Military electronics is not covered by the RoHS directive. ;-) > Yea, as in that field, bullets are no longer made of lead but of depleted uranium,. Some people claim it is very safe. Cannot use it for soldering, >1300 Celcius melting point. But plutonium perhaps? 640 C. There is already too much of it, http://arq.lanl.gov/source/orgs/nmt/nmtdo/AQarchive/98fall/magnetic_levitation.html so put it to good use.....Article: 94677
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message news:dqg95m$hj$1@news.datemas.de... > Yea, as in that field, bullets are no longer made of lead but of > depleted uranium,. > Some people claim it is very safe. > Cannot use it for soldering, >1300 Celcius melting point. > But plutonium perhaps? 640 C. There is already too much of it, > http://arq.lanl.gov/source/orgs/nmt/nmtdo/AQarchive/98fall/magnetic_levitation.html > so put it to good use..... > It's best to save DU to use as ballast in the back of Boeing 747s. See:- http://news.bbc.co.uk/1/hi/uk_politics/618204.stm DU is used because it's cheaper than Tungsten. Cheers, Syms.Article: 94678
On Sat, 14 Jan 2006 23:00:05 +0100, Holger Blum <usenet0106@kennsch.net> wrote: >Hello! > >While working with a MAC-FIR I came across an equation in Xilinx' >DSP-book (http://www.xilinx.com/publications/books/dsp/dsp-book.pdf) >which seems to be wrong in my eyes. > >On page 65 equation 4.4 for the generic saturation level says >Output width = ceil(log2(2^(b-1)*2^(c-1)*N))+1 >Where b/c are the numbers of data/coefficient bits and N is the filter >length. > >This formula is, apart from a missing parenthesis, ok, but the next one >for known coefficients says >Output width = ceil(log2(2^(b-1)*abs(sum(coef))*N))+1 > >Again missing right parenthesis and the N is in my eyes wrong, because >it is already included in the sum of coefficients. Could anyone approve >this? I have to cite this paper in a thesis in lack of another source >for this equation (though it seems to be obvious, but I have to be sure). The coefficients can be both positive and negative, and (for a unity gain filter) will typically sum to 1, not N. Incidentally, counting the parentheses, I make it 5x( and 5x) in the above equation; where is the missing one? - BrianArticle: 94679
I want to implement an ata controller in the fpga,the controller use the ultra dma mode to read and write datas,and I want to know if it is difficult to implement it.Can some one give me some advice.Article: 94680
Hi Alessandro, There are a few options... use Speedgrade 6, use the Pineline option in the SOPC Builder clock setup, split your design in a 100MHz, and lower speedpart.... (which will introduce big latencies when crossing the clock domains, but enables the 100 MHz logic to be small and therefore fast) Maybe you can be happy with the standard or economy core. They might have a higher fmax, to match your speed, but give lower MIPS. Have fun !Article: 94681
For PROMs I generally make Intel Hex files (.mcs) although the programmer we use from BP can take many different file formats. I only use this for programming parts off-board. For in-system programming you generally need a file format that works with your embedded software. For Xilinx bitstreams I generally prepare a "Hex" format file which is just a stream of hex characters with no header or other information (just the bits, ma'am). This I usually convert to a binary file for use by the embedded system (to reduce file size. Antti Lukats wrote: > "antonio bergnoli" <bergnoli@pd.infn.it> schrieb im Newsbeitrag > news:43cb5fd1$2_2@x-privat.org... > > Hi, > > I want to know if anybody has never programmed fpga or proms not using > > Impact or Quartus programmer but other (third party) tools. If yes, how ? > > which are the file formats to use? > > Thanks in advance. > > lots of people do that. > > most of the info is available, sometimes it needed to reverse engineer SVF > or BSDL files to complement the public information > > there are different formats that can be used depending on device targetted > > > -- > Antti Lukats > http://www.xilant.comArticle: 94682
"bjzhangwn" <bjzhangwn@126.com> wrote in message news:1137423677.818816.281490@g43g2000cwa.googlegroups.com... >I want to implement an ata controller in the fpga,the controller use > the ultra dma mode to read and write datas,and I want to know if it is > difficult to implement it.Can some one give me some advice. > I advise you to put the subject of your post into a search engine, perhaps Google would be a good start, and see where that takes you. Also :- http://groups.google.com/groups?as_q=ata+controller+fpga I hope Google works in China? HTH, Syms.Article: 94683
I see just one problem... It won't handle longer (PCI raw form-factor) PCI cards without an additional riser. Are you using the hot plug capability and if so, how does it work? Steven wrote: > Hello everyone > > Just wanted to share some of my recent experience from switching to > Amfeltec PCI extender from the one from Ultraview (the old one burnt > last month). > Amfeltec works very nice for me - easy to plug in, compact enough to > fit a small box, > comes with software for Linux, FreeBSD and Windows and also different > types of brackets. The extender has a built-in byte blaster that I use > with my Xilinix and Altera > FPGAs, which means that I need now just one tool instead of three. > > It's a cool product, quite unique I'd say, the more I use the more I > like it. > You can find it at http://www.amfeltec.com > > StevArticle: 94684
Hi, first thing: Understand how a frame is built up. (HSync, VSync, front porch HSync, back porch HSync, HSync Active Time, HSync Start Time, front porch VSync, back porch VSync, VSync Active Time, VSync Start Time, HSync Polarity, VSync Polarity etc.) Write some hardware which acts as a frame generator. If you are writing the frames into memory and then reading it back to display them you have to know the different sync parameters of the original frame. So you need some SyncDetectParam module For example you should know when to start reading out of the SRAM ( parameters HActiveStart, VActiveStart). Apart from that you have to make some calculations how big the SRAM has to be and whether you can support the desired pixel clock so that there will be no overflow (frames or parts of frames get lost because you are writing faster than you are reading). Alternatively you could use SDRAM (Single Data rate) if you want to be faster. Rgds Andr=E9 qtommy schrieb: > HI, All > I have questions regarding a project i am currently working on. > I have been assigned to develop an vga_controller with the sparten3.And > now there is problem with the dynamic memory. It should at first save the > picture to the sram and then read out and show it on the monitor. And i > have written any code. But there is still problem. Does anynone know, > where can i get any tutorial of the vga_controller? Thanks!Article: 94685
As I said, you need to have acess to ISE 8.1 (note the version number). In FED 8.1, you can select "Directed Routing Nets" from the List window. It then shows all the directed rounting nets in the ncd and their status (Type. Matched, etc). HTH, JimArticle: 94686
Antti Lukats wrote: > "qtommy" <qingwang_1978@hotmail.com> schrieb im Newsbeitrag > news:O-SdnWCndoFhB1beRVn_vQ@giganews.com... > > >Dear all, > >> > >>This may sound stupid to ask, but I am very frustrating now as my > >>deadline is approaching. I want to make use of the VGA generator > >>example on www.xess.com. How could I write/read data to the specific > >>address of the SRAM? > >>I would have to have a SRAM controller that writes and reads data to > >>the SRAM? How should that be implemented in VHDL? What else do I > >>need? I am planning to hard code the data to SRAM. Thank you very > >>much!!! > >> > > > > HI, I just also do the same work. I have the same problem. And have you > > resolve the problem? I would like to discuss it with you! Hier is my email > > address: qingwang_1978@hotmail.com. > > > > > > The xess demo only reads from the SDRAM, for write access you need to make > some statemachine based arbiter that will allow write access the SDRAM, > there is no demo for that unfortunatly, I did a quick dirty thing once it > only wrote a small image from camera in the SDRAM Actually, this is no longer true. We have a new VGA generator application that allows the image data to be updated in the SDRAM while the VGA generator is operating (http://www.xess.com/appnotes/an-103005-vgagen.html). This is done using a dual-port module that fits onto our SDRAM controller and allows you to have multiple, independent channels in and out of the external SDRAM. > > -- > Antti Lukats > http://www.xilant.comArticle: 94687
<devb@xess.com> schrieb im Newsbeitrag news:1137427117.144265.241180@o13g2000cwo.googlegroups.com... > > Antti Lukats wrote: >> "qtommy" <qingwang_1978@hotmail.com> schrieb im Newsbeitrag >> news:O-SdnWCndoFhB1beRVn_vQ@giganews.com... >> > >Dear all, >> >> >> >>This may sound stupid to ask, but I am very frustrating now as my >> >>deadline is approaching. I want to make use of the VGA generator >> >>example on www.xess.com. How could I write/read data to the specific >> >>address of the SRAM? >> >>I would have to have a SRAM controller that writes and reads data to >> >>the SRAM? How should that be implemented in VHDL? What else do I >> >>need? I am planning to hard code the data to SRAM. Thank you very >> >>much!!! >> >> >> > >> > HI, I just also do the same work. I have the same problem. And have you >> > resolve the problem? I would like to discuss it with you! Hier is my >> > email >> > address: qingwang_1978@hotmail.com. >> > >> > >> >> The xess demo only reads from the SDRAM, for write access you need to >> make >> some statemachine based arbiter that will allow write access the SDRAM, >> there is no demo for that unfortunatly, I did a quick dirty thing once it >> only wrote a small image from camera in the SDRAM > > Actually, this is no longer true. We have a new VGA generator > application that allows the image data to be updated in the SDRAM while > the VGA generator is operating > (http://www.xess.com/appnotes/an-103005-vgagen.html). This is done > using a dual-port module that fits onto our SDRAM controller and allows > you to have multiple, independent channels in and out of the external > SDRAM. > sorry, I did not know - it does pay off to look at XESS website from time to time to get new stuff!! independant channel support is really nice thing to have >> Antti Lukats >> http://www.xilant.com >Article: 94688
<jimwu88NOOOSPAM@yahoo.com> wrote in message news:1137426043.170197.3130@g14g2000cwa.googlegroups.com... > As I said, you need to have acess to ISE 8.1 (note the version number). All right, I did get that mate!! ;-) > In FED 8.1, you can select "Directed Routing Nets" from the List > window. It then shows all the directed rounting nets in the ncd and > their status (Type. Matched, etc). > Aha, now I see what you're saying, there's a new feature! Cool, I'll try it, even though it goes against my principle of waiting for SP3! > > HTH, > Sure does, many thanks! > > Jim >Article: 94689
Thanks for the ideas both of you.Article: 94690
Hi,
The following is the part of my code to drive 4 output ports with one
combinational signal:
LatchA : process(CLK66M)
begin
if(CLK66M'event and CLK66M = '1') then
A0_O <= RowPtr;
A1_O <= RowPtr;
A2_O <= RowPtr;
A3_O <= RowPtr;
...
endif;
end process;
1. RowPtr is a combinational signal;
2. A0_O, ... are 4 separate output pins;
3. I thought that Xilinx compiler 7.1 should create 4 registers for
each output pin and the output pins should be located in the I/O
blocks. But they are not. Only one middle register is created and is
located in the geometric center of 4 output pins, then 4 wires are
connected to the 4 output pins, leading to clock-to-output time
violations.
My question is:
How do I direct Xilinx compilter to generate 4 individual registers for
the above equations?
I tried the following attibute statement and failed:
attribute MAX_FANOUT: string;
attribute MAX_FANOUT of A0_O: integer is "1";
attribute MAX_FANOUT of A1_O: integer is "1";
attribute MAX_FANOUT of A2_O: integer is "1";
attribute MAX_FANOUT of A3_O: integer is "1";
Error information:
Line 1957. parse error, unexpected IDENTIFIER
attribute MAX_FANOUT: string;
attribute MAX_FANOUT of A0_O: integer is "13";
attribute MAX_FANOUT of A1_O: integer is "13";
attribute MAX_FANOUT of A2_O: integer is "13";
attribute MAX_FANOUT of A3_O: integer is "13";
Error information:
Line 1957. parse error, unexpected IDENTIFIER
attribute MAX_FANOUT: string;
attribute MAX_FANOUT of A0_O(0): integer is "1";
attribute MAX_FANOUT of A1_O(0): integer is "1";
attribute MAX_FANOUT of A2_O(0): integer is "1";
attribute MAX_FANOUT of A3_O(0): integer is "1";
Error information:
Line 1957. parse error, unexpected OPENPAR, expecting COLON
An suggestion for Xilinx compiler designers:
1. When one same combinational signal drives several output pins (the
situation are very common for memory storage system to access large
amount of memory chips), there should have 3 options:
1: as designed now;
2. create multiple registers with same combinational signal, their
locations can be adjusted to locate between the geometric center of
their target I/O blocks and the I/O blocks to get the best balances
between the delays from the combinational signal to the input of the
register and the clock-to-output timing;
3. All multiple registers are located in I/O blocks.
For example, in my case,
My running timing requirement is met, but clock-to-output timing is
violated. If all registers are located in I/O blocks, clock-to-output
timing may be met, but the running frequency may be violated. In that
situation, all 4 registers should be located near I/O blocks to meet
both timing requiments. Not like current case that either one register
is located in the geometri center or in I/O blocks.
Thank you.
Weng
2.
Article: 94691Hello, try to use the "KEEP" attribute for each signal. Regards, Ivan wtxwtx@gmail.com wrote: > Hi, > The following is the part of my code to drive 4 output ports with one > combinational signal: > LatchA : process(CLK66M) > begin > if(CLK66M'event and CLK66M = '1') then > A0_O <= RowPtr; > A1_O <= RowPtr; > A2_O <= RowPtr; > A3_O <= RowPtr; > ... > endif; > end process; > > 1. RowPtr is a combinational signal; > 2. A0_O, ... are 4 separate output pins; > 3. I thought that Xilinx compiler 7.1 should create 4 registers for > each output pin and the output pins should be located in the I/O > blocks. But they are not. Only one middle register is created and is > located in the geometric center of 4 output pins, then 4 wires are > connected to the 4 output pins, leading to clock-to-output time > violations. > > My question is: > How do I direct Xilinx compilter to generate 4 individual registers for > the above equations? > > I tried the following attibute statement and failed: > attribute MAX_FANOUT: string; > attribute MAX_FANOUT of A0_O: integer is "1"; > attribute MAX_FANOUT of A1_O: integer is "1"; > attribute MAX_FANOUT of A2_O: integer is "1"; > attribute MAX_FANOUT of A3_O: integer is "1"; > > Error information: > Line 1957. parse error, unexpected IDENTIFIER > > attribute MAX_FANOUT: string; > attribute MAX_FANOUT of A0_O: integer is "13"; > attribute MAX_FANOUT of A1_O: integer is "13"; > attribute MAX_FANOUT of A2_O: integer is "13"; > attribute MAX_FANOUT of A3_O: integer is "13"; > > Error information: > Line 1957. parse error, unexpected IDENTIFIER > > attribute MAX_FANOUT: string; > attribute MAX_FANOUT of A0_O(0): integer is "1"; > attribute MAX_FANOUT of A1_O(0): integer is "1"; > attribute MAX_FANOUT of A2_O(0): integer is "1"; > attribute MAX_FANOUT of A3_O(0): integer is "1"; > > Error information: > Line 1957. parse error, unexpected OPENPAR, expecting COLON > > An suggestion for Xilinx compiler designers: > 1. When one same combinational signal drives several output pins (the > situation are very common for memory storage system to access large > amount of memory chips), there should have 3 options: > 1: as designed now; > 2. create multiple registers with same combinational signal, their > locations can be adjusted to locate between the geometric center of > their target I/O blocks and the I/O blocks to get the best balances > between the delays from the combinational signal to the input of the > register and the clock-to-output timing; > 3. All multiple registers are located in I/O blocks. > > For example, in my case, > My running timing requirement is met, but clock-to-output timing is > violated. If all registers are located in I/O blocks, clock-to-output > timing may be met, but the running frequency may be violated. In that > situation, all 4 registers should be located near I/O blocks to meet > both timing requiments. Not like current case that either one register > is located in the geometri center or in I/O blocks. > > Thank you. > > Weng > > > > > 2. >Article: 94692
> I tried the following attibute statement and failed: > attribute MAX_FANOUT: string; > attribute MAX_FANOUT of A0_O: integer is "1"; > attribute MAX_FANOUT of A1_O: integer is "1"; > attribute MAX_FANOUT of A2_O: integer is "1"; > attribute MAX_FANOUT of A3_O: integer is "1"; attribute MAX_FANOUT: string; attribute MAX_FANOUT of A0_O: net is "1";Article: 94693
In article <dqflq9$sfp$01$1@news.t-online.com>, Antti Lukats wrote: > > Phil, Atmel AT40K/AT94K bitstream format is almost open > eg it is available under NDA from Atmel, and open source reverse engineered > documentation is also available - no NDA :) Hmm... will google show me this? :) > As of BIG FPGA companies making their bitstream format public - do not hope! > > second there are factory test bits and settings, again something that the > end user should not mess up All the better to have documentation, no? > so there are reasons for keeping the bitstream non public. I happen to disagree. We are all entitled to our opinions of course. If the vendors would have a well defined format to "compile" to, and a good library/port for a program to be able to take this format and then generate a bitstream, that would be a start. Note, I'd want to have the source available to be so that I could port this last bit of "technology" to my favourite OS (by choice or necessity). I can't believe that these things are anything but simple portable ANSI C (or some derivative)... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 94694
Brian Drummond wrote: > > FPGA capacities should now be big enough to support a "virtual FPGA" > layer on top of a real FPGA, using only the "public" parts of the > bitstream (e.g BRAM and SRL16 contents, possibly a subset of the > routing) to give a completely open format. Possibly a virtual XC6200, > but probably a coarser grained architecture (mini-Spartan perhaps). > I wonder what size Spartan-3 you would need for a virtual XC6264? At that point, why not create an ASIC... (yeah, price, etc, etc) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 94695
In article <dqasab$42d$1@newsg2.svr.pol.co.uk>, John Adair wrote: > > ... soon to be followed by Broaddown3 (XC3S4000/5000). What's the pricepoint/eta on these? :-) --Toby.Article: 94696
Hi Ivan and Sylvain, Both of you should get a reward from Xilinx: I get the help within 10 minutes!!! Thank you. WengArticle: 94697
John,
Is it true that uCLinux does not have protected kernel memory?
A simple programming loop index comparision error can wipe out the
system memory including kernel.
If this is the case, have you seen this kind of problem with
uCLinux.?
Do you think this is a real issues for uCLinux + microbraze
environment?
I had to deal with this kind of problems in vxWorks days, it was
a nightmare. A few bugs that is trivial (gdb the core dump) for the
protected kernel environment took a team of sw engineers 2 months
to reproduce and solved.
I am using PPC with Linux and it has been a joy to use. There
were one bugs shows up in test group that crash one program - first
crash in 6 months. It is solved in 5 mintues after looking a the
core
dump.
-Tony
Article: 94698Hi Sylvain, signal A0_O : std_logic_vector(12 downto 0); signal A1_O : std_logic_vector(12 downto 0); signal A2_O : std_logic_vector(12 downto 0); signal A3_O : std_logic_vector(12 downto 0); attribute MAX_FANOUT: string; attribute MAX_FANOUT of A0_O: net is "1"; attribute MAX_FANOUT of A1_O: net is "1"; attribute MAX_FANOUT of A2_O: net is "1"; attribute MAX_FANOUT of A3_O: net is "1"; Still error: parse error, unexpected OPENPAR, expecting COLON signal A0_O: std_logic_vector(12 downto 0); signal A1_O: std_logic_vector(12 downto 0); signal A2_O: std_logic_vector(12 downto 0); signal A3_O: std_logic_vector(12 downto 0); attribute KEEP: string; attribute KEEP of A0_O: signal is "true"; attribute KEEP of A1_O: signal is "true"; attribute KEEP of A2_O: signal is "true"; attribute KEEP of A3_O: signal is "true"; Still error: parse error, unexpected OPENPAR, expecting COLON All attribute statements are below the definitions of those signals. Thank you for further help. WengArticle: 94699
Tobias, this subject has been discussed ad nauseam, in this newsgroup and elsewhere. The reason for the "secrecy" is not so much fear of giving away secrets to a competitor, but rather fear of becoming inundated with support issues. We have about 100,000 designers using our parts, a few dozen of them exploring and abusing subtle aspects could easily bring our support hotline (and this newsgroup) to its knees. Also, the non-open nature of the bitstream provides our customers a certain level of security against reverse-engineering rip-off. Our primary obligation is to remain an innovative and profitable company, to the benefit of our customers, our employees, and our shareholders. Satisfying exotic academic research is fine, as long as it does not conflict with the primary obligation. Just my personal opinion... Peter Alfke
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