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
Two of my favorites: Ray Andraka Mike Treseler Brad Smallridge aivisionArticle: 106176
My algorithm is to solve the linear equation R.h=3Db, (R matrix ,b vector is known, generated in Matlab). R,b are transmitted to FPGA board. After the application caculation, h is sent back to Matlab. I set the number of trials is 100. it will no problem. If trials=3D100000, it will happen the "accidently stop" in Matlab. I guess you are right that it looks like memory leak. I tried a simple test. Numbers from 1 to 100 transmit from Matlab to FPGA board(UART) and send them back. These numbers are sent back correctly. If i send the number from 1 to 1000 to UART. The matlab will show like that: (InputBufferSize=3D512 in my matlab version) ---------------------------------------------------------------- Error using =3D=3D> serial.fread SIZE * PRECISION must be less than or equal to InputBufferSize. Error in =3D=3D> testuart at 17 y=3D fread(s,1000,'uint8'); ------------------------------------------------------- I am not sure if i say it clearly. Hope you can help me to figure it out. Thanks a lot. Zhi Mike Treseler wrote: > ZHI wrote: > > > The Matlab > > always > > show busy but not continue to next trial. I have to close Matlab and > > try again. The phenomenon happens every time. Is this the problem of my > > vhdl codes=EF=BC=9F > > Sounds like a Matlab bug. Open a case with them. > > > But how can it successuflly work for some trials (even > > reached 9883 trial)? > > Memory leaks are like that. > > > How to fix it? > > Upgrade Matlab. > Maybe try a different computer. >=20 > -- Mike TreselerArticle: 106177
Evan Lavelle wrote: > Actually, you can make your VHDL or Verilog description much more > abstract than this. I've recently been working with some very abstract > VHDL code, some of which was untimed, and some of which used functions > and procedures rather than explicit hierarchy. It was also very > dependent on passing around large records, and letting the synthesiser > get rid of the unused bits. The untimed code relied on register > retiming in DC (which I think XST supports). > > Personally, I really hate this sort of code. It was synthesising to > about 75 logic levels between clocks before I started hacking it. Following the links in Mike's posting proved to be interesting, as it references indirectly this great piece, which makes the same arguments about why you don't want to let hardware designers avoid a high level of design abstraction, as they will dig the same deep unmaintainable hole that assembly language provides for programmers, and their employers. http://www.designabstraction.co.uk/Articles/Advanced%20Synthesis%20Techniques.htm And clearly, the bottom line is well stated by this articles introductory "Scope" section. > It'll never happen; already been tried, failed. Hacking low-level > hardware semantics into existing C++ semantics just gives you a > verbose and complex mess, which is nowhere near as concise and clear > as a VHDL or Verilog description. Great for modelling, non-starter for > real-world synthesis. Having to work with some horrible "concise and clear" VHDL, I have to disagree. Job security by obscurity in a botched VHDL design that LACKS reasonable high level abstraction is exactly why in my mind that TTL designers should not be allowed to write TTL designs in VHDL/Verilog. That those constructs need to be removed from a production language that is general use, to specifically force mantainable coding standards, that improve productivity and maintainability over the long term.Article: 106178
Michael, I thought you wanted to use an FPGA (Virtex-4) for the receiver. Then you can use any oscillator frequency you want, and modify it with the DCM inside the FPGA. The decoder design that I sent you has a very wide data capture range, but slightly less when you go to 4x oversampling (instead of my 8x). Peter ========== Michael Dreschmann wrote: > On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote: > > >But I prefer a dedicated oscillator, because it uses less power, and > >uses an internal chip that is optimized for the purpose, and is > >manufactured by a company with expertise and a single-minded goal. And > >it hardly costs extra... > > Costs are no problem, it's a university project and not a design for > production. > I thought a crystal in combination with the cpld would need less power > than a dedicated oscillator. Could you give me a hint where to find a > 100 MHz low power oscialltor working at 2.5V? An external oscillator > of course would be easier. > An other question concerning power: > If I have a design that fits exactly in a xc2c64a cpld and I use the > next bigger one (xc2c128) with the same design how much more would be > the power consumption (roughly)? > > Thanks, > MichaelArticle: 106179
Hi,
I'm trying to get started with logic programming on this board
(ADS-XLX-V2PRO-DEVP20-6), ie. VHDL and no processors, and what could be easier
than flashing the LEDs. However, I haven't had any luck yet. Does anyone have
any such simple code which works the LEDs on this board? Or the serial line for
that matter, anything to enable me to get feedback from it. If you want to see
my efforts thus far, read on...
The best data to go by seemed to be Avnet's OPB-mem example project, which
includes a part to flash the LEDs (but driven by the processor). I ran that LED
test successfully, then tried to use it to guide my own code. I used their UCF
file almost verbatim, and wrote a simple VHDL entity which sets all the relevant
enable bits (I think I got them right, quite possibly not) and puts a constant
signal on the data bus, which should then drive the LEDs. However, no such luck
- they don't respond at all when I download the code to the board.
My speculations as to the problem:
- I missed or mis-set some enable bits,
- Something needs to transition for the LED register to be loaded. I tried to
transition the LED_CS_L signal, didn't help.
If anyone has time to look at the short VHDL file at the end, and perhaps see
what's wrong, that'd be fantastic.
I'm using ISE 8.1, downloading code over JTAG for now.
Thanks!
alex
-- main.vhd
-- Author: Alex Iliev
-- Entity based on Avnet's OPB-mem sample project
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
-- synthesis translate_off
library UNISIM;
use UNISIM.vcomponents.all;
-- synthesis translate_on
entity main is
-- these are the names used by Avnet for their ucf file, so this is just an
-- entity to allow mapping my names to their names and using their ucf file
-- as closely as possible.
port (
-- OPB_Clk : in std_logic := '0';
-- A : out std_logic_vector(0 to 31); -- A, OE, WE, D are shared flash & sram
OE_L : out std_logic;
-- RST_L : out std_logic;
SDRAM_CE_L : out std_logic;
-- sasho: for the reset button
SYS_RESET_N : in std_logic;
WE_L : out std_logic;
D : inout std_logic_vector(0 to 31);
FLASH_CS_L : out std_logic_vector(0 to 0);
SYS_ACE_CS_N : out std_logic;
GPIO_CS_N : out std_logic;
LED_CS_L : out std_logic;
-- sasho: changed this from inout in the example project to 'out' here.
SRAM_CS_L : out std_logic_vector(0 to 0) -- set up as vector to match output of platgen
-- SRAM_BS_L : out std_logic_vector(0 to 3) -- SRAM byte select
);
end main;
architecture Behavioral of main is
-- notice this is LSB on the left, like the D bus declaration taken from the
-- system_top entity.
signal data_write : std_logic_vector(0 to 31);
component IOBUF port
( O : out std_logic;
IO : inout std_logic;
I : in std_logic;
T : in std_logic);
end component;
begin
-- IOBUF for the D port. We don't need to read anything so the reading port
-- is open.
g1 : for i in D'range generate
iod0 : IOBUF port map
(I => data_write(i),
IO => D(i),
O => OPEN,
T => '0' -- enable output/disable tristate
);
end generate g1;
data_write <= X"AAAAAAAA";
LED_CS_L <= '0';
OE_L <= '1';
WE_L <= '0'; -- not sure if this WE_L is correct or
-- needed.
-- disable all other peripherals on the data bus.
SRAM_CS_L <= "1";
SDRAM_CE_L <= '1';
FLASH_CS_L <= "1";
-- these are tied to '1' as in the OPB_mem project.
SYS_ACE_CS_N <= '1';
GPIO_CS_N <= '1';
end Behavioral;
Article: 106180On 8 Aug 2006 13:52:43 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >Michael, I thought you wanted to use an FPGA (Virtex-4) for the >receiver. >Then you can use any oscillator frequency you want, and modify it with >the DCM inside the FPGA. Of course, I'm looking for an oscillator for the transmitting cpld. He also needs 100 MHz to generate the data stream but as far as I know there is now DCM or PLL in a CoolRunner 2. Or am I wrong? On the receiver side power and oscillator is no problem. MichaelArticle: 106181
True, CoolRunner has no DCM or PLL (that's what you meant to say, I suppose). When you want to tranmit 100 Mb per second in Manchester code, you really need a 200 MHz clock, since each data bit uses (potentially) two level transitions. (or you rely on the 50% clock duty cycle plus an XOR gate... Manchester code is wasteful in bandwidth, but easy to implement, and fairly rugged. Other schemes, like 8B10B use much lower bandwidth, but are more sensitive to frequency mismatch between transmitter and receiver. There are many xtal oscillator manufacturers. Typical telecom frequencies like 156 or 312 MHz oscillators are readily available, and are of high quality at a low price, if the frequency suits you. In that case you can count on extremely good frequency matching between sender and receiver. Peter Alfke, Xilinx ================ Michael Dreschmann wrote: > On 8 Aug 2006 13:52:43 -0700, "Peter Alfke" <peter@xilinx.com> wrote: > > >Michael, I thought you wanted to use an FPGA (Virtex-4) for the > >receiver. > >Then you can use any oscillator frequency you want, and modify it with > >the DCM inside the FPGA. > > Of course, I'm looking for an oscillator for the transmitting cpld. He > also needs 100 MHz to generate the data stream but as far as I know > there is now DCM or PLL in a CoolRunner 2. Or am I wrong? > On the receiver side power and oscillator is no problem. > > MichaelArticle: 106182
Antti wrote: > > cpld oscillator shure work, but you still need a resistor across not > gate in-out > it want oscillate otherwise. I have spent some time trying to get an > crystal > to swing on FPGA pins without external resistor but have not yet > succeeded. Interesting target - why is the resistor such a problem ? There are bigger headaches in FPGA osc than the resistor.. -jgArticle: 106183
Michael Dreschmann wrote: > On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote: > > >>But I prefer a dedicated oscillator, because it uses less power, and >>uses an internal chip that is optimized for the purpose, and is >>manufactured by a company with expertise and a single-minded goal. And >>it hardly costs extra... > > > Costs are no problem, it's a university project and not a design for > production. > I thought a crystal in combination with the cpld would need less power > than a dedicated oscillator. Could you give me a hint where to find a > 100 MHz low power oscialltor working at 2.5V? An external oscillator > of course would be easier. 100Mhz is tricky space for crystals, as you are also into overtone. Look at Maxim and Linear - they have a number of SOT23 Oscillators that are designed to give quite good precisions (for manchester), in 10-200Mhz ranges. If you are brave, a LC osc can be built with a CPLD Inverter ( no resistor needed ) - tho at 100Mhz the Tpd is a size-able chunk of half-period. Start at 10-20Mhz, and lower L/C, to see if 100Mhz is practical. You can also make a ring-oscillator, using just the PLD delay elements: this has the lowest precision, but manchester can auto-baud > An other question concerning power: > If I have a design that fits exactly in a xc2c64a cpld and I use the > next bigger one (xc2c128) with the same design how much more would be > the power consumption (roughly)? for low power CPLD clocking notes, take a look at this http://www.altera.com/literature/an/an422.pdf As often happens with benchmarks, the really usefull info is other-other. Here it is the Xilinx/Lattice relative infos - any Altera-others info will be carefully filtered :) -jgArticle: 106184
Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:44D8D028.7080802@xilinx.com... > >>Michael, >> >>The use of a CPLD or FPGA inversion is not recommended for a crystal >>oscillator. >> >>The problem is not that it won't work (it often does), it is that it >>sometimes will not start. The inversion also comes with a delay that is >>not something that you can easily model and prove that the oscillator >>will always start up. >> >>Once started, it will oscillate, it is the starting that is sometimes >>difficult, >> >>Austin > > > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps > and crystal will not oscillate under some conditions? > > It should be 100% a-stable as it can not stay in non-oscillating state. A more important question is WHICH frequency it oscillates at ! :) At lower slew rates (not this case), you can get multiple oscillation effects : At the thresholds, the extreme (excess) gain can give parasitic oscillations, or edge-fur, and that's NOT nice on a clock source ! -jgArticle: 106185
Frank Buss wrote: > Starting with ISE Webpack 8.2, I have to manually set the speed of the USB > port to 3 MHz every time I start Impact, because with 6 MHz the write > process is ignored most of the time and the old configuration is still > active. How can I preset 3 MHz? Looks like it is not stored in the Impact > project file. > > Or any other ideas why 6 MHz doesn't work on my computer? I've solved the problem for me: When hitting the "PROG" button or turning power off and on before accessing the board, looks like it works all the time, even with 6 MHz. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106186
I would look at the low-power xtal oscillators used in cell phones, often at 156 MHz. They are a bargain in small size, low power consumption, and cost. They are made by the millions (or is it billions by now ?) Pletronics is one manufacturer, but there are many others. Peter Alfke Jim Granville wrote: > Antti Lukats wrote: > > > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > > news:44D8D028.7080802@xilinx.com... > > > >>Michael, > >> > >>The use of a CPLD or FPGA inversion is not recommended for a crystal > >>oscillator. > >> > >>The problem is not that it won't work (it often does), it is that it > >>sometimes will not start. The inversion also comes with a delay that is > >>not something that you can easily model and prove that the oscillator > >>will always start up. > >> > >>Once started, it will oscillate, it is the starting that is sometimes > >>difficult, > >> > >>Austin > > > > > > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps > > and crystal will not oscillate under some conditions? > > > > It should be 100% a-stable as it can not stay in non-oscillating state. > > A more important question is WHICH frequency it oscillates at ! :) > At lower slew rates (not this case), you can get multiple oscillation > effects : At the thresholds, the extreme (excess) gain can give > parasitic oscillations, or edge-fur, and that's NOT nice on a clock source ! > > -jgArticle: 106187
fpga_toys@yahoo.com wrote: > JJ wrote: > > Myself I vote for the one that begins with V. > > > > Now if the C language would pick up some major extensions the likes of > > which we see in HDLs such as open ended bit sizes and the same notion > > of concurrency and nested modules I could probably do most everthing in > > a HDL C combined with regular C. If the compiler would spit out HDL for > > regular synthesis and allow HDL code to be simulated at C speeds, that > > would be neat. > > Most of the C based HDLs offer some means to assign arbitrary bit > widths to objects, frequently in ways that break ANSI C compatability. > Bit fields do however existing in the language, and in ways that are > actually pretty useful for most applications. Still, one of my nits in > doing FpgaC is to carry a proposal to the ANSI committee to allow bit > fields that are larger than the native type, forcing the compiler to > handle a 200 bit or 64 bit object the same on both an 8bit micro and a > 128 bit super computer. In FpgaC, I'm not sure there is a limit on the > width of an object, other than constants, which is something I'm > already working toward fixing. > Exactly, least possible change to the language but to allow wires bits fields to be truly arbitrarily large, Verilog allows 16M bit width if needed. perhaps we should be using Fortran or APL as base languages. Using C++ overloading operators and hence SystemC doesn't do it for me either. A base language that can do huge math ops in a few symbols is something we had 40 years ago. It is a pity N.Wirth didn't do more for HDLs beside Lola. > As for concurrency, that is something that hardware guys miss > understand completely. Every compiler is free to shuffle/reschedule the > code produced, as long as the results have the expected serial > symantics. Out of order execution and multiple issue pipelines, ARE > concurrency. As are threads, pipes, processes, and many other > concurrent abstracts in what appears a sequential language. > By concurrency I refer to the CSP model and the occam language which looks alot lke hardware design. Ofcourse HandelC evolved out of occam from the U Oxford work a decade ago in synthesizing occam processes as hardware. I don't know about the other xyzCs or FpgaC and will wait till they have been around a while. I do remember though before I became interested in FPGAs some 10 years ago several commercial ASIC HDL C and I recall that they all failed miserably in the market as "nobody wants this stuff". With FPGAs and systems guys, there is perhaps more room for using HDL C but it has to be a FREE language and preferably standardized. > In FpgaC everything in a statement group is completely concurrent. > Other C based HDLs offer other concurrency rules, from statement level > clock timing, to explict construction of parallelism using hardware HDL > semantics. > Really wIll have to look into FpgaC some time esp if its gets more traction and more references by others. snipping > While my interest in FpgaC is to build useful FPGA super computers in > the future, it's a love of both hardware design, and software design, > that enables that vision. That is not a reasonable vision, while the > only tools to program fpga designs, and at the bit and clock edge > level. I suspect, that just as assembler, and even 'low level" C is no > longer in favor for complex designs today ... there will be an > evolution where high level HDL tools move away from detailed hardware > description at the clock and signal level detail, and move up so that > system level specification which includes the interface descriptions > and leaves the internal hardware description clearly to the tools to I think there needs to be a combination of Verilog (maybe VHDL) and a subset of C++ so that processes can be described in a common language that might run as conventional software on a single or massively threaded cpu or might also be synthesized onto hardware. It should still allow for bitwise low level hardware design if need be but should also allow higher lever synthesis too. That should be a boon to those Opteron systems with FPGA coprocessors . > optimize and produce. I'm not the brighest tool designer on the planet > ... actually just a wet eared newbie ... so if I can get FpgaC to do > these things with a little magic, I'm certain the better guys on the > planet that do this for a living will blow some socks off with system > level C languages. I'm actually looking foward to a SystemC tool based > on C++ sematics that has really good synthesis ... maybe a few years > from now? I find myself moving further & further away from C++, leave as much of it as possible out of the loop. Perhaps Lisp would or should be the ticket. Well I am not the worlds brightest spark either but what I can see is a mess all around me where ever I look, most of it as a result of too much idiotic complexity and too many parties. I yearn for the simplicity of years past. I have 4 different computers around the office house and every one of them is really crap, and some of it is pretty new crap. This one won't run that OS, that OS or mobo don't like that HD, those 2 HDs from same vendor can't be on same ribbon. Its really endless list of incompatibles. Give me a system based on something like SpaceWire links for everything and lots of throughput processors and no Memory Wall! FWIW I always say that Verilog is closer to Pascal than C, C only supplies the arithmetic expression operators while Pascal supplies the module structure. A parser for C is far more complex than for Verilog even though on the surface C is supposed to be simpler. John Jakson transputer guyArticle: 106188
I'm about to test a DDR2-SDRAM controller. I have a question regarding the use of SSTL IO standard in Virtex-4: Is it needed to connect the Vref? In the user guide for Virtex-4 (ug70.pdf the bottom of page 290) I don't understand the note n2 which is related to Vcco for inputs: "Differential inputs and inputs using VREF are powered from VCCAUX. However, pin voltage must not exceed VCCO , due to the presence of clamp diodes to VCCO." Another question by the way: Which supply should Vccaux have? 2.5v? CheersArticle: 106189
I'm experiencing something strange with my Spartan 3 starter kit. It seems that when I download a bitstream via jtag directly, things don't always work the way they should. However, when I generate a mcs/prm file, then burn that prom file to the onboard prom via jtag + boot the fpga via that, it works perfectly! I've seen this behavior on multiple different designs... no common attribute as to when it happens + when it doesnt. I've tried forcing it to verify, but I've never once had that succeed, so I don't know if the verify functionality even works. Has anyone seen this before, and if so, any ideas about a solution? Cheers, --David CarneArticle: 106190
I didn't see the verify work and I haven't gone back to see if it could. The several times I've reprogrammed, the direct JTAG works fine; I've only programmed the flash load once or twice since direct seems to work. I do recall some DCM lock problems that *shouldn't* have been there as far as I could tell (and DCM reset didn't help) but I was actively changing the design and a next load usually took care of it. Rapid development masks bugs? - John_H "David Carne" <david-removeme-carne@shaw.ca> wrote in message news:20060808162224915-0700@news.vc.shawcable.net... > I'm experiencing something strange with my Spartan 3 starter kit. It > seems that when I download a bitstream via jtag directly, things don't > always work the way they should. However, when I generate a mcs/prm file, > then burn that prom file to the onboard prom via jtag + boot the fpga > via that, it works perfectly! I've seen this behavior on multiple > different designs... no common attribute as to when it happens + when it > doesnt. I've tried forcing it to verify, but I've never once had that > succeed, so I don't know if the verify functionality even works. > > Has anyone seen this before, and if so, any ideas about a solution? > > > Cheers, > > --David CarneArticle: 106191
"David Carne" wrote: > I'm experiencing something strange with my Spartan 3 starter kit. It > seems that when I download a bitstream via jtag directly, things don't > always work the way they should. However, when I generate a mcs/prm file, > then burn that prom file to the onboard prom via jtag + boot the fpga > via that, it works perfectly! Try changing the mode jumpers to JTAG; also see this msg + thread: http://groups.google.com/group/comp.arch.fpga/msg/8b2144041295cd24 John_H wrote: > I do recall some DCM lock problems that *shouldn't* have been there > as far as I could tell (and DCM reset didn't help) but I was actively changing > the design and a next load usually took care of it. Rapid development masks > bugs? My S3 board with ES silicon also exhibits SSO inspired DCM unlocks even when well within the revised^N S3 SSO guidelines. LOC'ing the DCM's to the other side of the chip 'fixed' it, but I never had the time to probe further: http://groups.google.com/group/comp.arch.fpga/msg/8becb47f6a28e749 BrianArticle: 106192
JJ wrote: > I do remember though before I > became interested in FPGAs some 10 years ago several commercial ASIC > HDL C and I recall that they all failed miserably in the market as > "nobody wants this stuff". With FPGAs and systems guys, there is > perhaps more room for using HDL C but it has to be a FREE language and > preferably standardized. 10 years ago the price performance of FPGA's really was marginal. A decade of Moore's Law, and we are just now finding the price performance of FPGA's to be very competitive ... without the proper tools. I agree that open source FPGA tools are critical .... and something that the big vendors haven't realized yet. I can still remember the posturing and standards problems that plagued the software industry 30 years ago ... till UNIX leveled the playing ground, and create a cooperative competitive environment the benifited all. Once reconfigurable computing starts to take off, the large computer vendors will mandate it. And leave those closed shops behind. Standards really make the difference ... it's why a C HDL really needs to be ANSI C, with as FEW changes as possible (IF any at all). It's actually quite possible to design with ANSI C, and leave the changes in the back end tools. Restricting bit field declarations to structures isn't really a problem, and allows portability. A few pragma's are a bit deal either. Everything else should be portable, standards based. It's the problem I had with TMCC (the starting source code for FPGA), and Handel-C. It was a hard call not to start from scratch, rather than use the subset TMCC. The evolution of TMCC to an ANSI C in the FpgaC project has been slow, but steady progress. And even as a subset, with so-so synthesis, is amazingly useful. A few more good hardware/software people working on it, and it could be really "done" in a few months. The most disappointing part of the project, has been the kids that arrive gungho, and discover it's actually some difficult learning and relatively challenging work as a programmer to do hardware tools. I'd hoped a few more computer engineering students would find the project.Article: 106193
GaL, See below, Austin GaLaKtIkUs™ wrote: > I'm about to test a DDR2-SDRAM controller. > I have a question regarding the use of SSTL IO standard in Virtex-4: Is > it needed to connect the Vref? For a driver, no. For a receiver, yes. > In the user guide for Virtex-4 (ug70.pdf the bottom of page 290) I > don't understand the note n2 which is related to Vcco for inputs: > "Differential inputs and inputs using VREF are powered from VCCAUX. This is telling you that the differential amplifier (comparator) and the Vref comparator are powered from Vccaux. That means that in order to meet the speed specifications for an input, the pin voltage should remain inside the limit of ground to Vccaux, better yet, 0.6 volts above ground, and no more than 0.6 volts below Vccaux. To go beyond this range means the full CMOS differential amplifier (comparator) may not be operating in its linear range. The comparator will function well beyond this range, but it is recommended to stay within the limits of the SSTL standard for pon voltages. > However, pin voltage must not exceed VCCO , due to the presence of > clamp diodes to VCCO." There are clamp diodes (intrinsic to the IO drivers) from ground to the pin, to Vcco. gnd ----->|------pin------->|-----Vcco Is that clear? These diodes are always there (that is what 'intrinsic' means: part of the device). They have always been there: since Virtex II in the Virtex line. The top diode to Vcco was not there in Virtex, or Virtex E. That was a long time ago. It has also been there in Spartan 3, and Spartan 3E, but not in Spartan 2, or 2E. So, diodes = S3, S3E, V2, V2 Pro, V2 Pro-X, V4, V5. > > Another question by the way: Which supply should Vccaux have? 2.5v? Vccaux is always per the data sheet: 2.5 volts. In this case, 2.5 volts. Maybe someday it will change, but so far it has not changed since it was first introduced. In any event, table 2, section 3, of the data sheet is what is important. That is where you find the recommended operating voltage ranges.Article: 106194
Antti Lukats wrote: > "Austin Lesea" wrote: >> The use of a CPLD or FPGA inversion is not recommended for a crystal >> oscillator. > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 > caps and crystal will not oscillate under some conditions? > It should be 100% a-stable as it can not stay in non-oscillating state. Back in the 1970's, an engineer I was working for decided to save a part on a design and use a spare 7414 inverter rather than a 7404 inverter as an oscillator. A TTL inverter, like the 7404, properly connected, makes a good oscillator. A 7414, which is a schmitt-trigger inverter, doesn't. Yes, it would always oscillate. But only sometimes at the correct frequency. More often at the third or fifth harmonic of the crystal. And sometimes higher harmonics. This left me with the idea that a good engineer should make sure that an oscillator design is a good design before building boards. Not afterward. -- Phil HaysArticle: 106195
On 8 Aug 2006 14:41:13 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >When you want to tranmit 100 Mb per second in Manchester code, you >really need a 200 MHz clock, since each data bit uses (potentially) two >level transitions. (or you rely on the 50% clock duty cycle plus an XOR >gate... When I simply xor the NRZ data with the clock signal I get spikes which isn't surprising. So I create two 50 MHz clocks from the 100 MHz clock that are phase-shifted by 90 degree (by using rising and falling edge of the 100 MHz clock). Then I invert one of the two clocks depending of the NRZ data bit. Finally the two 50 MHz clocks (one of them modulated by the data to send) are xored and I have my manchester signal. Because now the outputs of two flipflops are xored there is nearly no time difference between them and the output is fine (my theory, don't laugh Peter ;) ). Of course the incomming clock must have a 50% duty cycle. I haven't tested it in silicon but a Post-Fit simulation with modelsim shows a very good signal and I hope this is a good sign. >Manchester code is wasteful in bandwidth, but easy to implement, and >fairly rugged. Right, but in our application bandwidth is not a problem at the moment (optical link). We need to save power and so I try to use the smallest cpld possible. Thanks also for the infos of oscillator manufacturers. I'll look tomorrow, it's time for bed now in germany.. ;) MichaelArticle: 106196
Hi, Thank you all for your help. I think everything is clear to me now. MichaelArticle: 106197
"Jeff Cunningham" <jcc@sover.net> wrote in message news:44d7f7d1$0$6591$4d3efbfe@news.sover.net... > ZHI wrote: >> Thanks Mike Treseler >> I am not reading a vhdl netlist. I am reading a uart application >> codes. For example, the input signal (RXD signal) of FPGA firstly >> go through a IBUF then a BUFG. What's the uses of them respectively? >> Why need use these buffers? When need use them? >> Or we actually don't need to care these buffers at all. > > BUFG is a buffer which drives a global clock network. > IBUF is a buffer from the input pin. > > IBUF->BUFG would typically be used when an external pin is used to drive a > clock signal and the pin is NOT a dedicated clock input. > > Ideally a synthesizer would handle this automatically. Sometimes the tool > is not smart enough. Instantiating BUFG directly forces it to route the > signal on a global clock net. > Sometimes the tool is too smart, and sometimes what you need cannot be properly inferred. In a multiple clock design, I prefer to direct which clocks get which bufg's. I may also want to direct the naming to facilitate placement control in the constraints file. There are many potential reasons for doing direct VHDL instantation of a specific component. Nevertheless, I have difficulty with the idea of explicity instantiating hundreds of IBUFs and OBUFs in my code. The tools have matured to the extent that those key pieces will be inferred and created in the edif netlist. (It's the exceptions that merit explicit direction.) JTW > Having said that, treating a UART RXD signal as a global clock sounds > rather bizarre. > > -JeffArticle: 106198
I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I plan to use the xc3sprog program to send the bitsream to the board) and now I'd like to hook up the starter kit board and try it out... I'd like a simple design that I could run through ISE and download to the board that would do something on the LEDs so I know things are working, but I don't see anything like that - according to the README for xc3sprog there is some design called echo_out that does something like this, but I can't find it anywhere. Is it (or something similar) available on the web anywhere? ...maybe I'm missing something, but it seems like something like this should be in the Sparten-3 Starter-kit Board User Guide. One of the first things they should have you do is download a test design and run it through ISE and download the bitstream to the FPGA at which point it would display something on the LEDs in order to make sure you've hooked up everything correctly and that you've setup ISE correctly. PhilArticle: 106199
Not sure if this really helps but a few years ago I saw a problem that was remarkably similar in concept. The PC application would lock up after transferring a significant, but random amount of data to the FPGA via a serial connection. The FPGA uart was one of the free cores on the xilinx site. It turned out the receive data line into the FPGA uart was not being synchronised to the uart clock before being used in the uart. As a result the FPGA uart would occasionally get into a locked up state. (no excuse for the PC app locking up though). Fix was simply to add a flop synchornising the rxd to the uart clock. ZHI wrote: > My algorithm is to solve the linear equation R.h=b, (R matrix ,b vector > is known, generated in Matlab). R,b are transmitted to FPGA board. > After the application caculation, h is sent back to Matlab. > I set the number of trials is 100. it will no problem. If > trials=100000, it will happen the "accidently stop" in Matlab. > I guess you are right that it looks like memory leak. I tried a simple > test. > Numbers from 1 to 100 transmit from Matlab to FPGA board(UART) and send > them back. These numbers are sent back correctly. If i send the number > from 1 to 1000 to UART. The matlab will show like that: > (InputBufferSize=512 in my matlab version) > ---------------------------------------------------------------- > Error using ==> serial.fread > SIZE * PRECISION must be less than or equal to InputBufferSize. > Error in ==> testuart at 17 > y= fread(s,1000,'uint8'); > ------------------------------------------------------- > I am not sure if i say it clearly. Hope you can help me to figure it > out. > Thanks a lot. > > Zhi > >
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