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
I have completed three designs now which linked V2Pro's together over a cable at 2.5 or ~3.1 Gb/S. One used HSSDC cables which are used for fibre channel. Worked fine at 5M, although I did spec low loss and very thick TurboQuad cable. I have also had sucess with samtec high speed flex cables (4 x 3.1 Gb) http://www.samtec.com/high_speed_connectors/2006/SI_C2B.asp?m=hs#HSF Finally, I ran 4 x 2.5 G over 4 x SFP connectors and copper cable http://www.methode.com/datamate/sfp/index.html Basically, if you are careful with the layout and use a connector/cable designed for high speed signals you should be ok. I was lucky I could put the Xilinx right beside the connector in all cases. Longer than a few meters, or faster than 3G would make me more nervous. You will have to be even more careful and do lots of testing and eye measurements. Cheers, MikeJArticle: 107126
Totally_Lost wrote: > As I've noted before, you seriously need to "derate" large Xiinx FPGAs > for designs that have very high percentage of active logic. Since they > assume around 15-20% of the design will be active, it's very easy to be > unable to get power into the devices within the spec'ed voltage > margins, or to keep it cool if you do. Doing single point thermal > monitoring on the die, may not be enough to readily identify that other > portions of the die are well above that limit temp once you are > agressively cooling the part. > > Packing the device from edge to edge with active logic will cause > problems. At both high speeds and high density, many of the larger > parts are simply not usable. > I've packed some big FPGAs pretty densely with designs working at some pretty high clock rates (usually in the neighborhood of the maximum a 16 bit carry chain with inputs registered in adjacent slices can be clocked in that device) and have never had to derate a part. I've had a few that I needed to aggresively cool, but none that I've ever had to derate. Most of those designs required hand placement and careful design to meet timing. I certainly wouldn't call the large parts unusable for dense high performance designs. Demanding of careful design, yes. Unusable, no.Article: 107127
Mike Treseler wrote: > mikegurche@yahoo.com wrote: > > > This approach is based on the observation that synthesis software is > > weak on architecture-level manipulation but good at gate-level logic > > minimization. > > I have observed that synthesis software does what it is told. > If I describe two gates and a flop, that is what I get. > If I describe a fifo or an array of counters, that > is what I get. > > > The advantage of this approach is that I have better control on final > > hardware implementation. Instead of blindly relying on synthesis > > software and testing code in a trial-and-error basis, I can > > consistently get what I want, regardless which synthesis software is > > used. > > What I want is a netlist that sims the same > as my code and makes reasonable use of the > device resources. Synthesis does a good > job of this with the right design rules. > Trial and error would only come into play > if I were to run synthesis without simulation. > > > On the downside, this approach requires more time in initial > > design phase and the code is less compact. The VHDL code itself > > sometimes can be cumbersome. But it is clear and easy to comprehend > > when presented with the block diagram. > > I prefer clean, readable code, > verified by simulation and static timing. > I use the rtl viewer to convert > my logical description to a structural > one for review. > > > -- Mike Treseler Mike T., This issue has been debated in many threads and I don't want to do it again. The original poster, Eli, stated: ". . . I had no intention to reach a common consensus. I wanted to see practical code examples which demonstrate the various techniques and discuss their relative merits and disadvantages" I expressed my opinion and gave an example from a book. You can do the same. Whatever method you choose is fine with me, but I am irritated that you always think your way is THE WAY. Mike G.Article: 107128
> the input" but what waitrequest is all about is to signal the end of the
> 'address phase' of the transaction where 'address phase' are the clock
> cycle(s) where read and/or write are asserted along with address and
> writedata (if write is asserted).
If we could agree on slaves that don't need address/write
data/commands for more than one cycle we could completely eliminate
the waitrequest ;-)
Let's say the address/command phase is per definition one cycle.
That definition frees the master to do whatever it wants in the next
cycle. For another request to the same slave it has to watch for the
rdy_cnt in SimpCon. However, you can design a switch fabric with
SimpCon where it is legal to issue a command to a different slave in
the next cycle without attention to the first slave. You can just
ignore the first slaves output until you want to use it.
> The Avalon fabric 'almost' passes the waitrequest signal right back to the
> master device, the only change being that the Avalon logic basically gates
> the slave's waitrequest output with the slave's chipselect input (which the
> Avalon fabric creates) to form the master's waitrequest input (assuming a
> simple single master/slave connection for simplicity here). Per Avalon,
I'm repeating myself ;-) That's the point I don't like in Avalon,
Wishbone, OPB,...: You have a combinatorial path from address
register - decoding - slave decision - master decision (to hold
address/command or not). With a few slaves this will not be an
issue. With more slaves or a more complicated interconnect (multiple
master) this can be your critical path.
BTW: AMBA APB is an exception: It also requests the ready decision
(PREADY) in the following cycle. But AMBA APB still forces the
master to hold address/command till PREADY.
AMBA AHB is a little different: there is still an address and data
phase, but hey can overlap. On a wait request the address and data
have to be held by the master (although in the basic transfer this
is not necessary. A little bit confusing...
> Given the description that Martin posted on how his SimpCon interface logic
> works it 'appears' that he believes that this ability to start up another
> cycle prior to completion (meaning the data from the read has actually been
> returned) is what is giving SimpCon the edge over Avalon. At least that's
No, that's not the difference. I agree that for fully pipelined
transactions (e.g. cache line read) both busses should give you
absolutely the same performance.
> how it appears to me, which is why I asked him to walk me through the
> transaction to find where I'm missing something. My basic confusion is not
> understanding just exactly where in the read transaction does SimpCon 'pull
> ahead' of Avalon and give 'JOP on SimpCon' the performance edge over 'JOP on
> Avalon'.
As described in the other posting:
a.) the early pipeline restart
b.) the additional cycle in the Avalon interface for the
register to hold the data for the master (should be enhanced)
Martin
Article: 107129No more die shrinks, since ant smaller process needs a different supply voltage, and thus is an incompatible part. Also Spartan may have been a version of Virtex in the past. Nowadays the design goals are so much different ( die cost, speed, I/O vs logic density, package cost) that the two product lines are diverging more and more. Remember the original Porsche? It was a VW with a modified body and souped-up engine. No more! Peter Alfke kayrock66@yahoo.com wrote: > They actually kinda do die shrinks, but they give the new die a new > name and alter a few other things. Example, a Virtex 2 becomes a > Spartan 3, you get the idea... > > For each step in the process technology they make the trade offs that > make sense for those geometries (e.g bigger memory). They first > release a high priced wiz bang part with one name, then they follow up > with a lower price smaller die using the same process and give it a > different name. > >Article: 107130
Ray, I agree. Good post. Totally_Lost is, unfortunately, lost... totally. Austin Ray Andraka wrote: > Totally_Lost wrote: > >> As I've noted before, you seriously need to "derate" large Xiinx FPGAs >> for designs that have very high percentage of active logic. Since they >> assume around 15-20% of the design will be active, it's very easy to be >> unable to get power into the devices within the spec'ed voltage >> margins, or to keep it cool if you do. Doing single point thermal >> monitoring on the die, may not be enough to readily identify that other >> portions of the die are well above that limit temp once you are >> agressively cooling the part. >> >> Packing the device from edge to edge with active logic will cause >> problems. At both high speeds and high density, many of the larger >> parts are simply not usable. >> > > I've packed some big FPGAs pretty densely with designs working at some > pretty high clock rates (usually in the neighborhood of the maximum a 16 > bit carry chain with inputs registered in adjacent slices can be clocked > in that device) and have never had to derate a part. I've had a few that > I needed to aggresively cool, but none that I've ever had to derate. > Most of those designs required hand placement and careful design to meet > timing. I certainly wouldn't call the large parts unusable for dense > high performance designs. Demanding of careful design, yes. Unusable, no. >Article: 107131
mikegurche@yahoo.com wrote:
> The original poster, Eli, stated:
>> ". . . I had no intention to reach a common consensus. I wanted to
>> see practical code examples which demonstrate the various techniques
>> and discuss their relative merits and disadvantages"
I've already shared my examples.
My posting was intended as part of the
"discussion of their relative merits and disadvantages"
> I expressed my opinion and gave an example from a book. You can do
> the same. Whatever method you choose is fine with me, but I am
> irritated that you always think your way is THE WAY.
The vast majority of designers use your style, not mine.
Backhus said it best:
"discussion about styles is not really satisfying. You find it in this
newsgroup again and again, but in the end most people stick to the style
they know best. Style is a personal question than a technical one."
-- Mike Treseler
Article: 107132I'm having problems instantiating my EDK file within an ISE project. I have a top level VHDL that looks like: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; ---- Uncomment the following library declaration if instantiating ---- any Xilinx primitives in this code. library UNISIM; use UNISIM.VComponents.all; entity topnew is end topnew; architecture RTL of topnew is begin COMPONENT system PORT( fpga_0_RS232_Uart_RX_pin : IN std_logic; fpga_0_DDR_CLK_FB : IN std_logic; sys_clk_pin : IN std_logic; sys_rst_pin : IN std_logic; PortName : IN std_logic; fpga_0_LEDs_4Bit_GPIO_IO_pin : INOUT std_logic_vector(0 to 3); fpga_0_LEDs_Positions_GPIO_IO_pin : INOUT std_logic_vector(0 to 4); fpga_0_Push_Buttons_Position_GPIO_IO_pin : INOUT std_logic_vector(0 to 4); fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin : INOUT std_logic_vector(0 to 3); fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin : INOUT std_logic_vector(0 to 31); fpga_0_SRAM_256Kx32_Mem_DQ_pin : INOUT std_logic_vector(0 to 31); fpga_0_RS232_Uart_TX_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin : OUT std_logic_vector(0 to 12); fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin : OUT std_logic_vector(0 to 1); fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin : OUT std_logic; fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin : OUT std_logic_vector(0 to 3); fpga_0_SRAM_256Kx32_Mem_A_pin : OUT std_logic_vector(9 to 29); fpga_0_SRAM_256Kx32_Mem_BEN_pin : OUT std_logic_vector(0 to 3); fpga_0_SRAM_256Kx32_Mem_WEN_pin : OUT std_logic; fpga_0_SRAM_256Kx32_Mem_OEN_pin : OUT std_logic_vector(0 to 0); fpga_0_SRAM_256Kx32_Mem_CEN_pin : OUT std_logic_vector(0 to 0); fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin : OUT std_logic; fpga_0_SRAM_CLOCK : OUT std_logic ); END COMPONENT; Inst_system: system PORT MAP( fpga_0_RS232_Uart_RX_pin => , fpga_0_RS232_Uart_TX_pin => , fpga_0_LEDs_4Bit_GPIO_IO_pin => , fpga_0_LEDs_Positions_GPIO_IO_pin => , fpga_0_Push_Buttons_Position_GPIO_IO_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin => , fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin => , fpga_0_SRAM_256Kx32_Mem_A_pin => , fpga_0_SRAM_256Kx32_Mem_BEN_pin => , fpga_0_SRAM_256Kx32_Mem_WEN_pin => , fpga_0_SRAM_256Kx32_Mem_DQ_pin => , fpga_0_SRAM_256Kx32_Mem_OEN_pin => , fpga_0_SRAM_256Kx32_Mem_CEN_pin => , fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin => , fpga_0_SRAM_CLOCK => , fpga_0_DDR_CLK_FB => , sys_clk_pin => , sys_rst_pin => , PortName => ); end architecture RTL; ----------- But I get these errors: Compiling vhdl file "D:/comp8_xmp_ise/comp8/topnew.vhd" in Library work. ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 37. parse error, unexpected COMPONENT ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 40. parse error, unexpected IN ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 41. parse error, unexpected INArticle: 107133
I've created a patch for Impact so it supoorts Digilent USB. This patch could be modified to become some kind of SDK for different programmer cable which are not supported by Impact. So here is my survey. What kind of programmer cables would you like to use with Impact? Regards, ZoltanArticle: 107134
hi http://indi.joox.net now has the first compiled quartus files for the 16 bit indi core. basiclly and alu, control and registers, with fast interrupt switch. asynchro busy of cpu, and syncronous reset. the bus interface is not complete yet, as i have to think about the expansion modules. bsd licence, not tested as no test bench, but logic looks ok. cheers jacko p.s. i am thinking different read and write address buses, and some carry extension logic.Article: 107135
zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote: > I've created a patch for Impact so it supoorts Digilent USB. This patch > could be modified to become some kind of SDK for different programmer > cable which are not supported by Impact. > So here is my survey. What kind of programmer cables would you like to > use with Impact? For me, the biggest problem (with impact on linux) is the use of the windriver. It needs a recompile for every kernel update, it doesn't play nice with with other users of the parallel port (the normal lp module), it creates a security hole as big as a barn door, it taints the kernel and is usefull as a P.I.T.A. as ppdev/libusb could deliver the needed functionality for free. Otherwise, the MPSSE mode of the FT2232 would be welcome. B.t.w, I'll try to get MPSSE running for xilprog a.s.a.p. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 107136
My version works only on Win32 :( I do a lot of embedded Linux stuff, but I prefer my Windows desktop :) Uwe Bonnes wrote: > zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote: > > I've created a patch for Impact so it supoorts Digilent USB. This patch > > could be modified to become some kind of SDK for different programmer > > cable which are not supported by Impact. > > > So here is my survey. What kind of programmer cables would you like to > > use with Impact? > > For me, the biggest problem (with impact on linux) is the use of the > windriver. It needs a recompile for every kernel update, it doesn't play > nice with with other users of the parallel port (the normal lp module), it > creates a security hole as big as a barn door, it taints the kernel and is > usefull as a P.I.T.A. as ppdev/libusb could deliver the needed functionality > for free. > > Otherwise, the MPSSE mode of the FT2232 would be welcome. > > B.t.w, I'll try to get MPSSE running for xilprog a.s.a.p. > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 107137
Chuck Levin wrote: > I was thinking about using QuickLogic for a low power FPGA design. Does > anyone have any experiences they would like to share about their devices or > tools ? I did a PCI (actually PMC, but same thing, different form factor) design using the QL5064 device. Pros: * The tech support was excellent and their simulation models were great. * The core-to-fabric interface was well-documented and easy to use. * Behind a bridge, the chip did DMA transfers (64-bit/66MHz) at 500 MB/s. Hot damn. Specifics: we put two identical boards (each w/QL5064 and 1 GB SDRAM) onto a PMC carrier board, and told one to do DMA writes to the other. * Instant on -- no waiting forever (or at least beyond the PCI reset time) for the device to configure. * Only needs a single 3.3V power supply. Cons: * The fabric was supposed to work up to 100 MHz, but the interface between the fabric and the PCI core doesn't go that fast. Newer FPGAs from other vendors go a lot faster. * I couldn't get the full-up Leonardo (and later, Mentor Precision) to work with the device. The QuickLogic tools come with a QL-specific version of Synplify so I used that. Perhaps the full-up version of Synplify would have given me better results. Dunno * There's not much available in terms of interesting features: no clock DLL or PLL, no LVDS, etc, etc, etc. * They're OTP and you can't program them in-circuit, so you've got to spring for their programmer or use the factory programming services (which works well except you don't get instant gratification). * OTP means that you'll need an expensive socket on your prototype boards for development. * The parts are not cheap, esp. considering the speed. Good luck, -aArticle: 107138
me_2003@walla.co.il wrote: >> the clock rate is not the issue beacuse I dont want to give two cycles > for each write (not very elegant). To hell with elegance. Just make it work at the speed, and the cost, and the amount off effort that is acceptable... Peter AlfkeArticle: 107139
OK I figured it out. This was my own ignorance of VHDL. I'm a Verilog user. The Component declaration must go below the architecture of __ is line and the Port Map is below begin matteo wrote: > I'm having problems instantiating my EDK file within an ISE project. > > I have a top level VHDL that looks like: > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > ---- Uncomment the following library declaration if instantiating > ---- any Xilinx primitives in this code. > library UNISIM; > use UNISIM.VComponents.all; > > entity topnew is > end topnew; > > architecture RTL of topnew is > > begin > > COMPONENT system > PORT( > fpga_0_RS232_Uart_RX_pin : IN std_logic; > fpga_0_DDR_CLK_FB : IN std_logic; > sys_clk_pin : IN std_logic; > sys_rst_pin : IN std_logic; > PortName : IN std_logic; > fpga_0_LEDs_4Bit_GPIO_IO_pin : INOUT std_logic_vector(0 to 3); > fpga_0_LEDs_Positions_GPIO_IO_pin : INOUT std_logic_vector(0 to 4); > fpga_0_Push_Buttons_Position_GPIO_IO_pin : INOUT std_logic_vector(0 > to 4); > fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin : INOUT std_logic_vector(0 to 3); > fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin : INOUT std_logic_vector(0 to 31); > fpga_0_SRAM_256Kx32_Mem_DQ_pin : INOUT std_logic_vector(0 to 31); > > fpga_0_RS232_Uart_TX_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin : OUT std_logic_vector(0 to 12); > fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin : OUT std_logic_vector(0 to > 1); > fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin : OUT std_logic; > fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin : OUT std_logic_vector(0 to 3); > fpga_0_SRAM_256Kx32_Mem_A_pin : OUT std_logic_vector(9 to 29); > fpga_0_SRAM_256Kx32_Mem_BEN_pin : OUT std_logic_vector(0 to 3); > fpga_0_SRAM_256Kx32_Mem_WEN_pin : OUT std_logic; > fpga_0_SRAM_256Kx32_Mem_OEN_pin : OUT std_logic_vector(0 to 0); > fpga_0_SRAM_256Kx32_Mem_CEN_pin : OUT std_logic_vector(0 to 0); > fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin : OUT std_logic; > fpga_0_SRAM_CLOCK : OUT std_logic > ); > END COMPONENT; > > Inst_system: system PORT MAP( > fpga_0_RS232_Uart_RX_pin => , > fpga_0_RS232_Uart_TX_pin => , > fpga_0_LEDs_4Bit_GPIO_IO_pin => , > fpga_0_LEDs_Positions_GPIO_IO_pin => , > fpga_0_Push_Buttons_Position_GPIO_IO_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin => , > fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin => , > fpga_0_SRAM_256Kx32_Mem_A_pin => , > fpga_0_SRAM_256Kx32_Mem_BEN_pin => , > fpga_0_SRAM_256Kx32_Mem_WEN_pin => , > fpga_0_SRAM_256Kx32_Mem_DQ_pin => , > fpga_0_SRAM_256Kx32_Mem_OEN_pin => , > fpga_0_SRAM_256Kx32_Mem_CEN_pin => , > fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin => , > fpga_0_SRAM_CLOCK => , > fpga_0_DDR_CLK_FB => , > sys_clk_pin => , > sys_rst_pin => , > PortName => > ); > > > end architecture RTL; > > > ----------- > > But I get these errors: > > Compiling vhdl file "D:/comp8_xmp_ise/comp8/topnew.vhd" in Library > work. > ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 37. > parse error, unexpected COMPONENT > ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 40. > parse error, unexpected IN > ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 41. > parse error, unexpected INArticle: 107140
> * Behind a bridge, the chip did DMA transfers (64-bit/66MHz) at 500 > MB/s. Hot damn. Specifics: we put two identical boards (each w/QL5064 > and 1 GB SDRAM) onto a PMC carrier board, and told one to do DMA writes > to the other. > * Instant on -- no waiting forever (or at least beyond the PCI reset > time) for the device to configure. > * Only needs a single 3.3V power supply. Andy -- The QL5064 will go full tilt (533MB/s) if you are interested. There is a small matter about violating the PCI spec ...Article: 107141
GaLaKtIkUs=99 wrote: > Hi all! > Is there a way to check the syntax of an HDL file using Xilinx command > line tools? > > Thanks in advance If XST is launched with the "-compileonly" option than it will just compile the code which will in the same time make syntax check!!!Article: 107142
Antti wrote: > GaLaKtIkUs=99 schrieb: > > > In the Virtex-4 user guide (ug070.pdf p.365 table 8-4) it is clearly > > indicated that for INTERFACE_TYPE=3DNETWOKING and DATA_RATE=3DSDR the > > latency should be 2 CLKDIV clock periods. > > I instantiated an ISERDES of DATA_WIDTH=3D6 but I see that valid output > > appears on the next CLKDIV rizing edge. > > Any explanations? > > > > Merci d'avance! > > advice: dont belive the simulator, its not always correct. > place the iserdes and chipscope ILA into dummy toplevel, load some FPGA > and look what happens in real silicon. > > Antti The only Virtex-4 based board I have is the ML403. Any advice on which I/O to use? Is it possible to use some signal on one the expansion headers? i.e to loop it back without load resistor? or I should use DCI?Article: 107143
Austin Lesea wrote: > Totally_Lost is, unfortunately, lost... totally. So ... you are claiming any valid design will run in any Xilinx FPGA at max clock rate?Article: 107144
vt2001cpe wrote: > Anyone have experience with directly driving a cable with RocketIO? I > am interested in any information/experiences/advice regarding linking > two FPGAs via RocketIO over a cable. I have seen some signal > characterization information for high-speed links over copper, but > usually less than 800Mhz. I believe my implementation would use a a > less than 1 meter, but would like to know it works at 3, 5, > 10...meters. Ideally I would like to run the link at 10gbits, but > 6gbits could work. How feasible is this, or is it back to the drawing > board? Running RocketIO over a cable isn't a problem, but of course it depends on the cable characteristics, the data rate and acceptable losses. We have a number of reports on tests that were done with Virtex-II Pro RocketIO links: Infiniband - http://direct.xilinx.com/bvdocs/reports/ug043.pdf SATA - http://direct.xilinx.com/bvdocs/reports/rpt005.pdf CAT5/5e/6 - http://direct.xilinx.com/bvdocs/reports/rpt004.pdf Out of all of these the Infiniband style cables are the best and come in a variety of lengths and number of channels. I don't have any experience with PCI Express cables, but that they should be just as good since they use the same internal cable technology as the Infiniband cables. http://www.molex.com/cgi-bin/bv/molex/jsp/family/intro.jsp?superFamOID=-16583&pageTitle=Introduction&channel=Products&familyOID=-16641&chanName=family&frellink=Introduction Ed McGettigan -- Xilinx Inc.Article: 107145
zcsizmadia@gmail.com wrote: > My version works only on Win32 :( > I do a lot of embedded Linux stuff, but I prefer my Windows desktop :) How'd you patch it? It should be possible to port your change over to Linux (perhaps using a different technique but the mechanics of your patch should still apply) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107146
Austin Lesea wrote: > There is no such thing as "over-clocking" a FPGA: either it meets > timing and works, or it doesn't. You may have to have very exotic > cooling in order not to melt down the device, at speeds like 550 MHz > with all of the logic toggling. The Industrial temp spec is the > junction must be kept below 100C. Commercial grade must be kept below 85C. Excuse me .... "Over clocking" is defined as clocking faster than MFG Rated Specs. Certainly running any Xilinx FPGA past speced clock rates, is clearly "over clocking". In Fact, Over clocking is by definition the practice of taking parts (CPU, Memory, etc) to the edge of the process where it fails, and backing it off so it doesn't. Who is lost? totally .... ???? > You could increase the clock rate till the device fails to operate > correctly, or can not be cooled, but in this application it would be > very difficult to know if it wasn't operating correctly! Best to design > it to work where it is supposed to work. IFF, the spec's completely existed and were published openly.Article: 107147
hypermodest wrote: > > 3rd: budget? I assume you are not working for NSA or similar YAT (Yet > > Another TLA) > > Between $1k and $2k. $2K of recycled Virtex parts makes a pretty nice machine :)Article: 107148
burn.sir@gmail.com wrote: > And while we are at it, AES128 is still safe. I bet the X-men will > disagree, but mostly for marketing reasons :) or pumping/pimping their stock price so their options look better, to cash out. outlandish claims FPGA's can not be over clocked, just use them till they fail, and back off are just short of lies. Doesn't take other effects into effect, like thermally induced early life failures when running at max die temp and way past design currents with AGRESSIVE cooling (AKA holding the case temp at -60C in a moisture free atmosphere). When the only spec for safe operating range is die temp ... I suspect that doesn't include running the parts on a dry ice heat sink, before vccint pin currents are a problem.Article: 107149
Austin Lesea wrote:
> There is no such thing as "over-clocking" a FPGA
Since Austin is technically and english language challenged, here is an
aid to decrypting this bull shit claim that Austin proudly would object
that it's only ammonium nitrate .... hehehehe
The Free On-line Dictionary of Computing (27 SEP 03) [foldoc]
overclocking
<hardware> Any adjustments made to computer hardware (or
software) to make its CPU run at a higher clock frequency
than intended by the original manufacturers. Typically this
involves replacing the crystal in the clock generation
circuitry with a higher frequency one or changing jumper
settings or software configuration.
If the clock frequency is increased too far, eventually some
component in the system will not be able to cope and the
system will stop working. This failure may be continuous (the
system never works at the higher frequency) or intermittant
(it fails more often but works some of the time) or, in the
worst case, irreversible (a component is damaged by
overheating). Overclocking may necessitate improved cooling
to maintain the same level of reliability.
(1999-09-12)
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