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
"Pablo" <pbantunez@gmail.com> wrote in message
news:1181142136.464822.93270@g4g2000hsf.googlegroups.com...
>> Or my personal favourite, DCM reset polarity is inverted because you
>> forgot
>> to change the parameter setting from the default :)
>>
>> <how many times have I done that...>
>>
> I use the wizard to create a model for custom board. In which I
> configure clock (100->125), add leds and ddr. I don't change anymore.
> Where is this parameter?. How is it configured?
In the System Assembly view, if you right-click on the DCM instance and
select "configure IP", you'll find a parameter at the bottom called "Reset
Polarity" (0 is active low, 1 is active high).
But if you didn't add any DCMs manually yourself, then this is probably not
your problem.
Cheers,
-Ben-
Article: 120451> I'm starting to think that trying to make lwIP work in raw mode > instead (despite the lack of driver support for the temac!) might be > easier than dealing with all the xilkernel related issues. Or maybe I > could go back to EDK v7.1 (!), Avnet has a reference design with lwIP > v1.0 working in raw mode for that version... But what if I get a bug > in the design, I'll probably be told by Xilinx to upgrade to v9.1. > > Virtex-4 was released what, 2 years ago now? Come on software folks at > Xilinx, it's about time to get a working tcp/ip solution (free) to use > the hard temac without having to bother with xilkernel!! Is that too > much to ask? > This will be available in 9.2. A clean high performance lwip solution for both raw and socket modes for the TEMAC. The socket mode will still rely on xilkernel, but the issues will be fixed. We will also move to lwip v1.2.0. -SivaArticle: 120452
The Lattice SC purespeed I/O supports 2 Gbps data rate. This is the maximum available data rate in parallel I/O - in comparison to Altera and Xilinx. I would like to know how well designed Lattice SC Pure-speed I/O is for source synchronous application. I do not see a lot of disccussion surrounding this but if it is truely that fast then that is great. It will be great if you all can expand upon your concerns surrounding this. - MaverickArticle: 120453
Thanks Jim. I will read about the Adept software. I am trying to use about 100 oserdes in a source sunchronous application. The oserdes output is brought external to the V5 FPGA. But at this point I am trying to understand the factors that can introduce skew on the source synchronous output at the output pins of the FPGA. Three factors come to mind are (1) Clock skew - This can be mitigated by using bufio instead of bufg (2) Internal Trace routing mismatches from oserdes to the the pad - Don't know how to mitigate this one consistantly. (3) Internal routing mismatch from internal flip-chip pad to the fpga pin (?) - This can possibly mitigated by adjusting the board trace lengths. Basically I am trying to minimize the skew. Any guidance along those lines will be great. Thanks.Article: 120454
"Mavrick" <dmoyes@comcast.net> wrote in message news:eea7500.-1@webx.sUN8CHnE... > The Lattice SC purespeed I/O supports 2 Gbps data rate. This is the > maximum available data rate in parallel I/O - in comparison to Altera and > Xilinx. > > I would like to know how well designed Lattice SC Pure-speed I/O is for > source synchronous application. I do not see a lot of disccussion > surrounding this but if it is truely that fast then that is great. > > It will be great if you all can expand upon your concerns surrounding > this. > > - Maverick From Lattice's website, http://www.latticesemi.com/documents/PureSpeed-SC.pdf "Another key factor in buffer performance is pin capacitance. With clock periods in the nanosecond range, rise and fall times are, to say the least, critical. If pin capacitance is too high, a major portion of the clock period will be lost due to the slow rise time, severely limiting overall buffer performance. To combat this, the LatticeSC I/O pads have reduced capacitance (see Table 1), allowing Lattice to achieve best-in-class performance of 2Gbps." However, I think you'll find the pins don't have enough capacitance to control crosstalk. That's right, isn't it Austin? ;-) http://groups.google.com/group/comp.arch.fpga/msg/50ed6cc578204837?hl=en& HTH, Syms.Article: 120455
On 7 jun, 14:31, Patrick Dubois <prdub...@gmail.com> wrote: > On Jun 7, 8:10 am, Pablo <pbantu...@gmail.com> wrote: > > > On 7 jun, 12:45, Pablo <pbantu...@gmail.com> wrote: > > > > Hi, I have seen about configuring the JTAG as UART since I have not > > > RS232 port in my board. I have found that Xilinx provides OPB_MDM as > > > uart with C_USE_UART PARAMETER, but in my desing I use PowerPC. In > > > powerPC the debug is done by jtag_cntlr and not by opb_mdm so console > > > says that "opb_mdm_0 is not accessible from processor ppc405_0". > > > > Has anyone configured JTAG as UART in PowerPC? > > > > Regards > > > Solved. > > Would you mind sharing the solution? I'd like to know how to use JTAG > as UART in my design as well. It is very simple. If you use Microblaze, an opb_mdm block is added for the debug. Then, you have to go to Software Options and configure the STDOUT to opb_mdm_0 (that is the instance). Finally exec XMD (in bootloop mode) and write the following sentences: connect mdm -uart read_uart Now you could dow any executable.elf and run it. The output is written in the xmd console. And if you have powerpc, add a opb_mdm ip core and select C_USE_UART to 1. The following process is the same as the before one. Regards, PabloArticle: 120456
On Jun 7, 2:45 pm, Jon Beniston <j...@beniston.com> wrote: > On 7 Jun, 11:14, "nasif4...@gmail.com" <nasif4...@gmail.com> wrote: > > > how can i > > call another module in always block? > > You can't. Try: > > module test(clock,reset,count); > input clock, reset; > output [3:0] count; > wire [3:0] count; > > counter counter_inst(clock, reset, count); > > endmodule hey guys: you can't Instance any module in the procedural blocks like "always". for this work you should use Generators , but in your case as Jon Beniston wrote you don't need to use always @ clock. ARHArticle: 120457
On 6 Jun., 08:14, Totally_Lost <air_b...@yahoo.com> wrote: > On Jun 4, 6:45 pm, Ray Andraka <r...@andraka.com> wrote: > Hi Ray ... Just for reference, what would you consider an optimal > number of LUTs/Slices using this approach for an 8x8=>16 and 16x16=>32 > multiplier? Thanks Tricks like FFT based multiplications or Toom-Cook often are not beneficial in the range up to 64 bits because any improvement in LUTs (bothh area and depth) are killed by the area and delay required by the irregular routing. Therefor almost any hardware multiplier around is based on addition trees that are sum up partial products. (booth, wallace-tree, array, sequential, etc.) All of these architectures require N*N/K 1-bit adders when multiplying N bit numbers in K clock cycles. It turns out that all these architectures can be created from each other by just swapping wires around. This means, that if you are the type that uses RLOCs you can optimze the routing after placement has been fixed to equalize the critical path. (See our paper on that topic: http://eis.eit.uni-kl.de/eis/research/publications/papers/iccd04.pdf ) A script that implements this with a greedy algorithm is not extremely difficult to write. Kolja SulimmaArticle: 120458
Symon, Lattice has banks dedicated to just this purpose. They have limited IO standards, because the capacitance MUST be low at Gb/s data rates. In that sense, they no longer have "all IOs equally the same." This is a business decision: these pins can really only be used now for a much narrower range of applications, and pcb layout is constrained to always using these pins. In differentiates them from us, and that is what they need to survive (as if they go head to head, they are lost in the 'noise). In order to stay in business, Lattice has to carefully evaluate their features, and see if they can squeeze a few percent of market share. That is just fine by us. We continue to gain market share, so it must be extremely painful for our competition. Altera has no high speed 65nm process, and are more than one year late for S3, and Lattice has a great fab partner, and some very clever and useful features, but is so small, they can't compete on IP, services, software, and all the other things that make up an ecosystem surrounding a product. They have resorted to blogging for support (which is interesting, but makes me think they have no resources to do any serious support). If a dedicated bank, or even dedicated hard IP (which they also offer for some interfaces) looks like a great idea, then perhaps some future offering from Xilinx might have something similar. Until then... AustinArticle: 120459
Symon, I have one ppt slide, but I can't post it here. If you email me directly, I will mail the slide to you. AustinArticle: 120460
On Jun 7, 11:21 am, Pablo <pbantu...@gmail.com> wrote: > It is very simple. If you use Microblaze, an opb_mdm block is added > for the debug. Then, you have to go to Software Options and configure > the STDOUT to opb_mdm_0 (that is the instance). Finally exec XMD (in > bootloop mode) and write the following sentences: > > connect mdm -uart > read_uart > > Now you could dow any executable.elf and run it. The output is written > in the xmd console. > > And if you have powerpc, add a opb_mdm ip core and select C_USE_UART > to 1. The following process is the same as the before one. > > Regards, Pablo Thanks! Indeed quite simple.Article: 120461
On 7 Jun 2007 11:02:48 GMT, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote: >No. Hans said something about the SystemC(R) library and concurrency; >after that, ARH agreed with Hans about SystemC(R) abilities; and after >that C.P.G. pointed out that concurrency is not part of the SystemC(R) >standard. It is very clearly written in Section 4.2.1 The scheduling >algorithm: >"[..] > >4.2.1.2 Evaluation phase > >[..] > >Since process instances execute without interruption, only a single >process instance can be running at any >one time, and no other process instance can execute until the >currently executing process instance has >yielded control to the kernel. A process shall not pre-empt or >interrupt the execution of another process. This >is known as co-routine semantics or co-operative multitasking. I'm not quite sure what you're saying here, but SystemC would be useless if it didn't support a user-level notion of concurrency. It works like VHDL and Verilog - it has delta cycles, and 2-phase evaluate/update semantics. This allows the simulation of simultaneous accesses to multiple channels. Or are you saying that you can't implement SystemC on concurrent hardware/multi-threaded processors/whatever? This isn't the case. The original (free) OSCI simulator used QuickThreads, which probably explains the coroutine text in the LRM. But, if you look at 4.2.1 in more detail, you'll see that you can implement your scheduler in any way you want, as long as you preserve the simulation semantics. See note 3 in 4.2.1.2: "3 — An implementation running on a machine that provides hardware support for concurrent processes may permit two or more processes to run concurrently provided that the behavior appears identical to the co-routine semantics defined in this clause". Besides, there's nothing wrong with non-preemptive coroutine semantics. Why would you want to pre-empt an executing thread? Threads have to execute until they reach suspend points, or delta cycles wouldn't work. VHDL and Verilog work the same way - most of us have managed to hang up a simulator with an infinite loop in a process. > "I am no expert (not even a novice) so perhaps one of the Doulos guys > can shed some light on this? I guess they're working this week... BTW, what is SystemC(R)? 'SystemC' is an OSCI trademark, in the same way that 'Verilog' is a Cadence trademark. EvanArticle: 120462
On Jun 6, 7:41 pm, Peter Ryser <peter.ry...@xilinx.com> wrote: > Avail ram is definitely wrong. Try to add > mem=0x4000000 > to the kernel boot command line and see if that gets you any further. > > - Peter > > gseegmil...@gmail.com wrote: > > Anyone, > > > When I try to boot linux on a Xlinx ML403 board I get the following > > out put: > > > loaded at: 00400000 004FA1A0 > > board data at: 00000000 0000007C > > relocated to: 0040405C 004040D8 > > zimage at: 00404FE5 004F7A9B > > avail ram: 004FB000 7C9E2378 > > > Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/xsysace2 rw > > Uncompressing Linux...done. > > Now booting the kernel > > > Does the 'board data at' arguments look ok. Any help would be > > appriated!!! Thanks for responing!!! I have set memory to 0x04000000. The 'avail ram' is calculated using the end of used memory '004FB000' plus the size of the 'board data'. The 'board data' size is very large, something like 7C??????. Thanks again!!!Article: 120463
On Jun 6, 8:24 am, EdA <ed.art...@gmail.com> wrote: > On Jun 5, 12:10 pm, Amal <akhailt...@gmail.com> wrote: > > > Anyone has a good pointer to a portable (Windows, *nix) TCP/IP socket > > library that can be used with VHDL FLI, Verilog PLI/VPI, SystemC, or > > SystemVerilog DPI? > > Amal, > > Try this link:http://www.sutherland-hdl.com/pli_book_examples.html > > "David Roberts, of Cadence Design Systems, has provided a great > example using sockets to communicate between a PLI application and an > independently running C program. David has provided this example with > no restrictions on usage, under the GNU freeware license agreement." > > Allegedly it works on Linux and Windows. > > Enjoy, > /Ed Ed, I tried this library, but I am having problem with sending and receiving data. I am not sure if Modelsim is doing something wrong, but when I setup a server on the SystemVerilog side using DPI and send data through a TCL client, the server keeps on one line of data and keeps spitting out only the first line of data. I wonder if anyone else has used this example? -- AmalArticle: 120464
> p.s. I guess it would be fairly straightforward for Mike (the OP) to > change some values in his bypass network and see how it affects jitter. > That'd be interesting. Yes, that is the plan. Xilinx are looking at my layout, and I will incorporate their feedback and some other tweaks into a respin. I will get these boards manufactured with a few different mixes of caps around the Xilinx and spend some happy days in the lab. This won't happen for a couple of weeks of course. The design has approx 72 outputs wiggling at 400MBits and 76 outputs at 200MBits so it is doing pretty well. By overriding the auto-IDELAY calibration and doing a slow manual scan through the taps while this memory self test is running I can get a feeling for my margin, and I get zero errors over about a 0.5UI range which is pretty good. I would like to get my ~500pS jitter loss back of course (if I run the self test in super slow motion, the eye is a few taps wider so the increased jitter is hurting me slightly) Regards, Mike.Article: 120465
"Pablo" <pbantunez@gmail.com> wrote in message news:1181132895.858643.108730@g4g2000hsf.googlegroups.com... > First of all, thanks for your advices. I am agree with Patrick. For me > I choose the Symon's method, but at finally I will make the Zara > scripts because this computer has to be programmed by most of people. > in the case why not have a script that does the renaming ??Article: 120466
Hoping that the dynamic constant multiplier could save numbers of CLBs, but it's contrary. So, what's the use of it if it takes more resource than the true parallel multiplier? Here's the settings for both: Architect = virtex-e Inputs A=10bits, B=8bits, both unsigned and registered RPM rectangular shape Max. pipe line Output width = 10 bits Register output no CE/reset Latency = 4 For the dyn coef, don't care (stop) output during load, matter of fact the coefs just loaded once a while Here's the footprint results for the dyn coef multiplier 110 LUT + 131 registers It speads over 9 CLBs wide, 7 CLBs tall Uses 53 CLBs Here's the footprint results for true parallel 87LUT + 116 registers It speads over 5 CLBs wide, 10 CLBs tall Uses 37 CLBsArticle: 120467
The Xilinx Multiplier v9.0 from the architecture wizard has a constant-coefficient multipler. What are you using to generate the dynamic constant multipler? "Marlboro" <ccon67@netscape.net> wrote in message news:1181242535.641331.322380@m36g2000hse.googlegroups.com... > Hoping that the dynamic constant multiplier could save numbers of > CLBs, but it's contrary. So, what's the use of it if it takes more > resource than the true parallel multiplier? > > Here's the settings for both: > > Architect = virtex-e > Inputs A=10bits, B=8bits, both unsigned and registered > RPM rectangular shape > Max. pipe line > Output width = 10 bits > Register output no CE/reset > Latency = 4 > For the dyn coef, don't care (stop) output during load, matter of > fact the coefs just loaded once a while > > Here's the footprint results for the dyn coef multiplier > 110 LUT + 131 registers > It speads over 9 CLBs wide, 7 CLBs tall > Uses 53 CLBs > > Here's the footprint results for true parallel > 87LUT + 116 registers > It speads over 5 CLBs wide, 10 CLBs tall > Uses 37 CLBsArticle: 120468
Hi All,
I'm synthesizing the IP core for my chip using the Altera Quartus tools.
When I define constraints in the SDC file for the Timing Quest analyser &
fitter, I use the derive_pll_clocks command to automatically generate
clocks provided by the PLLs.
However this command generates the clock with names like this:
out_clk_pll:out_clk_pll_1|altpll:altpll_component|_clk0
(when used with -use_tan_name option) or:
out_clk_pll_1|altpll_component|pll|clk[0]
when used without this option.
However, when my PLL is instantiated this way:
out_clk_pll_1 : out_clk_pll
port map (
areset => aclr,
inclk0 => CLK40_1,
c0 => out_clk80,
c1 => out_clk80_latch,
c2 => out_clk80_data,
locked => open);
I'd like to be able to generate clocks with the names like out_clk80,
out_clk80_latch and so on... (i.e. with names of connected signals).
Is there any way to achieve this behaviour?
--
TIA & Regards,
Wojtek
Article: 120469Austin, And that's why the big X can't still offer a high end V5 with MGT's on a low cost small footprint (like 256fpBGA), isn't it? Some customers are not so happy anymore with the model that the big ones dictate the law. This is probably the biggest reason why there will always be a place for companies like Lattice and Actel. "...but is so small, they can't compete on IP, services, software, and all the other ..." is this your personal opinion, or is this the way that Xilinx masks that you are not capable of achieving the same performance out of a high speed process...? And what I see (and hear) is that Lattice FAE's deliver at least the same or sometimes even better support than Xilinx's (for normal companies, not the Alcatel's and Cisco's of this world of course). I can't comment on Altera because I never used it before. Regards, Luc On Thu, 07 Jun 2007 09:42:16 -0700, austin <austin@xilinx.com> wrote: >Symon, > >Lattice has banks dedicated to just this purpose. They have limited IO >standards, because the capacitance MUST be low at Gb/s data rates. > >In that sense, they no longer have "all IOs equally the same." > >This is a business decision: these pins can really only be used now for >a much narrower range of applications, and pcb layout is constrained to >always using these pins. In differentiates them from us, and that is >what they need to survive (as if they go head to head, they are lost in >the 'noise). > >In order to stay in business, Lattice has to carefully evaluate their >features, and see if they can squeeze a few percent of market share. >That is just fine by us. We continue to gain market share, so it must >be extremely painful for our competition. Altera has no high speed 65nm >process, and are more than one year late for S3, and Lattice has a great >fab partner, and some very clever and useful features, but is so small, >they can't compete on IP, services, software, and all the other things >that make up an ecosystem surrounding a product. They have resorted to >blogging for support (which is interesting, but makes me think they have >no resources to do any serious support). > >If a dedicated bank, or even dedicated hard IP (which they also offer >for some interfaces) looks like a great idea, then perhaps some future >offering from Xilinx might have something similar. Until then... > >AustinArticle: 120470
I use CoreGen V7.0 comes with ISE 6.3. I've notice that the older version worked as it supposes to be, the dyn coef multipler is smaller & faster On Jun 7, 2:50 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > The Xilinx Multiplier v9.0 from the architecture wizard has a > constant-coefficient multipler. > What are you using to generate the dynamic constant multipler? > > "Marlboro" <cco...@netscape.net> wrote in message > > news:1181242535.641331.322380@m36g2000hse.googlegroups.com... > > > > > Hoping that the dynamic constant multiplier could save numbers of > > CLBs, but it's contrary. So, what's the use of it if it takes more > > resource than the true parallel multiplier? > > > Here's the settings for both: > > > Architect = virtex-e > > Inputs A=10bits, B=8bits, both unsigned and registered > > RPM rectangular shape > > Max. pipe line > > Output width = 10 bits > > Register output no CE/reset > > Latency = 4 > > For the dyn coef, don't care (stop) output during load, matter of > > fact the coefs just loaded once a while > > > Here's the footprint results for the dyn coef multiplier > > 110 LUT + 131 registers > > It speads over 9 CLBs wide, 7 CLBs tall > > Uses 53 CLBs > > > Here's the footprint results for true parallel > > 87LUT + 116 registers > > It speads over 5 CLBs wide, 10 CLBs tall > > Uses 37 CLBs- Hide quoted text - > > - Show quoted text -Article: 120471
"John_H" <newsgroup@johnhandwork.com> wrote in message news:136god3hjd0oa7f@corp.supernews.com... > The Xilinx Multiplier v9.0 from the architecture wizard has a > constant-coefficient multipler. > What are you using to generate the dynamic constant multipler? I missed that the subject line specified CoreGen 7.0. I don't know that there's an equivalent multiplier in CoreGen 9.1.01i. The same "Multiplier v9.0" came up in CoreGen that was in the Architecture Wizard. There was also no "Virtex-E" family listed in the default menu of this newer tool version.Article: 120472
<lb.edc@telenet.be> wrote in message news:mjog63ljl67eee204pt3e0o2mcvmsqmra1@4ax.com... > Austin, > > And that's why the big X can't still offer a high end V5 with MGT's on > a low cost small footprint (like 256fpBGA), isn't it? > Some customers are not so happy anymore with the model that the big > ones dictate the law. This is probably the biggest reason why there > will always be a place for companies like Lattice and Actel. > > "...but is so small, they can't compete on IP, services, software, and > all the other ..." is this your personal opinion, or is this the way > that Xilinx masks that you are not capable of achieving the same > performance out of a high speed process...? > > And what I see (and hear) is that Lattice FAE's deliver at least the > same or sometimes even better support than Xilinx's (for normal > companies, not the Alcatel's and Cisco's of this world of course). I > can't comment on Altera because I never used it before. > > Regards, > > Luc Luc, Do you simply have a Xilinx thorn in your side that's making you a little grumpy? The MGTs *are* dedicated I/O standards without the "baggage" of supplying every standard known to Marketing. There are devices that have very high speed I/O in wireframe parts. There are devices that have high speed transceivers on tiny BGAs. But how many designers - what percentage of the market - need a cutting-edge family with enormous bandwidth to be in a tiny package that rivals the size of the die? I was in telecom years ago where the ideal chip might have 8 I/O for the system and a little more for control. They're just not made because the number of people that could use them are so small. Since most designers can simply not use some of the many I/O available on the hyper-performance devices, how many people are truly affected by the absence of the "convenient" 256 bin BGA? I'm also left wondering: what's the smallest flip-chip package Xilinx produces for any family? - John_HArticle: 120473
Mike, Wow. 0.5UI is a lot of margin. It really is. And, yes, I think we can recover some more "eye" for you, and increase your margin further. I suppose since no one has emailed me for the "bad" anti-resonant powerpoint slide, we don't have any "unbelievers" here. Fact is, doing a sweep of IO switching over frequency will show if there are any "really bad" places in your power distribution network (vs frequency). Doing a network analysis (using a variable frequency RLC meter, or a VNA -- although a VNA is not very good at milli-ohm impedances), will confirm that at some frequencies, the bypassing is all but non-existent. AustinArticle: 120474
I'm gonna use the luxury multipliers then, althought port B will be updated once per day :))) I have newer ISEs handy but have not installed them yet. Is that true ISE 9.1 doesn't support Virtex-e or just the Wizard? On Jun 7, 3:35 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > "John_H" <newsgr...@johnhandwork.com> wrote in message > > news:136god3hjd0oa7f@corp.supernews.com... > > > The Xilinx Multiplier v9.0 from the architecture wizard has a > > constant-coefficient multipler. > > What are you using to generate the dynamic constant multipler? > > I missed that the subject line specified CoreGen 7.0. > I don't know that there's an equivalent multiplier in CoreGen 9.1.01i. > The same "Multiplier v9.0" came up in CoreGen that was in the Architecture > Wizard. > There was also no "Virtex-E" family listed in the default menu of this newer > tool version.
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