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
In my NVIDIA GPU, I had to disable the transparency feature 'cause it caused EDK8x to freeze on the BSB wizard. You can imagine the amount of headache this caused me until I managed to hack my way out utilizing speculative guess!Article: 119001
Hi,
I am working on an DSP, have problem by data receiving. As listed
below, xilinx ise tools build a "DELAYCHAIN" into the circuit, as a
result, the data needs 7.956ns from PADS to FlipFlops.
My questions are:
1. How can i control the tools, to build or not to build the
"DELAYCHAIN".
2. When the data need 7.956ns, to get to the FFs, will it works, when
the datarate 150MHz (6.6ns) is?
Timing report from XILINX ISE 9.1i
======================================================
Delay type Delay(ns) Logical Resource
Tiopi 0.943 i_data<2>
i_data_2_IBUF
net (fanout=1) 0.063 i_data_2_IBUF
Tidockd 6.950 instance1/data_int<2>.DELAYCHAIN
instance1/data_int_2
Total 7.956ns (7.893ns logic, 0.063ns route) (99.2% logic, 0.8%
route)
=======================================================
Thanks
Cheng
Article: 119002On Tue, 8 May 2007 08:37:46 -0700, "John_H" <newsgroup@johnhandwork.com> wrote: >"Brian Drummond" <brian_drummond@btconnect.com> wrote in message >news:dot043d1oc23r5mjr4uco4j24h5n7nnqn5@4ax.com... >> order, asking only a mere $75 for shipping, on what, a 1kg product? >> We'll see how long it takes... >> >> Hey Xilinx, I'd suggest there's a little room for improvement here. >> >> - Brian > >If you sign up for X-Fest in Manchester, you might be offered a seminar >discount for development boards such as the Spartan-3A. Heck, the X-Fest I >attended even gave one away. There are a couple X-Fests in the UK, >Manchester is just the first of the two at the end of May. I wonder if you actually have to attend the X-Fest, or would signing up qualify? Manchester would be about a 22 hour round trip, or about 10 hours if I fly. An expensive way to save $26 + import duty + shipping! - BrianArticle: 119003
On Tue, 8 May 2007 15:12:39 -0600, <steve.lass@xilinx.com> wrote: >I have forwarded your comments to our configuration solutiuons >group. They are working on ideas to solve the issues you listed >below. [...] >There are a few programs that we could open-source, but they >only have a few engineers working on them, so it would not save >resources since we have to manage the open-source projects. > >The bigger applications like ProjNav and XPS are much more >device/Xilinx specific than most of you are implying so I don't >see an easy solution there either. Another possible [candidate for open-source | starved orphan within the Xilinx toolchain] is the floorplanner. (a) Unless it has GREATLY improved in 9.1, it has major shortcomings that have not been fixed in several major toolchain releases. (b) if it properly supported hierarchical RPMs it could be a very useful tool for high performance design, and/or allow an entry point for Open Source to add value to component placement. (c) [conjecture] its interfaces and device specific "knowledge" are less detailed than ISE or the back end, therefore easier to release to Open Source than the full tool set. - BrianArticle: 119004
On 9 Mai, 13:24, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Tue, 8 May 2007 08:37:46 -0700, "John_H" <newsgr...@johnhandwork.com> > wrote: > > >"Brian Drummond" <brian_drumm...@btconnect.com> wrote in message > >news:dot043d1oc23r5mjr4uco4j24h5n7nnqn5@4ax.com... > >> order, asking only a mere $75 for shipping, on what, a 1kg product? > >> We'll see how long it takes... > > >> Hey Xilinx, I'd suggest there's a little room for improvement here. > > >> - Brian > > >If you sign up for X-Fest in Manchester, you might be offered a seminar > >discount for development boards such as the Spartan-3A. Heck, the X-Fest I > >attended even gave one away. There are a couple X-Fests in the UK, > >Manchester is just the first of the two at the end of May. > > I wonder if you actually have to attend the X-Fest, or would signing up > qualify? Manchester would be about a 22 hour round trip, or about 10 > hours if I fly. > > An expensive way to save $26 + import duty + shipping! > > - Brian you only save 26, duty and shipping you have to pay anyway. but thats not the only special, so its possible to save more (if you spend more) AnttiArticle: 119005
steve.lass@xilinx.com wrote: > There are a few programs that we could open-source, but they > only have a few engineers working on them, so it would not save > resources since we have to manage the open-source projects. > > The bigger applications like ProjNav and XPS are much more > device/Xilinx specific than most of you are implying so I don't > see an easy solution there either. XST is very device specific and > this is one of the applications that starts their work over a year > ahead of a new device introduction. Why can't Xilinx make available the complete specification of the configuration bitstream for a single, already obsolete device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip together with the guarantee to deliver this chips for at least 20 years. Then the open source community had a basis to develop their own design tools at least for this FPGA. And I suppose there are many smaller projects for which such an old chip is more than sufficient. What would you say, if a CPU manufacturer doesn't make available the processor documentation (instruction set, instruction encoding). He only gives you a C compiler to design your software and anything below is the secret of the company. Nobody would buy such a processor, but that's exactly the situation with FPGA's.Article: 119006
When you create the CoreGen project you need to have verilog selected (I assume the problem is that you're getting VHDL instead?). But it's a project setting, I believe, not a MiG setting. On May 9, 12:23 am, Gordon Freeman <gordonfreeman1...@gmail.com> wrote: > Hi everyone! > When I use memory interface generater tool, I select device XC3S400. > The tool dosen't generate verilog code for me. I don't know why. Can > you help me to solve it, please?Article: 119007
On 2007-05-09, Ben Jones <ben.jones@xilinx.com> wrote: > tool flows. Most serious FPGA developers already have their own makefiles > and associated infrastructure that eases the portability of their design > from one vendor's device to another's. At which point, slapping a sparkly > GUI on top of it is not a high priority for them. Personally I'd rather have effort spent on a high quality emacs-mode for RTL development. VHDL mode is good, Verilog mode is good, but there is a _huge_ opportunity to improve the current situation. I'd also like to see a more "standardized" makefile based build system so that not every developer has to reinvent that particular wheel. Especially since the available parts (command line tools) are sometimes cumbersome to fit into the wheel (makefile). > An open-source equivalent of the Core Generator (~MegaWizard) could work; Opencores would seem like an ideal place for development of something like this. However, one problem that might bite open source efforts in this area is patents. While software patents might not be legal in at least some parts of the world, hardware patents are. So the legal status of a hypothetical parameterizable hardware library would be less certain than a software library... Personally I'm curious whether distributing the RTL source code for lets say an FFT core which is implemented using the "Foo bar method" infringes upon JBN's patent on a hardware implemention of the "Foo bar method". As an aside, Opencores actually had a "socbuilder" project, unfortunately no activity has taken place there for 3 years or so. > But would it make sense to try and do an open source FPGA floor-planning Actually, I think an open source FPGA floorplanning tool could be done. I've been thinking about it myself at some time and it wouldn't require that much knowledge of the device. It might even be possible to do a placer as open source (I've been toying with the idea of writing my own placer algorithm as a hobby project, just to see how difficult it is to get decent results. I certainly wouldn't realistically expect to beat the Xilinx placer though :)) Making a good quality router is probably much more difficult. (You could do probably do a bad router by using a subset of the available wires and not worry about the timing constraints though.) A good quality router would not only need access to all routing possibilities in some way but also the timing properties of the paths. I could also point out that there actually is source code available on the net for a place and routing tool (VPR). But the license is not open source last time I checked (http://www.eecg.toronto.edu/~vaughn/vpr/terms.html). > programming stuff, as has been pointed out by several others. I would be > incredibly happy to see a proper, flexible, standard stack for accessing > JTAG devices - and to achieve that, I think an open source effort is pretty > much the *only* approach that will work. Hear hear! All in all, lots of good thoughts in Ben's posting I think. Some extra bonus thoughts from me: the open source community probably don't gain any good will by demanding an arm and a leg from Altera and Xilinx without showing that we can add significant value to their bottom line. For example, if we show that we can build a high quality synthesizer frontend that has about the same performance as XST, they might seriously consider contributing to that effort, perhaps even replacing their own tool with the open source tool. But right now the only open source synthesizing tool I'm aware of (Icarus) has a much too small user community to make that happen. /AndreasArticle: 119008
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cpope wrote: >> cpope wrote: >>> Has anyone tried to install xilinx webpack on ubuntu 6.06LTS? If I run > the >>> web download tool (sudo ./setup) I get through the questions but it dies >>> shortly after I click install. If I use the single file download it asks > for >>> a registration ID which as far as I can tell doesn't exist for webpack? > Any >>> help is appreciated. > > Yes, I've done that. I'm saying that both installation methods are failing. > The web download method dies after install starts and the single file > download method asks for a non-existant registration ID. Thanks > > I've experienced the web install method not working on SuSE 10.1, fecora core 6 or RHEL4. It seems to be universally broken and not just a porting problem. The "Single File Download" installed on RHEL4 just fine, and without asking for registration IDs, so that seems like a more local problem for you. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGQdvDrPt1Sc2b3ikRAuIoAJ9v515JwqO5KthxF3uqrFBmLh+qAACgtjkT hvIsDEJ9Lzj/8FWl7W6kyRY= =bG7Y -----END PGP SIGNATURE-----Article: 119009
On May 8, 4:50 am, Guru <ales.gor...@email.si> wrote: > Why do you need a RAW mode? Do you actually need a TCP/IP stack? If > not you can write directly to TEMAC and send RAW frames at highest > speed possible. > > Guru Well, we need to send data using the TCP protocol ideally, but the UDP protocol could work as well. So my understanding is that a TCP/IP stack is required in our case. Maybe we could construct our own UDP packets without a stack though... RAW mode is simply to acheive better performance than sockets mode and also to ease the development (we don't want to bother with an OS and threads). Thanks. PatrickArticle: 119010
On May 8, 1:33 pm, Aggie <c.kevin....@gmail.com> wrote: > How can I display "hello world" onto the Char LCD which is on the > development board (ML405)? > > I realized a similar topic has been posted. But our situation is a > little different. > > I want to do it the "software" way, i.e. write a C program and > download it to the board. > > Here's what I'm using: > Xilinx Platform Studio 8.2 > Wind River - OS vxwork 6.4 > > Thanks in advance. Any input help. > > Kevin Since no one else bit, the easiest way is to assign a GPIO port to it, and connect it to the LCD pins per the schematic. From there, you will need to write routines that drive the pins according to the datasheet (practically any HD44780 sheet should do, as they all follow that spec)Article: 119011
On May 8, 4:29 pm, "Paul Tobias" <PaulTob...@MyWebSite.com> wrote: > If you browse to my website atwww.paultobias.com/Xilinx, I have posted the > source to a > LWIP driver and startup code for a raw API TCP client application that runs > on the V4fx ML403 board on top of Xilkernel (though it could be just as > easily standalone at present.) > > LWIP using sockets was far too slow for us, so I put this together using the > Temac sockets code for EDK 8.2/9.1 and the emac raw api driver (I think for > an older EDK version). > So far this is tested only for receiving TCPIP packets, which it does at > 3-400 Mbps, which is in > line with Ron Wright's presentation at Xfest recently. Using a good 32 bit > memory aligned memcpy function instead of the many bytewise packet copies in > LWIP should be an easy > first step to improve this rate. > > You are welcome to use this as a starting point, but be aware that I am a > novice at LWIP, TCP/IP internals and Xilinx, and the output routines are > totally untried or tested, except for > those used by the lower levels (ARP and ACKs etc.). More info in the > ReadMe file on site. > > Paul > > www.paultobias.com Thanks a lot Paul. Your XTemacif.c driver is exactly what is needed (which should have been provided by Xilinx in the first place). I didn't feel like I had the knowledge to write it myself, thanks for sharing your code! PatrickArticle: 119012
Mike Lundy wrote: > I have a dream where a software-only engineer [namely, most of my > friends] could simply buy a dev kit and have something nifty working > within an hour or two of it arriving in the mail. Much like the way > Lego Mindstorms work- Lego is brilliant with usability. If you design > your software so a 10-year-old could use it, you're pretty much > covered all your bases :) Well I happen to fall in this category, being a software engineer, and having bought the Spartan-3E Starter kit. Got ISE 8.1, which works just fine and had my first design running in just a few hours. I wouldn't say that the learning curve is terribly high, or that the Xilinx board was expensive (about ~$150). Of course it would be nice to have parts of ISE being open-source, though. I just can't see what it could provide that isn't already part of the package.Article: 119013
On May 9, 6:53 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > Some extra bonus thoughts from me: the open source community probably > don't gain any good will by demanding an arm and a leg from Altera > and Xilinx without showing that we can add significant value to their > bottom line. Many of the open source projects that have commercial support (IBM, SUN, etc) turned out to be useful for those vendors to avoid licensing fees (SCO/AT&T, Microsoft, etc) for the expensive monopoly products (UNIX, Microsoft Office, etc). The replacement products (Linux, OpenOffice, etc) had growing pains as things needed to be rewritten to remove licensed parts. In the early days of UNIX (a portable operating system) many of the vendors laughed hard a long about how poor a performer a high level language operating systems and applications would be ... while the dino assembly language OS's, compilers, tools and applications slowly died away, it became clear the NIH factors were much stronger than the technical basis for those arguements. We learned that the differences in server hardware (which are just as great as FPGA internals) could be abstracted away into hardware architecture layers that were VERY vendor dependent, yet had very high levels of common code factored into supporting subsystems. Complexity wise, there are very common threads in FPGA vendor tools ... high license costs make FPGA compilers (synthesis, place and route tools) expensive for wide scale adoption to replace CPU's ... where software tools are largely free or relatively low cost. While Xilinx states that licensing prohibts an OSS migration, it's clear from the StarOffice to OpenOffice migration that isn't always the case, and in the end the vendor version with licensed products offers a proprietary superior supported product for those customers that need all the features, while leveraging significant OSS advantages for the base product that expands the market. Likewise, just as UNIX/LInux have shown portable operating systems in a high level language are not only possible, but superior for mass markets, there is a strong likelyhood that similar evolution of synthesis, place and route tools is also possible. DItto for the GNU and GCC tool chains which provide broad cross platform solutions, not always as optimal as proprietary compilers from certain vendors, but broadly usable by most developers. Just as there are still some proprietary highly optimized OS's, compilers, and tool chains for certain computer applications for both the high end servers and low end embedded ends, if open source FPGA tools become common, there will remain proprietary solutions for niche markets too. Linux and GCC are not the only choice, but certainly the most common in certain high and low end markets, because they are open, vendor supported, and customer supported.Article: 119014
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think you may be underestimating the importance of the ancillary stuff that people use daily and are misinterpreting what people are asking for... steve.lass@xilinx.com wrote: > OpenOffice looks like a good eample of something that fits > well with the open-source model, but I don't see that good of > a fit with our tools. Certainly not all of them, but... > There are a few programs that we could open-source, but they > only have a few engineers working on them, so it would not save > resources since we have to manage the open-source projects. I hope one of those tools is the programming tool suite. There are many complaints about impact, and there are many situations where users would just *love* to be able to customize the programmer for their hardware. Where I work, we've pretty much given up on being able to use impact for anything other then writing ACE files, and it does a clunky job at that. I suspect that open-sourcing impact would make a *lot* of folks very very happy. > The bigger applications like ProjNav and XPS are much more > device/Xilinx specific than most of you are implying so I don't > see an easy solution there either. XST is very device specific and > this is one of the applications that starts their work over a year > ahead of a new device introduction. I think no one (or almost no one) thinks it is practical, or even desirable, for you to open-source xst, map, or par, or similar tools. And quite frankly, those tools don't have the problems that all the other fluff has with portability. What people want is a more open-source friendly attitude with all the other bits. The programmer is a blatant case where there are already several open-source programmer projects trying to make your programmer tools useful in various situations where impact breaks down. Give these projects active help, or turn impact into an open- source project, and many people will be happy. Overall, people want Xilinx to be more cooperative with open-source up front, instead of fighting it every step on the way. If you start with an open-source friendly attitude, then you'll surely find many ways to be more open that *help* your business. It shouldn't be a battle. We're not out for blood. We want to use Xilinx (or Altera, or etc.) parts! For the record, I have generally encountered helpful people within Xilinx for my own open source project (Icarus Verilog) so I suspect that this missing the point of open source is not universal within the sheltered caverns. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGQfPUrPt1Sc2b3ikRAjaoAJ903w6q0cxgtaf+8MtNOFZs9Y9MzwCgyDn5 4EDfChTwUjuVKNysVM1/eNc= =n5Qr -----END PGP SIGNATURE-----Article: 119015
"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message
news:f1sg8l$ats$1@news.lysator.liu.se...
>> An open-source equivalent of the Core Generator (~MegaWizard) could work;
> Opencores would seem like an ideal place for development of something like
> this. However, one problem that might bite open source efforts in this
> area
> is patents. While software patents might not be legal in at least some
> parts of the world, hardware patents are. So the legal status of a
> hypothetical
> parameterizable hardware library would be less certain than a software
> library... Personally I'm curious whether distributing the RTL source
> code for lets say an FFT core which is implemented using the "Foo bar
> method"
> infringes upon JBN's patent on a hardware implemention of the "Foo bar
> method".
This is true, and it's certainly a concern. Still, at least with patents
there comes disclosure, so it's possible to work around them to some extent.
The world survived the .GIF wars, of course. :)
Mostly, since FPGA vendors make their money off silicon sales, anything that
increases the usability of FPGAs and gets even the smallest of projects off
the ground is unlikely to be shot down. If you look at the semiconductor
marketplace as a whole, PLDs are still a relatively small chunk, but with
enormous growth potential. I don't much care if Altera grows its top line by
200%, so long as Xilinx is doing the same (or better ;-)).
Some might say that open-source vendor-independent tools would accellerate
the commoditization of the FPGA. I say, bring it on! (That's because I care
more about cool technology than I do about gross margins though. Go figure.)
>> But would it make sense to try and do an open source FPGA floor-planning
> Actually, I think an open source FPGA floorplanning tool could be done.
Yes, thinking about it, the idea of a generic tool for laying out your
circuit on some generic device is not too difficult to grasp. Someone would
need to establish a standard way to represent the various
columns/rows/grids/rings of resources on all the world's PLD parts, and work
out a way of translating the constraints applied by the user into whatever
the vendor's back-end tools understand.
> Making a good quality router is probably much more difficult.
The main problems with P&R are truly understanding the switch matrices
(virtually undocumented in the latest devices as far as I know) and having a
good timing model. Now, within the Xilinx tools (and presumably within brand
A's as well), the timing details are exposed as a library of API calls,
because they need to be shared between all the elements of the flow -
synthesis, map, PAR, trace, FPGA editor etc. This infrastructure works for
many different device families. There's no reason why a similar architecture
couldn't be devised to cope with devices from multiple vendors.
> Some extra bonus thoughts from me: the open source community probably
> don't gain any good will by demanding an arm and a leg from Altera
> and Xilinx without showing that we can add significant value to their
> bottom line.
As I've alluded to, I think the main concern is that Brand {A|X} doesn't
want to lose share to brand {X|A}. It's a game theory thing - the payoff for
co-operation (via OSS) is potentially huge...
> For example, if we show that we can build a high quality synthesizer
> frontend that has about the same performance as XST, they might seriously
> consider contributing to that effort, perhaps even replacing their own
> tool with the open source tool. But right now the only open source
> synthesizing tool I'm aware of (Icarus) has a much too small user
> community to make that happen.
Also, it uses the wrong language. :-P
I think open source synthesis is a very appealing prospect. In the last
couple of decades, people have really learned what works and what doesn't.
It's certainly a challenge, but at least just about everything you need to
know to write a synthesis tool (or the optimization engine of a synthesis
tool, which is what really matters) is right there in the device datasheets.
Plus, in starting from a clean sheet, the open-source community might well
be able to leapfrog a lot of the legacy support issues.
I guess there are political issues about synthesis tools as well, given that
commercial third-party synthesis vendors still exist. But the Xilinx focus
is (nominally) on building an FPGA ecosystem, which means encouraging
*anything* that will accelerate the adoption of FPGAs. Today's student
projects and underfunded startups are tomorrow's tier-one customers, after
all.
Cheers,
-Ben-
Article: 119016Guru wrote: > > Ave Paul! There is a lack of fast and free TCP/IP stacks which work > with TEMAC. It would be nice to port your stack to GSRD design > (www.xilinx.com/ gsrd) to get a maximum speed and royalty free > reference design. I got this design working on Avnet Virtex-4FX12 > MiniModule, which is a low cost high performance OEM module. > Unfortunatelly there are no good reference designs which can exploit > this performance. If I were a better SW engineer I could help you on > development from which both would benefit. > > Guru Hi Guru, I am the hardware engineer who is working with Paul. I'd love to hear any comments you might have on our approach. Our application specific IP that must also fit in the FPGA is a PLB master DMA device that uses about 50% of the BRAM and 25% of the fabric in the FX12. We originally were going to use the FX12 Minimodule, but switched to the ML403 to get 2x the DDR bandwidth. We can get by with 400 Mb/s performance for now, but would like to get 800 Mb. It seemed like all the GSRD examples almost filled a FX12, particularly with BRAM usage, so we used the EDK supplied PLB TEMAC core and the PLB DDR controller for now. Since our app only needs high speed in the receive direction, it seemed like it should be possible to remove half the GSRD logic (i.e. the transmit part) and then everything would fit. As someone who has worked with the GSRD, do you have a feel for how hard this would be? Or would you guess the full GSRD (both directions) could fit with our IP somehow? The critical resource seems to be BRAM and it always seemed like the xilinx IP really used more BRAM that it should. thanks, JeffArticle: 119017
Stephen Williams schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > > Where I work, we've pretty much given up on being able to use > impact for anything other then writing ACE files, and it does > a clunky job at that. I suspect that open-sourcing impact would > make a *lot* of folks very very happy. Hi Steve I just recalled, I have reverse engineered the ACE file format even written ACE compressor and player, so the work has begun already :) ah, yes I can open-source the ACE player.. please remind in a few days should i forget.. AnttiArticle: 119018
Can't figure it out... Why cant this compile:
S_chan0_clk : process (reset_delayed, ch_clk_div_int)
begin
for k in 0 to 15 loop
test_case := ch_clk_div_int(k);
if reset_delayed = '1' then
reset_chan_Q(k) <= '1';
reset_chan_QQ(k) <= '1';
elsif ch_clk_div_int(k) = '1' AND ch_clk_div_int(k)'EVENT then
reset_chan_Q(k) <= '0';
reset_chan_QQ(k) <= reset_chan_Q(k);
end if;
end process;
It should unroll the loop, and there is therefore nothing undefined
about the clk.... but yet ModelSim says that 'EVENT requires a static
prefix.... anyone know why? how to get around it? thanx
Article: 119019austin wrote: > 1. Learn spice > 2. Use spice. 3. The spice must flow! (sorry, couldn't resist ;-)Article: 119020
Ignore the test_case := ch_clk_div_int(k); that was from something else i was trying... forgot to delete it On May 9, 1:30 pm, Paul <pauljbenn...@gmail.com> wrote: > Can't figure it out... Why cant this compile: > > S_chan0_clk : process (reset_delayed, ch_clk_div_int) > begin > for k in 0 to 15 loop > test_case := ch_clk_div_int(k); > if reset_delayed = '1' then > reset_chan_Q(k) <= '1'; > reset_chan_QQ(k) <= '1'; > elsif ch_clk_div_int(k) = '1' AND ch_clk_div_int(k)'EVENT then > reset_chan_Q(k) <= '0'; > reset_chan_QQ(k) <= reset_chan_Q(k); > end if; > end process; > > It should unroll the loop, and there is therefore nothing undefined > about the clk.... but yet ModelSim says that 'EVENT requires a static > prefix.... anyone know why? how to get around it? thanxArticle: 119021
> OSS versions would lag a vendor-proprietary system significantly because > vendors just won't release early details of their new architectures to the > general public. Maybe this isn't such a bad thing. FPGA vendors could use this lag to maintain an advantage for selling thier own software tools. The vendors could license their own tools for the new bleeding edge parts, which OSS tools would be unable to support right away. OSS tools would support all of the older, previous generation parts, which would probably be good enough to help build the community. Its the same strategy Xilinx is already using with Webpack, only now you also get OSS tools the the community can rally around. Consider how this might work in the context of the current generation of products. Virtex 4/5 support would only be available from Xilinx since its relatively new, but a full OSS tool chain would by now be available for older Virtex II devices. A lot of people are still using Virtex II chips, so free tools would be a significant boost for the community. At the same time, no one who is currently buying Virtex 4/5 chips is going to stop and wait a year or two for the OSS tools for those to become available. Those using these chips are doing so because their applications NEED their power NOW, and it is worth paying a premium for that power. FPGA vendors could then time the release of the specs for devices knowing that in about a year or two, the OSS tools will be complete for it, and by that time a new, better device will be available with tools available only from them. In the end, I think everyone wins.Article: 119022
For a standalone example (no VxWorks) in C you can have a look at the ML405 reference design: http://www.xilinx.com/products/boards/ml405/reference_designs.htm http://www.xilinx.com/products/boards/ml405/files/ml405_emb_ref_ppc_81.zip In sw/standalone/simon.src you find a xromlcd.h and xromlcd.c that implements some functions to write to the LCD. These functions are called from simon.c It should be straight forward to port that code to VxWorks. - Peter Aggie wrote: > How can I display "hello world" onto the Char LCD which is on the > development board (ML405)? > > I realized a similar topic has been posted. But our situation is a > little different. > > I want to do it the "software" way, i.e. write a C program and > download it to the board. > > Here's what I'm using: > Xilinx Platform Studio 8.2 > Wind River - OS vxwork 6.4 > > Thanks in advance. Any input help. > > Kevin >Article: 119023
On May 9, 10:32 am, Chris <c@c> wrote: > austin wrote: > > 1. Learn spice > > 2. Use spice. > > 3. The spice must flow! > > (sorry, couldn't resist ;-) Hi Chris, What does 'flow' mean? WengArticle: 119024
On May 9, 10:27 am, "Ben Jones" <ben.jo...@xilinx.com> wrote: > This is true, and it's certainly a concern. Still, at least with patents > there comes disclosure, so it's possible to work around them to some extent. > The world survived the .GIF wars, of course. :) Which is why open source only works well with vendor partnerships to provide an IP shield and patent pool. It's difficult, if not impossible to make any open source synthesis tool successful when a vendor directly targets it for failure. Simply releasing free web pack ISE with XST makes buying into a less capable Verilog tool an unlikely success. A Vendor funding the same tool and giving it away, pretty much assures success. When reverse engineering vendor data formats is in violation of license NDA's, it's pretty much assured the vendor and litigate against the developers to block everything (at least in the US, harder to stop in other countries). > Mostly, since FPGA vendors make their money off silicon sales, anything that > increases the usability of FPGAs and gets even the smallest of projects off > the ground is unlikely to be shot down. If you look at the semiconductor > marketplace as a whole, PLDs are still a relatively small chunk, but with > enormous growth potential. I don't much care if Altera grows its top line by > 200%, so long as Xilinx is doing the same (or better ;-)). > > Some might say that open-source vendor-independent tools would accellerate > the commoditization of the FPGA. I say, bring it on! (That's because I care > more about cool technology than I do about gross margins though. Go figure.) > [ ... ] > I guess there are political issues about synthesis tools as well, given that > commercial third-party synthesis vendors still exist. But the Xilinx focus > is (nominally) on building an FPGA ecosystem, which means encouraging > *anything* that will accelerate the adoption of FPGAs. Today's student > projects and underfunded startups are tomorrow's tier-one customers, after > all. It's always the political issues, both inside and outside the vendor's staff. Especially the prevailing arguement about supporting the top 50 customers, OR supporting a pure commodity market with tens of thousands of customers. Something of a chicken and egg problem, that has a very direct out come on gaining/maintaining market share of a commodity with open source tools. The proprietary FPGA tools are unlikely to evolve to support such commodity markets, as they are not necessary to support the exisiting top 50 (500) customers that are (likely) already buying (expensive) 3rd party tools too. Unless of course, a vendor breaks ranks and goes after the commodity market share by making their tools widely available and useful for the many commodity markets, by setting the standard for those tools released in an open source environment.
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