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 May 29, 3:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: > On May 29, 1:47 pm, doug <x...@xx.com> wrote: > > > > > jleslie48 wrote: > > > On May 29, 10:52 am, doug <x...@xx.com> wrote: > > > >>>I haven't mentioned jitter because I simply do not know. As I'm > > >>>working with a relatively slow clock of 2MHz, I can't believe that > > >>>jitter is an issue. I'm synching a RS485 signal if that answers the > > >>>question. > > > >>I am puzzled. If all you want to do is decode a serial signal, why > > >>not just decode it with a higher speed clock as is done in a > > >>regular UART? If you are sending, you can generate a clock within > > >>the tolerance of the other receiver without any trouble. > > > > this is how I DECODE the serial signal. I'm not trying to decode it > > > at this time, but rather have my fpga repeat the signal with no phase > > > difference when the signal is lost. > > > I see the requirement now. Decoding the signal and retransmitting it > > makes it easy to deal with loss of signal but how do you deal with > > reacquisition of signal and fitting that nicely into a data stream? > > > > The point is my fpga is a middleware layer, and it cannot add any > > > phase difference to the downstream consumer of the signal. I do know > > > know or have control of the end consumer of the data stream. > > > This always makes it harder. > > I've created a semaphore flag to mark who is creating the output > signal to the downstream consumers. If the inbound signal is missing, > I use the internally generated signal. On acquisition of the inbound > signal, I set the semaphore to adjust the output signal to that, and > that [will] trigger this new ~re-sync~ the internally generated signal > to the newly aquirred inbound signal. Should the inbound signal then > be lost, the internal signal will have already been set up to the > exact phase of the last known inbound, and so the downstream device > should be unaware of the difference (plus or minus a few clock > pulses.) The idea is if the loss of signal is due to a wire > disconnect, when the user reconnects the wire, everything is the > same. If he has re-cycled the power on the producer, well then the > act of re-acquisition of will reset the internally generated signal > for the new rs485 signal. Is this clock a sine wave or a digital clock? I see people talking about using a DDS with ROM and DAC to generate a sine wave. Is that what you need or is this just a digital problem? I am also working on a similar problem. It is actually detecting a clock within the data, but the same problem, to continue the clock with minimal change in phase when no transitions are present in the data. You need to spec what time duration you expect this to work over. Unless both producers of the clock signal are running from a common reference clock, there will always be some slip in phase since the frequencies are not exactly the same. When the input returns, you need to make sure the internal DCO (digitally controlled oscillator, no ROM table to generate a sine wave) adjusts slowly so the downstream device is not upset by the wide frequency changes. But that is a matter of specification. The part of this which may be subtle is the design of the PLL, in particular the filter. This determines the response of the PLL to changes in the input and how stable the output will be. I am still working to prove that my design is stable for all inputs (input being not just the input to the board, but the input after it has been synchronized which produces some modulation). RickArticle: 140926
On May 28, 3:44=A0pm, iammay...@gmail.com wrote: > > ST said that it was redeploying approximately 1,000 engineers, > representing 10 percent of ST=92s R&D workforce, from non-core programs, > including FPGA and third-party design services, and from CPE modem and > GSM chipset activities > There was also a speculation that ST may spin off GOSPL in a > management buy out, or sell the operation to an FPGA company. If an existing FPGA company buys the GOSPL project, it will be to bury it. > Interestingly ST has been part of the Morpheus collobarative research. > It has recently compe up with the first prototypes of the Morpheus > chip. Chances are high that ST has transformed GOSPL into Morpheus. Morpheus is a lot more than just an FPGA. It includes a reconfigurable instruction set processor (RISA). Personally, I feel that is a bit of, "so what". I can almost guarantee that a RISA processor will get two or three standard configurations because of the costs associated with designing your own instruction set. Maybe I am missing something important about this, but I think it would be a better chip with some sort of minimal instruction set processor (MISC). Morpheus is a multi-partner development effort according to the reports. I can't imagine that this is going to be a rousing success. There are just too many cooks to spoil the pot. RickArticle: 140927
On May 29, 2:57=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > Weng Tianxiang wrote: > > I don't like to print download version of many documents. The download > > prints are huge and not easy to keep them in order. > > http://www.google.com/search?q=3Dkindle+dx Hi Mike, I know you are not kidding, but after I saw the search result, I immediately realized it may be a good idea some years later after the electronic reader is maturized. Otherwise it would be replaced every 2 or 3 years like PC. WengArticle: 140928
On May 29, 12:29=A0pm, rickman <gnu...@gmail.com> wrote: > On May 28, 11:07 am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > Hi, > > I don't like to print download version of many documents. The download > > prints are huge and not easy to keep them in order. > > > So that I bought Virtex-4 FPGA Handbook for $10 years ago, and I want > > to buy Virtex-5 FPGA Handbook too, but cannot find the related > > information. > > > I also want to buy Altera's Data Handbook. > > > I will appreciate if anyone can pose the website for these books if > > they are available. > > > Thank you. > > > Weng > > Chip makers stopped printing manuals years ago. =A0You can often get > flyers and short brochures from salesmen, but otherwise, it is all > electronic. =A0I think it was some ten years ago that I asked a salesman > for a printed copy and he printed it off on his printer. =A0At that > point I gave up and came over to the dark side... > > I still like my magazines in print. =A0It is hard to drag the keyboard > and monitor into the ... uh, reading room. =A0But even those are getting > smaller with links to "the complete article" on the web. > > Rick- Hide quoted text - > > - Show quoted text - Hi Rick, I have 4 versions of handbooks from Xilinx: Virtex II Platform FPGA Handbook (v1.0), publishing date: 12/06/00; Virtex II PRO Platform FPGA Handbook (v2.0), publishing date: October, 14, 2002; Spartan-3 Platform FPGA Handbook (1.0), publishing date: July 11, 2003; Virtex-4 Platform FPGA Handbook (v1.0), publishing date: 08/02/04. They are priceless data resources and the windows to look into Xilinx's technology develop progression. It is very impressive to me that all books have no ISBN number and all Xilinx handbooks have no entries in Amazon website, it means all handbook owners don't want to sell any of them on second book markets. WengArticle: 140929
"Mike Treseler" <mtreseler@gmail.com> wrote in message news:78b42pF1lj91bU1@mid.individual.net... > Weng Tianxiang wrote: > >> I don't like to print download version of many documents. The download >> prints are huge and not easy to keep them in order. > > http://www.google.com/search?q=kindle+dx A not unreasonable alternative today is to take the same $500 and buy a good double sided network printer (HP P2015N) and a 19 ring comb binder. OTOH, I might be just sore that I spent my $500 and did just that. For sure, either way is faster, more convenient, and overall cheaper than sending every document to Kinkos for printing. I have a few reservations about the Kindle DX. If you have one and use it for, specifically, Xilinx and similar other PDF documents, can you fill me in on how well it's working for you? I'm mostly interested in comparing ease of use to printed, letter size documents. Is the screen a full letter size page in size? If not, is it reasonably easy to zoom and navigate? How easy is it to download your documents to the device? Can you at least minimally search the document for specific text? Does it work well with the PDF table of contents and bookmarks? I'm not especially keen on the wireless service charges, and would prefer to focus on its equivalence to a printed page. Thanks.Article: 140930
"Marteno Rodia" <marteno_rodia@o2.pl> wrote in message news:6be75ef1-0259-4bd4-bdc7-96fe12669295@3g2000yqk.googlegroups.com... > Hello, > Again I encountered (or, more precisely, my colleague) some problem > with Xilinx. As far as I understand what he is trying to do, he wants > to synthesize two different cores into one system. The problem is that > during synthesis ISE throws out some pins of one core, which are, > however, necessary because they feeds inputs of the other core. > > How could this happen? If some (or all) of the outputs of core #2 do not make it to physical output pins of the device then it is quite possible that some of the inputs to core #2 can disappear. If those core #2 inputs happen to come from outputs of core #1 and those signals do not happen to go anywhere else, those will get optimized away as well. To put it more simply, those signals between core #1 and #2 that you think 'should' be there, do not in fact effect the value of any physical I/O pins of the device...therefore they can be removed and the behaviour of the device will not be affected. Second guessing the synthesis tool is usually a pointless exercise, the tool is correct in it's analysis of your logic very, very often. > Any tips? Run a simulation of the whole design. > What should we check? > That the output of the simulation matches what you expect. As 'MM' pointed out, the subject line of your post will not help you...consider not slamming others just because of your frustration. Kevin JenningsArticle: 140931
On May 29, 11:24=A0pm, gert1999 <ggd...@gmail.com> wrote: # Reply to jg: it is strange but it makes a difference. =A0I've been # reading lot's of pdf-files that are available on the web and I found # one of them (kind of quick start example) emphesises "make sure you # add the following timing constraints" Did you compare the fitter report files ? Are you saying SOME files work without adding the constraint, and some need it added ?. How loose can it be ? Xilinx CPLD flows are not the main testing area, so if you've found context-dependant quirks, I'd feed some examples back to Xilinx. -jgArticle: 140932
Considering a lot of xilinx employees post on this group, it's probably not too smart to tell somebody you don't like them and then expect that same person to help you. Just my $0.02. On May 29, 6:22=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Marteno Rodia" <marteno_ro...@o2.pl> wrote in message > > news:6be75ef1-0259-4bd4-bdc7-96fe12669295@3g2000yqk.googlegroups.com... > > > Hello, > > Again I encountered (or, more precisely, my colleague) some problem > > with Xilinx. As far as I understand what he is trying to do, he wants > > to synthesize two different cores into one system. The problem is that > > during synthesis ISE throws out some pins of one core, which are, > > however, necessary because they feeds inputs of the other core. > > > How could this happen? > > If some (or all) of the outputs of core #2 do not make it to physical out= put > pins of the device then it is quite possible that some of the inputs to c= ore > #2 can disappear. =A0If those core #2 inputs happen to come from outputs = of > core #1 and those signals do not happen to go anywhere else, those will g= et > optimized away as well. > > To put it more simply, those signals between core #1 and #2 that you thin= k > 'should' be there, do not in fact effect the value of any physical I/O pi= ns > of the device...therefore they can be removed and the behaviour of the > device will not be affected. =A0Second guessing the synthesis tool is usu= ally > a pointless exercise, the tool is correct in it's analysis of your logic > very, very often. > > > Any tips? > > Run a simulation of the whole design. > > > What should we check? > > That the output of the simulation matches what you expect. > > As 'MM' pointed out, the subject line of your post will not help > you...consider not slamming others just because of your frustration. > > Kevin JenningsArticle: 140933
On May 30, 10:46=A0am, rickman <gnu...@gmail.com> wrote: > Morpheus is a lot more than just an FPGA. =A0It includes a > reconfigurable instruction set processor (RISA). =A0Personally, I feel > that is a bit of, "so what". =A0I can almost guarantee that a RISA > processor will get two or three standard configurations because of the > costs associated with designing your own instruction set. =A0 Depends on what RISA really means. It may be market-speak for features that NIOS offers where (IIRC) you can map SW calls to FPGA fabric - that makes more sense, than 6 different ways to code an AND opcode.. -jgArticle: 140934
On 30 May, 10:07, -jg <Jim.Granvi...@gmail.com> wrote: > On May 30, 10:46=A0am, rickman <gnu...@gmail.com> wrote: > > > Morpheus is a lot more than just an FPGA. =A0It includes a > > reconfigurable instruction set processor (RISA). =A0Personally, I feel > > that is a bit of, "so what". =A0I can almost guarantee that a RISA > > processor will get two or three standard configurations because of the > > costs associated with designing your own instruction set. =A0 > > Depends on what RISA really means. It may be market-speak for > features that NIOS offers where (IIRC) you can map SW calls to > FPGA fabric - that makes more sense, than 6 different ways to code > an AND opcode.. > -jg folks you refer to that: http://www.morpheus-ist.org/index.htm or what? I do not see any mentioning of RISA there? AnttiArticle: 140935
Hi I wonder if there ary another patent free implementation of ARM cores excpet the Pollex series http://www.r-and-d.de/ AnttiArticle: 140936
On Sun, 24 May 2009 23:38:00 -0700 (PDT), Antti wrote: >this is the original code (opencores AX8 core) > >this code works OK on >1) simulation >2) Xilinx FPGA >3) Actel FPGA > >and it works wrong-different when used with Magma synthesis What sort of "wrong"? I can't see anything in the code that is non-standard. The empty then...elsif is hard to read, but you could easily fix that by adding null; or Inst <= Inst; -- yuck >so question is, is the code "wrong enough" to allow Magma synthesis >to generate valid as per VHDL code, that doesnt work? Did you get any warnings? The story is simple: no warnings + synth/sim mismatch == synthesis tool bug >I am guessing the problem for synthesis is that it is not so clear >how to implement the empty case, either by using clock enable >or feedback mux (to register or hold old value) Yeah, it's probably a bug triggered by the empty branch. But it is the tool's fault, not the code. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 140937
On 30 May, 12:08, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sun, 24 May 2009 23:38:00 -0700 (PDT), Antti wrote: > >this is the original code (opencores AX8 core) > > >this code works OK on > >1) simulation > >2) Xilinx FPGA > >3) Actel FPGA > > >and it works wrong-different when used with Magma synthesis > > What sort of "wrong"? =A0I can't see anything in the code > that is non-standard. =A0The empty then...elsif is hard to > read, but you could easily fix that by adding > =A0 null; > or > =A0 Inst <=3D Inst; =A0-- yuck > > >so question is, is the code "wrong enough" to allow Magma synthesis > >to generate valid as per VHDL code, that doesnt work? > > Did you get any warnings? =A0The story is simple: > no warnings + synth/sim mismatch =3D=3D synthesis tool bug > > >I am guessing the problem for synthesis is that it is not so clear > >how to implement the empty case, either by using clock enable > >or feedback mux (to register or hold old value) > > Yeah, it's probably a bug triggered by the empty branch. > But it is the tool's fault, not the code. > > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. no warnings, and Inst <=3D Inst; -- yuck did NOT FIX the problem, i tried that thanks for taking look at the code, your comment is about the same i did think myself -- possible synthesis bug.. AnttiArticle: 140938
> I wonder if there ary another patent free implementation of ARM cores > excpet the Pollex series > I wonder if this one is ;) How has this succeeded where picoTurbo failed? You could probably do an ARM clone without violating a patent - but Thumb support and being 100% binary compatible seems tricky. JonArticle: 140939
This is fix now the problem was the "if clock" was evaluating the signal only when the clock/inputA is in high, after removing that condition the output works as it should. ThanksArticle: 140940
Hi, Other thing I have found out there was not needed to add a SEQ at the main VHDL code, before the simulator was getting only once at the and function, but now it does without it. Regards,Article: 140941
On May 30, 6:53=A0am, j...@beniston.com wrote: > > I wonder if there ary another patent free implementation of ARM cores > > excpet the Pollex series > > I wonder if this one is ;) > > How has this succeeded where picoTurbo failed? > > You could probably do an ARM clone without violating a patent - but > Thumb support and being 100% binary compatible seems tricky. From what I have read it is not the binary code that is a problem. I don't think you can patent that. ARM patented some aspect of their interrupt handling that is essential to a correct implementation. I'm not sure when that runs out, but that is the only patent I know of in the ARM family that can't be designed around. My understanding is that is what got the guy in trouble who had an ARM version on opencores.org (since gone). RickArticle: 140942
rickman wrote: > On May 30, 6:53 am, j...@beniston.com wrote: >>> I wonder if there ary another patent free implementation of ARM >>> cores excpet the Pollex series >> >> I wonder if this one is ;) >> >> How has this succeeded where picoTurbo failed? >> >> You could probably do an ARM clone without violating a patent - but >> Thumb support and being 100% binary compatible seems tricky. > > From what I have read it is not the binary code that is a problem. I > don't think you can patent that. ARM patented some aspect of their > interrupt handling that is essential to a correct implementation. > I'm not sure when that runs out, but that is the only patent I know > of in the ARM family that can't be designed around. My understanding > is that is what got the guy in trouble who had an ARM version on > opencores.org (since gone). > Of all the ARM things I wouldn't want to copy would be their interrupt handling. If the NXP variety of ARM7 is anything to go by, there are enough supurious and missing interrupts to make me want to see an improvement.Article: 140943
> From what I have read it is not the binary code that is a problem. =A0I > don't think you can patent that. Sure. However, as you mention, there are some instructions / features that may be difficult to implement without violating a patent, thereby meaning you are not 100% compatible (not that the various ARMs themselves are). For patents possibly covering instructions, you have: 5583804: Data processing using multiply-accumulate instructions Although there was some evidence in the picoTurbo case that this patent may not be valid has it had been publicly disclosed before filing. > =A0ARM patented some aspect of their > interrupt handling that is essential to a correct implementation. > I'm =A0not sure when that runs out, but that is the only patent I know > of in the ARM family that can't be designed around. =A0 That is 5386563: Register substitution during exception processing. It has a couple more years before it expires. There is also 5701493: Exception handling method and apparatus in data processing systems There is potentially prior art that would invalidate 5386563. Then you have the patents covering thumb mode: 5758115/6021265: Interoperability with multiple instruction sets 5568646: Multiple instruction set mapping 5740461: Data processing with multiple instruction sets If you have a single decoder you might be able to work around these. There's probably a few others as well. JonArticle: 140944
On Sat, 30 May 2009 15:46:27 +0100, "Fredxx" <fredxx@spam.com> wrote: >rickman wrote: >> On May 30, 6:53 am, j...@beniston.com wrote: >>>> I wonder if there ary another patent free implementation of ARM >>>> cores excpet the Pollex series >>> >>> I wonder if this one is ;) >>> >>> How has this succeeded where picoTurbo failed? >>> >>> You could probably do an ARM clone without violating a patent - but >>> Thumb support and being 100% binary compatible seems tricky. >> >> From what I have read it is not the binary code that is a problem. I >> don't think you can patent that. ARM patented some aspect of their >> interrupt handling that is essential to a correct implementation. >> I'm not sure when that runs out, but that is the only patent I know >> of in the ARM family that can't be designed around. My understanding >> is that is what got the guy in trouble who had an ARM version on >> opencores.org (since gone). >> > >Of all the ARM things I wouldn't want to copy would be their interrupt >handling. If the NXP variety of ARM7 is anything to go by, there are enough >supurious and missing interrupts to make me want to see an improvement. The early VIC can indeed be troublesome. Happily, NXP replaced that controller in newer families (e.g., LPC23xx/24xx) with one that isn't susceptible to spurious interrupts. See the migration guide, AN10576. -- Rich Webb Norfolk, VAArticle: 140945
On May 30, 3:21=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On 30 May, 10:07, -jg <Jim.Granvi...@gmail.com> wrote: > > > On May 30, 10:46=A0am, rickman <gnu...@gmail.com> wrote: > > > > Morpheus is a lot more than just an FPGA. =A0It includes a > > > reconfigurable instruction set processor (RISA). =A0Personally, I fee= l > > > that is a bit of, "so what". =A0I can almost guarantee that a RISA > > > processor will get two or three standard configurations because of th= e > > > costs associated with designing your own instruction set. =A0 > > > Depends on what RISA really means. It may be market-speak for > > features that NIOS offers where (IIRC) you can map SW calls to > > FPGA fabric - that makes more sense, than 6 different ways to code > > an AND opcode.. > > -jg > > folks you refer to that: > > http://www.morpheus-ist.org/index.htm > > or what? > I do not see any mentioning of RISA there? > > Antti I don't recall where I read about this, it was in some news release on this event. But you will see it in the diagram on this page. http://www.morpheus-ist.org/pages/arch.htm rickArticle: 140946
On May 30, 3:21=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On 30 May, 10:07, -jg <Jim.Granvi...@gmail.com> wrote: > > > On May 30, 10:46=A0am, rickman <gnu...@gmail.com> wrote: > > > > Morpheus is a lot more than just an FPGA. =A0It includes a > > > reconfigurable instruction set processor (RISA). =A0Personally, I fee= l > > > that is a bit of, "so what". =A0I can almost guarantee that a RISA > > > processor will get two or three standard configurations because of th= e > > > costs associated with designing your own instruction set. =A0 > > > Depends on what RISA really means. It may be market-speak for > > features that NIOS offers where (IIRC) you can map SW calls to > > FPGA fabric - that makes more sense, than 6 different ways to code > > an AND opcode.. > > -jg > > folks you refer to that: > > http://www.morpheus-ist.org/index.htm > > or what? > I do not see any mentioning of RISA there? > > Antti Here is one link that refers to this term... http://www.pldesignline.com/products/217100139;jsessionid=3DEBDV2WOGJHFNGQS= NDLRSKH0CJUNN2JVNArticle: 140947
hi, i have an asynchronous fifo that i need to time constrain. please help me with this. rd clk = 50mhz wr clk = 200mhz gray count is passed from on domain to another thank you, randeel.Article: 140948
"rana" <randeelw@gmail.com> wrote in message news:4df88a41-379c-4494-a721-c5b76369bfa7@h11g2000yqb.googlegroups.com... > hi, > i have an asynchronous fifo that i need to time constrain. please help > me with this. > > rd clk = 50mhz > wr clk = 200mhz > gray count is passed from on domain to another > > thank you, > randeel. To save trashing data, first you need to ensure rd clk freq > wr clk freqArticle: 140949
On 30 May, 17:15, rickman <gnu...@gmail.com> wrote: > On May 30, 6:53=A0am, j...@beniston.com wrote: > > > > I wonder if there ary another patent free implementation of ARM cores > > > excpet the Pollex series > > > I wonder if this one is ;) > > > How has this succeeded where picoTurbo failed? > > > You could probably do an ARM clone without violating a patent - but > > Thumb support and being 100% binary compatible seems tricky. > > From what I have read it is not the binary code that is a problem. =A0I > don't think you can patent that. =A0ARM patented some aspect of their > interrupt handling that is essential to a correct implementation. > I'm =A0not sure when that runs out, but that is the only patent I know > of in the ARM family that can't be designed around. =A0My understanding > is that is what got the guy in trouble who had an ARM version on > opencores.org (since gone). > > Rick no, the reason nnARM was fighted was that it potentially used some of the original code or was borrowed from original code, or ARM assumed it was. I think ARM did license the rtl to some china universities, and it hit back the nnARM code is still available but rather large and useless anyway, what DOES make sense in FPGA is M3, it is real small and nice, full ARM7 or M3 are much larger than M1 Antti
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