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
"uvbaz" <uvbaz@stud.uni-karlsruhe.de> wrote in message news:1162831203.738143.159650@h54g2000cwb.googlegroups.com... > > i connected the oscilloscope to the end auf the > Agilent Cable, and got the stranger picture. Try longer cable and the picture will be even "stranger"... /MikhailArticle: 111601
"uvbaz" <uvbaz@stud.uni-karlsruhe.de> writes:
>Hi Jonathan,
>
>No, it is not insulting at all.
>
>Auctually there is an Agilent Softtouch Probes on the FPGA Board(for
>Logic Analyser), i connected the oscilloscope to the end auf the
>Agilent Cable, and got the stranger picture.
The LA probes have an internal RC-network (about 90K with 8.2p parallel) and
require the correct input stage. So they are not usable for normal scope inputs.
I've got biten the other way. I tried to feed the signals without the probe
heads in the LA and wondered about the strange bit patterns ;-)
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 111602reiner@hartenstein.de wrote: > Tommy Thorn wrote: >> lancepickens@gmail.com wrote: >>> Hi, >>> Coming from a scientific computing standpoint (with no hardware >>> experience). >>> I was wondering if you can improve any dedicated tasks by designing a >>> special >>> purpose chips ala FPGA to run your code? Does anyone have any >>> experience >>> with this? > > Tommy, > > There is a lot of papers around about software to FPGA migration > projects. (The highest speed-up factor I found there is 6000.) A few of > them are referenced in: > http://xputers.informatik.uni-kl.de/staff/hartenstein/lot/HartensteinWRCE06.pdf > > Rainier >> Yes. >> >> Tommy > Thats a fairly agenda driven paper. Its central theme is "Von Neumann is dead" (by the way, VN didn't create what is properly called the "stored program computer, he just had his name on the front of the joint paper that detailed it). Certainly a carefully written parallel program can have speed gains over a standard computer program, but there are many ways to achieve that parallelism, including FPGAs, multiprocessors, grids, etc. To be a viable replacement for general computing, FPGAs must have a high level language facillity associated with them, and existing efforts in that direction (C to hardware compilers) result in near parity with modern high speed processors. The true speed advantage does not occur until the design is transferred to full ASIC. Scott MooreArticle: 111603
Hi, I'm having problems hosting a ISE/EDK 8.1 SP3 project on a file server. The server runs Samba3 on Redhat. The workstation is WinXP and mounts a server folder with the "drive letter" method. When creating a new project, I get errors like "the destination folder is read-only" (which is not true). When I create the project on a local disk and copy it over to the network share later, most things work. Only the EDK submodule continue to produce errors, for example "error deleting ./src/microblaze - folder does not exist". EDK starts up with a message "CMD.EXE error, the current directory (\\server\share\folder\) may not be a UNC network path, changing to C:\". To me it seems that this may be the root cause for the subsequent errors. Note that I never used the \\server\share path, but rather worked through a driveletter mount. The ISE/EDK tools seem to resolve the driveletter to a fully qualified network path, and then choke on it. Is there a solution for this? I would really like to host the project on the server. I wouldn't mind to install other filesharing services (or a windows file server), if that helps. Regards, MarcArticle: 111604
I actually connected the co-processor to the microblaze using EDK co-processor wizard. However furthermore I checked system.mhs file. There is a line stating: PARAMETER C_FSL_LINKS = 1 So I think I can assume that the FSL is connected to the microblaze. As well in my top module file which is system.v as I've copied in my previous post, fsl connections for microblaze_to_customip and customip_to_microblaze have been instantiated. So I think that there shouldn't be a problem in connection. At least this is my impression. Zara wrote: > On 4 Nov 2006 09:31:57 -0800, "Xesium" > <amirhossein.gholamipour@gmail.com> wrote: > > >Hi guys, > >I'm trying to connect a simple co-processor to microblaze. The > >co-processor simply gets 8 inputs and does a simple arithmetic and > >gives one output. The problem that I'm currently experiencing is (I > >figured it out during simulation) that, when I put a data from > >microblaze on FSL the fsl_m_write signal from microblaze doesn't become > >1. So the co-processor never notices that there are data on the bus and > >it never changes status. As well when I check the data on the FSL > >microblaze-to-coprocessor bus, it is not what I'm trying to write. Put > >instruction takes 2 cycles to execute. The first cycle the data on FSL > >master output of microblaze is insane but the second cycle it becomes > >one. However I've made sure that FSL_M_FULL is not 1. So my FIFO is > >empty. The clk and reset signal of the co-processor is correctly > >connected to the processor. As well I'm doing blocking read and write. > >Do you have any idea why it is not working? > <...> > > I am not sure on how you do this on verilog (never workes with it!), > but I know for sure you must tell the micrtoblaze instance to really > have an fsl port (in VHDL: generic map (... C_FSL_LINKS=> 1..) > > Have you done so? Because, although all pins are there, the fsl > connection will not be instantiated if you don't tell the synthesiser > to do so > > > best regards, > > ZaraArticle: 111605
Hello all,
This is a repeat from article 104429 from june 17th to this group, see
http://www.fpga-faq.com/archives/104425.html#104429
Then the problem was in version 8.1i03, and it seemed that it would work with 8.2, but
alas it still does NOT work with 8.2i03.
Here again the problem in short:
The design is the 8051-microcontroller, now version 1.5, with patches from
http://www.oregano.at/ip/8051.htm
The design works perfectly OK in WebPACK version 7.1i04, so I would assume that something
drastic as this should not happen. The VHDL code also works on Altera FPGAs.
I am using Spartan3 here, and I'm using the linux version on Debian on Pentium IV.
From version 8 on, if MORE THAN HALF of the BRAMs are synthesized, during the end of the
synthesis fase it seems as though the blockrams are "thrown away".
The directory with the complete design can be found at
http://www.cs.rug.nl/~sietse/8051-new
In the synthesis report, mc8051_top.syr, under Low Level Synthesis the following lines appear:
INFO:Xst:2399 - RAMs <inst_Mram_mem13>, <inst_Mram_mem51> are equivalent, second RAM is removed
If the inferred rams do not take half of the available blokrams then these lines DO NOT appear
and the generated design just works. A few dozen 8051 programs are running perfectly, using
data2mem and a bmm-file to fill the memory.
If the lines appear, the blockrams are largely REMOVED and the bitfile does not work at all.
ONLY changing the size of the RAM can make the problem come and go.
But here are the relevant (i think) parts of the log (file: mc8051_top.syr):
=========================================================================
* Advanced HDL Synthesis *
=========================================================================
Loading device for application Rf_Device from file '3s400.nph' in environment /opt/WebPack-8.2.
INFO:Xst:1647 - Data output of ROM <Mrom__rom0000> is tied to register <rom_data_o>.
INFO:Xst:1650 - The register is removed and the ROM is implemented as read-only block RAM.
=========================================================================
Advanced HDL Synthesis Report
Macro Statistics
# RAMs : 3
128x8-bit single-port block RAM : 1
16384x8-bit single-port block RAM : 1
8192x8-bit single-port block RAM : 1
......
SO THE RAMs are synthesized initially!
======================================
THEN A NUMBER (5) OF STRANGE INFOs:
===================================
INFO:Xst:2399 - RAMs <inst_Mram_mem13>, <inst_Mram_mem51> are equivalent, second RAM is removed
DON'T KNOW WHAT THIS MEANS.
AND THE FINAL (synthesizer) REPORT NOTES:
# RAMS : 4
# RAMB16_S1 : 3
# RAMB16_S9 : 1
SO MOST RAMs ARE GONE!!!
=======================
=======================
What is going wrong here? Anyone an idea?
I also installed the WebPack on two different machines.
Regards,
Sietse Achterop
Computing Science department
University of Groningen
PS. I use this design in a number of courses on our University.
===============================================================
The VHDL RAM descriptions, see geheugen.vhdl, are like:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity mc8051_rom is
port (clk : in std_logic; -- clock signal
reset : in std_logic; -- reset signal
rom_data_o : out std_logic_vector(7 downto 0); -- data output
rom_adr_i : in std_logic_vector(15 downto 0)); -- adresses
end mc8051_rom;
architecture behav of mc8051_rom is
- we use a RAM that is initialized via data2mem with the hexfile.
type rom_type is array (16383 downto 0) of std_logic_vector(7 downto 0);
constant extrom : rom_type := (16383 downto 20 => x"01",
-- using 4Kbyte works?!
-- type rom_type is array (4095 downto 0) of std_logic_vector(7 downto 0);
-- constant extrom : rom_type := (4095 downto 20 => x"01",
19 downto 6 => x"00",
5 downto 0 => x"23"
); -- to avoid optimalizing out? Needed?
signal rom_adr : std_logic_vector(13 downto 0);
begin
rom_adr <= rom_adr_i(13 downto 0);
rom_read : process (clk)
begin
if rising_edge(clk) then
rom_data_o <= extrom(conv_integer(unsigned(rom_adr)));
end if;
end process rom_read;
end behav;
Article: 111606rickman wrote: > Jim Granville wrote: > >>When we spoke with infineon years ago, they said ~50K >>was enough to contemplate a new package. >>If it is one already in their flow, that helps as well. >>So, for Xilnix that means probably the QFN48. >>Then they think about OTHER customers, and something like >>this is NOT a blind alley, as there are many applications >>for CPLDs with more macrocells, but less IO. > > > It may not be a blind alley for us, but for the FPGA vendors, they > don't seem interested. The other issue with Xilinx is the family. > They are all about the Coolrunner II parts while I much prefer the > Coolrunner XPLA parts which only require a single power supply. At > least the Lattice parts incorporate an LDO if you want the advantages > of the newer process and are size limited. Well, I can understand they are less enthused about XPLA devices, as they are not their 'hot new thing' :) Some Semi suppliers will do a semi-custom easier than raise a new part number. The former only needs the volumes & packaging flows, and can even have subset testing, (and customers can do this themselves if they buy die ), whilst a new merchant part number needs more buy-in from marketing and product managers, ( as they might need to explain why sales for that line are lagging, two years down the track ) FPGA vendors already have their quasi-asic flows for FPGAs, this is just a small shift of that mindset into CPLDs, and they would PGM and test the die with your code, since this sounds like a fixed app ? -jgArticle: 111607
On 6 Nov 2006 08:40:03 -0800, "uvbaz" <uvbaz@stud.uni-karlsruhe.de> wrote: >Thanks! You have right. But how come you to the point, that the >problem there is? I have been debugging oscilloscope traces for a very, very long time :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 111608
Martin Thompson wrote:
> when I use a FIFO, all I
> want is a simple FIFO with a consistent interface. Do others have a
> different view?
> Perhaps we should all get together and write the wrappers and docs for
> this between us for the benefit of future generations ( :-)?)
I think you've hit the nail on the head.
There is no money to be made by solving
this problem, and spending time on it
won't speed up the hot project of the day.
There would have to be some other motivation.
-- Mike Treseler
Article: 111609I know there exists a path for the XUP board to communicate with a PC via the USB port because Chipscope does it and I have seen projects using their own boards but with USB as a configuration (JTAG) and communication option. The user guide doesn't give any insight on the issue and I tried searching for info on the web to no avail. Any tips or suggestions? ---Matthew HicksArticle: 111610
Try: www.opencores.org/projects.cgi/web/i2c/overview Good luck, Rotem. Chris wrote: > The opencores.org I2C appears to be only in VHDL. Does anyone know of a > free I2C master in Verilog? > > Thanks, Chris.Article: 111611
Hi i'm currently working on a high-speed chip-to-chip serial interface FPGA interface, i would like to know some suggestions regarding FPGA differential signalling; especially the trace matching of pair of LVDS signal, and the whole Channel (set of LVDS signals; Tx_Frame, Tx_Clk, Tx_Data) etc. My application is for 622Mbps signalling rate. Anyone has an experience on this?Article: 111612
Some FPGA's have PLL's that can be programmed to compensate for this offset. "Ray Andraka" <ray@andraka.com> wrote in message news:V7J3h.10344$tH2.5255@newsfe20.lga... > uvbaz wrote: > >> hallo everyone, >> >> I know that global clocks allow distributing the clock signal all over >> the FPGA with a low skew, but what happens, when i feed the clock e.g. >> my_clk into FPGA through a normal user I/O pin? >> >> I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the >> error in Xilinx ISE, my interest ist: what will happen with my_clk? >> >> Goes it after the input buffer still to the global clock buffer, or >> wires will be routed to all the flip-flops, which my_clk connectecd to? >> or somehow else? >> >> Thanks for your answer >> >> Regard, >> Cheng >> > > You should instantiate a bufg on your clock net to make sure it gets onto > the global routing. Not all synthesis tools automatically insert that > buffer, and without it, you won't get on the global clock net. Assuming > you do have that buffer, the clock that is distributed in the FPGA will > have low skew, but there will be a sizable offset from the external clock. > That may cause problems with communicating with devices external to the > FPGA.Article: 111613
Any DLL or PLL can compensate away the clock delay between its two inputs (same as an op-amp can compensate away any voltage difference between its two inputs), but you cannot mystically compensate away the dalay between the chip pin and the DLL/PLL input. Peter Alfke, Xilinx Applications On Nov 6, 5:47 pm, "Rob" <robns...@frontiernet.net> wrote: > Some FPGA's have PLL's that can be programmed to compensate for this offset. > > "Ray Andraka" <r...@andraka.com> wrote in messagenews:V7J3h.10344$tH2.5255@newsfe20.lga... > > > uvbaz wrote: > > >> hallo everyone, > > >> I know that global clocks allow distributing the clock signal all over > >> the FPGA with a low skew, but what happens, when i feed the clock e.g. > >> my_clk into FPGA through a normal user I/O pin? > > >> I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the > >> error in Xilinx ISE, my interest ist: what will happen with my_clk? > > >> Goes it after the input buffer still to the global clock buffer, or > >> wires will be routed to all the flip-flops, which my_clk connectecd to? > >> or somehow else? > > >> Thanks for your answer > > >> Regard, > >> Cheng > > > You should instantiate a bufg on your clock net to make sure it gets onto > > the global routing. Not all synthesis tools automatically insert that > > buffer, and without it, you won't get on the global clock net. Assuming > > you do have that buffer, the clock that is distributed in the FPGA will > > have low skew, but there will be a sizable offset from the external clock. > > That may cause problems with communicating with devices external to the > > FPGA.Article: 111614
Rob wrote: > Some FPGA's have PLL's that can be programmed to compensate for this offset. > This is not entirely true. The DCM will phase match the internal signal to the clock presented to it, but that does not compensate for the clock delay introduced by routing from a general purpose input. You need a feed back mechanism for that delay in order to automatically compensate. That said, the Virtex4 DCM does allow the user to program a fixed phase offset, or for the FPGA design to diddle the offset in a variable mode. A user could add an offset to compensate for the 'typical' delay, or tweak that offset till it "works", however this gets into dangerous territory since that offset compensation does not track the actual delays encountered on that route. A sophisticated user might be able to use the DCM variable offset to train on the clock signal to get something that would autocalibrate, but it isn't something I'd generally recommend for the V4 because there are better ways to handle it. The V4 offers you the idelay elements on each pin that you can use for training for data alignment based on either a training sequence or a forwarded clock. In that case, a training circuit adjusts the delay on the data path inputs to center them on the active clock edges. It is primarily intended for high data rate clock-forwarded interfaces. The other option might be to use a clock capable I/0 and the regional or local clocking, which gives a way to get in a clock for clocking a relatively small amount of local logic, and then resynchronizing the data to your global clock domain inside the FPGA.Article: 111615
Peter, >but you cannot mystically compensate away the > dalay between the chip pin and the DLL/PLL input. Why not? I've done this before. Perhaps we are talking about different things. If data and clock arrive at the FPGA concurrently, and I want the input flop on the data to be clocked by a global clock generated by a PLL, not the clock coming into the device, compensation (phase angle) has to be adjusted to account for clock network delays. These delays are known and can be easily compensated for by the hardware, so nothing is done mystically. Thank you, Rob "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162864709.366762.172700@b28g2000cwb.googlegroups.com... > Any DLL or PLL can compensate away the clock delay between its two > inputs (same as an op-amp can compensate away any voltage difference > between its two inputs), but you cannot mystically compensate away the > dalay between the chip pin and the DLL/PLL input. > Peter Alfke, Xilinx Applications > > On Nov 6, 5:47 pm, "Rob" <robns...@frontiernet.net> wrote: >> Some FPGA's have PLL's that can be programmed to compensate for this >> offset. >> >> "Ray Andraka" <r...@andraka.com> wrote in >> messagenews:V7J3h.10344$tH2.5255@newsfe20.lga... >> >> > uvbaz wrote: >> >> >> hallo everyone, >> >> >> I know that global clocks allow distributing the clock signal all over >> >> the FPGA with a low skew, but what happens, when i feed the clock e.g. >> >> my_clk into FPGA through a normal user I/O pin? >> >> >> I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the >> >> error in Xilinx ISE, my interest ist: what will happen with my_clk? >> >> >> Goes it after the input buffer still to the global clock buffer, or >> >> wires will be routed to all the flip-flops, which my_clk connectecd >> >> to? >> >> or somehow else? >> >> >> Thanks for your answer >> >> >> Regard, >> >> Cheng >> >> > You should instantiate a bufg on your clock net to make sure it gets >> > onto >> > the global routing. Not all synthesis tools automatically insert that >> > buffer, and without it, you won't get on the global clock net. Assuming >> > you do have that buffer, the clock that is distributed in the FPGA will >> > have low skew, but there will be a sizable offset from the external >> > clock. >> > That may cause problems with communicating with devices external to the >> > FPGA. >Article: 111616
"yy" <yy7d6@yahoo.com.ph> wrote in message news:1162860919.587459.46830@m73g2000cwd.googlegroups.com... > Hi i'm currently working on a high-speed chip-to-chip serial interface > FPGA interface, i would like to know some suggestions regarding FPGA > differential signalling; especially the trace matching of pair of LVDS > signal, and the whole Channel (set of LVDS signals; Tx_Frame, Tx_Clk, > Tx_Data) etc. > My application is for 622Mbps signalling rate. > Anyone has an experience on this? > It's important to keep all signals' p-to-n length matched closely. This will insure that there is a clean cross between the p and n inputs of the input comparator during one-to-zero and zero-to-one transitions. You don't want a p input to change from zero to one while the n input is still stuck at a one. For signal-to-signal length matching (in a source synchronous bus), you must consider the outputs' clock-to-out delay matching and the inputs' setup and hold time. There is no way to determine the length matching requirements without knowledge of the output and input characteristics. I would recommend using a FPGA family that has internal 100ohm differential termination (within the input block). For Xilinx, this is V2Pro and above (watch the VCCO requirements carefully). This will make layout easier and give you the best setup and hold margin because at 622Mbps you're gonna need all you can get. BobArticle: 111617
Ray, Some FPGA's do have a feed back pin to do what you are describing. My original post was not meant to reference the Virtex4. My intent was to add to the general discussion of clock delay and skew. The training you mention is something that my company had done to automatically compensate for data / clock skew--pretty neat. Sorry for any confusion. Rob "Ray Andraka" <ray@andraka.com> wrote in message news:mfS3h.11272$Wb2.6990@newsfe22.lga... > Rob wrote: > >> Some FPGA's have PLL's that can be programmed to compensate for this >> offset. >> > > > This is not entirely true. The DCM will phase match the internal signal > to the clock presented to it, but that does not compensate for the clock > delay introduced by routing from a general purpose input. You need a feed > back mechanism for that delay in order to automatically compensate. > > That said, the Virtex4 DCM does allow the user to program a fixed phase > offset, or for the FPGA design to diddle the offset in a variable mode. A > user could add an offset to compensate for the 'typical' delay, or tweak > that offset till it "works", however this gets into dangerous territory > since that offset compensation does not track the actual delays > encountered on that route. A sophisticated user might be able to use the > DCM variable offset to train on the clock signal to get something that > would autocalibrate, but it isn't something I'd generally recommend for > the V4 because there are better ways to handle it. The V4 offers you the > idelay elements on each pin that you can use for training for data > alignment based on either a training sequence or a forwarded clock. In > that case, a training circuit adjusts the delay on the data path inputs to > center them on the active clock edges. It is primarily intended for high > data rate clock-forwarded interfaces. The other option might be to use a > clock capable I/0 and the regional or local clocking, which gives a way to > get in a clock for clocking a relatively small amount of local logic, and > then resynchronizing the data to your global clock domain inside the FPGA. >Article: 111618
I just wanted to clear up the confusion: A closed-loop compensation can only occur between the two inputs of the DCM or PLL, I think we can all agree on that. The user can then introduce an open-loop correction to the DCM or PLL inputs, with the caveats that Ray mentioned. Peter Alfke On Nov 6, 7:07 pm, "Rob" <robns...@frontiernet.net> wrote: > Ray, > > Some FPGA's do have a feed back pin to do what you are describing. My > original post was not meant to reference the Virtex4. My intent was to add > to the general discussion of clock delay and skew. > > The training you mention is something that my company had done to > automatically compensate for data / clock skew--pretty neat. > > Sorry for any confusion. > > Rob > > "Ray Andraka" <r...@andraka.com> wrote in messagenews:mfS3h.11272$Wb2.6990@newsfe22.lga... > > > Rob wrote: > > >> Some FPGA's have PLL's that can be programmed to compensate for this > >> offset. > > > This is not entirely true. The DCM will phase match the internal signal > > to the clock presented to it, but that does not compensate for the clock > > delay introduced by routing from a general purpose input. You need a feed > > back mechanism for that delay in order to automatically compensate. > > > That said, the Virtex4 DCM does allow the user to program a fixed phase > > offset, or for the FPGA design to diddle the offset in a variable mode. A > > user could add an offset to compensate for the 'typical' delay, or tweak > > that offset till it "works", however this gets into dangerous territory > > since that offset compensation does not track the actual delays > > encountered on that route. A sophisticated user might be able to use the > > DCM variable offset to train on the clock signal to get something that > > would autocalibrate, but it isn't something I'd generally recommend for > > the V4 because there are better ways to handle it. The V4 offers you the > > idelay elements on each pin that you can use for training for data > > alignment based on either a training sequence or a forwarded clock. In > > that case, a training circuit adjusts the delay on the data path inputs to > > center them on the active clock edges. It is primarily intended for high > > data rate clock-forwarded interfaces. The other option might be to use a > > clock capable I/0 and the regional or local clocking, which gives a way to > > get in a clock for clocking a relatively small amount of local logic, and > > then resynchronizing the data to your global clock domain inside the FPGA.Article: 111619
Rob wrote: > Ray, > > Some FPGA's do have a feed back pin to do what you are describing. My > original post was not meant to reference the Virtex4. My intent was to add > to the general discussion of clock delay and skew. > > The training you mention is something that my company had done to > automatically compensate for data / clock skew--pretty neat. > > Sorry for any confusion. > > Rob Virtex4, as well as the other Xilinx FPGAs do have a feedback pin, which can be connected to an external net in order to deskew at the package level. In order to work properly, that feedback should come in on a global clock input, otherwise the compensation is destroyed by the internal route delays. The OP started out by saying he couldn't use the global clock pin for whatever reason, and therefore I was also assuming that using it for external feedback was also off the table. If you haven't done it already, the training is made much easier in V4 relative to earlier families.Article: 111620
Yes, my comments were assuming the signals were coming in on pins that drive the global networks. The stuff we usually work on is high-speed and skew sensitive, therefore I don't use anything but global clock pins. I know an engineer that made the mistake of not using a global clock pin and put himself into a bit of bind. Actually, the problems he had fall right into the things you describe. My motto is always use the global clock pins. "Ray Andraka" <ray@andraka.com> wrote in message news:DiT3h.10408$tH2.608@newsfe20.lga... > Rob wrote: > >> Ray, >> >> Some FPGA's do have a feed back pin to do what you are describing. My >> original post was not meant to reference the Virtex4. My intent was to >> add to the general discussion of clock delay and skew. >> >> The training you mention is something that my company had done to >> automatically compensate for data / clock skew--pretty neat. >> >> Sorry for any confusion. >> >> Rob > > Virtex4, as well as the other Xilinx FPGAs do have a feedback pin, which > can be connected to an external net in order to deskew at the package > level. In order to work properly, that feedback should come in on a > global clock input, otherwise the compensation is destroyed by the > internal route delays. The OP started out by saying he couldn't use the > global clock pin for whatever reason, and therefore I was also assuming > that using it for external feedback was also off the table. > > If you haven't done it already, the training is made much easier in V4 > relative to earlier families.Article: 111621
Ray, > ... under 13 msec including raster order input and output for an imaging > application Does this include the transfer time to and from the source/destination, or only the calculation time? Marc Reinig Laboratory for Adaptive Optics Fax UCO/Lick "Ray Andraka" <ray@andraka.com> wrote in message news:zya3h.8894$Wb2.7137@newsfe22.lga... > > > There are plenty of scientific apps out there that are being sped up by > FPGAs. I, for instance am just finishing up a 2D 32-2048 point floating > point FFT engine in Virtex4 that can compute a 2D 2Kx2K FFT on complex > data in under 13 msec including raster order input and output for an > imaging application. It resides in a single Virtex4 SX55 with external > QDR memory. >Article: 111622
The Verilog directory is *empty*. Paul S. "Rotem" <rotem.gazit@gmail.com> wrote in message news:1162848873.305384.84750@m7g2000cwm.googlegroups.com... > Try: www.opencores.org/projects.cgi/web/i2c/overviewArticle: 111623
I'm having problems getting a simulation running. Here's the recipe...
Quartus output VHO file - contains VHDL & Verilog components.
Testbench components - VHDL & Verilog components.
Note (and I *think* this is part of the problem) the VHO file contains a
certain verilog modle, whilst the testbench also contains an instance of
the same module, albeit with *different* parameter values.
Attempting to start the simulation under ModelSim ('vsim') loads a bunch
of structures from the library, and then halts with an error that just
does *not* make any sense at all!
The error is "irda_peripheral.v(155) The width (1) of VHDL port
'addr_cnt_out_2' does not match the width (5) of its Verilog connection
(3rd connection)".
This error occurs in the file that contains a 2nd instance of the
verilog module, and the 3rd connection is indeed a vector whose width is
specified with a parameter - which incidently differs from the value for
the instance inside the VHO file.
However:
* addr_cnt_out is internal to the VHO and not connected to the instance
in this file at all.
* neither of the parameters specify a width of '1' for the vector.
I suspect Modelsim is getting confused between the instance in the VHO
file and the instance in irda_peripheral.v and is having trouble wiring
up the ports?!?
Anyone else had a similar experience?
Regards,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Article: 111624Hello all, I'm designing with Altera FPGA with their Quartus software. My company also have license for Mentor Graphics' Precision synthesis tool. From a very brief check, it seems that Quartus' built-in synthesizer gives comparable results to the Precision. I wonder if there is any advantage in using an external synthesis tool. What does it give me more than Quartus has to offer? Thanks, Avishay
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