Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 140925

Article: 140925
Subject: Re: phase locking a slow (2Mhz) signal.
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 May 2009 15:33:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
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).

Rick

Article: 140926
Subject: Re: Has ST's FPGA project GOSPL transformed to Morpheus ?
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 May 2009 15:46:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 140927
Subject: Re: Are Virtex-5 FPGA Handbook or Altera latest Handbooks available
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 May 2009 16:40:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Weng

Article: 140928
Subject: Re: Are Virtex-5 FPGA Handbook or Altera latest Handbooks available
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 May 2009 17:00:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Weng


Article: 140929
Subject: Re: Are Virtex-5 FPGA Handbook or Altera latest Handbooks available to sell?
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Fri, 29 May 2009 20:15:25 -0500
Links: << >>  << T >>  << A >>
"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
Subject: Re: I don't like xilinx (again)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 29 May 2009 21:22:45 -0400
Links: << >>  << T >>  << A >>

"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 Jennings 



Article: 140931
Subject: Re: Coolrunner II: what's wrong up here ?
From: -jg <Jim.Granville@gmail.com>
Date: Fri, 29 May 2009 21:29:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

-jg



Article: 140932
Subject: Re: I don't like xilinx (again)
From: mtom199@gmail.com
Date: Fri, 29 May 2009 22:16:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Jennings


Article: 140933
Subject: Re: Has ST's FPGA project GOSPL transformed to Morpheus ?
From: -jg <Jim.Granville@gmail.com>
Date: Sat, 30 May 2009 00:07:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 140934
Subject: Re: Has ST's FPGA project GOSPL transformed to Morpheus ?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 30 May 2009 00:21:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
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?

Antti

Article: 140935
Subject: patent free ARM cores
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 30 May 2009 01:25:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I wonder if there ary another patent free implementation of ARM cores
excpet the Pollex series

http://www.r-and-d.de/

Antti

Article: 140936
Subject: Re: VHDL synthesis difference bwetween tools
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 30 May 2009 10:08:21 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL synthesis difference bwetween tools
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 30 May 2009 02:23:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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..

Antti

Article: 140938
Subject: Re: patent free ARM cores
From: jon@beniston.com
Date: Sat, 30 May 2009 03:53:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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.

Jon


Article: 140939
Subject: Re: Urgent help with a Simple AND simulation
From: Peter <pvrequiz@gmail.com>
Date: Sat, 30 May 2009 05:15:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. Thanks

Article: 140940
Subject: Re: Urgent help with a Simple AND simulation
From: Peter <pvrequiz@gmail.com>
Date: Sat, 30 May 2009 05:19:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: patent free ARM cores
From: rickman <gnuarm@gmail.com>
Date: Sat, 30 May 2009 07:15:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
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).

Rick

Article: 140942
Subject: Re: patent free ARM cores
From: "Fredxx" <fredxx@spam.com>
Date: Sat, 30 May 2009 15:46:27 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: patent free ARM cores
From: jon@beniston.com
Date: Sat, 30 May 2009 08:16:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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.

Jon





Article: 140944
Subject: Re: patent free ARM cores
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Sat, 30 May 2009 11:37:16 -0400
Links: << >>  << T >>  << A >>
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, VA

Article: 140945
Subject: Re: Has ST's FPGA project GOSPL transformed to Morpheus ?
From: rickman <gnuarm@gmail.com>
Date: Sat, 30 May 2009 08:45:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

rick

Article: 140946
Subject: Re: Has ST's FPGA project GOSPL transformed to Morpheus ?
From: rickman <gnuarm@gmail.com>
Date: Sat, 30 May 2009 08:51:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
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=
NDLRSKH0CJUNN2JVN

Article: 140947
Subject: time constraining asynchronous fifo
From: rana <randeelw@gmail.com>
Date: Sat, 30 May 2009 10:08:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: time constraining asynchronous fifo
From: "Phil Jessop" <phil@noname.org>
Date: Sat, 30 May 2009 18:18:15 +0100
Links: << >>  << T >>  << A >>

"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 freq 



Article: 140949
Subject: Re: patent free ARM cores
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 30 May 2009 11:00:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search