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
williams wrote: > Hello Guys, > I had a doubt about the IBUFG and BUFG in xilinx. > 1.I have connected clock from oscillator to CLKG IO of the Xilinx. In > this case is it required to instantiate the IBUFG inside my code > also?. Howdy Williams, I believe the tools will usually do it for you - the exception that comes to mind is differential clocks. > 2. The DCM output is already BUFG i think and so is it required to > BUFG again in my code? BUFG is another name for a global buffer. Although most of the time you'd want it on a global buffer, the output of a DCM is not "already BUFG", nor would you always want it to be. Even if it does automaticly insert a BUFG in some situations, I rarely trust that it will every time. Have fun, MarcArticle: 81901
parity wrote: > Hello, > > i'm from germany and just registered to this forum. Hello to everybody > out there. > > I'm working on very small FPGA Designs which are size-comparable > (about 4-40 Look-up-Tables on a VIRTEX FPGA) to 4 Bit-adders and 4 > Bit-multipliers. I use them just for testing some things. The problem > is that I use XPower to calculate the power consumption of the designs > and the power values are not what i expected. > > I have a testbench, an input stimuli and the placed and routed design. > Whenever i put stimulis to the design it delivers (like expected) the > "mW" values. But if i change the stimuli to other ones, which are > nearly the same, the power consumption raises to the double or stays > the same. (after subtracting the quiescent part). There's (in most > cases) nothing between them. > > Does anybody know this problem? Have I reached the smallest possible > XPower value, or what is it? > > Oh, and does anybody know, how accurate XPower should be. Is there a > chance to get some information about it? Howdy, Xilinx tries to make XPower as accurate as possible - otherwise why would people bother to use it? Is it possible there are bugs and you've stumbled upon one? Absolutely. Respectfully, not knowing exactly which FPGA, which version of XPower, which things you are changing between runs (code or otherwise), or which items within the FPGA that are actually being used to implement your different designs (shown in the .mrp file for each run), it is impossible to answer your question with any accuracy. Think of it like this: it would be the same if you just asked us why your car is _somtimes_ getting poor gas milage. But you don't give any info on the car, your actual milage, your expect milage, where you're driving, how you're driving. Have fun, MarcArticle: 81902
On 3 Apr 2005 17:25:20 -0700, "AugustoEinsfeldt" <aee@terra.com.br> wrote: >While using RLOC (under ISE6.3i) I can assign a single FDC primitive to >a specific slice in a CLB but cannot assign both flip-flops in a slice. >RLOC parameter is just RxCy.S0 or RxCy.S1 but each slice has two >flip-flops and I see no way to use both. Have not found any primitive >or attribute to do thi assignment. RxCy.FFX or RxCy.FFY, I think... oops, wrong syntax: the above no longer works, has been replaced by INST "I3/Q_14" RLOC = "X0Y7" | BEL = "FFX" ; (in UCF format; there is something similar in VHDL, refer to constraint guide for details but I think you have to attach separate RLOC and BEL attributes to each instance in VHDL) >It is the same when using XORCY and the design endup wasting half of >the resources (for this particular segment of the design). I think it's RxCy.XORF and RxCy.XORG, to go with the F and G LUTs in the slice. Modified as above... >The second question to follow is: is there a way to instruct the tool >(map/router) to use, say, long lines instead of lots of local lines >when sourcing several CLB inputs with a single signal? That's where I think you need XDL. >I cannot find a document in Xilinx web site instructing how to better >use the tools according the device's architecture, tool's processing >schemes and design goals. Once you know what to look for you can search for it, (most of the above is in the "constraints guide") but there's not much in the way of worked examples. Be aware that 6.3 tools have issues handling these constraints, which Bret Wade assures me are resolved in 7.1 (which I haven't downloaded yet, I'm on a modem...) http://www.shapes.demon.co.uk/files/crashme.zip is (a) a worked example using UCF attributes (and "black_box" attributes in VHDL), and (b) an illustration of some of the 6.3 issues... it successfully places 2 out of 8 instances, the others have a variety of bizarre mis-placements. Essentially, if an RPM has *something* in its lower left hand corner; AND if all RPMs are placed on even X and Y locations, everything works smoothly. Otherwise... - BrianArticle: 81903
Thanks, Brian. I'm just moving to 7.1 to skip some problems I found when translating NCD to XDL, and also in the hope to have improved PAR. I will use BEL attribute to improve results in the signal distribution before going deeper in XDL. As I said before, I'm facing a very good opportunity to learn fine placement and your directions are a great help. Thank you. -AugustoArticle: 81904
thangkho <> writes: > Been there, done that,...If you have only one external device > (SDRAM) it may be easy to adjust the trace/propagation... The > situation get worse when more SDRAMS are ppopulated at different > locations on your board. Ahh, yes. I guess this is not specific to SDRAMs, right? When you have multiple chips on your PCB that are driven by the same clock and are thus one big, multi-chip clock domain, you of course needs to make sure that timing is met withing that big clock domain. I don't see yet why the use of one or two DLLs (as sketched in my original post) _guarantees_ that timing is met since I would right now say that only the delay from SDRAM to FPGA has been taken into account. The path from FPGA to SDRAM is just as critical, I think, and has not been considered. In fact, I would say that one needs to use two separate clocks, one for sending to the SDRAM, and one for receiving. In essence, you need to give up the one big clock domain idea, and use some kind of self clocking data pipe, one for every direction. If you do insist on a single clock domain that covers both the FPGA and the SDRAM, you need to make sure that you PCB layout meets the timing constraints (in essence, PCB layout becomes part of your FPGA P&R run...), and then there should be no need to play tricks with DLLs other than as to compensate for an internal BUFG delay, which makes it possible to take that delay out of the P&R problem. So, I am still confused, I have to admit... > The board then need to be carefully designed and of course a second > DLL is a big help too. Refer to xapp132 for details, I will, thanks!Article: 81905
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote in news:d2rbm3$160 $1@news.dialog.net.pl: > Symon wrote: > >> You'll get considerably better accuracy, or considerably smaller lookup >> tables, by using the Sunderland algorithm and/or the sine difference >> algorithm. > > Thanks, I didn't know about them. The "sin(2*pi*x) - x" trick is > particularly nice, I'll think about incorporating it into my quadrature > mixer to increase accuracy beyond 17 bits (just to check the idea, > there's no technical reason to do so). However, compared to > > http://www.ecdl.hut.fi/~jvan/dds3_files/mapiee.pdf > > it seems that my algorithm (which is very simple, so I doubt that > I am the first inventor of it) is much better, because it needs > only 2^8 16-bit ROM cells to produce 17-bit approximation of > sin(x), where those algorithms need 2^8 9-bit cells to produce > ~12 bits of accuracy. :-) > > Best regards > Piotr Wyderski > > I wrote an article for Analog devices several years ago that discusses sine generation. It was implemented on a DSP, but the concepts are the same. http://www.danvillesignal.com/index.php?id=applications_signalgeneration You might be interested in our ADDS-21261/Cyclone DSP & FPGA Evaluation Kit. It is being sold by Arrow with a promo price of $199. http://www.danvillesignal.com/index.php?id=zx_platform -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 81906
"Marc Randolph" <mrand@my-deja.com> writes: > You've actually produced a variation of the original drawing. Here's a > simpler version of what you have, just ignoring the fact that the FPGA > buffers the clock: > > > OSC ---+ > | > +--> SDRAM > | > | > | > | : buf clock > | : v > +--:---> IBUFG ----> DLL0 ---> BUFG -+--> main clock > : ^ | > : +--------------+ > > > Assuming there isn't much phase difference between when the clock > reaches the SDRAM and when it reaches the GCLK input, the above is how > a "system synchronous" clock setup works. Your main clock will have > the same phase as (or often times, it will slightly lead) your input > clock signal, measured when it hits the FPGA GCLK pin. Yes, I think I understand this now, thanks! So, as I wrote in my other reply, the DLL is used to compensate for the BUFG (and IBUFG) delay so that the internal FPGA clock is properly synchronized with the external system clock. Since the P&R tools should know enough about the timing situation in the FPGA anyway, they might even be able to determine the delay needed in the DLL statically, and there would be no need for a feedback loop and no need to explicitely instantiate a DLL. (Maybe future FPGAs and their tools will use DLLs automatically if they are needed to meet the timing constraints?) So, in the picture above, the FPGA is now properly part of the system clock domain, but the SDRAM still needs to be considered. As I see it now, this is not a problem of the delay of the signals between FPGA and SDRAM, but a problem of the delay between the oscillator and the SDRAM. The SDRAM must be close enough to the FPGA so that they can be in a single clock domain, in any case. Right? > I've not read up on the S3 DCM, but I assume it is the same as the > in V2Pro, where you need to release the reset to the DCM *after* the > clock is present at the DCM input. As long as you're doing that, I > don't see a problem with it. I don't think I am doing this right now, but I will look into it. I guess the usual trick is to use shift register (that is clocked directly by the oscillator) that shifts out a couple of ones and the sticks at zero, right? Thanks everybody!Article: 81907
Philip, > The performance enhancement in the XC3100/3100A family is achieved by the > use of on chip charge pumps. ... These charge pumps use free running > oscillators that are separate from the config oscillator, and are almost > certainly the 16 MHz that you are seeing. Thanks for all your insight!! I was a bit surprized that the "smartest and most helpful engineers" at Xilinx did not pick up on the charge pump right away. As per our off-line talks, I have gone ahead and rebuilt the design using slew limited outputs for the two pins in question. I have begun running my transient tests but it will be a few weeks before I am convinced this was the problem. The following link is to my post about the reflected energy causing possible problems: http://groups-beta.google.com/group/comp.arch.fpga/browse_frm/thread/1423e577bf37d509/1f921b2ef9ae4542?q=reflected&rnum=3#1f921b2ef9ae4542 The following was taken from a Xilinx app. note. "For all FPGA families, ringing signals are not a cause for reliability concerns. To cause such a problem, the Absolution Maximum DC conditions need to be violated for a considerable amount of time (seconds). " I am including parts of our off-line talks that may be a benifit to others reading this thread. >So, I drug out the trusty scope to start probing around. Made a nice ground plane around the device for a reference. Ground plane is attached to devices ground in multiple places. The scope is a LeCroy 7300. 3GHz BW with a sample rate of 20GS/S. Using a 3.5GHz active probe with a loop of about 0.5". All measurements are taken at the FPGA's pins. Using no filtering, etc. If there is a glitch, I will find it. >The outputs are not terminated (except by the next device) and there is some undershoot from the reflection. This undershoot can be more than 0.5 Volts below the rail. On their newer parts I had seen where they started to specifiy the SWR of the next stage, but I was not able to obtain this document. You may recall me posting this lenghtly post last summer. I have never seen a problem where, say all of the energy was reflected back to the device's output and have it cause a problem. Maybe the 3100A was prone to having problems with this. > >Any idea? Well anything that goes more than .5V below ground would concern me, even very short duration. I don't think the 3100A was particularly prone to this. While normally you worry about undershoot and overshoot at a receiver, in the case of FPGAs, all pins are both. So even if you are usin a pin only as an output, it still has an input structure including the protection diodes. The undershoot can cause the diode to conduct, and this can in turn upset the local ground reference inside the FPGA. This may be your fault mode. Note that this type of thing can have data pattern sensitivity. I.E. a bunch of outputs all switching low at the same time, maybe on pins that are further away from the ground pins rather than nearer, with reflections arriving at about the same time, etc. Two suggestions: can you force the data outputs to bang between paterns that are predominantly all '1's and then '0's? Other idea, set up a low impedance pulse generator to generate say a 1 uS pulse of -1V, and apply it to some pins (1 at a time) and see if this induces the problem.Article: 81908
shankar.vk@gmail.com wrote: > When I try to write into this register from ARM software as > shown below, write is not happening. ARM is running at 48 Mhz. > > int* reg = 0x44400030; > *reg = 0x3; > > The above code is not able to modify the register. I recommend that you look at the compiler output, either through an assembly listing or, better yet, through the disassembly output of a debugger. See what code is being generated. Compare that to what you know works. This is a powerful technique that all programmers, but especially embedded systems programmers and systems programmers can benefit from. It might have something to do with memory mapping or the width of the write, but those are just guesses. ThadArticle: 81909
In article <XYS3e.131292$r55.32410@attbi_s52>, Ziggy wrote: > > I hadnt thought about the patents expiring on the older X86 stuff, which > would suit the bill fine. A reproduction of a 486 or base Pentium would > be plenty for what i want to do. I doubt it's a matter of patents, but more a matter of licening. The two are very different beasts. Having said that, what you do in your own home for your own amusement is your business... :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 81910
Does anyone have experience with reverse engineering ASIC (black box) into equivelant FPGA devices (pin equivelant with a sub-board if necessary)? -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 81911
Have your program/script create a package file with a constant table and include it in your probject. You can then "use" the package in your architecture and directly use the constant table. Andrew Whyte wrote: > Thanks for your reply Mike. Ideally I'd like to read any kind of memory > configuration file into a design with Synplify - doesn't have to be > Xilinx-specific formats. > > With XST, what I can do is read in a .mif file and then parse the data > to create init values for my memory elements. Synplify does not appear > to able to do the file read. > > Any more ideas? > > Andrew > > Mike Treseler wrote: > >> Andrew Whyte wrote: >> >>> Hi, >>> >>> I'm trying to read in data from a .mif file to initialise some memory >>> elements in Synplify 7.6.1, but it fails when it encounters the line >>> >>> FILE initfile : TEXT; >> >> >> >> A .mif file is specific to X devices. >> >> Synplify can synthesize variable or constant >> arrays into ram or rom using only vhdl source code >> for any fpga. >> >> Vendor-specific download widgets are handled with >> vendor attributes in the code like this: >> >> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html >> >> But consider maintaining vendor-independent code. >> That's a common reason for using Synplify over XST >> in the first place. >> >> -- Mike Treseler >>Article: 81912
Thank you very much beeraka !!! That was it !!! :)Article: 81913
When you want the code of uart, you mast go to your EDK installation folder then hw\XilinxProcessorIPLib\pcores\opb_uart16550_v1_00_c and there you get the vhdl code and datasheets!Article: 81914
Hello all
I am working on the design of a simple RAM module for my
microcontroller design. In the VHDL simulation data is not getting
loaded into the bidirectional IO bus what might be the problem with
my simple design. The program is given below::
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity sram is
port(
clock: in std_logic;
enable: in std_logic;
rwbar: in std_logic; -- (1 - Read, 0 - Write)
addr: in std_logic_vector(4 downto 0);
data: inout std_logic_vector(15 downto 0)
);
end sram;
architecture sram_arch of sram is
type ram_type is array (0 to 31) of
std_logic_vector(15 downto 0);
signal tmp_ram: ram_type;
begin
process(clock)
begin
if(clock='1' and clock'event) then
if(enable='1') then
if(rwbar='1') then
data <= tmp_ram(conv_integer(addr));
elsif(rwbar='0') then
tmp_ram(conv_integer(addr)) <= data;
else
data <= (data'range => 'Z');
end if;
else
data <= (data'range => 'Z');
end if;
end if;
end process;
end sram_arch;
There is one program which I downloaded but isnt helping me out
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity mc8051_ramx is
port (clk : in std_logic; -- clock signal
data_bus : inout std_logic_vector(7 downto 0); -- data
input
addr_bus : in std_logic_vector(4 downto 0); -- adresses
ram_wr_i : in std_logic; -- read=0, write=1
rst_b : in std_logic); -- rst_b signal
end mc8051_ramx;
architecture sim of mc8051_ramx is
type ram_type is array (31 downto 0) of bit_vector(7 downto 0);
begin
p_readwrite : process (clk, rst_b)
variable gpram: ram_type; -- general purpose RAM
begin
if rst_b='0' then
data_bus <= "00000000";
gpram := (others => (others =>'0')); -- rst_b every
bit
else
if (clk'event and clk = '1' ) then
data_bus <=
to_stdlogicvector(gpram(conv_integer(unsigned(addr_bus))));
if ram_wr_i='1' then
gpram(conv_integer(unsigned(addr_bus))) :=
to_bitvector(data_bus);
end if;
end if;
end if;
end process p_readwrite;
end sim;
I am not able to sort out my mistake. Please help me out with my
code.
Vasant
Article: 81915Yes. "Tobias Weingartner" <weingart@cs.ualberta.ca> wrote in message news:slrnd52ogp.ivg.weingart@irricana.cs.ualberta.ca... > Does anyone have experience with reverse engineering ASIC (black box) > into equivelant FPGA devices (pin equivelant with a sub-board if > necessary)? >Article: 81916
On Mon, 4 Apr 2005 10:12:21 -0700, "Symon" <symon_brewer@hotmail.com> wrote: >Yes. >"Tobias Weingartner" <weingart@cs.ualberta.ca> wrote in message >news:slrnd52ogp.ivg.weingart@irricana.cs.ualberta.ca... >> Does anyone have experience with reverse engineering ASIC (black box) >> into equivelant FPGA devices (pin equivelant with a sub-board if >> necessary)? >> > you mean you decapped a chip, looked at the layout with a microscope, re-drew the polygons and generated a flat gate-level netlist ? ;-)Article: 81917
"mk" <kal*@dspia.*comdelete> wrote in message news:btt251hsfuth938fd2amhv0njtrmeem9ob@4ax.com... > On Mon, 4 Apr 2005 10:12:21 -0700, "Symon" <symon_brewer@hotmail.com> > wrote: > > you mean you decapped a chip, looked at the layout with a microscope, > re-drew the polygons and generated a flat gate-level netlist ? ;-) > Naahh, I sent a copy of the databook to Pune, India. Three months later, during which time we had a board relayout with a bigger FPGA, I got the VHDL back along with a bloke from India. He stuck the VHDL into the FPGA and debugged it. We sent them money. Easy as that, I even got to spend some time in Bangalore and Goa 'researching' the best VHDL houses! Cheers, Syms.Article: 81918
You should instantiate the RAM module directly into your code, either as a component or as a macro. See this link (.ppt) http://ece.gmu.edu/courses/ECE449/viewgraphs_S05/449_lecture3.html MilindArticle: 81919
Hi, I have read these materials before I wrote the code, and I have just re-read it, seems like the way that I instantiate the code is write. I don't know why the data is not there though. Does anyone have an example or something? Thanks, AnnArticle: 81920
Tobias Weingartner wrote: > I doubt it's a matter of patents, but more a matter of licening. The two > are very different beasts. But if there isn't a patent on an architecture, you don't need a license to implement it. The purpose of the license is to grant you a right that was taken away from the patent. If there's no patent, you haven't been denied the right.Article: 81921
Is there any way of using the Xilinx toolchain on a Mac? I have become spoiled by my Mac Mini, and unpacking my loud PC just to run place-and-route seems inelegant. TomArticle: 81922
On 04 Apr 2005 19:48:58 +0100 (BST), Thomas Womack <twomack@chiark.greenend.org.uk> wrote: >Is there any way of using the Xilinx toolchain on a Mac? > >I have become spoiled by my Mac Mini, and unpacking my loud PC >just to run place-and-route seems inelegant. > >Tom give this a try http://www.microsoft.com/mac/products/virtualpc/virtualpc.aspxArticle: 81923
Antti Lukats wrote:
>Hi
>
>is it only me that every time I try to use some a little advance feature I
>trap into some Xilinx bug??
>
>1) implementing SRL16 based serial divider, found bug in MAP
>2) implementing JTAG Hub found synthesis bug
>3) implementing frequency meter in FPGA found P&R bug with Virtex 4 devices
>
>
Which version of ISE? I trust you are reporting these bugs to Xilinx
(open a webcase) so that they get fixed before I migrate to 7.1 (still
using 6.3)
--
--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: 81924Hi Morpheus, I am not an expert on DPSK, but I can answer your first question. Two's complement multiplication does not require normalization [vs. unsigned multiplication in say floating point]. Howeve a MACC (Multiply Accumulate] could eventually overflow. It really depends on the number of Multiply-Accumulate operations. In a Virtex4 DSP48, you have a 48 Bit accumulator - and so for a 12x12 Filter each multiply will produce 24 bits and so you will have 24 guardbits in the DSP48. That should be more than enough - since even a 1024 tap filter will require 10 guard bits after the multiply. If you are instantiating remember that the 12 bits going in to the DSP48 have to be sign extended all the way up to 18 bits. So in your case you probably don't need to worry about overflow - but you should probably change your code to keep the MSB of the MACC (and round or truncate the LSB). You can also keep more bits than your input datawidth. So if you have a 12x12 Filter with say 64 taps - your result is actually going to be 30 bits (the lowest 30 out of the 48 coming out of the DSP48 - the rest of the outputs will all be sign extended bits). How many of these bits you want to keep for the subsequent adders is up to your accuracy requirements and DPSK. Once you have all of your filter results you could also choose to keep all 30 bits - and add the 30 bit numbers in other DSP48's and then round/truncate only at the end of your last add operation. By the way as long as you sign extend to your desired number of bits - there is no difference between a signed adder and an unsigned adder. The DSP48 signextends the multiplier result internally before going to the 48-bit Accumulator for MACC's. - Vic morpheus wrote: > Hi all, > This is a really trivial question, but I just can't seem to think > correctly, so I thought I'll throw this out here. I am building a > non-coherent DPSK receiver in the FPGA. Its all 2's complement > arithmetic. Two 12*12 multiplers with an adder that adds the result of > the multiplies (matched filter implementation). Then I have a moving > average filter which basically boils down to 10 adders (all signed) > which adds 10 samples of 24 bit data(result of the adder post > multiplication) > > I use the result of the moving average filter to decode the data. I > have two questions > 1. In 2's complement arithmetic, do I need to handle the overflow > issues when multiplying and adding (i thought you could safely ignore > the overflow in 2's complement). If I do, how? > 2. Does anyone have a good idea for a data decoding scheme. Right now I > am using the "poor man's" detection scheme of deciding a bit based on > the sign bit of the moving average sum and its not giving me the > required fidelity? > > Thes questions may sound a little cryptic but any help would be > appreciated. > Thanks > MORPHEUS
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