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 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
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. -- RickArticle: 155802
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
> 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 FoxArticle: 155804
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
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. PhilippArticle: 155806
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. -- GaborArticle: 155807
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
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? -- RickArticle: 155809
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... -- RickArticle: 155810
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... -- GaborArticle: 155811
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. -- RickArticle: 155812
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
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. -jgArticle: 155814
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.) -- glenArticle: 155815
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. -- RickArticle: 155816
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
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. -- glenArticle: 155818
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.comArticle: 155819
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
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
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.comArticle: 155822
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... -- RickArticle: 155823
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, AndyArticle: 155824
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:
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