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 155800

Article: 155800
Subject: Re: FPGA temperature measurement
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 11 Sep 2013 16:19:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 29, 2013 2:44:05 PM UTC-7, John Larkin wrote:
> We're experimenting with heat sinking an Altera Cyclone 3 FPGA. To
> 
> measure actual die temperature, we built a 19-stage ring oscillator,
> 
> followed by a divide-by-16 ripple counter, and brought that out.
> 
> 
> 
> The heat source is the FPGA itself: we just clocked every available
> 
> flop on the chip at 250 MHz. We stuck a thinfilm thermocouple on the
> 
> top of the BGA package, and here's what we got:
> 
> 
> 
> https://dl.dropboxusercontent.com/u/53724080/Thermal/R2_Temp_Cal.jpg
> 
> 
> 
> 
> 
> We can now use that curve (line, actually!) to evaluate various heat
> 
> sinking options, for both this chip and the entire board.
> 
> 
> 
> The equivalent prop delay per CLB seems to be about 350 ps. The prop
> 
> delay slope is about 0.1% per degree C.
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
> John Larkin         Highland Technology, Inc
> 
> 
> 
> jlarkin at highlandtechnology dot com
> 
> http://www.highlandtechnology.com
> 
> 
> 
> Precision electronic instrumentation
> 
> Picosecond-resolution Digital Delay and Pulse generators
> 
> Custom laser drivers and controllers
> 
> Photonics and fiberoptic TTL data links
> 
> VME thermocouple, LVDT, synchro   acquisition and simulation

The plot has increasing temperature with decreasing frequency which doesn't make sense.   Increasing the frequency should be increasing the current consumption which results in increasing the temperature.

Are you doing this to confirm Altera's die/pkg thermal coefficient data or do they not publish that information?

Ed McGettigan
--
Xilinx Inc.

Article: 155801
Subject: Re: FPGA temperature measurement
From: rickman <gnuarm@gmail.com>
Date: Thu, 12 Sep 2013 04:29:47 -0400
Links: << >>  << T >>  << A >>
On 9/11/2013 7:19 PM, Ed McGettigan wrote:
> On Thursday, August 29, 2013 2:44:05 PM UTC-7, John Larkin wrote:
>> We're experimenting with heat sinking an Altera Cyclone 3 FPGA. To
>>
>> measure actual die temperature, we built a 19-stage ring oscillator,
>>
>> followed by a divide-by-16 ripple counter, and brought that out.
>>
>>
>>
>> The heat source is the FPGA itself: we just clocked every available
>>
>> flop on the chip at 250 MHz. We stuck a thinfilm thermocouple on the
>>
>> top of the BGA package, and here's what we got:
>>
>>
>>
>> https://dl.dropboxusercontent.com/u/53724080/Thermal/R2_Temp_Cal.jpg
>>
>>
>>
>>
>>
>> We can now use that curve (line, actually!) to evaluate various heat
>>
>> sinking options, for both this chip and the entire board.
>>
>>
>>
>> The equivalent prop delay per CLB seems to be about 350 ps. The prop
>>
>> delay slope is about 0.1% per degree C.
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>> John Larkin
>>
>
> The plot has increasing temperature with decreasing frequency which doesn't make sense.   Increasing the frequency should be increasing the current consumption which results in increasing the temperature.
>
> Are you doing this to confirm Altera's die/pkg thermal coefficient data or do they not publish that information?
>
> Ed McGettigan
> --
> Xilinx Inc.

I don't think you understand what he is doing.  The concept is to 
construct a ring oscillator that consists of elements within the silicon 
of the FPGA.  This circuit will have a natural oscillation frequency 
related to the delay of the circuit.  The delay in the transistors will 
be related to the temperature which will make the oscillation frequency 
inversely related to temperature.  Measure the frequency and you can 
calculate the temperature.  The heat dissipation of the ring oscillator 
has negligible effect on the temperature.

You are confusing the cause and the effect.  The temperature is the 
cause and the ring oscillator frequency is the effect.

He is doing this to measure the temperature of the chip with different 
heat sink designs rather than to actually design a cooling solution by 
calculating results based on the thermal parameters of the various 
components.  Thermal design can be rather complicated if there are more 
than the one heat source involved.  Experimental methods can yield quick 
results especially if some aspects of the design are done and fixed and 
you don't really have a specific goal.

-- 

Rick

Article: 155802
Subject: Re: FPGA temperature measurement
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 12 Sep 2013 10:13:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, September 12, 2013 1:29:47 AM UTC-7, rickman wrote:
> On 9/11/2013 7:19 PM, Ed McGettigan wrote:
> 
> > On Thursday, August 29, 2013 2:44:05 PM UTC-7, John Larkin wrote:
> >> We're experimenting with heat sinking an Altera Cyclone 3 FPGA. To
> >> measure actual die temperature, we built a 19-stage ring oscillator,
> >> followed by a divide-by-16 ripple counter, and brought that out.
> >>
> >> The heat source is the FPGA itself: we just clocked every available
> >> flop on the chip at 250 MHz. We stuck a thinfilm thermocouple on the
> >> top of the BGA package, and here's what we got:
> >>
> >> https://dl.dropboxusercontent.com/u/53724080/Thermal/R2_Temp_Cal.jpg
> >>
> >> We can now use that curve (line, actually!) to evaluate various heat
> >> sinking options, for both this chip and the entire board.
> >>
> >> The equivalent prop delay per CLB seems to be about 350 ps. The prop
> >> delay slope is about 0.1% per degree C.
> >>
> >> --
> >> John Larkin
> >
> > The plot has increasing temperature with decreasing frequency which 
> > doesn't make sense.   Increasing the frequency should be increasing 
> > the current consumption which results in increasing the temperature.
> >
> > Are you doing this to confirm Altera's die/pkg thermal coefficient 
> > data or do they not publish that information?
> >
> >
> > Ed McGettigan
> > --
> > Xilinx Inc.
> 
> I don't think you understand what he is doing.  The concept is to 
> construct a ring oscillator that consists of elements within the silicon 
> of the FPGA.  This circuit will have a natural oscillation frequency 
> related to the delay of the circuit.  The delay in the transistors will 
> be related to the temperature which will make the oscillation frequency 
> inversely related to temperature.  Measure the frequency and you can 
> calculate the temperature.  The heat dissipation of the ring oscillator 
> has negligible effect on the temperature.
> 
> You are confusing the cause and the effect.  The temperature is the 
> cause and the ring oscillator frequency is the effect.
> 
> He is doing this to measure the temperature of the chip with different 
> heat sink designs rather than to actually design a cooling solution by 
> calculating results based on the thermal parameters of the various 
> components.  Thermal design can be rather complicated if there are more 
> than the one heat source involved.  Experimental methods can yield quick 
> results especially if some aspects of the design are done and fixed and 
> you don't really have a specific goal.
> 
> -- 
> Rick

You're right I misunderstood the use of the ring oscillator
with respect to the temperature measurement.  I should have
read the original post more thoroughly.

Ed McGettigan
--
Xilinx Inc.


Article: 155803
Subject: Re: FPGA temperature measurement
From: Bart Fox <bartfox@gmx.net>
Date: Sun, 15 Sep 2013 06:56:00 +0200
Links: << >>  << T >>  << A >>
> We're experimenting with heat sinking an Altera Cyclone 3 FPGA. To
> measure actual die temperature, we built a 19-stage ring oscillator,
> followed by a divide-by-16 ripple counter, and brought that out.

Here are comparable experiments done with Xilinx Virtex 5:

http://www.cs.uni-paderborn.de/fileadmin/Informatik/AG-Platzner/publications/ruething12_fpl/ruething_fpl12.pdf

regards,
Bart Fox

Article: 155804
Subject: Legal Issues Reproducing Old CPU
From: ditiris@gmail.com
Date: Tue, 17 Sep 2013 21:30:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
This might not be the best group to ask, but I figured I would start here. =
I need to duplicate a 35-year-old CPU. Are there legal ramifications doing =
this?=20

For instance on OpenCores they have a partially-compliant C54x DSP core. I =
assume the partial compliance is in part not to run into licensing issues a=
nd have TI sue them. However, I need to duplicate the CPU's instruction set=
 and associated cycle count exactly, so I'm pretty much going to copy the C=
PU using the existing documentation.

Thanks in advance for the help.

Article: 155805
Subject: Re: Legal Issues Reproducing Old CPU
From: Philipp Klaus Krause <pkk@spth.de>
Date: Wed, 18 Sep 2013 12:43:01 +0200
Links: << >>  << T >>  << A >>
Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
> This might not be the best group to ask, but I figured I would start
> here. I need to duplicate a 35-year-old CPU. Are there legal
> ramifications doing this?
> 
> For instance on OpenCores they have a partially-compliant C54x DSP
> core. I assume the partial compliance is in part not to run into
> licensing issues and have TI sue them. However, I need to duplicate
> the CPU's instruction set and associated cycle count exactly, so I'm
> pretty much going to copy the CPU using the existing documentation.
> 
> Thanks in advance for the help.
> 

IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
OK, unless some of the instructions are patented. Patents expire after
at most 20 years in any part of the world that I know of, so with a
35-year-old CPU you should be ok.

Philipp

Article: 155806
Subject: Re: Legal Issues Reproducing Old CPU
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 18 Sep 2013 09:53:48 -0400
Links: << >>  << T >>  << A >>
Philipp Klaus Krause wrote:
> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>> This might not be the best group to ask, but I figured I would start
>> here. I need to duplicate a 35-year-old CPU. Are there legal
>> ramifications doing this?
>>
>> For instance on OpenCores they have a partially-compliant C54x DSP
>> core. I assume the partial compliance is in part not to run into
>> licensing issues and have TI sue them. However, I need to duplicate
>> the CPU's instruction set and associated cycle count exactly, so I'm
>> pretty much going to copy the CPU using the existing documentation.
>>
>> Thanks in advance for the help.
>>
> 
> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
> OK, unless some of the instructions are patented. Patents expire after
> at most 20 years in any part of the world that I know of, so with a
> 35-year-old CPU you should be ok.
> 
> Philipp

I think you need to be careful.  While patents do expire (patents from
35 years ago expired after 17 years IIRC), copyrights generally do not.
On the other hand it would be unusual for the owners of such old
copyrights to pursue legal action against you unless you were making
a lot of these devices.  Still you're better off getting legal advice
from someone who knows more about these issues, especially if you're
intending to make significant money from this copying effort.

-- 
Gabor

Article: 155807
Subject: Re: Legal Issues Reproducing Old CPU
From: hamilton <hamilton@nothere.com>
Date: Wed, 18 Sep 2013 10:07:54 -0600
Links: << >>  << T >>  << A >>
On 9/17/2013 10:30 PM, ditiris@gmail.com wrote:
> This might not be the best group to ask, but I figured I would start here. I need to duplicate a 35-year-old CPU. Are there legal ramifications doing this?
>
> For instance on OpenCores they have a partially-compliant C54x DSP core. I assume the partial compliance is in part not to run into licensing issues and have TI sue them. However, I need to duplicate the CPU's instruction set and associated cycle count exactly, so I'm pretty much going to copy the CPU using the existing documentation.
>
> Thanks in advance for the help.
>
Is this an educational exercise or a product development case ?




Article: 155808
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 Sep 2013 14:24:24 -0400
Links: << >>  << T >>  << A >>
On 9/18/2013 12:30 AM, ditiris@gmail.com wrote:
> This might not be the best group to ask, but I figured I would start here. I need to duplicate a 35-year-old CPU. Are there legal ramifications doing this?
>
> For instance on OpenCores they have a partially-compliant C54x DSP core. I assume the partial compliance is in part not to run into licensing issues and have TI sue them. However, I need to duplicate the CPU's instruction set and associated cycle count exactly, so I'm pretty much going to copy the CPU using the existing documentation.
>
> Thanks in advance for the help.

Although I am not a lawyer...  My understanding is that you can 
duplicate any hardware that is not patented.  Few CPUs involve patents 
that can not be circumvented by not duplicating the exact circuit.  One 
exception is the ARM7 (at least the 7).  It has some feature of some 
interrupt instruction that requires a piece of hardware that is 
patented.  That is the only example I know of.

Since you are looking at duplicating a 35 year old CPU, I think it would 
be pretty safe.  Which CPU is it, if you don't mind?

-- 

Rick

Article: 155809
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 Sep 2013 14:27:42 -0400
Links: << >>  << T >>  << A >>
On 9/18/2013 9:53 AM, GaborSzakacs wrote:
> Philipp Klaus Krause wrote:
>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>> This might not be the best group to ask, but I figured I would start
>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>> ramifications doing this?
>>>
>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>> core. I assume the partial compliance is in part not to run into
>>> licensing issues and have TI sue them. However, I need to duplicate
>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>> pretty much going to copy the CPU using the existing documentation.
>>>
>>> Thanks in advance for the help.
>>>
>>
>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
>> OK, unless some of the instructions are patented. Patents expire after
>> at most 20 years in any part of the world that I know of, so with a
>> 35-year-old CPU you should be ok.
>>
>> Philipp
>
> I think you need to be careful. While patents do expire (patents from
> 35 years ago expired after 17 years IIRC), copyrights generally do not.
> On the other hand it would be unusual for the owners of such old
> copyrights to pursue legal action against you unless you were making
> a lot of these devices. Still you're better off getting legal advice
> from someone who knows more about these issues, especially if you're
> intending to make significant money from this copying effort.

Copyright does not cover a design, it only covers an expression.  If you 
reverse engineered the chip and were making identical chips, that would 
be covered by copyright...  But just duplicating the functionality, even 
by constructing a gate level copy of the CPU, would not be covered by 
copyright.

I am also not a lawyer...

-- 

Rick

Article: 155810
Subject: Re: Legal Issues Reproducing Old CPU
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 18 Sep 2013 15:01:28 -0400
Links: << >>  << T >>  << A >>
rickman wrote:
> On 9/18/2013 9:53 AM, GaborSzakacs wrote:
>> Philipp Klaus Krause wrote:
>>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>>> This might not be the best group to ask, but I figured I would start
>>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>>> ramifications doing this?
>>>>
>>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>>> core. I assume the partial compliance is in part not to run into
>>>> licensing issues and have TI sue them. However, I need to duplicate
>>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>>> pretty much going to copy the CPU using the existing documentation.
>>>>
>>>> Thanks in advance for the help.
>>>>
>>>
>>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
>>> OK, unless some of the instructions are patented. Patents expire after
>>> at most 20 years in any part of the world that I know of, so with a
>>> 35-year-old CPU you should be ok.
>>>
>>> Philipp
>>
>> I think you need to be careful. While patents do expire (patents from
>> 35 years ago expired after 17 years IIRC), copyrights generally do not.
>> On the other hand it would be unusual for the owners of such old
>> copyrights to pursue legal action against you unless you were making
>> a lot of these devices. Still you're better off getting legal advice
>> from someone who knows more about these issues, especially if you're
>> intending to make significant money from this copying effort.
> 
> Copyright does not cover a design, it only covers an expression.  If you 
> reverse engineered the chip and were making identical chips, that would 
> be covered by copyright...  But just duplicating the functionality, even 
> by constructing a gate level copy of the CPU, would not be covered by 
> copyright.
> 
> I am also not a lawyer...
> 

Watch out!  How are you going to have the same instruction set without
"copying" it?  If the instruction set itself is copyrighted (IIRC this
was the case for the Intel 8080) you could have ompletely different
underlying hardware and still infringe on the copyright.  I seem to
recall that some people worked around this by simply changing the
instruction mnemonics...

-- 
Gabor

Article: 155811
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 Sep 2013 15:25:32 -0400
Links: << >>  << T >>  << A >>
On 9/18/2013 3:01 PM, GaborSzakacs wrote:
> rickman wrote:
>> On 9/18/2013 9:53 AM, GaborSzakacs wrote:
>>> Philipp Klaus Krause wrote:
>>>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>>>> This might not be the best group to ask, but I figured I would start
>>>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>>>> ramifications doing this?
>>>>>
>>>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>>>> core. I assume the partial compliance is in part not to run into
>>>>> licensing issues and have TI sue them. However, I need to duplicate
>>>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>>>> pretty much going to copy the CPU using the existing documentation.
>>>>>
>>>>> Thanks in advance for the help.
>>>>>
>>>>
>>>> IANAL, but AFAIK, reproducing instruction set and cycle count
>>>> exactly is
>>>> OK, unless some of the instructions are patented. Patents expire after
>>>> at most 20 years in any part of the world that I know of, so with a
>>>> 35-year-old CPU you should be ok.
>>>>
>>>> Philipp
>>>
>>> I think you need to be careful. While patents do expire (patents from
>>> 35 years ago expired after 17 years IIRC), copyrights generally do not.
>>> On the other hand it would be unusual for the owners of such old
>>> copyrights to pursue legal action against you unless you were making
>>> a lot of these devices. Still you're better off getting legal advice
>>> from someone who knows more about these issues, especially if you're
>>> intending to make significant money from this copying effort.
>>
>> Copyright does not cover a design, it only covers an expression. If
>> you reverse engineered the chip and were making identical chips, that
>> would be covered by copyright... But just duplicating the
>> functionality, even by constructing a gate level copy of the CPU,
>> would not be covered by copyright.
>>
>> I am also not a lawyer...
>>
>
> Watch out! How are you going to have the same instruction set without
> "copying" it? If the instruction set itself is copyrighted (IIRC this
> was the case for the Intel 8080) you could have ompletely different
> underlying hardware and still infringe on the copyright. I seem to
> recall that some people worked around this by simply changing the
> instruction mnemonics...

No, the instruction set is a concept and is not copyrightable.  The Z80 
had the same instructions the 8080 had including the opcodes.  They 
changed the nemonics because they could be copyrighted... possibly.

Don't confuse the design with the code.  There are also issues with the 
size of the material "copied".  A title of a book is not copyright 
protected for example.  So you will find a NOP instruction in many CPU 
designs even though the 8080 had one.  They even use the same nemonic in 
many CPU instruction sets.

-- 

Rick

Article: 155812
Subject: Re: Legal Issues Reproducing Old CPU
From: Rob Doyle <radioengr@gmail.com>
Date: Wed, 18 Sep 2013 14:08:28 -0700
Links: << >>  << T >>  << A >>
On 9/18/2013 12:01 PM, GaborSzakacs wrote:

> Watch out!  How are you going to have the same instruction set without
> "copying" it?  If the instruction set itself is copyrighted (IIRC this
> was the case for the Intel 8080) you could have ompletely different
> underlying hardware and still infringe on the copyright.  I seem to
> recall that some people worked around this by simply changing the
> instruction mnemonics...


I thought the mnemonics were copyrighted.  Not the instruction set.

Rob.


Article: 155813
Subject: Re: Legal Issues Reproducing Old CPU
From: jg <j.m.granville@gmail.com>
Date: Wed, 18 Sep 2013 16:01:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, September 18, 2013 4:30:15 PM UTC+12, dit...@gmail.com wrote:
> This might not be the best group to ask, but I figured I would start here. I need to duplicate a 35-year-old CPU. Are there legal ramifications doing this? 
> 

Which core ?
If you are doing this to keep a legacy product alive, and keep off the chip-sales commercial radar ( ie no product names mentioned ) - then no one will know, and even if they did know, are unlikely to care.

Even more direct commercial replacements, of very old devices, seems to be fine, and you are a long way from this.

A good example is http://www.tekmos.com/products

Here, they even mention vendor names and part numbers, and pitch directly for chip sales, but the vendors do not care, as they no longer have direct commercial offering.
 
-jg

Article: 155814
Subject: Re: Legal Issues Reproducing Old CPU
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 19 Sep 2013 07:16:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip on duplicating an old CPU)

> Copyright does not cover a design, it only covers an expression.  If you 
> reverse engineered the chip and were making identical chips, that would 
> be covered by copyright...  But just duplicating the functionality, even 
> by constructing a gate level copy of the CPU, would not be covered by 
> copyright.

I suppose I wouldn't be surprised if someone would claim copyright
infringement on a gate level copy, but it isn't likely that anyone
would do that. The technology changes enough that gate level doesn't
really apply. (Note that an FPGA implementation of the same netlist,
implemented using LUTs, wouldn't be a gate level copy, anyway.)

Older CPUs liked to use pass transistors. Intel, more than many
others, liked to use dynamic logic. (With a minimum clock frequency.)
It isn't likely one would do either of those today.

You might get cycle accurate by wasting some cycles that would
otherwise not be needed in current logic.

Do you need to duplicate the exact signals on the chip, or just
the instruction level function and timing?
 
> I am also not a lawyer...

Neither am I.  (IANALE.)

-- glen

Article: 155815
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Thu, 19 Sep 2013 04:39:53 -0400
Links: << >>  << T >>  << A >>
On 9/19/2013 3:16 AM, glen herrmannsfeldt wrote:
> rickman<gnuarm@gmail.com>  wrote:
>
> (snip on duplicating an old CPU)
>
>> Copyright does not cover a design, it only covers an expression.  If you
>> reverse engineered the chip and were making identical chips, that would
>> be covered by copyright...  But just duplicating the functionality, even
>> by constructing a gate level copy of the CPU, would not be covered by
>> copyright.
>
> I suppose I wouldn't be surprised if someone would claim copyright
> infringement on a gate level copy, but it isn't likely that anyone
> would do that. The technology changes enough that gate level doesn't
> really apply. (Note that an FPGA implementation of the same netlist,
> implemented using LUTs, wouldn't be a gate level copy, anyway.)

Of course neither of us are lawyers, but I'm pretty sure that gate a 
level copy would not be a violation of copyright.  Copyright violation 
would require that you actually copy some feature of the chip.  But then 
I guess you could argue that the gate inter-connectivity is a feature of 
the chip.

I guess this is above my pay grade...


> Older CPUs liked to use pass transistors. Intel, more than many
> others, liked to use dynamic logic. (With a minimum clock frequency.)
> It isn't likely one would do either of those today.

That was *very* old CPUs...  But then he did say 35 years.  That would 
be 1980'ish, so integrated circuit CPUs were around and the pass 
transistor FF was used then.

-- 

Rick

Article: 155816
Subject: Re: Legal Issues Reproducing Old CPU
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Thu, 19 Sep 2013 09:07:30 -0700
Links: << >>  << T >>  << A >>
On Thu, 19 Sep 2013 04:39:53 -0400
rickman <gnuarm@gmail.com> wrote:

> On 9/19/2013 3:16 AM, glen herrmannsfeldt wrote:
> 
> > [snip]
> 
> > Older CPUs liked to use pass transistors. Intel, more than many
> > others, liked to use dynamic logic. (With a minimum clock frequency.)
> > It isn't likely one would do either of those today.
> 
> That was *very* old CPUs...  But then he did say 35 years.  That would 
> be 1980'ish, so integrated circuit CPUs were around and the pass 
> transistor FF was used then.
> 
> -- 
> 
> Rick

I was under the impression that they still did; that a Core i7 for
instance has for any given core a minimum frequency to keep it alive,
otherwise you have to put it into sleep.  I can't imagine they manage
to put together a chip with a 3.6 GHz clock frequency out of classic
CMOS.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 155817
Subject: Re: Legal Issues Reproducing Old CPU
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 19 Sep 2013 16:39:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

(snip on using pass transistors and/or dynamic logic)

> I was under the impression that they still did; that a Core i7 for
> instance has for any given core a minimum frequency to keep it alive,
> otherwise you have to put it into sleep.  I can't imagine they manage
> to put together a chip with a 3.6 GHz clock frequency out of classic
> CMOS.

They may or may not use dynamic logic, but many processors now have
a PLL based frequency multiplier on the clock. That has a minimum
clock frequency.

The 8086 and 8088 have dynamic logic with, if I remember, a 2MHz
clock minumum.  The 8080 is dynamic, but the Z80 is static.
At some point, that was a useful advantage.

-- glen

Article: 155818
Subject: Re: Legal Issues Reproducing Old CPU
From: Tim Wescott <tim@seemywebsite.really>
Date: Thu, 19 Sep 2013 12:35:14 -0500
Links: << >>  << T >>  << A >>
On Tue, 17 Sep 2013 21:30:15 -0700, ditiris wrote:

> This might not be the best group to ask, but I figured I would start
> here. I need to duplicate a 35-year-old CPU. Are there legal
> ramifications doing this?
> 
> For instance on OpenCores they have a partially-compliant C54x DSP core.
> I assume the partial compliance is in part not to run into licensing
> issues and have TI sue them. However, I need to duplicate the CPU's
> instruction set and associated cycle count exactly, so I'm pretty much
> going to copy the CPU using the existing documentation.

I suspect the reason it's only partially compliant is because it was too 
much work to make it fully compliant, not because of any IP issues.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com


Article: 155819
Subject: Re: Legal Issues Reproducing Old CPU
From: ditiris@gmail.com
Date: Fri, 20 Sep 2013 06:59:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Wow, lots of activity since I last checked. To answer some questions:

This is for business, not an educational exercise.

The chip is in the TI 9900 family (weird architecture).

I will need to reproduce all logical levels into and out of the chip with t=
iming faithful to the original chip (or as close as I can get it, divide is=
 going to be an issue). A lot of the circuits on the board are old 54-serie=
s discrete logic, so those all get sucked in too, so we wind up emulating t=
he tri-state internal to the FPGA. Outside, we have lots of level converter=
s and discrete control to faithfully replicate the 5V tri-state.

The application is real-time, so I think that rules out software emulation.=
 I explored that path a bit, but after reading up on SNES emulators (1991 3=
.58MHz 16-bit CPU) and finding that most are heavily optimized and largely =
written in assembly, I figured HDL was a better cost-value-risk proposal. W=
hen I got to the part how most software emulators only work most of the tim=
e and they actually need a 3GHz multi-core CPU to accurately model the SNES=
 hardware delays in all cases, I was really convinced HDL was the way to go=
...

Software emulators are apparently fine legally, and I think that's a close =
corollary to what we'll be doing. Given that Tekmos has a business at all, =
we should really be fine.

However, we're still going to consult with a lawyer just to be sure.

Article: 155820
Subject: timing closure
From: alb <alessandro.basili@cern.ch>
Date: Fri, 20 Sep 2013 16:38:30 +0200
Links: << >>  << T >>  << A >>
Hi everyone,

I know the subject is a bit broad, but I'm having issues in achieving
timing closure and I'm trying to add timing constraints but a bit
randomly...

Any pointer to a good source for a more methodical approach?
Thanks a lot,

Al

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 155821
Subject: Re: Legal Issues Reproducing Old CPU
From: Tim Wescott <tim@seemywebsite.really>
Date: Fri, 20 Sep 2013 12:08:23 -0500
Links: << >>  << T >>  << A >>
On Fri, 20 Sep 2013 06:59:18 -0700, ditiris wrote:

> Wow, lots of activity since I last checked. To answer some questions:
> 
> This is for business, not an educational exercise.
> 
> The chip is in the TI 9900 family (weird architecture).
> 
> I will need to reproduce all logical levels into and out of the chip
> with timing faithful to the original chip (or as close as I can get it,
> divide is going to be an issue). A lot of the circuits on the board are
> old 54-series discrete logic, so those all get sucked in too, so we wind
> up emulating the tri-state internal to the FPGA. Outside, we have lots
> of level converters and discrete control to faithfully replicate the 5V
> tri-state.
> 
> The application is real-time, so I think that rules out software
> emulation. I explored that path a bit, but after reading up on SNES
> emulators (1991 3.58MHz 16-bit CPU) and finding that most are heavily
> optimized and largely written in assembly, I figured HDL was a better
> cost-value-risk proposal. When I got to the part how most software
> emulators only work most of the time and they actually need a 3GHz
> multi-core CPU to accurately model the SNES hardware delays in all
> cases, I was really convinced HDL was the way to go...
> 
> Software emulators are apparently fine legally, and I think that's a
> close corollary to what we'll be doing. Given that Tekmos has a business
> at all, we should really be fine.
> 
> However, we're still going to consult with a lawyer just to be sure.

Legal problems aside, if there's an emulator out there that's 100% 
accurate but for timing, and if you can do it this way, I'd run it fast 
enough so that the slowest instruction happens on time, then slow all the 
other ones down to match.

That gets difficult if some execution times are data-dependent.

As far as actual legal problems -- I think you're OK, but talking to a 
lawyer is a Good Idea.  

First TI would have to care.  Then they'd have to dare.  Your biggest 
problem would be some TI lawyer trying to justify his pay by finding an 
encroachment, and you getting squished long before you can win just 
because they're so much bigger than you.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com


Article: 155822
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Fri, 20 Sep 2013 13:54:44 -0400
Links: << >>  << T >>  << A >>
On 9/20/2013 9:59 AM, ditiris@gmail.com wrote:
> Wow, lots of activity since I last checked. To answer some questions:
>
> This is for business, not an educational exercise.
>
> The chip is in the TI 9900 family (weird architecture).
>
> I will need to reproduce all logical levels into and out of the chip with timing faithful to the original chip (or as close as I can get it, divide is going to be an issue). A lot of the circuits on the board are old 54-series discrete logic, so those all get sucked in too, so we wind up emulating the tri-state internal to the FPGA. Outside, we have lots of level converters and discrete control to faithfully replicate the 5V tri-state.
>
> The application is real-time, so I think that rules out software emulation. I explored that path a bit, but after reading up on SNES emulators (1991 3..58MHz 16-bit CPU) and finding that most are heavily optimized and largely written in assembly, I figured HDL was a better cost-value-risk proposal. When I got to the part how most software emulators only work most of the time and they actually need a 3GHz multi-core CPU to accurately model the SNES hardware delays in all cases, I was really convinced HDL was the way to go....

When you say real time, you mean it not only has to be fast enough to 
meet any time deadlines, but you are concerned about the software being 
run having timing loops to interact with the rest of the hardware. 
Certainly that is possible, but it will be a lot of work.

I assume you have explored all the other solutions to the problem and 
you have decided that even though you can't spec out the time and effort 
for this one, you think it will be the fastest and least expensive?

Given that you have the rest of the board design at your disposal, I 
would think it might be easier to reverse engineer the board level 
design and add timing to it to offload that responsibility from the 
software.  This may require a few changes to the software which I 
suppose is a bit more of an unknown.

Can you share any more details about the business need for this?  I had 
a TMS9900 CPU board when I was getting started with CPUs and I designed 
a TMS9995 board for my own use.  Yes, the architecture seemed a bit odd 
compared to other CPUs, but it was derived from a mini-computer where 
the idea worked well.  Once on an IC, the memory bandwidth limited 
performance.  But once the memory is inside the IC as well, performance 
will take off again.  I bet this design could be moderately competitive 
in an FPGA if you wanted to run it as fast as it would go, likely 50 to 
100 MHz.

Do you have adequate docs on the CPU?  Which one are you using?  I might 
still have a 9900 handbook somewhere around...

-- 

Rick

Article: 155823
Subject: Re: timing closure
From: jonesandy@comcast.net
Date: Fri, 20 Sep 2013 14:51:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
If you only have one clock frequency, here is a decent starting point:

Synplify has an option to set a default clock frequency and another to appl=
y the clock period to all unconstrained IO.=20

If you have any IO that need tighter constraints than one clock period, you=
 will need to set those up in the constraints manager.

Microsemi also has a good online tutorial for setting up constraints for so=
urce-synchronous interfaces using virtual clocks.

I prefer to set timing constraints in synthesis so that they are available =
for both Synplify and Designer. I do not use the Libero front end, only Syn=
plify and Designer.

If you can avoid them, do not use multi-cycle or false path constraints. Th=
ey are very difficult to verify without much more expensive tools. It is wa=
y too easy to relax the timing on unintended paths with these constraints, =
and unless you hit just the right conditions in a post-P&R simulation, you'=
ll never know it (until wierd stuff starts happening in the lab or in the f=
ield).

Hope this helps,

Andy

Article: 155824
Subject: FPGA Synthesis to LUT: Looking for papers/algorithms
From: Fpga Newbie <macdev21@gmail.com>
Date: Fri, 20 Sep 2013 23:21:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,=20

I am looking for some easy to understand papers/links that explain the mapp=
ing from a generic netlist to LUT. For e.g. looking at c=3D(a+b)*c - d; I w=
ould imagine there is a generic adder, multiplier and subtractor involved a=
nd I understand that Verilog/VHDL -> generic synthesis process.=20

From the generic netlist , say a collection of and/or/nand/not OR higher le=
vel macros like multipliers etc how do you map to the FPGA LUT? Some papers=
 or links would be very helpful.=20

Thanks



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