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
On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner" <zapwireDASHgroups@yahoo.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:4gcrj690ue2un4cu7d0fen5vjcq43pci6l@4ax.com... >> The software is the heart of an FPGA company. > >Glad to know I'm not the only one who thought the first response to that >article: > >"Xilinx sell hardware, software especially high level tools is secondary." > >...was a bit clueless! And the bitstream structure is secret, so third parties can't supply end-to-end software, as far as I'm aware. I bet some small IP house could do a better job. JohnArticle: 150476
On Jan 23, 1:36=A0pm, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote: > On Mon, 24 Jan 2011 08:35:19 +1100, "Phil Allison" <phi...@tpg.com.au> wr= ote: > > ><k...@att.bizzzzzzzzzzzz> > > >** You are a total cunthead and a massive liar. > > You already said that Phyllis. =A0You're not adding anything to the group= now. This will help deal with Phyllis: <http://groups.google.com/group/ comp.arch.fpga/browse_thread/thread/b633ae5fc3619c99#>Article: 150477
John Larkin wrote: > On Mon, 24 Jan 2011 09:09:42 +0100, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 23/01/2011 06:10, John Larkin wrote: >>> On Sat, 22 Jan 2011 23:03:16 -0600, "krw@att.bizzzzzzzzzzzz" >>> <krw@att.bizzzzzzzzzzzz> wrote: >>> >>>> On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin >>>> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>> http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation >>>>> >>>>> Yikes, this explains some stuff. I wonder how long it will take to >>>>> undo the damage. >>>> >>>> Damage? The damage caused by closing a software development lab? >>> >>> I meant the damage likely *done* by that lab. We'd been speculating >>> how Xininx managed to snarl up their software so thoroughly, and >>> whether they will ever get it fixed. I can't imagine why they'd >>> outsource something this important to France. >>> >> >> I find it hard to believe that supposedly educated, intelligent and >> experienced engineers can post such ignorant xenophobic drivel. > > Well, two facts exist: > > 1. Their software is a nightmare, and it's costing them business > > 2. They are dumping the French operation. > > The software is the heart of an FPGA company. The very architecture of > the chip has to be coordinated with possible compiler strategies. The > idea of outsourcing anything this important to a group 8 or 9 time > zones away, working in another language, in a country where it's > almost impossible to fire incompetant workers, where people take long > lunches with wine and don't work weekends, just amazes me. > While there may or may not be a lot of French software workers out there, I've worked with a handful who were pretty good. And more than once, I've done things in software to where I *wished* I'd taken a long lunch, with or without wine. :) Nothing particularly tragic, there - software is specifically resistant to both the work ethic and to other input analyses. >> >> Xilinx (or rather, their users and customers) have trouble with the >> Xilinx software because the Xilinx leadership do not prioritise it >> appropriately, and (apparently) do not listen to or understand the >> issues customers have with the software. They alone are at fault. It >> could well be that the main management fault was to hire a development >> team that was not competent to do the development - but the problem is >> their lack of competence, not their nationality! > > I'd have been equally surprised had they outsourced anything this > core-critical to any other country that far from San Jose. Big > Software is nearly impossible to manage even without an ocean in the > way. > I'd almost say it's just equally impossible. Hard to say in detail without specifics. But interfaces are always hard. > >> >> I know that sci.electronics.design is a hangout for mostly geriatric >> American right-wingers who like to spend their free time blaming the >> world's ills on "leftist weenies", foreigners, atheists, intellectuals, >> and other dangerous sub-humans. > > Jim isn't typical. > > John > -- Les CargillArticle: 150478
I think that iMpact is messing with me. Here's what I do: 1) Create a bit file with ISE 11.5 2) Downloading the bit file to my Virtex-5 via JTAG. (I'm using a DLC9G and WinXP) 3) Run a regression test on the system. If the regression test passes I do the following: 4) Create a MCS file with iMpact. 5) Load the MCS into the attached SPI chip (again, with the DLC9G) 6) Power cycle the board. 7) Re-run the regression test. Here's my issue: I have two bit files for this project. One was created last month, one was created last week. The steps above are repeated EXACTLY for the two bit files. There are no warnings or errors generated with steps 2 through 6. Step 7 fails for one bit file, and passes for the other. With one bit file, and chip never leaves the DONE state. Keep in mind that both bit files load and run "just fine" when I load them through the JTAG port. Has anyone seen this before? I haven't gotten any help from the factory yet. Regards, G.Article: 150479
How will any of this ameliorate coprolalia by Phil Allison and Archie?Article: 150480
On Jan 24, 12:21=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 24 Jan 2011 09:09:42 +0100, David Brown > > <da...@westcontrol.removethisbit.com> wrote: > > >I find it hard to believe that supposedly educated, intelligent and > >experienced engineers can post such ignorant xenophobic drivel. > > Well, two facts exist: > > 1. Their software is a nightmare, and it's costing them business > > 2. They are dumping the French operation. > > The software is the heart of an FPGA company. The very architecture of > the chip has to be coordinated with possible compiler strategies. The > idea of outsourcing anything this important to a group 8 or 9 time > zones away, working in another language, in a country where it's > almost impossible to fire incompetant workers, where people take long > lunches with wine and don't work weekends, just amazes me. This is probably a discussion to stay out of, but I want to correct a misapprehension on your part. I have worked with the French at a major telecom company and will tell you that they are no more incompetent or drunk than American workers. The continent does have a different work culture in terms of leave. They get lots more vacation than we typically do and they manage to get their work done without working late nights and weekends. Actually I have always thought it very odd that US workers were willing to take on the burden of completing projects on time and budget when they have little or no say in the process of setting those goals. Lets face it. Being willing to work unlimited, unpaid overtime is something that the majority of workers in the US are unwilling to do. For some reason engineers seem to be in a class all by themselves in that regard here in the US. What other professions are willing to do that? > >Xilinx (or rather, their users and customers) have trouble with the > >Xilinx software because the Xilinx leadership do not prioritise it > >appropriately, and (apparently) do not listen to or understand the > >issues customers have with the software. =A0They alone are at fault. =A0= It > >could well be that the main management fault was to hire a development > >team that was not competent to do the development - but the problem is > >their lack of competence, not their nationality! > > I'd have been equally surprised had they outsourced anything this > core-critical to any other country that far from San Jose. Big > Software is nearly impossible to manage even without an ocean in the > way. Distance doesn't create problems in management... management creates problems in management. I've worked on projects where no two people were in the same city and they progressed well, except for the management which kept feeding lies upstream in order to tell them what they wanted to hear. I guess one difference is that it is a bit harder to manage by "walking around", something upper management should do. Then they can find out things that they aren't being told. But none of this has to do with nationality. RickArticle: 150481
On Jan 24, 12:49=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner" > > <zapwireDASHgro...@yahoo.com> wrote: > >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mess= age > >news:4gcrj690ue2un4cu7d0fen5vjcq43pci6l@4ax.com... > >> The software is the heart of an FPGA company. > > >Glad to know I'm not the only one who thought the first response to that > >article: > > >"Xilinx sell hardware, software especially high level tools is secondary= ." > > >...was a bit clueless! > > And the bitstream structure is secret, so third parties can't supply > end-to-end software, as far as I'm aware. I bet some small IP house > could do a better job. > > John They did, it was called NeoCAD and they were bought by Xilinx! RickArticle: 150482
On 01/22/2011 11:10 PM, John Larkin wrote: > I meant the damage likely *done* by that lab. We'd been speculating > how Xininx managed to snarl up their software so thoroughly, and > whether they will ever get it fixed. I can't imagine why they'd > outsource something this important to France. One word, Alcatel. JonArticle: 150483
On Jan 24, 2:09 am, David Brown <da...@westcontrol.removethisbit.com> wrote: > I find it hard to believe that supposedly educated, intelligent and > experienced engineers can post such ignorant xenophobic drivel. > > Xilinx (or rather, their users and customers) have trouble with the > Xilinx software because the Xilinx leadership do not prioritise it > appropriately, and (apparently) do not listen to or understand the > issues customers have with the software. They alone are at fault. It > could well be that the main management fault was to hire a development > team that was not competent to do the development - but the problem is > their lack of competence, not their nationality! > > I know that sci.electronics.design is a hangout for mostly geriatric > American right-wingers who like to spend their free time blaming the > world's ills on "leftist weenies", foreigners, atheists, intellectuals, > and other dangerous sub-humans. You left out OUTSOURCING, Downsizing, dumping out staff en masse and hiring them all back as contractors to avoid social responsibilities, Pensions and raiding thereof, H1b visas and the way corporations take classes on how to BS around the law that requires them to hire qualified US people for the jobs first, etc. (Where WERE you back in Jan 2010 when that was discussed?) I would EXPECT that most US Engineers would be very well focused on all of those threats to their livelyhood, wouldn't you?? If you're gonna try this Xenophobia canard you MIGHT want to WATCH THIS FIRST! (Even more references at bottom of post) http://www.youtube.com/watch?v=TCbFEgFajGU > That's fair enough, within the limits > of freedom of speech. It can even be entertaining at times. But please > keep that sort of thing within s.e.d. and not serious newsgroups. > > Follow-up flames to s.e.d., and leave c.a.f. alone for a possible > discussion about the actual effect of this news on Xilinx and its customers. I look forward to you serious discussion and problem resolution. On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner" wrote: Glad to know I'm not the only one who thought the first response to that article: "Xilinx sell hardware, software especially high level tools is secondary." ...was a bit clueless! On Jan 24, 11:49 am, John Larkin wrote: And the bitstream structure is secret, so third parties can't supply end-to-end software, as far as I'm aware. I bet some small IP house could do a better job. ----------------------------------- http://groups.google.com/group/sci.electronics.design/msg/3f074e88bda71375 PERM Fake Job Ads defraud Americans to secure green cards for H-1b workers http://www.youtube.com/watch?v=TCbFEgFajGU > Immigration attorneys from Cohen & Grigsby explains how they assist > employers in running classified ads with the goal of NOT finding any > qualified applicants, and the steps they go through to disqualify even > the most qualified Americans in order to secure green cards for H-1b > workers. See what politicians call a "shortage of skilled U.S. > workers." Microsoft, Oracle, Hewlett-Packard, and thousands of other > companies are running fake ads in Sunday newspapers across the country > each week. G > Has Obama reversed this fraud? "Ban" through a german anonymous remailer motzarella wrote Ban > Sorry you didn't find a job, but maybe it's because your Ban > qualification is sub standard. I wouldn't employ a Ban > complainer like this who blames all those Mexicans for Ban > taking away engineering jobs. ciao Ban Hillary Clinton Pushes For More H1B Visas and OutSourcing June 2007 http://www.youtube.com/watch?v=UhLBSLLIhUs Hillary Clinton reaffirms support for more H-1B visas July 2007 http://www.youtube.com/watch?v=AOW0cUaGWZU H 1B visa racket busted in US, 11 Indians arrested Feb 14, 2009 http://www.youtube.com/watch?v=Uaofpy3D-oE H1-B visa bar disappoints young Indians Feb 16, 2009 http://www.youtube.com/watch?v=ohaSa_1WZVo Visa Consultants selling H-1b visas July 2007 http://www.youtube.com/watch?v=bOqOxYr4F18 WashTech on Microsoft Replacing American Workers Feb 10 2009 http://www.youtube.com/watch?v=SwnvkK94o3I Immigration Gumballs - notice the graphs Nov 2006 http://www.youtube.com/watch?v=n7WJeqxuOfQArticle: 150484
On Jan 24, 1:50=A0pm, ghelbig <ghel...@lycos.com> wrote: > I think that iMpact is messing with me. > > Here's what I do: > > 1) Create a bit file with ISE 11.5 > 2) Downloading the bit file to my Virtex-5 via JTAG. =A0(I'm using a > DLC9G and WinXP) > 3) Run a regression test on the system. > > If the regression test passes I do the following: > > 4) Create a MCS file with iMpact. > 5) Load the MCS into the attached SPI chip (again, with the DLC9G) > 6) Power cycle the board. > 7) Re-run the regression test. > > Here's my issue: > > I have two bit files for this project. =A0One was created last month, > one was created last week. =A0The steps above are repeated EXACTLY for > the two bit files. =A0There are no warnings or errors generated with > steps 2 through 6. > > Step 7 fails for one bit file, and passes for the other. =A0With one bit > file, and chip never leaves the DONE state. =A0Keep in mind that both > bit files load and run "just fine" when I load them through the JTAG > port. > > Has anyone seen this before? =A0I haven't gotten any help from the > factory yet. > > Regards, > G. The first thing I look for is whether the .mcs file was really created correctly. I have been burned by the ISE GUI grabbing an existing impact project that built a new .mcs file from an old .bit file. If you look in the directory where the .mcs file was built, there should also be a .prm file with the same base file name. In this file you can see the name and modification date of the .bit file(s) that were used in creating the .mcs file. Also I have had some issues with indirect SPI programming using impact. However usually these show up as an error when you go to verify the .mcs file in SPI flash. When you say "never leaves the DONE state" do you mean that DONE never goes high? Or does DONE go high, but the chip never comes out of reset. The latter condition can be bitstream-dependent although I've never seen this behavior when using Master-SPI config mode. Just be sure that you use the default startup clock (CCLK) when you run BitGen. -- GaborArticle: 150485
On Mon, 24 Jan 2011 09:21:27 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >I'd have been equally surprised had they outsourced anything this >core-critical to any other country that far from San Jose. Big >Software is nearly impossible to manage even without an ocean in the >way. If you intend to outsource something, you really must concentrate on writing sensible _good_quality_ specifications. With the coders in the next cubicle (at least in the same time zone), you can always discuss the problems immediately, With development teams in the Americas, Europe and Asia, the common real time discussion window is quite limited due to the time zones.Article: 150486
Hello!
I'm trying to get the following snippet to work and I'm 1) wondering
what's wrong and 2) wondering if I'm going about this the right way.
I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz)
which control the CPU and the output to the LCD (obviously enough). What
I want to happen is that the CPU will set trigger on the leading edge of
the CPU clock and clear it on the falling edge of the LCD clock (which
should ensure that it has been picked up by the 'main' process).
The error message I'm getting is "statement is not synthesizable since
it does not hold its value under NOT(clock-edge) condition".
The code:
trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
begin
trigger <= '0';
if reset = '1' then
trigger <= '0';
elsif clk'event and clk = '1' and output_trigger = '1' then
trigger <= '1';
elsif clk_200kHz'event and clk_200kHz = '0' then
trigger <= '0';
end if;
end process;
main: process(...)
if reset
...
elsif clk_200kHz'event and clk_200kHz = '1' then
...
end if;
end process;
Article: 150487On Jan 24, 3:32=A0pm, Trygve Laugst=F8l <tryg...@inamo.no> wrote: > Hello! > > I'm trying to get the following snippet to work and I'm 1) wondering > what's wrong and 2) wondering if I'm going about this the right way. > > I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz) > which control the CPU and the output to the LCD (obviously enough). What > I want to happen is that the CPU will set trigger on the leading edge of > the CPU clock and clear it on the falling edge of the LCD clock (which > should ensure that it has been picked up by the 'main' process). > > The error message I'm getting is "statement is not synthesizable since > it does not hold its value under NOT(clock-edge) condition". > > The code: > > =A0 =A0 =A0trigger_xfer: process(reset, clk, clk_200kHz, output_trigger) > =A0 =A0 =A0begin > =A0 =A0 =A0 =A0 =A0trigger <=3D '0'; > =A0 =A0 =A0 =A0 =A0if reset =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '0'; > =A0 =A0 =A0 =A0 =A0elsif clk'event and clk =3D '1' and output_trigger =3D= '1' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '1'; > =A0 =A0 =A0 =A0 =A0elsif clk_200kHz'event and clk_200kHz =3D '0' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '0'; > =A0 =A0 =A0 =A0 =A0end if; > =A0 =A0 =A0end process; > > =A0 =A0 =A0main: process(...) > =A0 =A0 =A0 =A0 =A0if reset > =A0 =A0 =A0 =A0 =A0 =A0 =A0... > =A0 =A0 =A0 =A0 =A0elsif clk_200kHz'event and clk_200kHz =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0... > =A0 =A0 =A0 =A0 =A0end if; > =A0 =A0 =A0end process; First, I know of no FPGA that has dual-clocked flip-flops available in the internal fabric. So it's no wonder that the code is not synthesizable. Second, 200 KHz is really slow, so you should probably just sample it with the 48 MHz CPU clock and use the sampled signal with another flip-flop delay to detect edges instead of trying to create a dual-clocked process. Third. It's not clear to me that you are taking care of synchronization properly here. If the intent is for a single event on the CPU clock to create an output that can be sampled at the falling edge of the 200 KHz clock, then I don't see how you will ensure any minimum setup time unless the event was already somehow synchronous to the 200 KHz clock. -- GaborArticle: 150488
[Note that I'm quite a newbie to VHDL] On 1/24/11 9:41 PM, Gabor wrote: > On Jan 24, 3:32 pm, Trygve Laugstøl<tryg...@inamo.no> wrote: >> Hello! >> >> I'm trying to get the following snippet to work and I'm 1) wondering >> what's wrong and 2) wondering if I'm going about this the right way. >> >> I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz) >> which control the CPU and the output to the LCD (obviously enough). What >> I want to happen is that the CPU will set trigger on the leading edge of >> the CPU clock and clear it on the falling edge of the LCD clock (which >> should ensure that it has been picked up by the 'main' process). >> >> The error message I'm getting is "statement is not synthesizable since >> it does not hold its value under NOT(clock-edge) condition". >> >> The code: >> >> trigger_xfer: process(reset, clk, clk_200kHz, output_trigger) >> begin >> trigger<= '0'; >> if reset = '1' then >> trigger<= '0'; >> elsif clk'event and clk = '1' and output_trigger = '1' then >> trigger<= '1'; >> elsif clk_200kHz'event and clk_200kHz = '0' then >> trigger<= '0'; >> end if; >> end process; >> >> main: process(...) >> if reset >> ... >> elsif clk_200kHz'event and clk_200kHz = '1' then >> ... >> end if; >> end process; > > First, I know of no FPGA that has dual-clocked flip-flops available in > the internal > fabric. So it's no wonder that the code is not synthesizable. Hm, I though this should synthesize a S/R+reset flip flop but I guess because of the 'event it will become clocks instead. > Second, 200 KHz is really slow, so you should probably just sample it > with the > 48 MHz CPU clock and use the sampled signal with another flip-flop > delay > to detect edges instead of trying to create a dual-clocked process. How would that work? It is generated from the 48MHz clock already just on the outside of the entity. > Third. It's not clear to me that you are taking care of > synchronization properly > here. If the intent is for a single event on the CPU clock to create > an output > that can be sampled at the falling edge of the 200 KHz clock, then I > don't > see how you will ensure any minimum setup time unless the event was > already somehow synchronous to the 200 KHz clock. Hm, I'm not really seeing the problem but that's probably because of my lack of understanding. Could you elaborate or show/point me some code that does what I want to do? I've been trying to read up on links from searches like "clock synchronization" and "clock domains" but haven't found something that really applies to my case (and makes sense to me). -- TrygveArticle: 150489
On Jan 24, 1:58=A0pm, Jon Elson <jmel...@wustl.edu> wrote: > On 01/22/2011 11:10 PM, John Larkin wrote: > > > I meant the damage likely *done* by that lab. We'd been speculating > > how [ Xilinx ] managed to snarl up their software so thoroughly, and > > whether they will ever get it fixed. I can't imagine why they'd > > outsource something this important to France. > > One word, Alcatel. > > Jon History The formation of Alcatel-Lucent created the world=92s first truly global communications solutions provider, with the most complete end-to-end portfolio of solutions and services in the industry. Alcatel-Lucent combined two entities =97 Alcatel and Lucent Technologies =97 which shared a common lineage dating back to 1986. That was the year Alcatel=92s parent company, CGE (la Compagnie G=E9n=E9rale d=92Electricit= =E9), acquired ITT=92s European telecom business. Nearly 60 years earlier, ITT had purchased most of AT&T=92s manufacturing operations outside the United States. Lucent Technologies was spun off from AT&T.Article: 150490
PA > ** You are a total cunthead and a massive liar. krw > You already said that Phyllis. =A0You're not adding anything to the group now. dsk > This will help deal with Phyllis: Nah. Phil is nastier than a hemmorhoid. From puiterl@notaimvalley.nl Mon Jan 24 13:30:11 2011 Path: unlimited.newshosting.com!s03-b24.iad!npeersf01.iad.highwinds-media.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news3.google.com!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Message-Id: <4d3def63$0$81483$e4fe514c@news.xs4all.nl> From: Paul Uiterlinden <puiterl@notaimvalley.nl> Subject: Re: statement is not synthesizable since it does not hold its value under NOT(clock-edge) condition Newsgroups: comp.arch.fpga,comp.lang.vhdl Followup-To: comp.arch.fpga Date: Mon, 24 Jan 2011 22:30:11 +0100 References: <4d3de1c1$1@news.broadpark.no> Organization: AimValley User-Agent: KNode/0.10.5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit Lines: 38 NNTP-Posting-Host: 195.242.97.150 X-Trace: 1295904611 news.xs4all.nl 81483 puiterl/[::ffff:195.242.97.150]:45199 X-Complaints-To: abuse@xs4all.nl Xref: unlimited.newshosting.com comp.arch.fpga:108184 comp.lang.vhdl:38275 X-Received-Date: Mon, 24 Jan 2011 21:31:16 UTC (s03-b24.iad) Trygve Laugstøl wrote: > Hello! > > I'm trying to get the following snippet to work and I'm 1) wondering > what's wrong The first assignment to "trigger" (right after the "begin") cannot be right. What you have described here is something like: "reset trigger on any event on signals reset, clk, clk_200kHz and output_trigger, unless there is a rising edge on clk while output_trigger is '1'. In the latter case, set trigger." If you leave out the first assignment, things perhaps start looking what you want. If it will be synthesisable, I don't know (I don't do synthesis). Have you simulated this code at all? > The code: > > trigger_xfer: process(reset, clk, clk_200kHz, output_trigger) > begin > trigger <= '0'; > if reset = '1' then > trigger <= '0'; > elsif clk'event and clk = '1' and output_trigger = '1' then > trigger <= '1'; > elsif clk_200kHz'event and clk_200kHz = '0' then > trigger <= '0'; > end if; > end process; > -- Paul Uiterlinden www.aimvalley.nl e-mail addres: remove the not.Article: 150491
On 1/24/11 10:30 PM, Paul Uiterlinden wrote: > Trygve Laugstøl wrote: > >> Hello! >> >> I'm trying to get the following snippet to work and I'm 1) wondering >> what's wrong > > The first assignment to "trigger" (right after the "begin") cannot be right. > > What you have described here is something like: "reset trigger on any event > on signals reset, clk, clk_200kHz and output_trigger, unless there is a > rising edge on clk while output_trigger is '1'. In the latter case, set > trigger." > > If you leave out the first assignment, things perhaps start looking what you > want. If it will be synthesisable, I don't know (I don't do synthesis). > > Have you simulated this code at all? No, it fails with the error message in the subject. -- TrygveArticle: 150492
On Jan 24, 3:47 pm, Trygve Laugst=F8l <tryg...@inamo.no> wrote:
> [Note that I'm quite a newbie to VHDL]
>
> On 1/24/11 9:41 PM, Gabor wrote:
>
>
>
> > On Jan 24, 3:32 pm, Trygve Laugst=F8l<tryg...@inamo.no> wrote:
> >> Hello!
>
> >> I'm trying to get the following snippet to work and I'm 1) wondering
> >> what's wrong and 2) wondering if I'm going about this the right way.
>
> >> I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz)
> >> which control the CPU and the output to the LCD (obviously enough). Wh=
at
> >> I want to happen is that the CPU will set trigger on the leading edge =
of
> >> the CPU clock and clear it on the falling edge of the LCD clock (which
> >> should ensure that it has been picked up by the 'main' process).
>
> >> The error message I'm getting is "statement is not synthesizable since
> >> it does not hold its value under NOT(clock-edge) condition".
>
> >> The code:
>
> >> trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
> >> begin
> >> trigger<=3D '0';
> >> if reset =3D '1' then
> >> trigger<=3D '0';
> >> elsif clk'event and clk =3D '1' and output_trigger =3D '1' t=
hen
> >> trigger<=3D '1';
> >> elsif clk_200kHz'event and clk_200kHz =3D '0' then
> >> trigger<=3D '0';
> >> end if;
> >> end process;
>
> >> main: process(...)
> >> if reset
> >> ...
> >> elsif clk_200kHz'event and clk_200kHz =3D '1' then
> >> ...
> >> end if;
> >> end process;
>
> > First, I know of no FPGA that has dual-clocked flip-flops available in
> > the internal
> > fabric. So it's no wonder that the code is not synthesizable.
>
> Hm, I though this should synthesize a S/R+reset flip flop but I guess
> because of the 'event it will become clocks instead.
>
> > Second, 200 KHz is really slow, so you should probably just sample it
> > with the
> > 48 MHz CPU clock and use the sampled signal with another flip-flop
> > delay
> > to detect edges instead of trying to create a dual-clocked process.
>
> How would that work? It is generated from the 48MHz clock already just
> on the outside of the entity.
>
> > Third. It's not clear to me that you are taking care of
> > synchronization properly
> > here. If the intent is for a single event on the CPU clock to create
> > an output
> > that can be sampled at the falling edge of the 200 KHz clock, then I
> > don't
> > see how you will ensure any minimum setup time unless the event was
> > already somehow synchronous to the 200 KHz clock.
>
> Hm, I'm not really seeing the problem but that's probably because of my
> lack of understanding. Could you elaborate or show/point me some code
> that does what I want to do? I've been trying to read up on links from
> searches like "clock synchronization" and "clock domains" but haven't
> found something that really applies to my case (and makes sense to me).
>
> --
> Trygve
Here is how I do it. I cut this from a program and ripped out all the
other code to just highlight the edge detection. Replace TT_B2 with
your LCD clock and add your code where indicated. The function
NegEdge() just ANDs TT_DD with not TT_D to make it clear what the IF
statement is doing. There will be a delay of one to two clock cycles
from the edge of your slow clock before the code in the IF statement
is executed, but with your app, I expect this doesn't matter.
CTPData: process (SysClk, SysRst) begin
if (SysRst =3D '1') then
TT_D <=3D '0';
TT_DD <=3D '0';
elsif (rising_edge(SysClk)) then
TT_D <=3D TT_B2;
TT_DD <=3D TT_D;
-- RD output interface
if (NegEdge(TT_D, TT_DD)) then -- falling edge of TT data strobe
-- This is where you put your LCD code
end if; -- NegEdge(TT
end if; -- elsif (rising_edge(SysClk
end process CTPData;
This approach solves a lot of problems. It gets rid of communication
issues between clock domains and the two FFs handle metastability
issues, which you can still have even though the two frequencies are
locked, the phase is likely not. If you really want to be sure of
dealing with meta stability, combine the two delay FFs and register
that. With only one LUT, 20 ns will be lots of settling time.
Rick
Article: 150493On Mon, 24 Jan 2011 13:17:46 -0800 (PST), Greegor <greegor47@gmail.com> wrote: >On Jan 24, 1:58 pm, Jon Elson <jmel...@wustl.edu> wrote: >> On 01/22/2011 11:10 PM, John Larkin wrote: >> >> > I meant the damage likely *done* by that lab. We'd been speculating >> > how [ Xilinx ] managed to snarl up their software so thoroughly, and >> > whether they will ever get it fixed. I can't imagine why they'd >> > outsource something this important to France. >> >> One word, Alcatel. >> >> Jon > >History > >The formation of Alcatel-Lucent created the world’s first truly global >communications solutions provider, with the most complete end-to-end >portfolio of solutions and services in the industry. > >Alcatel-Lucent combined two entities — Alcatel and Lucent Technologies >— which shared a common lineage dating back to 1986. That was the year >Alcatel’s parent company, CGE (la Compagnie Générale d’Electricité), >acquired ITT’s European telecom business. Nearly 60 years earlier, ITT >had purchased most of AT&T’s manufacturing operations outside the >United States. Lucent Technologies was spun off from AT&T. Lucent was briefly in the FPGA business, Xilinx clones I think. So did the Lucent-Alcatel thing result in Xilinx picking up the French group? JohnArticle: 150494
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Jan 24, 12:21 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Mon, 24 Jan 2011 09:09:42 +0100, David Brown >> >> <da...@westcontrol.removethisbit.com> wrote: >> >> >I find it hard to believe that supposedly educated, intelligent and >> >experienced engineers can post such ignorant xenophobic drivel. >> >> Well, two facts exist: >> >> 1. Their software is a nightmare, and it's costing them business >> >> 2. They are dumping the French operation. >> >> The software is the heart of an FPGA company. The very architecture of >> the chip has to be coordinated with possible compiler strategies. The >> idea of outsourcing anything this important to a group 8 or 9 time >> zones away, working in another language, in a country where it's >> almost impossible to fire incompetant workers, where people take long >> lunches with wine and don't work weekends, just amazes me. > >This is probably a discussion to stay out of, but I want to correct a >misapprehension on your part. I have worked with the French at a >major telecom company and will tell you that they are no more >incompetent or drunk than American workers. The continent does have a >different work culture in terms of leave. They get lots more vacation >than we typically do and they manage to get their work done without >working late nights and weekends. > >Actually I have always thought it very odd that US workers were >willing to take on the burden of completing projects on time and >budget when they have little or no say in the process of setting those >goals. Lets face it. Being willing to work unlimited, unpaid >overtime is something that the majority of workers in the US are >unwilling to do. For some reason engineers seem to be in a class all >by themselves in that regard here in the US. What other professions >are willing to do that? > > >> >Xilinx (or rather, their users and customers) have trouble with the >> >Xilinx software because the Xilinx leadership do not prioritise it >> >appropriately, and (apparently) do not listen to or understand the >> >issues customers have with the software. They alone are at fault. It >> >could well be that the main management fault was to hire a development >> >team that was not competent to do the development - but the problem is >> >their lack of competence, not their nationality! >> >> I'd have been equally surprised had they outsourced anything this >> core-critical to any other country that far from San Jose. Big >> Software is nearly impossible to manage even without an ocean in the >> way. > >Distance doesn't create problems in management... management creates >problems in management. I've worked on projects where no two people >were in the same city and they progressed well, except for the >management which kept feeding lies upstream in order to tell them what >they wanted to hear. I guess one difference is that it is a bit >harder to manage by "walking around", something upper management >should do. Then they can find out things that they aren't being >told. > >But none of this has to do with nationality. > >Rick http://www.eetimes.com/electronics-news/4212317/Xilinx--sales-fall-short-of-estimates "Xilinx recorded $4.3 million worth of restructuring charges during the recently concluded quarter. Olson said the charges were greater than expected because the company is closing its software development operation in France, where regulations make eliminating jobs difficult." JohnArticle: 150495
On Jan 24, 12:23=A0pm, Gabor <ga...@alacron.com> wrote: > On Jan 24, 1:50=A0pm, ghelbig <ghel...@lycos.com> wrote: > > > > > > > I think that iMpact is messing with me. > > > Here's what I do: > > > 1) Create a bit file with ISE 11.5 > > 2) Downloading the bit file to my Virtex-5 via JTAG. =A0(I'm using a > > DLC9G and WinXP) > > 3) Run a regression test on the system. > > > If the regression test passes I do the following: > > > 4) Create a MCS file with iMpact. > > 5) Load the MCS into the attached SPI chip (again, with the DLC9G) > > 6) Power cycle the board. > > 7) Re-run the regression test. > > > Here's my issue: > > > I have two bit files for this project. =A0One was created last month, > > one was created last week. =A0The steps above are repeated EXACTLY for > > the two bit files. =A0There are no warnings or errors generated with > > steps 2 through 6. > > > Step 7 fails for one bit file, and passes for the other. =A0With one bi= t > > file, and chip never leaves the DONE state. =A0Keep in mind that both > > bit files load and run "just fine" when I load them through the JTAG > > port. > > > Has anyone seen this before? =A0I haven't gotten any help from the > > factory yet. > > > Regards, > > G. > > The first thing I look for is whether the .mcs file was really created > correctly. > I have been burned by the ISE GUI grabbing an existing impact project > that > built a new .mcs file from an old .bit file. > > If you look in the directory where the .mcs file was built, there > should also > be a .prm file with the same base file name. =A0In this file you can see > the > name and modification date of the .bit file(s) that were used in > creating > the .mcs file. > > Also I have had some issues with indirect SPI programming using > impact. =A0However usually these show up as an error when you go to > verify the .mcs file in SPI flash. =A0When you say "never leaves the > DONE state" do you mean that DONE never goes high? =A0Or does > DONE go high, but the chip never comes out of reset. =A0The latter > condition can be bitstream-dependent although I've never seen > this behavior when using Master-SPI config mode. =A0Just be sure > that you use the default startup clock (CCLK) when you run > BitGen. > > -- Gabor It is the "DONE goes high, but the chip never comes out of reset" case. It seems to be bit-stream dependent, I can make good MCS files from old BIT files. I'm stumped. The only thing I can see different in the two cases (works, does not work) from start to finish is the Verilog code. G.Article: 150496
Le 24/01/2011 20:51, rickman a écrit : > This is probably a discussion to stay out of, but I want to correct a > misapprehension on your part. I have worked with the French at a > major telecom company and will tell you that they are no more > incompetent or drunk than American workers. The continent does have a > different work culture in terms of leave. They get lots more vacation > than we typically do and they manage to get their work done without > working late nights and weekends. Thanks Rick. Working late nights happens sometimes, though. (and now I'll stay out of the discussion but will keep watching with great interest since I happen to be French) NicolasArticle: 150497
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com> wrote: <snip> >This is probably a discussion to stay out of, but I want to correct a >misapprehension on your part. I have worked with the French at a >major telecom company and will tell you that they are no more >incompetent or drunk than American workers. The continent does have a >different work culture in terms of leave. They get lots more vacation >than we typically do and they manage to get their work done without >working late nights and weekends. > >Actually I have always thought it very odd that US workers were >willing to take on the burden of completing projects on time and >budget when they have little or no say in the process of setting those >goals. Lets face it. Being willing to work unlimited, unpaid >overtime is something that the majority of workers in the US are >unwilling to do. For some reason engineers seem to be in a class all >by themselves in that regard here in the US. What other professions >are willing to do that? > this is definitely a sore point for me. We all have our 'Project from Hell' and mine involved a French company. The company that hired me had a contract to develop and install some new technology. The customer hired a French company to verify that we met the contract requirements. Now, we were doing things that, to this point, no one had done before, and the best part was that none of us had ever even worked in this INDUSTRY before. We didn't know what couldn't be done! Now, the interesting thing about the French company, was how they kept 'interpretting' the contract requirements, and asking for tests that I realized had nothing whatsoever to do with the project we were working on. They were taking all our results and technologies, including our software, and just shipping it to the home office to use in their own projects! Now, the real reason it was the project from hell, was that the management was ALL ex-military. They had very little technical expertise, and they seemed to feel that success required only two things - their orders to get something done, and sufficient effort on our part to follow their orders. It was common to work seven days a week, 10 to 12 hours a day, and they were chewing us out daily that we were behind schedule! The truth was, all of the workers were so burned out that we could barely think, much less be creative and solve problems as they came up. I remember coming in one morning, and noticing a co-worker (who was one of their darlings. It was rumored that he worked so late that, when he went home, he slept in his car because he was too tired to climb the stairs. He got up at 6, went up and showered and changed, and then went in to work!) Anyway, I noticed that he was typing up a test procedure - click... click... click... click at about one letter a second. He was dead on his feet, and it was only 7:30 in the morning! They laid me off just before the end of the project - I wasn't putting in enough effort! I was only working 65- 70 hours a week! CharlieArticle: 150498
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >Distance doesn't create problems in management... management creates >problems in management. I've worked on projects where no two people >were in the same city and they progressed well, except for the >management which kept feeding lies upstream in order to tell them what >they wanted to hear. I guess one difference is that it is a bit >harder to manage by "walking around", something upper management >should do. Then they can find out things that they aren't being >told. > Actually, distance DOES create problems in management, and modern management techniques are not very effective. The ability to manage a distributed workforce is a very rare talent. Among the requirements, is enough technical skill to be able to divide the task into appropriate pieces, and have the ability to make sure that all the system requirements are complete, and that they are being met by each member of the team. It also requires the right sort of project, where inter-member interaction is only needed for specific tasks, and not for just general co-ordination... CharlieArticle: 150499
On Mon, 24 Jan 2011 16:06:46 -0800, Charlie E. <edmondson@ieee.org> wrote: >On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com> >wrote: > > >>Distance doesn't create problems in management... management creates >>problems in management. I've worked on projects where no two people >>were in the same city and they progressed well, except for the >>management which kept feeding lies upstream in order to tell them what >>they wanted to hear. I guess one difference is that it is a bit >>harder to manage by "walking around", something upper management >>should do. Then they can find out things that they aren't being >>told. >> > >Actually, distance DOES create problems in management, and modern >management techniques are not very effective. The ability to manage a >distributed workforce is a very rare talent. Among the requirements, >is enough technical skill to be able to divide the task into >appropriate pieces, and have the ability to make sure that all the >system requirements are complete, and that they are being met by each >member of the team. It creates problems but it certainly can be done. I worked on the processor Apple used in its G5 PowerMacs. About a quarter of the processor was done in Germany, a little in Texas, and we did the rest along with all the chip integration. It worked out very well but as you say, the system requirements were very well laid out and the project was divided by functional unit. >It also requires the right sort of project, where inter-member >interaction is only needed for specific tasks, and not for just >general co-ordination... That certainly helps. Basically it's broken down into smaller projects, each more or less independent. BTW, we tried to bring on some people in India. A lot of effort was spent coordinating the project and no results were ever seen from them. It takes the right people, too.
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