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
descoubes wrote: > Hi, > I'm looking for a video decoder board, that could be plugged on an Altera > dev. board proto header. (cyclone or stratix) > The decoder chip used could be any popular one (TVP5150, SAA7115...). > Could anybody answer me? > > Thanks > O.Descoubes > Was also looking for that so I decided to make my own encoder/decoder board with ADI chips (o; Never though about producing it though (o; rickArticle: 77876
Someone knows roughly the prices for EPCS1 and EPCS4 at 100 pieces? I know I can lookup at www.ebv.com but I see nothing mentioned about at which quantities those prices are... rickArticle: 77877
During the mentioned study, we were limited to a Virtex-II board and could thus not evaluate the Nios processor. However, we have ordered an Altera Cyclone board with the Nios-II design kit. A follow-up study will be made this spring, evaluating Nios-II and LEON2 on Altera hardware. It is not possible to evaluate Microblaze and Nios on the same hardware since only mapped netlists are provided with their design kits. Jiri.Article: 77878
On Wed, 19 Jan 2005 07:03:27 -0800, jiri_gaisler wrote: > During the mentioned study, we were limited to a Virtex-II board and > could thus not evaluate the Nios processor. However, we have ordered > an Altera Cyclone board with the Nios-II design kit. A follow-up > study will be made this spring, evaluating Nios-II and LEON2 on > Altera hardware. It is not possible to evaluate Microblaze and Nios > on the same hardware since only mapped netlists are provided with > their design kits. > > Jiri. I appreciate that you can't evaluate a Nios 2 on a Xilinx fpga, or a Microblaze on an Altera fpga (or either on other fpga's), so any sort of comparison matrix is going to have gaps in it. I also appreciate that testing different cpus on different fpgas takes time and costs money (unless you can borrow the boards). I just object to the idea of a thesis claiming to be a general comparison of synthesizable cpu cores but missing out what is probably the most commonly used core, and which claims to address portability yet limits this to a single fpga from a single vendor. At the very least, your thesis should make these limitations abundantly clear, and you could give limited information (such as performance and size estimates from the design software) for high and low-end chips. Still, the paper provides some useful information for people looking at these cores, and it's good of you to make it publicly available. mvh., DavidArticle: 77879
hi i have written 3 microblaze (MB) system in MHS and MSS MB0 = MB1 == MB1 and, thanks to this this usergroup and Xilinx :), the hardware compilation seems ok..... And now i am looking for excersize applications for this..... Probably it will be C (thread) based sample application codes... Would be great if someone who knows web link or materials, point this out to me... thankyouArticle: 77880
Jedi wrote: > descoubes wrote: > >> Hi, >> I'm looking for a video decoder board, that could be plugged on an Altera >> dev. board proto header. (cyclone or stratix) >> The decoder chip used could be any popular one (TVP5150, SAA7115...). >> Could anybody answer me? >> >> Thanks >> O.Descoubes >> > > Was also looking for that so I decided to make my own encoder/decoder > board with ADI chips (o; > > > Never though about producing it though (o; I'm currently in the process of developing FPGA-based video processing kit. Anybody care to share a wishlist? Features, interfaces, memory, particular parts, price target, etc. -- GeorgiArticle: 77881
Please tell Eric Crabill that his computer has a virus and is sending out e-mail spam to many people. thanks, -- glenArticle: 77882
Hi, I think it's more likely I'm being spoofed. Can you check the full header of the email and let me know if it's from xilinx.com? In the past, I have received spam from myself! In fact, there are probably people receiving spam from you, too, as we speak... :) However, if it did come from xilinx.com, I'll follow up on it. Hazards of life on the Internet, Eric Glen Herrmannsfeldt wrote: > > Please tell Eric Crabill that his computer has > a virus and is sending out e-mail spam to many > people.Article: 77883
jiri_gaisler wrote: > A master thesis comparing the LEON2, Microblaze and Openrisc-1200 > processors has been carried out by two students from the Chalmers > University in Sweden. The final report is now available online at: > > http://www.gaisler.com/doc/Evaluation_of_synthesizable_CPU_cores.pdf On page 5, they have an estimate of 15 million gates for a 32x32 multiplier (1 clock). Anybody knows how they came to this one ?Article: 77884
>
> I'm currently in the process of developing FPGA-based video processing
> kit. Anybody care to share a wishlist? Features, interfaces, memory,
> particular parts, price target, etc.
>
Input: At least one PAL/NTSC decoder.
At least one AD9888
At least one TMDS receiver
Output: PAL/NTSC encoder
THS8135
TMDS transmitter
RAM: 64 bits of fast DDR
Article: 77885Hi all, I'm designing a system in which a 4-bit + clock LVDS point-to-point bus has to connect two FPGAs. The two FPGAs are on two different boards--one is on a mainboard and the other is on a plug-in board. What kind of board-to-board connector is recommended for high-speed (~400 Mbps) LVDS signals? Connector parameters to look for? Signal integrity issues? Board layout with regard to the connectors? Rules of thumb? Thanks, -- GeorgiArticle: 77886
"Georgi Beloev" <gbH8SPAM@beloev.net> wrote in message news:7amdnXr20aQsPHPcRVn-pQ@megapath.net... > I'm currently in the process of developing FPGA-based video processing > kit. Anybody care to share a wishlist? Features, interfaces, memory, > particular parts, price target, etc. > > -- Georgi I'd love to see DVI in/out links (TMDS) for my own experiments.Article: 77887
take a look at samtec they have good ones! But be careful: They are pretty hard to solder, because of the fine pitch. QSH series regards, thomasArticle: 77888
Mouser has a small selection of cables and connectors for LVDS mostly, I think, to support the Camera Link systems. The wires are matched pairs. That may be a relatively inexpensive way to go. 3M has some cables but watch out, some are non-stock items. Give me a call if your PCB software doesn't support dual and match length traces. Brad Smallridge 415-661-8068 www.aivision.comArticle: 77889
hi all, exist a one jvm for the object architecture? thanks riscArticle: 77890
OK. I'm just braindead, my verilog is horribly rusty, insert tons o
excuses here, but...
I'm struggling with how the initial condition semantics are working in
XST's (6.1) verilog synthesizer for inferred registers (target V2pro):
All this is being tested by compiling and viewing with a logic analyzer.
live_pulse is an input which goes high for a single clock cycle. This
is a gross hack upstream, but I got that to work.
But given that, I'm having trouble defining initial conditions for
inferred registers. I don't want to wrap everything in a big reset
statement that is unnecessary, given that I'm not going to port this
to an ASIC so I'm perfectly happy with assuming "all registers shalt
start at 0"
The sample code:
reg live_lag, live_lag2, live_lag3, live_lag4;
// synthesis attribute INIT of live_lag3 is "R"
always @(posedge clk_0)
begin
live_lag <= live_pulse;
live_lag2 <= (live_pulse ? 1 : 0);
live_lag3 <= (live_pulse ? 1 : live_lag3);
live_lag4 <= (live_pulse ? 1 : live_lag4);
end
live_lag and live_lag2, as expected, are the live_pulse delayed a
single clock cycle, with the correctly inferred initial condition of
starting at 0.
live_lag3 and live_lag4 however, the synthesis tool reports as "value
never changes" and replaces with a logic 1, even when a synthesis
attribute is set for live_lag3 saying that its initial state should be
R (reset to 0).
Of course, in XDL synthesis, the Verilog "initial" construct is
ignored, so I can't use that.
So the stupid question du jour: How does one specify initial register
conditions for synthesized registers in XST?
Or do I just have to directly instantiate registers to get the right
property?
--
Nicholas C. Weaver. to reply email to "nweaver" at the domain
icsi.berkeley.edu
Article: 77891See http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0082_10.html (or the same thing at http://tinyurl.com/5mfwf ) for the information on Initial Value support in Verilog2001. "Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message news:csmo1v$2u4n$1@agate.berkeley.edu... > OK. I'm just braindead, my verilog is horribly rusty, insert tons o > excuses here, but... > > > I'm struggling with how the initial condition semantics are working in > XST's (6.1) verilog synthesizer for inferred registers (target V2pro): > > All this is being tested by compiling and viewing with a logic analyzer. > > live_pulse is an input which goes high for a single clock cycle. This > is a gross hack upstream, but I got that to work. > > But given that, I'm having trouble defining initial conditions for > inferred registers. I don't want to wrap everything in a big reset > statement that is unnecessary, given that I'm not going to port this > to an ASIC so I'm perfectly happy with assuming "all registers shalt > start at 0" > > The sample code: > > reg live_lag, live_lag2, live_lag3, live_lag4; > // synthesis attribute INIT of live_lag3 is "R" > always @(posedge clk_0) > begin > live_lag <= live_pulse; > live_lag2 <= (live_pulse ? 1 : 0); > live_lag3 <= (live_pulse ? 1 : live_lag3); > live_lag4 <= (live_pulse ? 1 : live_lag4); > end > > live_lag and live_lag2, as expected, are the live_pulse delayed a > single clock cycle, with the correctly inferred initial condition of > starting at 0. > > live_lag3 and live_lag4 however, the synthesis tool reports as "value > never changes" and replaces with a logic 1, even when a synthesis > attribute is set for live_lag3 saying that its initial state should be > R (reset to 0). > > Of course, in XDL synthesis, the Verilog "initial" construct is > ignored, so I can't use that. > > So the stupid question du jour: How does one specify initial register > conditions for synthesized registers in XST? > > Or do I just have to directly instantiate registers to get the right > property? > -- > Nicholas C. Weaver. to reply email to "nweaver" at the domain > icsi.berkeley.eduArticle: 77892
In article <WIBHd.9$ML4.142@news-west.eli.net>, John_H <johnhandwork@mail.com> wrote: >See >http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0082_10.html >(or the same thing at http://tinyurl.com/5mfwf ) for the information on >Initial Value support in Verilog2001. Ahh, all so simple! -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 77893
Just use an assignment when you define the reg. Initial blocks are ignored as for synthesis only. HTH, Mike module test_reg ( clk_0, live_pulse, live_lag, live_lag2, live_lag3, live_lag4 ); input live_pulse, clk_0; output reg live_lag, live_lag2, live_lag3 = 1'b0, live_lag4 = 1'b0; always @(posedge clk_0) begin live_lag <= live_pulse; live_lag2 <= (live_pulse ? 1 : 0); live_lag3 <= (live_pulse ? 1 : live_lag3); live_lag4 <= (live_pulse ? 1 : live_lag4); end endmodule Nicholas Weaver wrote: > OK. I'm just braindead, my verilog is horribly rusty, insert tons o > excuses here, but... > > > I'm struggling with how the initial condition semantics are working in > XST's (6.1) verilog synthesizer for inferred registers (target V2pro): > > All this is being tested by compiling and viewing with a logic analyzer. > > live_pulse is an input which goes high for a single clock cycle. This > is a gross hack upstream, but I got that to work. > > But given that, I'm having trouble defining initial conditions for > inferred registers. I don't want to wrap everything in a big reset > statement that is unnecessary, given that I'm not going to port this > to an ASIC so I'm perfectly happy with assuming "all registers shalt > start at 0" > > The sample code: > > reg live_lag, live_lag2, live_lag3, live_lag4; > // synthesis attribute INIT of live_lag3 is "R" > always @(posedge clk_0) > begin > live_lag <= live_pulse; > live_lag2 <= (live_pulse ? 1 : 0); > live_lag3 <= (live_pulse ? 1 : live_lag3); > live_lag4 <= (live_pulse ? 1 : live_lag4); > end > > live_lag and live_lag2, as expected, are the live_pulse delayed a > single clock cycle, with the correctly inferred initial condition of > starting at 0. > > live_lag3 and live_lag4 however, the synthesis tool reports as "value > never changes" and replaces with a logic 1, even when a synthesis > attribute is set for live_lag3 saying that its initial state should be > R (reset to 0). > > Of course, in XDL synthesis, the Verilog "initial" construct is > ignored, so I can't use that. > > So the stupid question du jour: How does one specify initial register > conditions for synthesized registers in XST? > > Or do I just have to directly instantiate registers to get the right > property? > -- > Nicholas C. Weaver. to reply email to "nweaver" at the domain > icsi.berkeley.eduArticle: 77894
Nicholas Weaver wrote: > OK. I'm just braindead, my verilog is horribly rusty, insert tons o > excuses here, but... > > > I'm struggling with how the initial condition semantics are working in > XST's (6.1) verilog synthesizer for inferred registers (target V2pro): > > All this is being tested by compiling and viewing with a logic analyzer. > > live_pulse is an input which goes high for a single clock cycle. This > is a gross hack upstream, but I got that to work. > > But given that, I'm having trouble defining initial conditions for > inferred registers. I don't want to wrap everything in a big reset > statement that is unnecessary, given that I'm not going to port this > to an ASIC so I'm perfectly happy with assuming "all registers shalt > start at 0" > > The sample code: > > reg live_lag, live_lag2, live_lag3, live_lag4; > // synthesis attribute INIT of live_lag3 is "R" > always @(posedge clk_0) > begin > live_lag <= live_pulse; > live_lag2 <= (live_pulse ? 1 : 0); > live_lag3 <= (live_pulse ? 1 : live_lag3); > live_lag4 <= (live_pulse ? 1 : live_lag4); > end > > live_lag and live_lag2, as expected, are the live_pulse delayed a > single clock cycle, with the correctly inferred initial condition of > starting at 0. > > live_lag3 and live_lag4 however, the synthesis tool reports as "value > never changes" and replaces with a logic 1, even when a synthesis > attribute is set for live_lag3 saying that its initial state should be > R (reset to 0). > >From the Constraints Guide: "It is illegal to attach INIT to a net or signal in FPGAs." You could instantiate an FD for live_lag3 and live_lag4 and apply the INIT constraint to each flop, or instantiate FDC for each signal even though the clear input of the FDC is set to 1'b0 it will come up low. I generally add a clear input to my lower level modules and a reset term in my clocked processes like: module foo (live_pulse, clear, clk, live_lag); input live_pulse, clear, clk; output live_lag; always @ (posedge clk or posedge clear) if (clear) live_lag <= 0; else live_lag <= live_pulse ? 1 : live_lag; endmodule Then at the upper level I tie the module's clear input to 1'b0, which is like what happens with the FDC. The clear doesn't create hardware, it just forces the proper initial state after loading. For 1 or 2 signals at the top level, instantiating the FDC is usually easier. By the way does the synthesis also rip out your signals if you code them like this? if (live_pulse) live_lag3 <= 1; > Of course, in XDL synthesis, the Verilog "initial" construct is > ignored, so I can't use that. > > So the stupid question du jour: How does one specify initial register > conditions for synthesized registers in XST? > > Or do I just have to directly instantiate registers to get the right > property? > -- > Nicholas C. Weaver. to reply email to "nweaver" at the domain > icsi.berkeley.eduArticle: 77895
Hi people, I'm trying to develop a partial reconfigurable system based on a Virtex-II 2000 FPGA. I've read the Xilinx 290 Application Note, and some others description. Now I've a doubt about bus macro, and I apologize if the answer to my question could result obvious, but I'm newbie in this branch, so forgive me :) The bus macro file provided with App290 seems to be designed for a 250 device. Can I find macros for my virtex? I didn't find anything on Xilinx website. So, I think I have to describe a macro for my FPGA. In Xilinx bus macro file I find: inst "t1A_(3)" "TBUF" , placed R24C7 TBUF_X12Y0 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t1E_(3)" "TBUF" , placed R24C9 TBUF_X16Y0 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t2B_(2)" "TBUF" , placed R24C7 TBUF_X12Y1 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t2F_(2)" "TBUF" , placed R24C9 TBUF_X16Y1 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t3C_(1)" "TBUF" , placed R24C8 TBUF_X14Y0 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t3G_(1)" "TBUF" , placed R24C10 TBUF_X18Y0 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t4D_(0)" "TBUF" , placed R24C8 TBUF_X14Y1 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" ; inst "t4H_(0)" "TBUF" , placed R24C10 TBUF_X18Y1 , cfg "TINV::T IINV::I _SUPERBEL::TRUE" In top.ucf, instead: INST bm16_1/bus1 LOC = TBUF_X6Y45; INST bm16_1/bus2 LOC = TBUF_X6Y43; This means that bm16_1/bus is located at TBUF with X=6 and Y=45. So what's the meaning, instead, of " inst "t1A_(3)" "TBUF" , placed R24C7 TBUF_X12Y0"? In particular, how I've to refer R C X e Y values? As I've understood, the bus macro provides a description of the bus, and .ucf constraint file place the bus in the correct position on FPGA grid in order to match the modules. Is it correct? So, in the macro, how I describes the values? Thank you very very much. SalvatoreArticle: 77896
"jiri_gaisler" <jiri@gaisler.com> skrev i meddelandet news:1106130542.868417.48750@c13g2000cwb.googlegroups.com... > A master thesis comparing the LEON2, Microblaze and Openrisc-1200 > processors has been carried out by two students from the Chalmers > University in Sweden. The final report is now available online at: > > http://www.gaisler.com/doc/Evaluation_of_synthesizable_CPU_cores.pdf > . > > Jiri Gaisler > > Gaisler Research > The big question is if it makes sense to use 2-8000 CLBs for a CPU in the first place? Reasonably, such a chip will need to have an external flash memory and the pins between the FPGA and the Flash. Think it will be hard to pricewise meet a hardwired solution with internal/external CPU. Think it would be nice to compare with a solution based on the AT91FR40162 (10 x 10 mm) running 60 MIPS at 20 mW with a smaller FPGA. The FPSLIC and some PowerPC equipped Virtex are another approach which should be more cost effective for most applications One advantage of implementing in FPGA, is it allows you to migrate if chips become obsolete. Then again, going with a Microblaze will force you into Xilinx FPGAs, and if you choose the Leon/OpenRISC, the core is more expensive. Building your own chip, is of course more fun! -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 77897
Georgi Beloev wrote: > Hi all, > > I'm designing a system in which a 4-bit + clock LVDS point-to-point bus > has to connect two FPGAs. The two FPGAs are on two different boards--one > is on a mainboard and the other is on a plug-in board. > > What kind of board-to-board connector is recommended for high-speed > (~400 Mbps) LVDS signals? Connector parameters to look for? Signal > integrity issues? Board layout with regard to the connectors? Rules of > thumb? Howdy Georgi, I hate to say that it doesn't matter, but in the grand scheme of things, the type or style of the connector is not of huge importance at that speed, as long as one pin isn't massively longer than another (which occurs with some types of right angle connectors). We run many times that speed using the worst connector you can imagine. Much more important is the stuff that Brad mentioned: keep _p/_n pair trace length the same and routed as a diff pair into and out of the connector - and routed against a ground plane if possible. Give yourself a ground pin next to each pair within the connector. Have fun, MarcArticle: 77898
I am trying to get a simple LogicLock region (about 200 LEs) optimized, back annotated and tested. But I am having problems. I am hoping someone can help me out. I am using VHDL files and an entity called mesher in a file named mesher.vhd. I am targeting a Stratix FPGA. This is what I have done so far: 1) Made a project with mesher as the top level. I set all the ports to virtual pins in the assignment editor, and defined the clock 2) Compiled. 3) Defined the LogicLock Region and dragged the entity mesher into it. Also placed all the virtual IOs into the LogicLock Region. 4) Compiled. 5) Adjusted synthesizer and fitter parameters until I was happy with the fit. 6) Back annotated placement and routing and wrote the .VQM file. Everything seemed okay, except a few LEs are placed outside the LogicLock region for some of the fitter generated nodes. I don't know why, because there was enough unused LEs inside the LogicLock Region. The nodes place outside were not part of any critical path. How does one get the fitter to place these nodes inside the LogicLock Region? 7) To check if everything would work, I removed my source files from the project files list and entered the .VQM file. 8) I turned off all fitter optimizations. 9) Tried to compile and I got fitting errors. I would expect this compile to place all node where they were when I back annotated. I would expect the timing to be exactly the same too. Does anyone know what becomes of the LEs used for the virtual IOs when the LogicLock Region is imported into another project. Do they need to be removed or do they get removed by the compiler? Thanks in Advance, DougArticle: 77899
On Wed, 2005-01-19 at 17:29 -0800, Marc Randolph wrote: > I hate to say that it doesn't matter, but in the grand scheme of > things, the type or style of the connector is not of huge importance at > that speed, as long as one pin isn't massively longer than another > (which occurs with some types of right angle connectors). We run many > times that speed using the worst connector you can imagine. > > Much more important is the stuff that Brad mentioned: keep _p/_n pair > trace length the same and routed as a diff pair into and out of the > connector - and routed against a ground plane if possible. Give > yourself a ground pin next to each pair within the connector. Not true. Its not the frequency that matters but the edge rate. Given the 4 bits and clock it sounds an awful lot like the TigerSHARC link port and it has a very fast edge rate. The data sheet indicates a MAX of 200ps (that's pico-seconds). Anyways, at that edge rate any change in impedance in the trace will cause reflections. If the path of the differential pair through the connector has a different impedance than the rest of the trace you will get a reflection. In fact you'll get two--one at each side of the connector. That is the difference in high-speed connectors--they pay attention to this. Now it is true that the trace length through the connector needs to be matched as well. Otherwise you'll get the + and - signals getting out of phase. You'll always have slight mismatches in impedance and trace length. But with a 200ps edge rate you have a lot less margin for error than at more reasonable rates. Hope that helps.
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