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
It maybe due to the input types used,unsigned types wider than 32 bits cannot be used without overflow errors occuring in conversion functions.I am not sure that is the reason but its worth checking.Article: 79026
I'm trying to use the proposed IEEE.fixed_pkg (fixed-point math package) available here: http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html The simulator doesn't complain (GHDL in this case), but ISE doesn't seem to like the negative values in ranges, like: variable exp_value_fp : ufixed( 0 downto -17); I get this message: ERROR:Xst:1548 - c:/phil/vhdl/svm/../csvm.vhd line 60: Negative range in type of signal <exp_value_fp> is not supported. 1) does fixed_pkg work with other synthesis tools? 2) Suggestions for other alternatives to fixed_pkg that might work with ISE? PhilArticle: 79027
Antti Lukats wrote: > "Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag > news:bvNNd.24610$C24.2729@attbi_s52... >> Antti Lukats wrote: >> >>Whops :) Hey we all do silly things.. > [snip] >> Sounds like a more current C-1 board.. It Also sounds cool. > > HAHA! I do have a C-1 !! Was one of the first one to buy and get it LOOONG > time ago. It's still collecting dust. I did something with it, but its full > of design mistakes and it was too-old (component wise) before it was > announced. What kind of design errors does it have? Juha -- Juha Turunen (turunen(at)iki.fi) elpuri@IRC | The problem with the global Torikatu 5A4, 53100 Lappeenranta, Finland | village are all the global GSM: 040-7092525, http://iki.fi/turunen/ | village idiots.Article: 79028
Hi, there is an interesting paper about this topic. It includes various reset strategies and should clarify your doubts. It can be found at the following url: http://www.sunburst-design.com/papers/ HTH Ansgar -- Attention please, reply address is invalid, please remove "_xxx_" ro reply "fpgabuilder" <fpgabuilder-news@yahoo.com> schrieb im Newsbeitrag news:1107990759.754345.93630@l41g2000cwc.googlegroups.com... > Ok! From all the previous topic and other resources on the net I see > following ckt touted to work for distributing async resets. > > always@(posedge clk or negedge ext_reset_l) > if(!ext_reset_l) > int_reset_l <= 2'b00; > else > begin > int_reset_l[0] <= 1'b1; > int_reset_l[1] <= int_reset_l[0]; > end > end > assign chip_reset_l = int_reset_l[1]; > > My questions is - > What happens if the second flop (int_reset_l[1]) goes metastable or > if it cannot then why? > > I cannot understand why so many have recommended the above ckt. as a > solid form of negating async reset syncly!? > > e.g. http://i.cmpnet.com/deepchip/downloads/cliff_resets.zip > > I would appreciate it much if someone can educate me on this? > TIA. >Article: 79029
Any reason Altera removed their NIOS2 GNU gcc/binutils sources
from their ftp server?
Before they supplied the login information and path on their
website for recompiling the NIOS toolchain (without any
documentation of course ;o) and now the direcotries are
empty...
Since I only have NIOS2 for Windows platform transferring
the sources is:
1. PITA due to DOS files
2. tweaking involved for compiling on UNIX hosts
since it does't like --target=nios2-elf as under
Cygwin environment.
rick
Article: 79030I don't know of any synthesis tool which supports fixed or floating point at the moment. You could write your own fixed point representation which will synthesise.Article: 79031
Thanks everyone. Well, I guess the question I have is why is that reset is related ot clock only when d input is changing? Can the inverters in the second flop not go metastable when the reset changes but d input does not? AFAIK, this would depend on how the ff is constructed. But the most basic FF that I have studied in past have set and preset input in the feedback loop of the master latch part of the FF. BTW, Ansgar, thanks for the link. Actually the paper that I reference in my post is the by the same authors Wills and Cummings, as pointed out in your post and when I looked previously there it was the same and did help answer my question.Article: 79032
In article <1108136783.695698.36550@g14g2000cwa.googlegroups.com>, Jezwold <edad3000@yahoo.co.uk> wrote: >I don't know of any synthesis tool which supports fixed or floating >point at the moment. >You could write your own fixed point representation which will >synthesise. > Actually, I was told that the ieee.fixed_pkg works with Altera, Mentor and Synplicity synthesis tools (as long as you comment out the alias statements in it). IIRC synopsys was also on the list... But ISE was missing from the list. PhilArticle: 79033
If the simulation is showing many cycles between the phase_inc or phase_dec to the completion of the phase adjustment, you may be good from all the investigations I did before. I thought there were something like 89 DLL cycles required before the phase adjustment was "complete" and the next adjustment would occur. With a 100 MHz clock and 3 MHz adjustment rate, that doesn't mesh. I was hoping someone with a greater knowledge of the DLLs and DCMs across the families might comment on the number of cycles required. Anyone? "Ray Andraka" <ray@andraka.com> wrote in message news:YCUOd.84010$Tf5.6765@lakeread03... > Austin Lesea wrote: > Peter, can you get me Virtex4 for under $12? If so, I'll gladly use > that instead. Target device is a spartan3-50 for cost reasons. Syms, > as Austin noted, DSS is not in S3. Clock looks like it will be about > 100 MHz, and I'll be bumping the phase up by a quarter cycle in 64 > increments. Will be using the 0 and 90 clk outs, both edges to get > measurements in each phase quadrant to keep the number of measurements > reasonable. (Simulation works fine on it, so as long as the simulation > matches the hardware, it will be OK). Thanks. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 79034
In article <mr3Pd.585$ss.29@newsfe1-gui.ntli.net>, Kryten wrote: > > However, if the card gets the FPGA bit file re-written on a PC then > returned, the CPLD hardware method might have to send megabytes of data > before the FPGA sees the sync word. A micro-based method might be able to > search a FAT to find a particular-named file, though obviously this is a > non-trivial job unless you have some experience with FAT already. Anyone got > any PD FAT source code in C? I'm sure there are others, but OpenDOS, OpenBSD, NetBSD, FreeBSD, Linux, and such do have farious versions of FAT code. Also, I seem to remember a number of MP3 type projects out there with FAT code. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 79035
Thanks for all your hints But increasing the BRAM was enough, so everything is working properly now! CiaoArticle: 79036
In article <cuhmtn$29v$03$1@news.t-online.com>, Antti Lukats wrote: > > 600E is supported by free tools, 600 not :) Which free tools? :-) -Toby. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 79037
"Tobias Weingartner" <weingart@cs.ualberta.ca> schrieb im Newsbeitrag news:slrnd0pqc5.ldf.weingart@irricana.cs.ualberta.ca... > In article <cuhmtn$29v$03$1@news.t-online.com>, Antti Lukats wrote: > > > > 600E is supported by free tools, 600 not :) > > Which free tools? :-) > > -Toby. actels tools (free versions) support the smallest of each family 600E is smalles of PA3E :) for the non-E only the very small are supported by the free stuff well actually nothing is supported as the current Libero/Designer that has PA3 support as advertized doesnt actually generate programming files for any of the PA3 at all, so nothing is supported that both for free tools users as for paid licensees AnttiArticle: 79038
John, As I said, maybe the "FACTORY_JF" thing helps. Is it in the Spartan 3? From Answer 13756 :- 2. Increase the FACTORY_JF setting to 'FFFF. The DCM updates its taps approximately every twenty input clocks when the "FACTORY_JF" attribute is set to 0xFFFF. (The default settings of 0xC080h result in updates that occur much more slowly.) Note that a well-decoupled and stable power supply is the preferred solution. Increasing the FACTORY_JF setting may introduce a small amount of jitter (~30 ps) because the DCM frequently updates its delay line. (This is why FACTORY_JF is not set to the maximum value by default.) If the power supply is unstable, the phase error introduced may be much bigger than the extra jitter introduced; therefore, increasing the FACTORY_JF setting may improve the design. Cheers, Syms. p.s. I see Xilinx have now got a Google search on their website. It seems to work much better than the regular search! "John_H" <johnhandwork@mail.com> wrote > I thought there were something like 89 DLL cycles required before the phase > adjustment was "complete" and the next adjustment would occur. With a 100 > MHz clock and 3 MHz adjustment rate, that doesn't mesh. > > I was hoping someone with a greater knowledge of the DLLs and DCMs across > the families might comment on the number of cycles required. > > Anyone?Article: 79039
John, I used to have the numbers written down somewhere. But that isn't the point. I believe it was something like so many clocks (86 seems to be what I remember from V2)from the CLKIN domain, followed by three clocks in the PSCLK domain. It is non-deterministic, hence the reason for the PSDONE bit: some shifts do not require all the clocks. There is basically a mathematical operation going on here -- we multiply the desired phase counter serially (8 bits, or a fraction of 256, where 256/256 = one whole period) by the number of taps presently used ot hold a whole period. That then tells us the tap location of the desired phase. It is recommended (required) that you wait for PSDONE. In subsequent versions, there are slight differences in this logic to do the math (clock cycles per update), so if I told you a number, and you used it, you would probably break in a future version of the DCM in a new family (like V4). Wait for PSDONE, and then everything is gauranteed to work. I know the simulation model is a rough algorithmic version of what really happens, but I wouldn't count on it to be the actual representation of the "right" number of cycles, as it will not behave like a serial arithmetic multiplier. So, do not use a fixed number of cycles. That isn't what we gaurantee. We gaurantee that PSDONE tells you that it is done shifting. It will take fewer clocks (on average, depending on the values of where the taps are for one full period, and where you are shifting to/from) than the total number to do the arithmetic, so any number I give you will change from family to family, and doesn't help anyway (as it represents the maximum, only). Austin John_H wrote: > If the simulation is showing many cycles between the phase_inc or phase_dec > to the completion of the phase adjustment, you may be good from all the > investigations I did before. > > I thought there were something like 89 DLL cycles required before the phase > adjustment was "complete" and the next adjustment would occur. With a 100 > MHz clock and 3 MHz adjustment rate, that doesn't mesh. > > I was hoping someone with a greater knowledge of the DLLs and DCMs across > the families might comment on the number of cycles required. > > Anyone? > > > "Ray Andraka" <ray@andraka.com> wrote in message > news:YCUOd.84010$Tf5.6765@lakeread03... > >>Austin Lesea wrote: >>Peter, can you get me Virtex4 for under $12? If so, I'll gladly use >>that instead. Target device is a spartan3-50 for cost reasons. Syms, >>as Austin noted, DSS is not in S3. Clock looks like it will be about >>100 MHz, and I'll be bumping the phase up by a quarter cycle in 64 >>increments. Will be using the 0 and 90 clk outs, both edges to get >>measurements in each phase quadrant to keep the number of measurements >>reasonable. (Simulation works fine on it, so as long as the simulation >>matches the hardware, it will be OK). Thanks. >> >>-- >>--Ray Andraka, P.E. >>President, the Andraka Consulting Group, Inc. >>401/884-7930 Fax 401/884-7950 >>email ray@andraka.com >>http://www.andraka.com >> >> "They that give up essential liberty to obtain a little >> temporary safety deserve neither liberty nor safety." >> -Benjamin Franklin, 1759 >> >> > > >Article: 79040
Why do you want to use negative indice?? it's the first time i saw such
thing
and so does it work if you use positive indice??
"Phil Tomson" <ptkwt@aracnet.com> a écrit dans le message de news:
cui1g701ovi@enews2.newsguy.com...
> In article <cufvla02a24@enews2.newsguy.com>,
> Phil Tomson <ptkwt@aracnet.com> wrote:
>>
>>This page:
>>http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264
>>
>>shows some templates for ROM inference in Spartan3 using Xilinx's ISE
>>software.
>>
>>One of the templates is:
>> library ieee;
>> use ieee.std_logic_1164.all;
>> use ieee.std_logic_unsigned.all;
>> entity rominfr is
>> port (
>> clk : in std_logic;
>> en : in std_logic;
>> addr : in std_logic_vector(4 downto 0);
>> data : out std_logic_vector(3 downto 0)
>> );
>> end rominfr;
>> architecture syn of rominfr is
>> type rom_type is array (31 downto 0) of std_logic_vector (3 downto 0);
>> constant ROM : rom_type :=
>> ("0001","0010","0011","0100","0101","0110","0111","1000","1001","1010"
>>,"1011","1100","1101","1110","1111","0001","0010","0011","0100","0101"
>>,"0110","0111","1000","1001","1010","1011","1100","1101","1110","1111" );
>> begin
>> process (clk)
>> begin
>> if (clk'event and clk = '1') then
>> if (en = '1') then
>> data <= ROM(conv_integer(addr);
>> end if;
>> end if;
>> end process;
>> end syn;
>>
>>
>>My question is: are they types of the inputs and outputs important for the
>>software to infer the ROM? For example, could I have:
>>
>>
>> entity rominfr is
>> port (
>> clk : in std_logic;
>> en : in std_logic;
>> addr : in std_logic_vector(9 downto 0);
>> data : out ufixed(0 downto -17) -- ufixed is fixed point
>> --type from:
>> --http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html
>> );
>> end rominfr;
>>
>>Would the ROM still be inferred because I didn't use std_logic_vector on
>>the data output? Just wondering how strict the template must be adhered
>>to.
>>
>>
>>There are conversion routines to go to/from std_logic_vector<=>ufixed,
>>however I'd prefer to keep the output of the ROM in ufixed format if
>>possible.
>>
>
> FYI: the line:
> data : out ufixed(0 downto -17)
>
> Causes the following error:
> ERROR:Xst:1548 - c:/phil/vhdl/svm/../lookuptable.vhd line 13: Negative
> range in type of signal <data> is not supported.
>
> So looks like you can't use a ufixed (with negative indices ) in a port
> signal, anyway.
>
> Phil
Article: 79041So, bottom line, the simulation might not provide 100% results for PSDONE but should give a rough approximation. 33 cycles at a CLKIN of 100 MHz may not be enough. The algorithm Ray Andraka produces should be based on PSDONE for minimum phase update step size. Thanks. "Austin Lesea" <austin@xilinx.com> wrote in message news:cuiqt2$ee61@cliff.xsj.xilinx.com... > John, > > I used to have the numbers written down somewhere. But that isn't the > point. > > I believe it was something like so many clocks (86 seems to be what I > remember from V2)from the CLKIN domain, followed by three clocks in the > PSCLK domain. It is non-deterministic, hence the reason for the PSDONE > bit: some shifts do not require all the clocks. There is basically a > mathematical operation going on here -- we multiply the desired phase > counter serially (8 bits, or a fraction of 256, where 256/256 = one > whole period) by the number of taps presently used ot hold a whole > period. That then tells us the tap location of the desired phase. > > It is recommended (required) that you wait for PSDONE. In subsequent > versions, there are slight differences in this logic to do the math > (clock cycles per update), so if I told you a number, and you used it, > you would probably break in a future version of the DCM in a new family > (like V4). Wait for PSDONE, and then everything is gauranteed to work. > > I know the simulation model is a rough algorithmic version of what > really happens, but I wouldn't count on it to be the actual > representation of the "right" number of cycles, as it will not behave > like a serial arithmetic multiplier. > > So, do not use a fixed number of cycles. That isn't what we gaurantee. > We gaurantee that PSDONE tells you that it is done shifting. > > It will take fewer clocks (on average, depending on the values of where > the taps are for one full period, and where you are shifting to/from) > than the total number to do the arithmetic, so any number I give you > will change from family to family, and doesn't help anyway (as it > represents the maximum, only). > > AustinArticle: 79042
Neo wrote: > read the manual and set the jumper switches M1,M2,M3. One more thing to do in the 17xxx series PROMs. There is a reset polarity bit in the prom which is *NOT* part of the binary file you create in impact or prom file formatter. This must be set to active LOW which is *NOT* the default setting or your FPGA will not program. The way to program this bit depends on your programming equipment.Article: 79043
Hi, can the MGT of Virtex-4FX talk to the MGT of Virtex-2Pro (XC2VPX) ? Any experience or problems ? TullioArticle: 79044
I should send text to a parallel printer. What is a centronics interface? "Roel" <electronics_designer@hotmail.com> wrote in message news:cuglno$51a$1@news2.zwoll1.ov.home.nl... > Marco wrote: > > Is it possible? > > > > > It's very simple in case of a printer having a centronics interface. > Even graphics can be done easily after sending the right commands. > > In case of a USB printer you will need a USB host. Implementing that in > an FPGA will be much more difficult, so buy an old fashion HP500 Deskjet > from Ebay and use that one (: > > Best Regards, > Roel > >Article: 79045
>Well, I guess the question I have is why is that reset is related ot >clock only when d input is changing? Can the inverters in the second >flop not go metastable when the reset changes but d input does not? >AFAIK, this would depend on how the ff is constructed. But the most >basic FF that I have studied in past have set and preset input in the >feedback loop of the master latch part of the FF. Metastability requires a race condition. You have to be interested in whether the FF will go from a 0 to a 1 or stay at a 0. (or the other way around) There is such a race condition when reset goes away if you are trying to clock a 1 into a FF. If you are trying to clock in a 0, there is no problem - you get 0 or 0 so it doesn't matter. The second FF in the case being discussed is the 0 to 0 case. The first FF might go metastable. The whole point of this discussion is to move the metastability considerations from all over the FSM to one concentrated place where the designer can check it carefully by hand. The tools don't help much, at least not yet. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 79046
Antti Lukats wrote:
> <snip FPGA bootloader for SD Card>
Kryten wrote:
> Wouldn't this be better done by a small micro (e.g. AVR) though?
It could be, but it would be slower and more expensive.
> These could be smaller than the 9536 chips.
The 9536XL is amazingly cheap.
> I'm also looking for a system where the main micro can use the SD card after
> booting.
Shouldn't be any problem with that. Just tie the SD to both the
CPLD (or uP) and the FPGA, and have the CPLD (or uP) put its SD
interface pins into high-Z once the config is done.
> However, if the card gets the FPGA bit file re-written on a PC then
> returned, the CPLD hardware method might have to send megabytes of data
> before the FPGA sees the sync word. A micro-based method might be able to
> search a FAT to find a particular-named file,
True. A point in favor of the microcontroller.
Though if you don't mind writing special code for the PC, you can
have it always arrange for the FPGA bit file to be a single contiguous
chunk near the start of the SD.
In fact, once you've got it there the first time, you should be able
to rewrite the bit file without it moving around.
> though obviously this is a
> non-trivial job unless you have some experience with FAT already. Anyone got
> any PD FAT source code in C?
Yes, RDCF2 by Philip J. Erdelsky:
http://alumnus.caltech.edu/~pje/rdcf2.txt
I wish I'd known about RDCF2 when I wrote the boot ROM for the ReplayTV.
I wrote my own read-only FAT filesystem for it. (Used for software
development only; the ReplayTV does not use FAT.)
Eric
Article: 79047Kryten wrote: > Anyone got any PD FAT source code in C? Tobias Weingartner wrote: > I'm sure there are others, but OpenDOS, OpenBSD, NetBSD, FreeBSD, Linux, > and such do have farious versions of FAT code. None of which are public domain. The BSD licensed code is closest. But code for either a BSD or Linux kernel will be hard to adapt to a tiny microcontroller.Article: 79048
Christos wrote: > Hi, > > It seems that it is not possible to instantiate an accumulator with the > Megawizard plug-in which has an input wider than 33 bits. > > If you set the input wider than 33 bits it gives the following error: > > --------------------------------------------------------------------------- > Microsoft Visual C++ Runtime Library > > Runtime Error! > > Program: C:\altera\quartus41\bin\mega_altaccumulate.exe > > This application has requested the Runtime to terminate it in an unusual > way, > Please contact the application's support team for more information. > ---------------------------------------------------------------------------- > -- > > I have winXP sp1 running QuartusII 4.1 sp2 full version. > I have tried this to other PCs with similar configuration and still did not > work. > Finally, I have read all help files with megawizard and the altaccumulate > and have not seen anywhere stating this limitation. > > Thanks to anyone which can help. > Hi Christos, We tested the altaccumulate megafunction with a size of 34 bits and with all other settings as default, the problem mentioned was not encountered. Would it be possible to email me the settings that were chosen in the Megawizard that were no-default? That would help us reproduce the problem. - Subroto Datta Altera Corp. > ChristosArticle: 79049
Brian Davis wrote: > Elder Costa wrote: > >>I tried to do it as in the snippet bellow and I get compilation error: > > > There seem to be various typos in those code snippets you posted- > did you cut and paste, or re-type them, into your post? Cut and pasted. The only real typo was the extra semicolon Neo pointed out (Xst just ignores it :-( ). If you mean the exchanged As and Bs, that was due me not willing to change the VHDL code in the hierarchy this module is par of. > > Also, an important BRAM safety tip: > > A variable width dual port spanning multiple BRAMs needs > reindexing of the wider port bits to do what you intend. I guess I learned that today the worst way. It took me a couple of hours looking at simulation results to figure it out. Thanks & regards. Elder
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