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
Subroto Datta wrote: > Hi Big, > > We'd like to hear your view about how Quartus can be made better for > your needs. > Always like the topological display of VHDL modules in other tools like ispLever or Actel's Libero... It is painful to import a VHDL design into Quartus and manually arrange the file order... Ah yeah..when is Altera striking with a free Linux version? (o; rickArticle: 81426
Very nice Antti! No need to resort to LFSRs after all. Next, we're all looking forward to a (slow) compact nybble serial MicroBlaze reimplementation. :-) Jan GrayArticle: 81427
There is a simple work around for the libcurl problem with the 7.1 installer, just link the newer libcurl library to libcurl.so.2. This will allow you to install 7.1. ln -s /usr/lib/libcurl.so.3.0.0 /usr/local/lib/libcurl.so.2 Once installed the CLI tools work fine however the ISE GUI has a number of problems. The first thing that happens is an RPC error, Cannot register service: RPC: Unable to receive; errno = Connection refused unable to register (registryProg, registryVers, tcp) Wind/U Error (248): Failed to connect to the registry on server wasp.bjrosen.com Cannot register service: RPC: Unable to receive; errno = Connection refused OLE API Function OleInitialize is not currently implemented. Further warnings will be suppressed I'm guessing that this is a kernel issue, FC3 uses 2.6.10 while RHEL3 uses the ancient 2.4.21 kernel. Does anyone know a work around for this, is there something that needs to be compiled into the 2.6.10 kernel? More seriously the file browser doesn't work, you get a path name to long error if you try to access anything that is outside of the local directory. However you can work around this by typing in the explicit paths to open files. If you open an existing project things work fine. I use HDLmaker to build my Xilinx projects, the 7.1 tools work fine with HDLmaker built projects. http://www.polybus.com/hdlmaker/users_guide/Article: 81428
Matthias Alles wrote: > Hi! > > I want to store the program code for the Microblaze processor in my > serial configuration Flash and use a bootloader to copy it to the > external memory. Is there an OPB component available that connects to > the serial Xilinx Flash, when the Flash is connected to the FPGA like on > the Spartan3 Starter Kit Board? You can use general purpose I/O and do bit twiddling in software. It's a bit strange solution in an FPGA, but you do not need to add your own hardware to the OPB. Kolja SulimmaArticle: 81429
You need portmap installed and started. Then the browser will work fine.Article: 81430
Hi Jan I've wondered about how trully RISC PPC really is. Ironic that it comes out of the work of John Cocke and the 801, the current PPC seems to be RISC in actual performance but much harder to describe than other RISCs esp DLX, MIPS or ARM. RISC ISAs are always characterized by the target technology on which they are 1st implemented, hence poor FPGA efficiency unless thats where you/we start. If IBM were starting today on a fresh ISA with the memory wall in mind (100s of dead cycles per cache miss), I would think/hope they would come up with something entirely different. I would suggest that RISC ness could well be defined by how easy it is to build an ISA simulator and how close that runs to the hosting platform. The closer it runs to host, the less peripheral things the ISA must do per opcode. Clearly PPC, ARM, SPARC all do alot more than simple datapath operations but all are defined with specific HW features in mind so their soft cores are all big to start. The PearPPC emulator that runs on x86 to allow running MacOSX supposedly runs about 500 x86 ops per PPC op (from Pear site). The 68K emulators seem to run far closer to x86 performance perhaps because they are far "simpler" to understand. Generally the goal of emulation is to reach about 10x slow down. PearPC only achieves better performance closer to 50x slower IIRC through use of a JIT but the 68K JITs are still far better. It amuses me to think that an emulated 68K running MacOS7 must run orders faster (acceptably so on Basilisk) than an emulated PPC running the much heavier OSX, just where is the world going! The new Transputer also runs its ISA simulator closer to host speed (60x slower in plain C). Perhaps I should have started with the approach to build fastest possible ISA encoding with x86 native asm simulator in mind but it wouldn't much effect final HW architecture, just encodings. Perhaps really fast emulation of new ISA should be at top of todo list of architects to help propagate new cpus, certainly to get something running ASAP. regards johnjakson at usa dot comArticle: 81431
lecroy, Regardless of what any piece of paper claims, it is the memory of many here that the only way to recover is by powering down. As a 15 year old problem, it is one that we only have our (failing) memories to rely upon. There was no answer database in those days. There was no hotline. Austin lecroy7200 wrote: >>The oscillator itself is at a much higher frequency, and is divided down >>to the number listed in the data sheet. At least, we still do it that >>way, even today. > > > This is not what the data sheet states. The 4000 data sheet makes a > distinction that it runs at 8MHz and divides down to the 1MHz where the 3000 > is at 1MHz. I am not disagreeing with you. I believe that the 3000 was > changed overtime and the clock was part of these changes and now runs at > around 16MHz. The documents were never updated to reflect this change > because it was "transparrent" to the end user. Of course this is all a > guess on my part. > > >>The accuracy of this oscillator would be from 1/2 to 2X the nominal (it >>just isn't critical). > > > Agree, it just needs to work. Too bad it seems to have problems. > > >>Since this part still had paper schematics (REALLY) it is far too old >>for us to go look at its design. > > > Funny, we can still pull up our paper documents if needed. I agree, its > not fun but sometimes you just have to roll up your sleves and dig in. > > >>Phil is on the right track. >> >>This part did have a brownout issue (if the the voltage dropped just >>right, for just the right amount of time, and came back up) that would >>place it in a locked state that could not be recovered until the power >>was cycled. > > > Again, I read Xilinx's app. note on the brown out problem and it makes it > clear that the part can be reset without removing power. I don't disagree > that the internal logic could get into a locked state and that there was not > a problem with brown out. I also think it is very possible that the current > devices being sold could have a second problem with the internal oscillator. > There is no mention anywhere about the oscillators failing to start or > locking up in the brown out app. note. I am sure if Xilinx would have known > this, it would have been documented and the power cycle requirements would > have been called out, which they are not. > > >>I solved this problem 15 years ago by using a Dallas Semi Power on Reset >>part to reset the power supply if it detected a glitch. > > > Again, power cycling the device, no matter how it could be done, is not an > option for this system. > > It sounds like Xilinx is not willing to dig into the root problem of the > oscillator. I can understand this to some degree. After all the software > has not supported the device in several years. So my next question is if > you are able to tell me if the oscillator design used in the currently sold > 3000s is being used in other Xilinx devices? > > > > > > > > > > > > > > > >Article: 81432
lecroy, If repowering the device will return the part to a state where it can be programmed, then I have to say it is a bad device. Trying to infer the operation by sniffing for a oscillator that is the wrong frequency sounds suspicious. Austin lecroy7200 wrote: >>>Do you recall how low the Vcc had to cycle, in order to correctly > > recover ? > >>As I recall, it had to go below 150 mV to 300 mV to recover. >> > > After testing the second failure, I tried the power cycle test again. The > second part behaved the same as the first. Removing power from the device > and shorting the supply (much less than 150mV) for over 1mS would not cause > the oscillator to restart (observing it with the spectrum analyzer). > > > > > > > >Article: 81433
On Wed, 23 Mar 2005 16:13:45 +0100, Sylvain Munaut wrote: > You need portmap installed and started. Then the browser will work fine. Portmap is installed but it's dead. When I do a status on portmap I get Executing /etc/rc.d/init.d/portmap status .. portmap dead but subsys locked Any ideas about how to get portmap to work?Article: 81434
> lecroy, > > If repowering the device will return the part to a state where it can be > programmed, then I have to say it is a bad device. Austin, not to make fun of the situation, but I really have no idea what you are trying to tell me in this statement. > > Trying to infer the operation by sniffing for a oscillator that is the > wrong frequency sounds suspicious. > > Austin I am sorry, but again I must be missing something. Are you stating that you don't believe my test results and that looking at the devices internal oscillator with a spectrum analyzer is not a valid test??Article: 81435
Hi folks, This question is aimed at those who have created designs including DSP using a device family containing dedicated arithmetic silicon (e.g. Xilinx DSP48/18x18s/Altera DSP blocks): On what % of designs you have completed did you run out of dedicated arithmetic blocks and have to implement filters in the main logic fabric? Thanks very much for your time, KenArticle: 81436
Well, it's not just any piece of paper, it's the Xilinx published papers. I agree, it does appear that the documents for this device were not kept up. I don't know if the problem is 15 years old or not. Is it tied to when the oscillators frequency was changed to 16MHz, it is possible. I am guessing that this happend after 1997 when the 4000 data sheet I have was published. Again, its all a guess on my part. Xilinx would need to answer this. The problem now is how to prevent it with the next design. The first step is to determine if the design used for the currently sold 3000 series oscillators was used in other devices. If so, I plan to stay clear of these.Article: 81437
Hi, You did not say which version of ISE you were using but I have had it working for version 4.2, 5.1 & 6.3. I have a few things for you to check: (1) Have you created an Implementation constraints file (.UCF) and is it associated with the top level of your design? It should appear as a "U" module immediately below (and indented) your top levels "V" entry in the "Sources in Project" list. If not add new source of type "implementation constraints file"....... (2) Uses the Edit Constraints(text) option in the processes list (in the "User Constraints section) you should see some lines like... NET "ssg<0>" LOC = "E14" ; NET "ssg<1>" LOC = "G13" ; NET "ssg<2>" LOC = "N15" ; NET "ssg<3>" LOC = "P15" ; NET "ssg<4>" LOC = "R16" ; NET "ssg<5>" LOC = "F13" ; NET "ssg<6>" LOC = "N16" ; NET "ssg<7>" LOC = "P16" ; where "ssg" is the name of the signal in your top level entity declaration. You can put the lines in the UCF manually, the definitions are in the examples on Digilent's web site. Hope this helps, TimArticle: 81438
Hey Ken, It's often the other way round for me, sometimes I'd run out of fabric and BRAMs for distributed arithmetic DSP unless I used the multipliers for boring 'normal' DSP. Of course, all my designs are carefully planned, so I never actually run out of resource. Ahem. Anyway, why do you ask? Cheers, Syms. "Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message news:d1s68b$u73$02$1@news.t-online.com... > Hi folks, > > This question is aimed at those who have created designs including DSP > using a device family containing dedicated arithmetic silicon (e.g. Xilinx > DSP48/18x18s/Altera DSP blocks): > > On what % of designs you have completed did you run out of dedicated > arithmetic blocks and have to implement filters in the main logic fabric? > > Thanks very much for your time, > > Ken > > >Article: 81439
lecroy, No one changed the frequency of any oscillator. The layout has been shrinking so as to be able to be fabricated, that is all. Did the oscillator go from 8 MHz to 16 MHz over this period of time? Maybe. But, for you to infer something from a 16 MHz signal is suspect: does failure to configure 100% correlate with this signal? If you power it down, and back on, can it be reprogrammed? If not, it is a bad part. If it can be reprogrammed, then it is a good part (as far as configuration is concerned). If you have a case open with the hotline, what have they said, and what are they doing? If you do not have a case open with the hotline, then you should have one open. Austin lecroy7200@chek.com wrote: > Well, it's not just any piece of paper, it's the Xilinx published > papers. I agree, it does appear that the documents for this device > were not kept up. > > I don't know if the problem is 15 years old or not. Is it tied to when > the oscillators frequency was changed to 16MHz, it is possible. I am > guessing that this happend after 1997 when the 4000 data sheet I have > was published. Again, its all a guess on my part. Xilinx would need > to answer this. > > The problem now is how to prevent it with the next design. The first > step is to determine if the design used for the currently sold 3000 > series oscillators was used in other devices. If so, I plan to stay > clear of these. >Article: 81440
Jeremy Stringer wrote: > Preben Holm wrote: > >> can anybody tell me the real difference between >> - behavior (guess this is pure VHDL) > > > This is purely behavioral - it literally just simulates what the VHDL > describes, without any device-specific timing or anything. > >> - post-translate (guess this is after synthethis) >> - post-map >> - post place and route (guess this is when the design is "final" and >> is known where to be put in the FPGA) > > > Post place-and-route simulates the behavior with timing, after the > design has been fitted into the device. I assume that post-map and > post-translate just have less, or less accurate, information (I don't do > these type of simulations). > > As an example: > > foo: process(clk) > begin > if rising_edge(clk) then > if rst = '1' then > dout <= '0'; > else > dout <= din; > end if; > end if; > end process foo; > > In a pure behavioral simulation, dout would change exactly on the clock > edge. In a post place and route simulation, it wouldn't - it would take > into account the delay of the flip-flops, and also the routing delay > from the output to the next input - this might be, say, 5 ns later. > > Jeremy Post-map also takes care of some delays - but which ones. I can't use the post place and route, cause I can't count on this, when I don't simulate the whole design since the routing will not be correct?Article: 81441
> No one changed the frequency of any oscillator. I will see if I can locate one of the pre 97 devices to verify this. We may some some in stock in our area. I will let you know what I find. > The layout has been shrinking so as to be able to be fabricated, that is > all. Did the oscillator go from 8 MHz to 16 MHz over this period of time? > Maybe. > But, for you to infer something from a 16 MHz signal is suspect: does > failure to configure 100% correlate with this signal? Well, there is certainly nothing that prevents Xilinx from running their own tests to validate what I am seeing. I certainly can not force them to do so. I am 99.9% confident that the 16MHz is from the 3000's internal oscillator and that this is the fundimental frequency. I see this signal on every working device and no where else. It is a very loose frequency, it tracks with the individual device's temperature and it has the most energy from my sweeps. So far there is 100% correlation of the failure, but we are only talking one data point. I can also tell you that once I reset the power that the 16MHz signal for that device was present (again which it was not while in this failed state) and the part began to function normally. The oscillator locking fits with what I am seeing, not being able to reprogram the devices. > If you power it down, and back on, can it be reprogrammed? Again, this depends what you mean. Looking at the power on the device, I can bring it below what I can detect for over 1mS and turn it back on and the part will not allow me to reprogram it. Nor will the oscillator start running. I have to remove power for a much longer time in order for the oscillator to start and allow me to reprogram. This appears to be the case with all six failures I have seen, in that they need the power removed for several seconds inorder to recover. > If not, it > is a bad part. If it can be reprogrammed, then it is a good part (as > far as configuration is concerned). Agree. Again, out of the six times I have now seen this, the failure has not appeared to cause any damage to the devices. > If you have a case open with the hotline, what have they said, and what > are they doing? I am not so sure this is the place to discuss this. If you want the persons name I have been in contact with, or the case number feel free to send me a direct e-mail. During the first contact I was asked if I was the person posting in this forum, to which I responded yes. I explained in detail what I knew at the time, including providing exact part numbers and lot codes for the parts I was testing. I was told by the person I spoke with that this was outside what the hotline could handle and that it would be elevated to a higher group and that they would get back with me. I continued to work on the problem and made the comment in one of my postings about not yet hearing back from Xilinx. That same night I received and e-mail from the hotline as follows: "It's been a few days since we last communicated, and I wanted to check in. Since this device isn't officially supported by the hotline any longer, I'm having to do a fair amount of work to find any information on it here. I'll keep investigating this, and I'll let you know when I come across anything that hasn't been tried already according to the suggestions on comp.arch.fpga." Later after reproducing the failure I tried to contact the support group and left a voice message stating what I had found and asked for them to return my call. After I did not hear back from them for several hours I continued my testing. Once I discovered the oscillator problem I again tried to contact support and left a second voice mail. Again, there was no return call. On my third attempt I finally spoke with my original contact and was told that you were the expert at Xilinx and that your posting about the part being designed on paper was correct and that there was nothing they could do. Google groups was down that day and I was not able to read your posting, so they forwarded me your post. I still have the case number open, and if I learn anymore about the problem I will try and contact them again. So, now that we have established you as being the expert at Xilinx the question becomes if you can help. I am setting up one more test to determine the state of the program/done pin prior to attempting to reprogram the device after the failure. I will publish these findings once I have them. Also, if I am able to locate an older device and test it, I will publish what I find on the internal oscillator.Article: 81442
> Hey Ken, > It's often the other way round for me, sometimes I'd run out of fabric and > BRAMs for distributed arithmetic DSP unless I used the multipliers for > boring 'normal' DSP. Of course, all my designs are carefully planned, so I > never actually run out of resource. Ahem. > Anyway, why do you ask? > Cheers, Syms. Hi Syms, Thanks for your reply. The general consenus as far as I am aware seems to be that designers will want to use dedicated FPGA silicon blocks that will accomplish a given task before implementing such tasks on the generic fabric. I am just curious to see exactly how designers are using the "lego blocks" they have available to them hence I thought I would see what the inhabitants of this ng do. Cheers, KenArticle: 81443
John_H wrote: > The next Thursday March 11th is in the year 2010 so I figure you mean March > 24th as it says in the link :-) I hope the talk is informative (for a > reasonable engineer). Whoops, that was quite the typo! Yes, I meant Thursday, March 24. Although 2010 would certainly give me lots of time to prepare :). Hope you enjoy it. Regards, Vaughn [v b e t z (at) altera.com]Article: 81444
lecroy7200@chek.com wrote: <snip> > So far there is 100% correlation of the failure, but we are only > talking one data point. I can also tell you that once I reset the > power that the 16MHz signal for that device was present (again which it > was not while in this failed state) and the part began to function > normally. > > The oscillator locking fits with what I am seeing, not being able to > reprogram the devices. I would expect (generally speaking) a Config Ring osc to gate itself off, after config is completed. What does a normally operating device show - does this osc appear to gate in normal usage ? > > >>If you power it down, and back on, can it be reprogrammed? > > > Again, this depends what you mean. Looking at the power on the device, > I can bring it below what I can detect for over 1mS and turn it back on > and the part will not allow me to reprogram it. Nor will the > oscillator start running. I have to remove power for a much longer time > in order for the oscillator to start and allow me to reprogram. This > appears to be the case with all six failures I have seen, in that they > need the power removed for several seconds inorder to recover. It may pay to get a closer number on that - < 5 seconds and > 1ms is quite wide... Most vanilla buried POR cells are RC in nature (tho the R may be a FET ), and they will have a TIME as well as a voltage requirement for reset. Austin has given ~150mV-350mV region as voltage, but no one have a time value yet. You could ask Xilinx explicitly if newer devices have any buried POR cells, that are not also replicated by a RESET ? I would expect this type of oops to be eliminated :) -jgArticle: 81445
Well that begs another question. I am a post DOS Xilinx user. I understand that DOS is still being supported and I am a bit of a DOS dinosaur myself. So does it behove me to start making batch files and processing stuff using DOS batch files?Article: 81446
B. Joshua Rosen wrote: > Once installed the CLI tools work fine however the ISE GUI has a number > of problems. The first thing that happens is an RPC error, > > Cannot register service: RPC: Unable to receive; errno = Connection refused > unable to register (registryProg, registryVers, tcp) > Wind/U Error (248): Failed to connect to the registry on server wasp.bjrosen.com > Cannot register service: RPC: Unable to receive; errno = Connection refused > OLE API Function OleInitialize is not currently implemented. Further > warnings will be suppressed > > I'm guessing that this is a kernel issue, FC3 uses 2.6.10 while RHEL3 uses > the ancient 2.4.21 kernel. .. This smacks of an issue with Bristol's Wind/U Windows emulation on Unix/Linux (http://www.bristol.com/crossplatform/). If I'm not mistaken, you may need to do more research on how Bristol's libraries are resolving their linking issues. 'ldd' and 'nm' may help you on this path. I don't think it has anything to do with the kernel, but then again I don't know for sure since I don't know from a source code point of view. -HerbArticle: 81447
way back when i was using bristol, process 'scm' had to be online for OLE to do anything. i don't know what's going on today, or if bristol elimated the scm process (which I had heard from the engineering dept) in favor of other methods. another suggestion you could use is install on a RHEL3 system and do some comparisons process and other wise. i don't know why you want FC3 to work so bad, since you will probably spend a lot of time trying to get it to work while your design schedule lags. for some reason too you've fixated on the "kernel". you may want to run the kernel config utility to see what the hell is really in the kernel, and make it less of a mystery. you will find it just adds support for new hardware devices, a few file systems and the like, and nothing to do with the issues you are having. also consider running strace so you can see your software stack. -HTArticle: 81448
lecroy, I have found the case, and the CAE assigned, and I am working with Peter to resolve this. So, your support for this issue is now Peter Alfke and Austin Lesea. All I can say is that if we can't help you, then no one can, so you can not complain about not getting the best resources assigned to the job! Basically, as an officially usupported part (end of life, last time buy status, etc. ...), we will do what we can. Peter and I are the only ones here who remember anything about the XC3000. The hotline was unable to follow through on this due to the age of the part, and the total lack of information on it. In future, we will provide the hotline for a way to deal with this other than just getting frustrated. I apologize for that on the part of Xilinx. It is a situation that we had not anticipated (support of an obsolete product). I suggest we move this off of this forum. AustinArticle: 81449
Hi Jedi, > Always like the topological display of VHDL modules in other tools > like ispLever or Actel's Libero... Can you expand on this? Haven't got the slightest idea what you mean. I'm envisioning a Mercator projection of desing blocks on a map... > It is painful to import a VHDL design into Quartus and manually > arrange the file order... Yep. Dunno whether there's work on this, but you're right, doing a 2-pass parse/compile/elaborate would be handy. Then again, this would mostly make sense when building a project for the first time. Maybe something for the New Project Wizard. > Ah yeah..when is Altera striking with a free Linux version? (o; I'm pushing for this as well. Would you be OK with a GUI-less version? (anyone interested raise their hands!). Altera pays royalties on the GUI under Linux and Solaris, so if you can get by without a GUI, Altera can truly ship something free. Best regards, Ben
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