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 4/6/2016 11:40 PM, Jon Elson wrote:
> Rick C. Hodgin wrote:
>
>
>>
>> I figured the CPUs I'd make would cost $1,000 each in the early samples,
> OK, the MOSIS standard order is for 40 parts. So, that's $40K each
> revision. Unless you are truly brilliant, it is going to take a BUNCH of
> respins of the part to get anything working.
>> with an anticipated 50 to 100 CPU minimum, but that if I am able to create
>> the industry I'm hoping to create (people who are willing to buy CPUs that
>> are wrought of love, more than high-speed bells and whistles, looking to
>> them as a utility to augment man's existence, rather than as a whizz bang
>> eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
>> 5 is just so last year") kind of thing).
>
> Uhhh, I can imagine there will be at LEAST 5 customers for this. How many
> shirts do you have? Because you are certainly going to lose your shirt on
> this project!
I think Rick H doesn't understand that electronics works exactly the way
it does because it allows the industry to provide $25 cell phones to
those who *need* them rather than the $400 latest eye candy phones to
those who want them. (I don't know of any $12,000 phones) In some ways
the $400 phones subsidize the cheap phones, but not in a serious way.
The expensive phones just drive the "bleeding edge" market since that
always costs more initially. Then once the high initial costs are
amortized, the rest of us get the benefit of the technology at the
sustained product rate.
Producing a CPU chip with no real market in an antique technology will
not help anyone, man or God.
This project *is* starting to sound familiar now.
--
Rick
Article: 158751On 4/6/2016 4:38 PM, Rick C. Hodgin wrote: > On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote: > >> Also, why are you doing this? Is this a hobby? Work related? Starting a >> new bussiness? Want to design and implement a NSA-proof PC? > > To be honest, I am a Christian, and I want to use the talents I was gifted > with and give the fruit of my labor back to God, and to my fellow man (and > not a pursuit of money, or proprietary IP, or patents, or other such things, > but rather an expression of love basically in giving back). This jogged a memory of a joke I was told at work when I worked on an IRAD project that was being graded by the government. The government format for the write up had a few sections and two were the GOAL and the PURPOSE. Everyone was confused about the difference in the two. So Fred wrote his report and said his goal was to measure some parameter and his purpose was to prove the parameter met some requirements. His boss read his report and said, "No, your goal is to prove the parameter met the requirements so what is your purpose?". He worked on it again saying his purpose was to show the unit X would work in system Y. It was reviewed by his second level boss who said, "No, your goal is to prove unit X works in system Y, what is your purpose?" This happened a couple more times until his report got through all the reviewers and he presented his report to a meeting. He started out saying... "My purpose is to get into heaven". -- RickArticle: 158752
rickman <gnuarm@gmail.com> wrote: > > The issue was open source software. The drivers for the GPU were > binary. If the drives for any other part of the chip were binary I'm > sure it would have come up. Many-KLOC drivers are not the same as documentation, even if they're open source. You'll find many many SOCs where source code is available but documentation is not. Most Android phones for example. The OSS people moan about binary blobs, they do not moan that about undocumented hardware or hardware that is unusable without the vendor-provided OSS driver. That driver keeps the Linux OSS folks happy, but is not helpful if you want to write your own driver (for an OS that isn't Linux, for example). The moral of the story is that a lot of the debate about OSS is framed by software people with a very strong Linux focus. They aren't hardware engineers. It may have OSS but not be open hardware - indeed most devices that run Linux aren't open hardware. > What part of the CPU chip on the rPi is not documented in the manual? > It is large and I have not read it all of course, but I'm sure I would > have heard in these discussions if there were any other part than the > GPU that was driven by closed source code. There is no 'CPU chip', it's a system on chip, ie a paste together of silicon and HDL IP from different vendors. Off the top of my head: 'The GPU': The VideoCore GPU 'scalar/vector' processor (VPU) The VideoCore GPU 'shader' processors (QPU) The graphics pipeline (DMA, DAC, HDMI tranceiver, etc) The DSI display output The imaging pipeline (CSI, camera hardware) Hardware encoders/decoders Cache internals and memory controller The Syonpsys USB core The Arasan SDHCI core (any differences from the standard SDHCI) Internal power control Internal clock generation Internal resets (if any, I'm unclear) There are probably other bits. TheoArticle: 158753
On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote:
> Rick C. Hodgin wrote:
>
>
> >
> > I figured the CPUs I'd make would cost $1,000 each in the early samples,
> OK, the MOSIS standard order is for 40 parts. So, that's $40K each
> revision. Unless you are truly brilliant, it is going to take a BUNCH of
> respins of the part to get anything working.
I can't remember who it was I searched a while back (2014 I think), but
I found a company that was manufacturing on 250nm and 500nm process
technologies. The mask sets were $15K each, and each run varied, but
the total cost for 100 parts was less than $100K including masks.
> > with an anticipated 50 to 100 CPU minimum, but that if I am able to create
> > the industry I'm hoping to create (people who are willing to buy CPUs that
> > are wrought of love, more than high-speed bells and whistles, looking to
> > them as a utility to augment man's existence, rather than as a whizz bang
> > eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
> > 5 is just so last year") kind of thing).
>
> Uhhh, I can imagine there will be at LEAST 5 customers for this. How many
> shirts do you have? Because you are certainly going to lose your shirt on
> this project!
Well, it's not a goal. It's not being done for money. I would like to have
assistance from those who are willing to give. I also don't intend on being
the only one who works on it. I intend others who are experts in this field
will come forward and help out. And if not, then I will do my best.
Best regards,
Rick C. Hodgin
Article: 158754On Thursday, April 7, 2016 at 2:42:24 AM UTC-4, rickman wrote: > On 4/6/2016 4:41 PM, Rick C. Hodgin wrote: > > On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote: > >> On 4/6/2016 4:19 PM, Rick C. Hodgin wrote: > >>> On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote: > >>>> On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote: > >>>> > >>>>> On 4/6/2016 8:20 AM, Rick C. Hodgin wrote: > >>>>>> On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote: > >>>>>>> On 4/5/2016 10:47 PM, Rick C. Hodgin wrote: > >>>>>>>> > >>>>>>>> Alright ... suppose I target this from another angle. What if I take > >>>>>>>> the CPU completely off the 80386 motherboard, and create a custom > >>>>>>>> socket connected to my FPGA, and I provide it with everything it > >>>>>>>> requires? > >>>> > >>>> This is probably a much better idea. > >>>> > >>>> The reason for that is that I would expect the motherboard manufacturer > >>>> probably didn't expect someone would be messing with the onboard clock. > >>>> And then they, presumably, didn't design it to handle it. It's enough for > >>>> a single component to misbehave at low frequency and the whole thing > >>>> would fail. > >>>> > >>>> Doing things the other way around should be easier. I can't imagine the > >>>> CPU to be that picky about what it gets from the outside world. > >>>> > >>>> Then again... if the memory controller is embedded in the CPU... > >>> > >>> Not on the 386 chips. The first memory controllers which appeared on > >>> x86 CPUs came from AMD and that was on K8 I believe. > >>> > >>>>> You should be able to design one board with an FPGA, a 386 socket and a > >>>>> 386 plug which will work for any of the three things you have talked > >>>>> about doing, emulating the mobo with your FPGA, emulating the 386 with > >>>>> your FPGA and monitoring the 386 in a real mobo with the FPGA. > >>>>> > >>>>> 386 Chip > >>>>> ____________ > >>>>> ++++++++++++ FPGA > >>>>> ============== _____________ > >>>>> |||||||||||| ,,,,,,,,,,,,, > >>>>> =================================================== PCB > >>>>> |||||||||||| > >>>>> Plugs into 386 Mobo > >>>>> > >>>>> When emulating the 386 unplug it from the socket. When emulating the > >>>>> mobo, unplug from the mobo. When monitoring the 386 in operation plug > >>>>> in the 386 and plug the board into the mobo. > >>>> > >>>> Oh, ok. I was really struggling to figure out how would he mechanically > >>>> intercept the signals between the CPU and the motherboard. Although this > >>>> design still has me scratching my head about those several hundred pins > >>>> that need to be manufactured and installed (by hand?), it's much better > >>>> than what I envisioned. :) > >>>> > >>>> If you two really build such a PCB, would you post the design here? I'd > >>>> really like to see how you route all those wires. :) > >>> > >>> The 80386 used a 132-pin socket, of which 40 pins are either not connected > >>> or only carry Vcc or Vss voltages: > >>> > >>> http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2 > >>> > >>> The sockets and pinouts are fairly standard, though less common these > >>> days. I could de-solder a connector on one of the motherboards I have > >>> for my particular application. Provided the vias were all in the right > >>> place, it should transfer over and re-solder just fine. > >>> > >>>> An innocent question: why not intercept the signals running at full > >>>> speed, storing them and transmitting them later? You probably wouldn't be > >>>> able to record a whole lot of them at once, but you record a bit, power > >>>> cycle the CPU, record a bit more, power cycle the CPU, record a bit > >>>> more.... > >>> > >>> That was my first desire. But, once I learned about AMD's Am386's > >>> ability to clock down to even 0 MHz and maintain its internal state > >>> correctly, I began to think it would be easier to examine if it were > >>> running at lower speed. > >>> > >>> The clock signal to an 80386 is double-pumped, so a 2 Hz input clock > >>> would cause 1 clock cycle per second. > >> > >> That jogged a recollection. Once the internal speeds got faster they > >> added phase locked loops to use a slow external clock and a faster > >> internal clock. These are no longer compatible with slow clocking. > > > > I believe that occurred on the 80486 and the DX/2, DX/3 (un-released), > > and DX/4 models. > > > > The 80387 co-processor has the ability to run dual clocks internally, > > which are governed in the range of 14:10 (I believe), but they don't > > have to run faster. They can be locked and always run at the same > > speed. > > > >> Same is true of FPGAs if you use the internal PLL. It will be fairly > >> simple to generate a variable speed clock to drive the CPU with. Then > >> the FPGA can either work at that same rate, or resync the interface to a > >> fast internal clock which does not change rate. It all depends on what > >> you are doing with the data once you get it and what your other > >> interfaces are. > > > > I had the idea that I would use the simulated clock output for an input > > trigger back into the FPGA for doing all monitoring/sampling. > > If you are plugged into the mobo, I don't think you can source the > clock. That would work ok if the FPGA is emulating the mobo. Correct. I don't plan on connecting to the motherboard though until I get the entire ISA working. And even then it will be a minimal research effort such that if I can't get it working in a week or two, then I'll move on to the next thing. After hearing all of the difficulties I may have on the motherboard side, the re-grouping of just working with the Am386 CPU makes a lot more sense. Plus, it actually accomplishes nearly all of my goals as my goals were to replace the CPU's instruction set with my own, and to validate it 1:1 that I am correct. By having a side-by-side comparison I can do that. And as I've stated, it might even be interesting to try to get other 80386-clone CPUs to test out side-by-side in the configuration, and then write a paper outlining where they are different. But, that's the lowest possible goal, just a "wouldn't it be interesting" thought. :-) Best regards, Rick C. HodginArticle: 158755
On Thursday, April 7, 2016 at 3:08:16 AM UTC-4, rickman wrote: > On 4/6/2016 4:38 PM, Rick C. Hodgin wrote: > > On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote: > > > >> Also, why are you doing this? Is this a hobby? Work related? Starting a > >> new bussiness? Want to design and implement a NSA-proof PC? > > > > To be honest, I am a Christian, and I want to use the talents I was gifted > > with and give the fruit of my labor back to God, and to my fellow man (and > > not a pursuit of money, or proprietary IP, or patents, or other such things, > > but rather an expression of love basically in giving back). > > This jogged a memory of a joke I was told at work when I worked on an > IRAD project that was being graded by the government. The government > format for the write up had a few sections and two were the GOAL and the > PURPOSE. Everyone was confused about the difference in the two. So > Fred wrote his report and said his goal was to measure some parameter > and his purpose was to prove the parameter met some requirements. His > boss read his report and said, "No, your goal is to prove the parameter > met the requirements so what is your purpose?". He worked on it again > saying his purpose was to show the unit X would work in system Y. It > was reviewed by his second level boss who said, "No, your goal is to > prove unit X works in system Y, what is your purpose?" > > This happened a couple more times until his report got through all the > reviewers and he presented his report to a meeting. He started out > saying... "My purpose is to get into heaven". I read this earlier this morning, but I didn't understand it, and still don't. What does it mean? Best regards, Rick C. HodginArticle: 158756
Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> >> The issue was open source software. The drivers for the GPU were >> binary. If the drives for any other part of the chip were binary I'm >> sure it would have come up. > > Many-KLOC drivers are not the same as documentation, even if they're open > source. > > You'll find many many SOCs where source code is available but documentation > is not. Most Android phones for example. The OSS people moan about binary > blobs, they do not moan that about undocumented hardware or hardware that is > unusable without the vendor-provided OSS driver. That driver keeps the > Linux OSS folks happy, but is not helpful if you want to write your own > driver (for an OS that isn't Linux, for example). > > The moral of the story is that a lot of the debate about OSS is framed by > software people with a very strong Linux focus. They aren't hardware > engineers. It may have OSS but not be open hardware - indeed most devices > that run Linux aren't open hardware. > The Linux people aren't that happy about it but the experience with graphics cards has led to acceptance of this. Linus is on record as saying all drivers should trigger a full on GPL cascade - that all drivers, and any* other code that runs in kernel mode is part of the kernel ( which is true from a support/accountability perspective ). *or something... But graphics card makers have set the standards and practices. The OSS folk made their peace with the Philistines. The problem then becomes - you may hear from corporate counsel that the drivers for your FPGA may be a GPL liability. It's a bit more unsettling that say, an Allwinner A20 requires a blob. My understanding is that this is an extension of the same principle but because those SOICs are not available with seperable graphics cards, The generation that remembers what happens when all hardware is proprietary is going into the sunset. And phone makers re at least attempting to exploit this. Pure IP ploys rarely work out, however. >> What part of the CPU chip on the rPi is not documented in the manual? >> It is large and I have not read it all of course, but I'm sure I would >> have heard in these discussions if there were any other part than the >> GPU that was driven by closed source code. > > There is no 'CPU chip', it's a system on chip, ie a paste together of > silicon and HDL IP from different vendors. Off the top of my head: > > 'The GPU': > The VideoCore GPU 'scalar/vector' processor (VPU) > The VideoCore GPU 'shader' processors (QPU) > The graphics pipeline (DMA, DAC, HDMI tranceiver, etc) > The DSI display output > The imaging pipeline (CSI, camera hardware) > Hardware encoders/decoders > Cache internals and memory controller > The Syonpsys USB core > The Arasan SDHCI core (any differences from the standard SDHCI) > Internal power control > Internal clock generation > Internal resets (if any, I'm unclear) > > There are probably other bits. > > Theo > -- Les CargillArticle: 158757
On 4/7/2016 6:23 AM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> >> The issue was open source software. The drivers for the GPU were >> binary. If the drives for any other part of the chip were binary I'm >> sure it would have come up. > > Many-KLOC drivers are not the same as documentation, even if they're open > source. > > You'll find many many SOCs where source code is available but documentation > is not. Most Android phones for example. The OSS people moan about binary > blobs, they do not moan that about undocumented hardware or hardware that is > unusable without the vendor-provided OSS driver. That driver keeps the > Linux OSS folks happy, but is not helpful if you want to write your own > driver (for an OS that isn't Linux, for example). > > The moral of the story is that a lot of the debate about OSS is framed by > software people with a very strong Linux focus. They aren't hardware > engineers. It may have OSS but not be open hardware - indeed most devices > that run Linux aren't open hardware. > >> What part of the CPU chip on the rPi is not documented in the manual? >> It is large and I have not read it all of course, but I'm sure I would >> have heard in these discussions if there were any other part than the >> GPU that was driven by closed source code. > > There is no 'CPU chip', it's a system on chip, ie a paste together of > silicon and HDL IP from different vendors. Off the top of my head: > > 'The GPU': > The VideoCore GPU 'scalar/vector' processor (VPU) > The VideoCore GPU 'shader' processors (QPU) > The graphics pipeline (DMA, DAC, HDMI tranceiver, etc) > The DSI display output > The imaging pipeline (CSI, camera hardware) > Hardware encoders/decoders > Cache internals and memory controller > The Syonpsys USB core > The Arasan SDHCI core (any differences from the standard SDHCI) > Internal power control > Internal clock generation > Internal resets (if any, I'm unclear) > > There are probably other bits. Which of these bits are not fully documented (by "not fully" I mean as fully as digital logic is ever documented). I know the GPU is proprietary and only supported by an closed source binary module. I find it hard to believe the cache and memory controller are not fully documented for example. Is the USB core only supported with a binary core? How about the clock generator? You are saying there is source code, but no documentation? -- RickArticle: 158758
rickman wrote: > > Serial flash parts use extra board space and are a PITA to design in so > you can program on the board. The serial configuration of Xilinx parts > is also rather slow in comparison to the boot time of a internal flash > FPGA. I believe it is something like two orders of magnitude faster. > The Spartan 3AN is a bit of a joke in some respects, but if you are > using Xilinx parts I guess that is what you get. If it were a good > idea, why do they only do that on the 10 year old Spartan 3A line? > Well, the Spartan 3A is a very good price, if you don't need ultimate speed or vast density. It seems to work very well in the relatively modest projects I've been working on. JonArticle: 158759
Rick C. Hodgin wrote: > On the other hand, you're given a house. Great. You have a house. :-) > It comes from volunteers who heard about your need, and out of the love > of their heart built you a house. It's a gift, and the house will carry > with it that history. Every time you consider something about that house, > there will be that original offering given to you. > Well, that sounds like Habitat for Humanity. A good organization. Maybe you will be CPUs for Humanity? But, wasn't that what the Raspberry Pi was all about, initially? And, it is a LOT more computer than a '386, and no slave labor involved in Linux. As for making chips in your garage, besides the part about how difficult it will be to get the yield above 0.000%, once the EPA or the neighbors find out you are using Arsine, Phosphine and DiBorane in there, you will be doign very well if you can keep yourself out of a jail cell. Especially if you happen to be in California. JonArticle: 158760
Rick C. Hodgin wrote: > On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote: >> Rick C. Hodgin wrote: >> >> >> > >> > I figured the CPUs I'd make would cost $1,000 each in the early >> > samples, >> OK, the MOSIS standard order is for 40 parts. So, that's $40K each >> revision. Unless you are truly brilliant, it is going to take a BUNCH of >> respins of the part to get anything working. > > I can't remember who it was I searched a while back (2014 I think), but > I found a company that was manufacturing on 250nm and 500nm process > technologies. The mask sets were $15K each, and each run varied, but > the total cost for 100 parts was less than $100K including masks. That is quite amazing, and I find it VERY hard to believe that is in the US. If going offshore, you may well end up with Chinese or Malaysian practically-slave labor making the parts. > > Well, it's not a goal. It's not being done for money. I would like to > have > assistance from those who are willing to give. Yes, I got this part, but I think you are massively underestimating costs that will be hard to push down. I make electronic stuff for some VERY niche markets, and have some idea what various things cost to have done. Also, since working with having some custom chips made, I have some idea of the processes required, and the insane levels of clean room procedures, etc. to make stuff work at all. There are truck-movable clean room packages that you can buy, they roll it off the truck and slide it into your facility. So, there are outfits that are making various semiconductor products in house. I think a lot of them are diode laser manufacturers, however. Jon JonArticle: 158761
On Thursday, April 7, 2016 at 3:48:47 PM UTC-4, Jon Elson wrote: > Rick C. Hodgin wrote: > > > > On the other hand, you're given a house. Great. You have a house. :-) > > It comes from volunteers who heard about your need, and out of the love > > of their heart built you a house. It's a gift, and the house will carry > > with it that history. Every time you consider something about that house, > > there will be that original offering given to you. > > > Well, that sounds like Habitat for Humanity. A good organization. > Maybe you will be CPUs for Humanity? But, wasn't that what the Raspberry Pi > was all about, initially? And, it is a LOT more computer than a '386, and > no slave labor involved in Linux. I look at things like Stallman and Torvalds and their behavior, and that means something to me. It reflects the inner man, which is why I am in pursuit of these endeavors. That's all. > As for making chips in your garage, besides the part about how difficult it > will be to get the yield above 0.000%, once the EPA or the neighbors find > out you are using Arsine, Phosphine and DiBorane in there, you will be doign > very well if you can keep yourself out of a jail cell. Especially if you > happen to be in California. The term "garage" was metaphorical. It would be me and a small consortium of people working to produce these chips ourselves using equipment which is, by industry standards, antiquated, but still viable, rather than having them made through GlobalFoundries, for example. Best regards, Rick C. HodginArticle: 158762
On Thursday, April 7, 2016 at 3:57:30 PM UTC-4, Jon Elson wrote: > Rick C. Hodgin wrote: > > > On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote: > >> Rick C. Hodgin wrote: > >> > >> > >> > > >> > I figured the CPUs I'd make would cost $1,000 each in the early > >> > samples, > >> OK, the MOSIS standard order is for 40 parts. So, that's $40K each > >> revision. Unless you are truly brilliant, it is going to take a BUNCH of > >> respins of the part to get anything working. > > > > I can't remember who it was I searched a while back (2014 I think), but > > I found a company that was manufacturing on 250nm and 500nm process > > technologies. The mask sets were $15K each, and each run varied, but > > the total cost for 100 parts was less than $100K including masks. > That is quite amazing, and I find it VERY hard to believe that is in the US. > If going offshore, you may well end up with Chinese or Malaysian > practically-slave labor making the parts. I can't remember who it was. I have an email. Most of the companies I sought were unwilling to entertain a run of a single wafer. But a couple of them pointed me to smaller firms which specialize in one-off wafers. I contacted them asking for pricing of an approximately 200 mm^2 chip on 250nm to 500nm process technologies. That was the information I was given. Nothing formal. No contracts or an examination of any type of design. But, just a ball-park figure. > > Well, it's not a goal. It's not being done for money. I would like to > > have > > assistance from those who are willing to give. > Yes, I got this part, but I think you are massively underestimating costs > that will be hard to push down. I make electronic stuff for some VERY niche > markets, and have some idea what various things cost to have done. Also, > since working with having some custom chips made, I have some idea of the > processes required, and the insane levels of clean room procedures, etc. to > make stuff work at all. There are truck-movable clean room packages that > you can buy, they roll it off the truck and slide it into your facility. > So, there are outfits that are making various semiconductor products in > house. I think a lot of them are diode laser manufacturers, however. I have spent some time researching this industry, and the clean room requirements of 3,000 to 10,000 nm process technologies are significantly different than modern fabs' needs. But, I hear what you are saying, and I appreciate the information. I have been content to produce products which run in FPGA form on a little board which plugs in to my system, though I ultimately would like to create a completely integrated system with all components to have a fully functional real computer made atop this protractive effort. And, when I speak of these things, I always reference James 4:15, which is about acknowledging that the Lord may have other plans for me, and if so then I will follow Him. Best regards, Rick C. HodginArticle: 158763
On 4/7/2016 3:42 PM, Jon Elson wrote: > rickman wrote: > > >> >> Serial flash parts use extra board space and are a PITA to design in so >> you can program on the board. The serial configuration of Xilinx parts >> is also rather slow in comparison to the boot time of a internal flash >> FPGA. I believe it is something like two orders of magnitude faster. >> The Spartan 3AN is a bit of a joke in some respects, but if you are >> using Xilinx parts I guess that is what you get. If it were a good >> idea, why do they only do that on the 10 year old Spartan 3A line? >> > Well, the Spartan 3A is a very good price, if you don't need ultimate speed > or vast density. It seems to work very well in the relatively modest > projects I've been working on. Not trying to argue, but I don't see how they are at a good price. You can get many FPGAs at the same price range with *much* more capacity. The AN parts seem to have a price premium of around 20% and the flash parts from Lattice can be had a lower prices. Further, the AN flash parts are available in a lot fewer packages and none of them very small. A number of the Lattice parts can hold multiple configurations and switch in just a very few milliseconds. This sort of thing takes 100's of milliseconds in the Xilinx parts. That is the sort of difference you get when the parts are designed with flash in mind. The program memory in a Xilinx part is literally an afterthought. -- RickArticle: 158764
On 4/7/2016 4:17 PM, Rick C. Hodgin wrote: > On Thursday, April 7, 2016 at 3:57:30 PM UTC-4, Jon Elson wrote: >> Rick C. Hodgin wrote: >> >>> On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote: >>>> Rick C. Hodgin wrote: >>>> >>>> >>>>> >>>>> I figured the CPUs I'd make would cost $1,000 each in the early >>>>> samples, >>>> OK, the MOSIS standard order is for 40 parts. So, that's $40K each >>>> revision. Unless you are truly brilliant, it is going to take a BUNCH of >>>> respins of the part to get anything working. >>> >>> I can't remember who it was I searched a while back (2014 I think), but >>> I found a company that was manufacturing on 250nm and 500nm process >>> technologies. The mask sets were $15K each, and each run varied, but >>> the total cost for 100 parts was less than $100K including masks. >> That is quite amazing, and I find it VERY hard to believe that is in the US. >> If going offshore, you may well end up with Chinese or Malaysian >> practically-slave labor making the parts. > > I can't remember who it was. I have an email. Most of the companies I > sought were unwilling to entertain a run of a single wafer. But a couple > of them pointed me to smaller firms which specialize in one-off wafers. > I contacted them asking for pricing of an approximately 200 mm^2 chip on > 250nm to 500nm process technologies. That was the information I was > given. Nothing formal. No contracts or an examination of any type of > design. But, just a ball-park figure. You don't need a wafer to get a chip. There are foundries that will batch your design onto a shared wafer. You likely can't use a 500 nm process, but you can get a decent process that will be inexpensive. I recall the minimum price for a small chip would be in the low 10's of thousands. >>> Well, it's not a goal. It's not being done for money. I would like to >>> have >>> assistance from those who are willing to give. >> Yes, I got this part, but I think you are massively underestimating costs >> that will be hard to push down. I make electronic stuff for some VERY niche >> markets, and have some idea what various things cost to have done. Also, >> since working with having some custom chips made, I have some idea of the >> processes required, and the insane levels of clean room procedures, etc. to >> make stuff work at all. There are truck-movable clean room packages that >> you can buy, they roll it off the truck and slide it into your facility. >> So, there are outfits that are making various semiconductor products in >> house. I think a lot of them are diode laser manufacturers, however. > > I have spent some time researching this industry, and the clean room > requirements of 3,000 to 10,000 nm process technologies are significantly > different than modern fabs' needs. But, I hear what you are saying, and > I appreciate the information. I have been content to produce products > which run in FPGA form on a little board which plugs in to my system, > though I ultimately would like to create a completely integrated system > with all components to have a fully functional real computer made atop > this protractive effort. > > And, when I speak of these things, I always reference James 4:15, which > is about acknowledging that the Lord may have other plans for me, and if > so then I will follow Him. Plans are great, but does He have funding? -- RickArticle: 158765
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: > On 4/7/2016 6:23 AM, Theo Markettos wrote: [On the undocumented parts of the Raspberry Pi] > > There is no 'CPU chip', it's a system on chip, ie a paste together of > > silicon and HDL IP from different vendors. Off the top of my head: > > > > 'The GPU': > > The VideoCore GPU 'scalar/vector' processor (VPU) > > The VideoCore GPU 'shader' processors (QPU) > > The graphics pipeline (DMA, DAC, HDMI tranceiver, etc) > > The DSI display output > > The imaging pipeline (CSI, camera hardware) > > Hardware encoders/decoders > > Cache internals and memory controller > > The Syonpsys USB core > > The Arasan SDHCI core (any differences from the standard SDHCI) > > Internal power control > > Internal clock generation > > Internal resets (if any, I'm unclear) > > > > There are probably other bits. > > Which of these bits are not fully documented (by "not fully" I mean as > fully as digital logic is ever documented). I know the GPU is > proprietary and only supported by an closed source binary module. All of them. > I find it hard to believe the cache and memory controller are not fully > documented for example. Is the USB core only supported with a binary > core? How about the clock generator? You are saying there is source > code, but no documentation? You can find it hard to believe if you like. To repeat myself, in the USB case the driver is open source but documentation of the hardware is not. In the SDHCI case the core is based on a standard but the documentation for the specific IP core is not available. All the rest are controlled by the GPU with the ARM sending commands via the 'mailbox' interface: ie there is a software API, there is no hardware documentation. Look for them in: https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf or https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf - you won't find them. TheoArticle: 158766
On Thursday, April 7, 2016 at 5:20:10 PM UTC-4, David Brown wrote: > [snip] I appreciate your input, David. Your knowledge and experience serve many people well. They are assets to be sure. Best regards, Rick C. HodginArticle: 158767
Rick C. Hodgin wrote: > On Thursday, April 7, 2016 at 3:57:30 PM UTC-4, Jon Elson wrote: >> Rick C. Hodgin wrote: >> >> > On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote: >> >> Rick C. Hodgin wrote: >> >> >> >> >> >> > >> >> > I figured the CPUs I'd make would cost $1,000 each in the early >> >> > samples, >> >> OK, the MOSIS standard order is for 40 parts. So, that's $40K each >> >> revision. Unless you are truly brilliant, it is going to take a BUNCH >> >> of respins of the part to get anything working. >> > >> > I can't remember who it was I searched a while back (2014 I think), but >> > I found a company that was manufacturing on 250nm and 500nm process >> > technologies. The mask sets were $15K each, and each run varied, but >> > the total cost for 100 parts was less than $100K including masks. >> That is quite amazing, and I find it VERY hard to believe that is in the >> US. If going offshore, you may well end up with Chinese or Malaysian >> practically-slave labor making the parts. > > I can't remember who it was. I have an email. Most of the companies I > sought were unwilling to entertain a run of a single wafer. But a couple > of them pointed me to smaller firms which specialize in one-off wafers. Really, nobody will do a single wafer (even if that is what is supposed to be delivered) as so many things can go wrong. So, they run a couple wafers and give you the best one. And, the cost of the wafer disappears into the noise of the entire effort. The masks are the huge expense, and then once they are set up to run a specific process, it only costs a tiny bit of extra time to run a couple more through all the same steps. Many of the steps are done by pushing a boat of 25+ wafers through an oven all at the same time. JonArticle: 158768
rickman wrote: > > You don't need a wafer to get a chip. There are foundries that will > batch your design onto a shared wafer. You likely can't use a 500 nm > process, but you can get a decent process that will be inexpensive. I > recall the minimum price for a small chip would be in the low 10's of > thousands. MOSIS is still running the AMI (now ON Semi) C5N process, with 500 nm feature size. Now, we use it for mixed signal stuff that is very heavy on the analog side, but the process is CMOS with some high res poly. It is one of the cheaper processes they offer. JonArticle: 158769
On Thursday, April 7, 2016 at 6:40:48 PM UTC-4, Jon Elson wrote: > Rick C. Hodgin wrote: > > > On Thursday, April 7, 2016 at 3:57:30 PM UTC-4, Jon Elson wrote: > >> Rick C. Hodgin wrote: > >> > >> > On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote: > >> >> Rick C. Hodgin wrote: > >> >> > >> >> > >> >> > > >> >> > I figured the CPUs I'd make would cost $1,000 each in the early > >> >> > samples, > >> >> OK, the MOSIS standard order is for 40 parts. So, that's $40K each > >> >> revision. Unless you are truly brilliant, it is going to take a BUNCH > >> >> of respins of the part to get anything working. > >> > > >> > I can't remember who it was I searched a while back (2014 I think), but > >> > I found a company that was manufacturing on 250nm and 500nm process > >> > technologies. The mask sets were $15K each, and each run varied, but > >> > the total cost for 100 parts was less than $100K including masks. > >> That is quite amazing, and I find it VERY hard to believe that is in the > >> US. If going offshore, you may well end up with Chinese or Malaysian > >> practically-slave labor making the parts. > > > > I can't remember who it was. I have an email. Most of the companies I > > sought were unwilling to entertain a run of a single wafer. But a couple > > of them pointed me to smaller firms which specialize in one-off wafers. > > Really, nobody will do a single wafer (even if that is what is supposed to > be delivered) as so many things can go wrong. So, they run a couple wafers > and give you the best one. And, the cost of the wafer disappears into the > noise of the entire effort. The masks are the huge expense, and then once > they are set up to run a specific process, it only costs a tiny bit of extra > time to run a couple more through all the same steps. Many of the steps are > done by pushing a boat of 25+ wafers through an oven all at the same time. Makes sense. Good information. Thank you. Best regards, Rick C. HodginArticle: 158770
On Thursday, April 7, 2016 at 6:43:08 PM UTC-4, Jon Elson wrote: > rickman wrote: > > You don't need a wafer to get a chip. There are foundries that will > > batch your design onto a shared wafer. You likely can't use a 500 nm > > process, but you can get a decent process that will be inexpensive. I > > recall the minimum price for a small chip would be in the low 10's of > > thousands. > MOSIS is still running the AMI (now ON Semi) C5N process, with 500 nm > feature size. Now, we use it for mixed signal stuff that is very heavy on > the analog side, but the process is CMOS with some high res poly. It is one > of the cheaper processes they offer. For my needs, it will be a long time before I'm ready to go to a fab. My desire would be by July 12, 2022, which would be 10 years after I started this project, but that's just a target. I think if I was going to create a semiconductor fab, I would call it Sand Castles. :-) Best regards, Rick C. HodginArticle: 158771
On Thursday, April 7, 2016 at 5:25:04 PM UTC-4, Theo Markettos wrote: > In comp.arch.fpga rickman wrote: > > I find it hard to believe the cache and memory controller are not fully= =20 > > documented for example. Is the USB core only supported with a binary= =20 > > core? How about the clock generator? You are saying there is source= =20 > > code, but no documentation? >=20 > You can find it hard to believe if you like. To repeat myself, in the US= B > case the driver is open source but documentation of the hardware is not. = In > the SDHCI case the core is based on a standard but the documentation for = the > specific IP core is not available. >=20 Another example is the Texas Instruments AM3352 processor. That part has a= freely available ~5000 page technical reference manual that lists all of t= he myriad registers for all of the various subsystems (such as the two USB = cores) as well as the bit fields within the registers, but many of those fi= elds are totally undefined as to their function. TI supplies an RTOS as we= ll as Linux for the device. Unless you reverse engineer to create your own= documentation, using the OS is the only way to use that device. Unfortunately, I don't think undocumented hardware that is only supported a= t the software device driver level is that uncommon. Obviously 'someone' w= ould have to have the hardware documentation in order to write the device d= river(s), but that can be taken care of without divulging the documentation= outside of the company's control by writing and owning the device driver c= ode or contracting out the work only under NDA. Kevin JenningsArticle: 158772
On 4/7/2016 7:26 PM, KJ wrote: > On Thursday, April 7, 2016 at 5:25:04 PM UTC-4, Theo Markettos wrote: >> In comp.arch.fpga rickman wrote: >>> I find it hard to believe the cache and memory controller are not fully >>> documented for example. Is the USB core only supported with a binary >>> core? How about the clock generator? You are saying there is source >>> code, but no documentation? >> >> You can find it hard to believe if you like. To repeat myself, in the USB >> case the driver is open source but documentation of the hardware is not. In >> the SDHCI case the core is based on a standard but the documentation for the >> specific IP core is not available. >> > Another example is the Texas Instruments AM3352 processor. That part has a freely available ~5000 page technical reference manual that lists all of the myriad registers for all of the various subsystems (such as the two USB cores) as well as the bit fields within the registers, but many of those fields are totally undefined as to their function. TI supplies an RTOS as well as Linux for the device. Unless you reverse engineer to create your own documentation, using the OS is the only way to use that device. > > Unfortunately, I don't think undocumented hardware that is only supported at the software device driver level is that uncommon. Obviously 'someone' would have to have the hardware documentation in order to write the device driver(s), but that can be taken care of without divulging the documentation outside of the company's control by writing and owning the device driver code or contracting out the work only under NDA. I was talking about this because of the rPi and the controversy around the lack of source for the GPU. I thought that was the only binary code in the Linux package. Theo is saying that even though there are source codes for various other pieces of the chip, the pieces are not actually documented. That surprises me. But it's not the first time I've been surprised. :) BTW, I apologize to Theo if I sounded a bit stiff about this. I just don't like to fully believe something if there is doubt. But now that I have heard this from several people, I guess I should believe it. -- RickArticle: 158773
In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: > > I was talking about this because of the rPi and the controversy around > the lack of source for the GPU. I thought that was the only binary code > in the Linux package. Theo is saying that even though there are source > codes for various other pieces of the chip, the pieces are not actually > documented. That surprises me. But it's not the first time I've been > surprised. :) > Not so long ago there was a much-ballyhoo'd "release" of GPU documentation and a "contest" to use the GPU. The implication seemed to be that we'd see a GPU-accelerated X server in the not-too-distant future. Was that entirely of smoke and mirrors? Thanks for reading, bob prohaskaArticle: 158774
rickman wrote: > > Not trying to argue, but I don't see how they are at a good price. You > can get many FPGAs at the same price range with *much* more capacity. Yes, but in fact the smallest Spartan 3A or 3AN has been enough for a number of projects I am doing. So, I do not NEED the higher density, and certainly, the later rev Spartans go up to insane capacity, but I just don't need that. > The AN parts seem to have a price premium of around 20% and the flash > parts from Lattice can be had a lower prices. Further, the AN flash > parts are available in a lot fewer packages and none of them very small. > > A number of the Lattice parts can hold multiple configurations and > switch in just a very few milliseconds. And, I don't really need multiple configs in most of the things I'm doing. I prefer to be able to mail a new config to people and have them plug in a chip, if that is necessary. So, Xilinx is working for me. And, yes, after going to the trouble of getting comfortable in the Xilinx tools, the last thing I want to do is learn somebody else's tools' quirks. Jon
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