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 6/30/2013 5:01 AM, Tom Gardner wrote: > On 30/06/13 07:25, rickman wrote: >> On 6/29/2013 9:56 AM, Tom Gardner wrote: >>> On 29/06/13 14:10, Eric Wallin wrote: >>> >>>> I don't get all the accolades for Win7, it's a dog. >>> >>> Yes, but it is better than Vista, and the hacks don't feel so guilty >>> about supporting it. >>> >>> Good things about linux: fanbois are vocally and acerbically critical >>> when >>> things don't work smoothly, and then point you towards the many >>> alternatives >>> that /do/ work smoothly. >> >> Many of the Linux "fanbois" also expect all users to be geeks who are >> happy to dig into the machine to keep it humming. Most people don't >> want to know how it works under the hood, they just want it >> to work... like a car. Linux is no family sedan. That is what Windows >> tries to be with some moderate level of success. > > Many, but not all. > > One deep geek whose idea of an ideal distro is that "it just > works and lets me get on with what I want to do" is > http://www.dedoimedo.com/ > He savages distros that don't work out of the box. > > Have you looked at some of the modern distros? > They are easy to get going and easy to learn - arguably > easier than Windows8 judging by its reviews and > lack of uptake. > > Try Mint, or xubuntu. I had that conversation recently in one of the newsgroups and it ended up with an argument where at least one person was arguing that you shouldn't use a computer unless you are prepared to work on it. I don't want to have that discussion again. Maybe later. Linux reminds me of Forth in that regard. Someone said, "If you've seen one Forth, you've seen one Forth". There seem to be so many different Linux distros, one of them has to be good, right? Oh, BTW, one of the disk copy programs I tried to use installed a dual boot Linux partition on my laptop. It runs ok, but it craps out because it finds an error in one of the files... the exact sort of hard drive error that is the reason why I am trying to copy my hard drive to a new one. Maybe this is just the stupid program, but this is one reason why I don't think Linux is the answer to any problems I have. -- RickArticle: 155476
On 6/29/2013 5:14 AM, Tom Gardner wrote: > On 29/06/13 02:02, rickman wrote: >> On 6/28/2013 5:11 PM, Tom Gardner wrote: >>> On 28/06/13 20:06, rickman wrote: >>>> I think the trick will be in finding ways of dividing up the programs >>>> so they can meld to the hardware rather than trying to optimize >>>> everything. >>> >>> My suspicion is that, except for compute-bound >>> problems that only require "local" data, that >>> granularity will be too small. >>> >>> Examples where it will work, e.g. protein folding, >>> will rapidly migrate to CUDA and graphics processors. >> >> You are still thinking von Neumann. Any application can be broken down >> into small units and parceled out to small processors. But you have to >> think in those terms rather than just saying, "it >> doesn't fit". Of course it can fit! > > Regrettably not. People have been trying different > techniques for ~50 years, with varying degrees of > success as technology bottlenecks change. > The people working in those areas are highly > intelligent and motivated (e.g. high performance > computing research) and there is serious money > available (e.g. life sciences, big energy). > > As a good rule of thumb, if you can think of it, > they've already tried it and found where it does > and doesn't work. So you are saying that multiprocessors are dead on arrival? I don't think so. No one I have seen has started the design process from scratch thinking like they were designing hardware. How does a bee hive work? How about an ant farm? How do all the cells in your body work together? No, the fact that the answer has not been found does not mean it does not exist. >>>> Consider a chip where you have literally a trillion operations per >>>> second available all the time. Do you really care if half go to waste? >>>> I don't! I design FPGAs and I have never felt obliged (not >>>> since the early days anyway) to optimize the utility of each LUT and >>>> FF. No, it turns out the precious resource in FPGAs is routing and you >>>> can't do much but let the tools manage that anyway. >>> >>> Those internal FPGA constraints also have analogues at >>> a larger scale, e.g. ic pinout, backplanes, networks... >>> >>> >>>> So a fine grained processor array could be very effective if the >>>> programming can be divided down to suit. Maybe it takes 10 of these >>>> cores to handle 100 Mbps Ethernet, so what? Something like a >>>> browser might need to harness a couple of dozen. If the load slacks >>>> off and they are idling, so what? >>> >>> The fundamental problem is that in general as you make the >>> granularity smaller, the communications requirements >>> get larger. And vice versa :( >> >> Actually not. The aggregate comms requirements may increase, but we >> aren't sharing an Ethernet bus. All of the local processors talk to >> each other and less often have to talk to non-local >> processors. I think the phone company knows something about that. > > That works to an extent, particularly in "embarrassingly parallel" > problems such as telco systems. I know: I've architected and > implemented some :) > > It still has its limits in most interesting computing systems. Well, the other approaches are hitting a wall. It is clearly time for a change. You can say this or that doesn't work, but they have only been tried in very limited contexts. >>> I'm sort-of retired (I got sick of corporate in-fighting, >>> and I have my "drop dead money", so...) >> >> That's me too, but I found some work that is paying off very well now. >> So I've got a foot in both camps, retired, not retired... both are fun >> in their own way. But dealing with international shipping >> is a PITA. > > Or even sourcing some components, e.g. a MAX9979KCTK+D or +TD :( Yes, actually component lead time is a PITA. The orders are very "lumpy" as one of my customer contacts refers to it. So I'm not willing to inventory anything I don't have to. At this point that will only be connectors. >>> I regard golf as silly, despite having two courses in >>> walking distance. My equivalent of kayaking is flying >>> gliders. >> >> That has got to be fun! > > Probably better than you imaging (and that's recursive > without a terminating condition). I know instructors > that still have pleasant surprises after 50 years :) > > I did a tiny bit of kayaking on flat water, but now > I wear hearing aids :( One of my better kayaking friends has a cochlear implant with an external processor. She either wears her older back up processor or none at all. >> I've never worked up the whatever to learn to fly. > > Going solo is about as difficult as learning to drive > a car. And then the learning really starts :) Yes, but it is a lot more training than learning to drive and a lot more money. It is also a lot more demanding of scheduling in that you can't just say, "Dad, can I drive you to the store?" >> It seems like a big investment and not so cheap overall. > > Not in money. In the UK club membership is $500/year, > a launch + 10 mins instruction is $10, and an hour > instruction in the air is $30. The real cost is time: > club members help you get airborne, and you help them > in return. Very sociable, unlike aircraft with air > conditioning fans up front or scythes above. > > >> But there is clearly a great thrill there. > > 0-40kt in 3s, 0-50kt in 5s, climb with your feet > above your head, fly in close formation with raptors, > eyeball sheep on a hillside as you whizz past > below them at 60kt, 10-20kft, 40kt-150kt, hundreds > and thousands of km range, pre-solo spinning at > altitudes that make power pilots blanche, and > pre-solo flying in loose formation with other > aircraft. > > Let me know if you want pointers to youtube vids. Not at this time. I'm way too busy with other things including getting a hip replacement. -- RickArticle: 155477
On Sunday, June 30, 2013 12:03:45 PM UTC-4, Les Cargill wrote: > There is no > feedback path in the marketplace for us to express our disdain > over bloatware. I'd like to give the FPGA vendors a piece of my mind regarding their FPGA t= ools. Talk about the bloatiest of great white whale bloaty-bloat SW. Fire= up your virus scanner and go to bed, only to wake up and find it listlessl= y pawing C:\Altera or C:\Xilinx, wearing your hard drive head down to a blo= ody nub.Article: 155478
I am looking to incorporate the download capability for the Lattice USB download cable into a design. I found an app note on this but it uses a slightly old chip the FT2232D. FTDI refers to this chip as "Please note that the FT2232D is not an new generation of device." I assume they are indicating that you shouldn't start a new design with this chip, but I'm not sure. Looking at the XP2 development kit they seem to use the FT2232H with a slightly different schematic. They omit an analog switch which is used as a multiplexer to use the same pins for two different functions, JTAG and I2C. I guess in the XP2 design they don't need the I2C interface. Does anyone know which design is in the Lattice HW-USBN-2A cable? I also followed a number of links I found in the searches on this and found several projects for open source debugging cables using FTDI devices. One is OOCDLink with not so much documentation. Another is usbjtag which seems to be nothing but dead links at this point. There are others also. Looks like this FTDI chip could be a useful tool for JTAG debugging, but it is a little hard to corral the hardware. -- RickArticle: 155479
rickman <gnuarm@gmail.com> wrote: (snip) > The only fly in the ointment is that it isn't practical to combine an > x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great > idea. That might be practical in another 5 years when low end computers > are commonly using more than 16 GB of DRAM on the board. OK, but how about 4G of DRAM off chip, but in the same package. Maybe call it L4 cache instead of DRAM. Use a high interleave so you can keep the access rate up, and besides the cost of the wiring isn't so high as it would be outside the package. -- glenArticle: 155480
On 7/1/2013 2:51 AM, glen herrmannsfeldt wrote: > rickman<gnuarm@gmail.com> wrote: > > (snip) >> The only fly in the ointment is that it isn't practical to combine an >> x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great >> idea. That might be practical in another 5 years when low end computers >> are commonly using more than 16 GB of DRAM on the board. > > OK, but how about 4G of DRAM off chip, but in the same package. > Maybe call it L4 cache instead of DRAM. Use a high interleave so > you can keep the access rate up, and besides the cost of the wiring > isn't so high as it would be outside the package. How is that any real advantage? Once you go off chip you have suffered the slings and arrows of outrageous output drivers. -- RickArticle: 155481
On 01/07/13 09:07, rickman wrote: > On 7/1/2013 2:51 AM, glen herrmannsfeldt wrote: >> rickman<gnuarm@gmail.com> wrote: >> >> (snip) >>> The only fly in the ointment is that it isn't practical to combine an >>> x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great >>> idea. That might be practical in another 5 years when low end computers >>> are commonly using more than 16 GB of DRAM on the board. >> >> OK, but how about 4G of DRAM off chip, but in the same package. >> Maybe call it L4 cache instead of DRAM. Use a high interleave so >> you can keep the access rate up, and besides the cost of the wiring >> isn't so high as it would be outside the package. > > How is that any real advantage? Once you go off chip you have suffered > the slings and arrows of outrageous output drivers. > Making separate chips and putting them in the same package is the golden middle road here. You need output drivers - but you don't need the same sort of drivers as for separate chips on a motherboard. There are several differences - your wires are shorter (so less noise, better margins, easier timing, lower currents, lower power), you can have many more wires (broader paths means higher bandwidth), and you have dedicated links (better timing, easier termination, separate datapaths for each direction). It is particularly beneficial if the die are stacked vertically rather than horizontally - your inter-chip connections are minimal length, it's (relatively) easy to have huge parallel buses, and you can arrange the layout as you want. There is significant work being done in making chip packaging and driver types for exactly this sort of arrangement. It is perhaps more aimed at portable devices rather than big systems, but the idea is the same.Article: 155482
On Mon, 01 Jul 2013 00:58:08 -0400, rickman wrote: > I am looking to incorporate the download capability for the Lattice USB > download cable into a design. I found an app note on this but it uses a > slightly old chip the FT2232D. FTDI refers to this chip as "Please note > that the FT2232D is not an new generation of device." I assume they are > indicating that you shouldn't start a new design with this chip, but I'm > not sure. > > Looking at the XP2 development kit they seem to use the FT2232H with a > slightly different schematic. They omit an analog switch which is used > as a multiplexer to use the same pins for two different functions, JTAG > and I2C. I guess in the XP2 design they don't need the I2C interface. > > Does anyone know which design is in the Lattice HW-USBN-2A cable? > > I also followed a number of links I found in the searches on this and > found several projects for open source debugging cables using FTDI > devices. One is OOCDLink with not so much documentation. Another is > usbjtag which seems to be nothing but dead links at this point. There > are others also. > > Looks like this FTDI chip could be a useful tool for JTAG debugging, but > it is a little hard to corral the hardware. I did something similar in a 2009 design; I had an embedded x86 that needed to configure a Xilinx FPGA, so I put an FT2232H on the board as a USB-JTAG converter. Avoid the FT2232D if you can; you need the -H or one of the newer parts to get 480Mb/s USB 2.0. 12Mb/s seems so slow these days. I'm an X and A guy (no experience with Lattice) but I would hazard a guess that many different types of JTAG probes would work with your FPGA, given suitable driver software. Reverse engineer a few and find one with a design you like. There's nothing restricting you to a design from a (clearly old) Lattice app note. Regards, AllanArticle: 155483
rickman wrote: > On 6/30/2013 12:03 PM, Les Cargill wrote: >> rickman wrote: >>> On 6/29/2013 12:50 PM, Les Cargill wrote: >>>> rickman wrote: >>>>> >>>>> That's not the reason. Intel could buy any of the DRAM makers any day >>>>> of the week. >>>> >>>> >>>> I have to presume they "couldn't", because they didn't. >>> >>> That's a bit silly. Why would they want to? >> >> I presume for the same reasons that "soundcards" were added to >> motherboards. You lose traces, you lose connectors. > > The only fly in the ointment is that it isn't practical to combine an > x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great > idea. That might be practical in another 5 years when low end computers > are commonly using more than 16 GB of DRAM on the board. > > You presume a lot. That is not the same as it being correct. > > I am examining the "isn't practical" premise, and trying to do that without any preconceptions. I've seen ... high levels of integration in real life before - stuff you wouldn't normally think of as practical. Of *course* i don't know for sure - I wasn't there when it wasn't done... :) >> Right. > > >> Right! > > You seem to be learning... ;^) > > That's the goal! :) >>>>> In fact, Intel started out making DRAMs! >>>> >>>> Precisely! They did one of the first "bet the company" moves >>>> that resulted in the 4004. >>> >>> Making the 4004 was *not* a "bet the company" design. They did it under >>> contract for a calculator company who paid for the work. Intel took >>> virtually no risk in the matter. >>> >> >> Interestingly, many people say they took considerable risk. It was >> certainly disruptive. > > > Like who? What was the risk, that the calculator wouldn't work, they > wouldn't get the contract??? Where was the "considerable" risk? > Journalists, mainly. They're probably doing the usual; "constructing a narrative". There's a general credo in storyteller spheres that SiVa is all about doing crazy things . > Actually, there was little risk. Once they convinced the calculator > company that they could do it more cheaply it was an obvious move to > make. The technology was to the point where they could put a small CPU > on a chip (or chips) and make a fully functional computer. There was no > idea of becoming the huge computer giant. I am sure they realized that > this could become the basis of a very significant industry. So where > was the risk? > > As the story was told, the risk was mostly in what they'd have to do to adapt. >>>>> The main reason why main >>>>> memory isn't on the CPU chip is because there are lots of >>>>> variations in >>>>> size *and* that it just wouldn't fit! You don't put one DRAM chip in a >>>>> computer, they used to need a minimum of four, IIRC to make up a >>>>> module, >>>>> often they were 8 to a module and sometimes double sided with 16 chips >>>>> to a DRAM module. >>>>> >>>> >>>> If you were integrating inside the package, you could use any >>>> physical configuration you wanted. But the thing would still have been >>>> too big. >>> >>> Yes, I agree, main memory is too big to fit on the CPU die for any size >>> memory in common use at the time. Isn't that what I said? >>> >> >> If you did, I missed it. > > Uh, look above... > > "The main reason why main memory isn't on the CPU chip is because there > are lots of variations in size *and* that it just wouldn't fit!" > Well, I got that eventually - although I suppose I got hung up on "variations in size" - just pick one. <snip> >>> >>> Then why did you write "That's not generally the bottleneck"? >>> >> >> Because on most designs I have seen for the last decade or >> more, the memory bus is not the processor interconnect bus. > > What does that mean? I don't know what processor designs you have seen, > but all of the multicore stuff (which is what they have been building > for nearly a decade) is memory bus speed constrained because you have > two or three or four or eight processors sharing just one memory > interface or in some cases I believe they have used two. This is a > classic problem at this point referred to as the "memory wall". Google it. > > We're back to the interconnect bus vs. the memory bus distinction. Interconnects must be arbitrated or otherwise act like "networks"; what I am calling a memory bus does not have to. Sadly, now we have to distinguish between usage of these terms in whether it's multicore or not. FWIW, I have nearly avoided anything multicore in terms of my living successfully so far that does not run shrink wrap. >>>>> We >>>>> seem to be reaching the point that the improvements in processor speed >>>>> are all being consumed by the support software rather than getting to >>>>> the apps. >>>>> >>>> >>>> But things like BeOS and the like have been available, and remain >>>> widely unused. There is some massive culture fail in play; either >>>> that or things are just good enough. >>> >>> I'm not sure why you consider this to be a "culture" issue. Windows is >>> the dominant OS. >> >> Well - that is a cultural artifact. What else can it be? There is no >> feedback path in the marketplace for us to express our disdain >> over bloatware. > > You can't buy a computer with Linux or some other OS? > Linux isn't bloated? I don't know if you can buy something preloaded with BeOS or not. Used to be that specialist things like DAW machines used Be. > >>> It is very hard to work with other OSs because there >>> are so many fewer apps. I can design FPGAs only with Windows or Linux >>> and at one time I couldn't even use Linux unless I paid for the >>> software. BeOS doesn't run current Windows programs does it? >>> >> >> No. My point is that the culture does not reward minimalist >> software solutions unless they're in the control or embedded >> space. > > Why is that? Of course rewards are there for anyone who makes a better > product. > > Don't be silly. >>>> Heck, pad/phone computers do much much *less* than desktops and >>>> have the bullet in the market. You can't even type on them but people >>>> still try... >>> >>> They do some of the same things which are what most people need, but >>> they are very different products than what computers are. The market >>> evolved because the technology evolved. 10 years ago pads were mostly a >>> joke and there smart phones weren't really possible/practical. Now the >>> processors are fast enough running from battery that hand held computing >>> is practical and the market will turn that way some 99%. >> >> Phones and tablets are and will always be cheezy little non-computers. >> They don't have enough peripheral options to do anything >> besides post cat pictures to social media sites. > > Ok, another quote to go up there with "No one will need more than 640 > kBytes" and "I see little commercial potential for the internet for the > next 10 years." > Both of those are also true, given other constraints. I would say the commercial potential of the internet has been more limited than people would perhaps prefer. > I'll bet you have one of these things as a significant computing > platform in four years... you can quote me on that! > > We'll see - I can't find that today, and I have looked. Gave up in a fit of despair and bought a netbook. >> You *can* make serious control surface computers out of them, but >> they're no longer at a consumer-friendly price. And the purchasing >> window for them is very narrow, so managing market thrash is >> a problem. >> >>> Desktops will >>> always be around just as "workstations" are still around, but only in >>> very specialized, demanding applications. >>> >> >> Or they can be a laptop in a box. The world* is glued together by >> Visual Basic. Dunno if the Win8 tablets can be relied on to run that >> in a manner to support all that. >> >> *as opposed to the fantasy world - the Net - which is glued with Java. >> >> I expect the death of the desktop is greatly exaggerated. > > I don't know what the "death of the desktop" is, but I think you and I > will no longer have traditional computers (aka, laptops and desktops) as > anything but reserve computing platforms in six years. > We'll see. FWIW, the people that made this machine I am typing on now no longer make desktops, so I see something coming. Not sure what, though. > I am pretty much a Luddite when it comes new technology. Skepticism != Luddism. > I think most > of it is bogus crap. But I have seen the light of phones and tablets > and I am a believer. I have been shown the way and the way is good. > > Here's a clue to the future. How many here want to use Windows after > XP? Who likes Vista? Who likes Win7? Win8? They're all fine, so far. No trouble with Win7 or Win8 here. Win8 is far too clever but it works. > Is your new PC any faster > than your old PC (other than the increased memory for memory bound > apps)? Yes. But my old PC is a 3.0GHz monocore. The only reason I upgraded was that Silverlight stopped utilizing graphics cards. > PCs are reaching the wall while hand held devices aren't. There is more than one wall. > Handhelds will be catching up in six years and will be able to do all > the stuff you want from your computer today. Tomorrow's PC's, > meanwhile, won't be doing a lot more. So the gap will narrow and who > wants all the baggage of traditional PCs when they can use much more > convenient hand helds? I/O won't be a problem. Uh huh. Right :) > I think all the tablets > plug into a TV via HDMI and you can add a keyboard and mouse easily. That's true enough. But that isn't all the I/O I would need. It isn't even the right *software*. > So > there you have all the utility of a PC in a tiny form factor along with > all the advantages of the handheld when you want a handheld. > > If the FPGA design software ran on them well, I'd get one today. But I > need to wait a few more years for the gap to close. > Ironically, I expect Apple to sell desktops for quite some time. Other than that, here's to the gamers. -- Les CargillArticle: 155484
David Brown wrote: > On 01/07/13 09:07, rickman wrote: >> On 7/1/2013 2:51 AM, glen herrmannsfeldt wrote: >>> rickman<gnuarm@gmail.com> wrote: >>> >>> (snip) >>>> The only fly in the ointment is that it isn't practical to combine an >>>> x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great >>>> idea. That might be practical in another 5 years when low end computers >>>> are commonly using more than 16 GB of DRAM on the board. >>> >>> OK, but how about 4G of DRAM off chip, but in the same package. >>> Maybe call it L4 cache instead of DRAM. Use a high interleave so >>> you can keep the access rate up, and besides the cost of the wiring >>> isn't so high as it would be outside the package. >> >> How is that any real advantage? Once you go off chip you have suffered >> the slings and arrows of outrageous output drivers. >> > > Making separate chips and putting them in the same package is the golden > middle road here. You need output drivers - but you don't need the same > sort of drivers as for separate chips on a motherboard. There are > several differences - your wires are shorter (so less noise, better > margins, easier timing, lower currents, lower power), you can have many > more wires (broader paths means higher bandwidth), and you have > dedicated links (better timing, easier termination, separate datapaths > for each direction). It is particularly beneficial if the die are > stacked vertically rather than horizontally - your inter-chip > connections are minimal length, it's (relatively) easy to have huge > parallel buses, and you can arrange the layout as you want. > > There is significant work being done in making chip packaging and driver > types for exactly this sort of arrangement. It is perhaps more aimed at > portable devices rather than big systems, but the idea is the same. > This is what I was meaning - although I don't know enough deeply enough about DRAM to know what the slings and arrows are. DRAM still seem like magic to me, in a way. Magic I am used to, but still.... -- Les CargillArticle: 155485
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> OK, but how about 4G of DRAM off chip, but in the same package. >> Maybe call it L4 cache instead of DRAM. Use a high interleave so >> you can keep the access rate up, and besides the cost of the wiring >> isn't so high as it would be outside the package. > How is that any real advantage? Once you go off chip you > have suffered the slings and arrows of outrageous output drivers. It must help some, or Intel wouldn't have put the off chip in package cache on some processors. Pentium pro if I remember, and maybe Pentium 2. Yes it is off chip and requires drivers, but the capacitance will be less than off package, the distance (speed of light) delay will be less, and known. The drivers can be sized optimally for the needed speed and distance. -- glenArticle: 155486
On 7/1/2013 7:09 AM, David Brown wrote: > On 01/07/13 09:07, rickman wrote: >> On 7/1/2013 2:51 AM, glen herrmannsfeldt wrote: >>> rickman<gnuarm@gmail.com> wrote: >>> >>> (snip) >>>> The only fly in the ointment is that it isn't practical to combine an >>>> x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a great >>>> idea. That might be practical in another 5 years when low end computers >>>> are commonly using more than 16 GB of DRAM on the board. >>> >>> OK, but how about 4G of DRAM off chip, but in the same package. >>> Maybe call it L4 cache instead of DRAM. Use a high interleave so >>> you can keep the access rate up, and besides the cost of the wiring >>> isn't so high as it would be outside the package. >> >> How is that any real advantage? Once you go off chip you have suffered >> the slings and arrows of outrageous output drivers. >> > > Making separate chips and putting them in the same package is the golden > middle road here. You need output drivers - but you don't need the same > sort of drivers as for separate chips on a motherboard. There are > several differences - your wires are shorter (so less noise, better > margins, easier timing, lower currents, lower power), you can have many > more wires (broader paths means higher bandwidth), and you have > dedicated links (better timing, easier termination, separate datapaths > for each direction). It is particularly beneficial if the die are > stacked vertically rather than horizontally - your inter-chip > connections are minimal length, it's (relatively) easy to have huge > parallel buses, and you can arrange the layout as you want. Yes, there are some advantages to combining die within a package, but there are lots of downsides too. The real issue is that it doesn't solve any of the problems PCs are facing. The drivers might be a little smaller, but they are still orders of magnitude bigger and slower than staying on chip. How fast does level 1 cache run? At the processor clock speed in all cases I've seen. Level 2 is a bit slower and I think the main difference between level 2 and level 3 is not the speed, but the complexity of the management (correct me if I am wrong). So even level 3 cache runs at half the speed of the CPU or at minimum over a GHz. Going off the die you won't get that sort of speed and you still have the same SI issues of boards (like ground bounce) even if they aren't as pronounced. TI produced a version of their cell phone ARM chip which has the memory chip soldered directly on top. That would be very close to a multichip module. I don't know how popular it ended up being. They used it on the BeagleBoard but I think for most apps and assembly houses this is just *too* fancy. Multichip modules just plain cost too much for most uses. > There is significant work being done in making chip packaging and driver > types for exactly this sort of arrangement. It is perhaps more aimed at > portable devices rather than big systems, but the idea is the same. Do you know of anyone currently working to combine the CPU and main memory? There are numerous reasons why this is a bad idea, even if they are still separate chips. But that may change as requirements change. Who knows? In the portable market there does seem to be a fat sweet spot in the center of memory sizes where you could get by with a single memory size. We may see a multichip module for that some day... but not until it is actually solving some problem you can't get around using separate packages. -- RickArticle: 155487
On 7/1/2013 9:01 AM, Les Cargill wrote: > David Brown wrote: >> >> There is significant work being done in making chip packaging and driver >> types for exactly this sort of arrangement. It is perhaps more aimed at >> portable devices rather than big systems, but the idea is the same. >> > > This is what I was meaning - although I don't know enough deeply enough > about DRAM to know what the slings and arrows are. > > DRAM still seem like magic to me, in a way. Magic I am used to, but > still.... Yeah, it *is* magic in a way. They have spent an awful lot of money over the years optimizing the whole DRAM thing. When I studied semiconductor physics many years ago in school I was told that the cutting edge of this stuff was just measurements and the theory was always lagging behind. The lab tries a bunch of stuff to measure the results of varying the parameters and the factory gets to fine tune it. With each new process generation they get to start again. -- RickArticle: 155488
On 7/1/2013 1:46 PM, glen herrmannsfeldt wrote: > rickman<gnuarm@gmail.com> wrote: > > (snip, I wrote) > >>> OK, but how about 4G of DRAM off chip, but in the same package. >>> Maybe call it L4 cache instead of DRAM. Use a high interleave so >>> you can keep the access rate up, and besides the cost of the wiring >>> isn't so high as it would be outside the package. > >> How is that any real advantage? Once you go off chip you >> have suffered the slings and arrows of outrageous output drivers. > > It must help some, or Intel wouldn't have put the off chip > in package cache on some processors. Pentium pro if I remember, > and maybe Pentium 2. > > Yes it is off chip and requires drivers, but the capacitance will > be less than off package, the distance (speed of light) delay > will be less, and known. The drivers can be sized optimally for > the needed speed and distance. That was a long time ago and it was more about the fact that PC makers didn't know how to design high speed PCBs. So Intel wrapped all that up in a module so the motherboard makers didn't have to think about it. Selling the CPU on its own board along with the cache didn't make the cache run faster, it just made it work! After all, it was still the exact same circuit, it was just pre-fabbed. The problem came back when the SDRAM got faster at higher clock speeds. I remember all the theories of how this brand of memory module was crap and that one was golden and how this motherboard could only take RAM in two of the sockets before it went wonkey, blah, blah, blah... all of it was caused by the motherboard makers not knowing how to design high speed traces on a PCB. So the combos of MB and DRAM modules was a hit or miss proposition. I don't recall which generation of DRAM it was, but eventually they moved to point to point signals so there wouldn't be any more multi-driver busses which are very hard to design at 800 MHz. -- RickArticle: 155489
On 7/1/2013 8:59 AM, Les Cargill wrote: > rickman wrote: >> On 6/30/2013 12:03 PM, Les Cargill wrote: > > I am examining the "isn't practical" premise, and trying to do that > without any preconceptions. I've seen ... high levels of integration > in real life before - stuff you wouldn't normally think of > as practical. > > Of *course* i don't know for sure - I wasn't there when > it wasn't done... :) I'm not saying you *can't* combine SDRAM and an x86 CPU. This may have been done by someone at some point. I'm saying it isn't practical for mainstream uses. It won't show up at Best Buy in the next five years. But who knows beyond that? I think the PC market is headed for a dramatic change within the next five years. Handhelds are taking computing in a very new direction and the momentum is reaching the critical point. >>> Interestingly, many people say they took considerable risk. It was >>> certainly disruptive. >> >> >> Like who? What was the risk, that the calculator wouldn't work, they >> wouldn't get the contract??? Where was the "considerable" risk? >> > > Journalists, mainly. They're probably doing the usual; "constructing a > narrative". There's a general credo in storyteller spheres that SiVa is > all about doing crazy things . > >> Actually, there was little risk. Once they convinced the calculator >> company that they could do it more cheaply it was an obvious move to >> make. The technology was to the point where they could put a small CPU >> on a chip (or chips) and make a fully functional computer. There was no >> idea of becoming the huge computer giant. I am sure they realized that >> this could become the basis of a very significant industry. So where >> was the risk? >> >> > > As the story was told, the risk was mostly in what they'd have to do to > adapt. I don't know what that means. >>>>>> The main reason why main >>>>>> memory isn't on the CPU chip is because there are lots of >>>>>> variations in >>>>>> size *and* that it just wouldn't fit! You don't put one DRAM chip >>>>>> in a >>>>>> computer, they used to need a minimum of four, IIRC to make up a >>>>>> module, >>>>>> often they were 8 to a module and sometimes double sided with 16 >>>>>> chips >>>>>> to a DRAM module. >>>>>> >>>>> >>>>> If you were integrating inside the package, you could use any >>>>> physical configuration you wanted. But the thing would still have been >>>>> too big. >>>> >>>> Yes, I agree, main memory is too big to fit on the CPU die for any size >>>> memory in common use at the time. Isn't that what I said? >>>> >>> >>> If you did, I missed it. >> >> Uh, look above... >> >> "The main reason why main memory isn't on the CPU chip is because there >> are lots of variations in size *and* that it just wouldn't fit!" >> > > Well, I got that eventually - although I suppose I got hung up on > "variations in size" - just pick one. But it is *both* as well as the processing technology mismatch. The trifecta! >>>> Then why did you write "That's not generally the bottleneck"? >>>> >>> >>> Because on most designs I have seen for the last decade or >>> more, the memory bus is not the processor interconnect bus. >> >> What does that mean? I don't know what processor designs you have seen, >> but all of the multicore stuff (which is what they have been building >> for nearly a decade) is memory bus speed constrained because you have >> two or three or four or eight processors sharing just one memory >> interface or in some cases I believe they have used two. This is a >> classic problem at this point referred to as the "memory wall". Google >> it. >> >> > > We're back to the interconnect bus vs. the memory bus distinction. > Interconnects must be arbitrated or otherwise act like "networks"; > what I am calling a memory bus does not have to. > > Sadly, now we have to distinguish between usage of these terms in > whether it's multicore or not. > > FWIW, I have nearly avoided anything multicore in terms of my living > successfully so far that does not run shrink wrap. I'm not sure what this means. >>> Phones and tablets are and will always be cheezy little non-computers. >>> They don't have enough peripheral options to do anything >>> besides post cat pictures to social media sites. >> >> Ok, another quote to go up there with "No one will need more than 640 >> kBytes" and "I see little commercial potential for the internet for the >> next 10 years." >> > > Both of those are also true, given other constraints. I would say > the commercial potential of the internet has been more limited > than people would perhaps prefer. What?? We left 640 kB behind before we left MS-DOS behind!!! The Internet is the biggest commercial opportunity since the baby boom! >> I'll bet you have one of these things as a significant computing >> platform in four years... you can quote me on that! >> >> > > We'll see - I can't find that today, and I have looked. Gave up in a > fit of despair and bought a netbook. You can't find what today? >>> You *can* make serious control surface computers out of them, but >>> they're no longer at a consumer-friendly price. And the purchasing >>> window for them is very narrow, so managing market thrash is >>> a problem. >>> >>>> Desktops will >>>> always be around just as "workstations" are still around, but only in >>>> very specialized, demanding applications. >>>> >>> >>> Or they can be a laptop in a box. The world* is glued together by >>> Visual Basic. Dunno if the Win8 tablets can be relied on to run that >>> in a manner to support all that. >>> >>> *as opposed to the fantasy world - the Net - which is glued with Java. >>> >>> I expect the death of the desktop is greatly exaggerated. >> >> I don't know what the "death of the desktop" is, but I think you and I >> will no longer have traditional computers (aka, laptops and desktops) as >> anything but reserve computing platforms in six years. >> > > We'll see. FWIW, the people that made this machine I am typing on now > no longer make desktops, so I see something coming. Not sure what, though. That is the point. No one knows for sure or they would already be there. As they push on the technology they make changes like DNA evolving. Some survive some pass on. But with each generation we get adaptation. When there is more severe pressure, there is greater change. The change in technology provides fertile ground for mutations and the change in computing happens faster giving use things we didn't know we wanted. But we do want and we will change what we buy. I just want a big screen and a keyboard... or so I think. I've been thinking for the last few years a big flat TV would do nicely as my screen and I can have a keyboard with me even more easily than my 17" laptop. So why wouldn't a tablet with say a 128 GB flash drive make my day? Right now the only limitation is the lack of support for Android by the FPGA software vendors. I can't imagine that isn't going to change soon. >> I am pretty much a Luddite when it comes new technology. > > Skepticism != Luddism. Ok, I'm also a curmudgeon. >> I think most >> of it is bogus crap. But I have seen the light of phones and tablets >> and I am a believer. I have been shown the way and the way is good. >> >> Here's a clue to the future. How many here want to use Windows after >> XP? Who likes Vista? Who likes Win7? Win8? > > > They're all fine, so far. No trouble with Win7 or Win8 here. Win8 is > far too clever but it works. Ask around, very few here like anything after XP. >> Is your new PC any faster >> than your old PC (other than the increased memory for memory bound >> apps)? > > Yes. But my old PC is a 3.0GHz monocore. > > The only reason I upgraded was that Silverlight stopped utilizing > graphics cards. Silverlight was one of the first things I turned off! What does it do that you or I need? >> PCs are reaching the wall while hand held devices aren't. > > There is more than one wall. Uh, what? >> Handhelds will be catching up in six years and will be able to do all >> the stuff you want from your computer today. Tomorrow's PC's, >> meanwhile, won't be doing a lot more. So the gap will narrow and who >> wants all the baggage of traditional PCs when they can use much more >> convenient hand helds? I/O won't be a problem. > > Uh huh. Right :) > >> I think all the tablets >> plug into a TV via HDMI and you can add a keyboard and mouse easily. > > That's true enough. But that isn't all the I/O I would need. It isn't > even the right *software*. Ok, what software do you need? It will be available on tablets running either Android or who knows, MS may be able to throw their 600 pound gorilla Windows into the tablet market. I mean, if the hardware keeps pumping up and the market pressures squeeze Windows down to something more like 2000 or XP in a couple more years it won't be the worst match ever. >> So >> there you have all the utility of a PC in a tiny form factor along with >> all the advantages of the handheld when you want a handheld. >> >> If the FPGA design software ran on them well, I'd get one today. But I >> need to wait a few more years for the gap to close. >> > > > Ironically, I expect Apple to sell desktops for quite some time. Other > than that, here's to the gamers. Some years ago when the fortunes of Apple was less certain I predicted that my friend who worked at a newspaper would be switching to a PC because Apple would be going under. Then they came out with I guess the iPod... wow! Then the iPhone, more wow! So my predictions of their demise was a bit premature... The point though is that the newspaper was full of Macs because the software was so much better for their needs than anything on the PC. Newspapers, etc will be running desktops for some time because they need the BIG screens. But the software gap has closed. So the PC is suitable for graphic arts now. Once they learn that they don't need the hunk of iron to power their 26" screens anymore, they will be changing. In fact, they may "get it" before the rest of us. -- RickArticle: 155490
On 7/1/2013 8:02 AM, Allan Herriman wrote: > On Mon, 01 Jul 2013 00:58:08 -0400, rickman wrote: >> >> Looks like this FTDI chip could be a useful tool for JTAG debugging, but >> it is a little hard to corral the hardware. > > > I did something similar in a 2009 design; I had an embedded x86 that > needed to configure a Xilinx FPGA, so I put an FT2232H on the board as a > USB-JTAG converter. > > Avoid the FT2232D if you can; you need the -H or one of the newer parts > to get 480Mb/s USB 2.0. 12Mb/s seems so slow these days. > > I'm an X and A guy (no experience with Lattice) but I would hazard a > guess that many different types of JTAG probes would work with your FPGA, > given suitable driver software. Reverse engineer a few and find one with > a design you like. There's nothing restricting you to a design from a > (clearly old) Lattice app note. Yes, that is what I am thinking. But I'm looking for hard info to minimize my development time. The "suitable driver software" means using the Lattice software which should just work. Once we are finished testing the next batch of boards I will pry open the JTAG cable Lattice sells. Although I bought it back in 2008 so it likely has the 2232D design. I'm concerned about the software not liking what I build. It *is* pretty touchy software and there is a small flash part that needs to be programmed just right. What did you have to do to get yours to work with the X part? Where did you get the flash programming file? -- RickArticle: 155491
On 01/07/13 23:26, rickman wrote: > On 7/1/2013 7:09 AM, David Brown wrote: >> On 01/07/13 09:07, rickman wrote: >>> On 7/1/2013 2:51 AM, glen herrmannsfeldt wrote: >>>> rickman<gnuarm@gmail.com> wrote: >>>> >>>> (snip) >>>>> The only fly in the ointment is that it isn't practical to combine an >>>>> x86 CPU with 4 GB of DRAM on a single chip. Oh well, otherwise a >>>>> great >>>>> idea. That might be practical in another 5 years when low end >>>>> computers >>>>> are commonly using more than 16 GB of DRAM on the board. >>>> >>>> OK, but how about 4G of DRAM off chip, but in the same package. >>>> Maybe call it L4 cache instead of DRAM. Use a high interleave so >>>> you can keep the access rate up, and besides the cost of the wiring >>>> isn't so high as it would be outside the package. >>> >>> How is that any real advantage? Once you go off chip you have suffered >>> the slings and arrows of outrageous output drivers. >>> >> >> Making separate chips and putting them in the same package is the golden >> middle road here. You need output drivers - but you don't need the same >> sort of drivers as for separate chips on a motherboard. There are >> several differences - your wires are shorter (so less noise, better >> margins, easier timing, lower currents, lower power), you can have many >> more wires (broader paths means higher bandwidth), and you have >> dedicated links (better timing, easier termination, separate datapaths >> for each direction). It is particularly beneficial if the die are >> stacked vertically rather than horizontally - your inter-chip >> connections are minimal length, it's (relatively) easy to have huge >> parallel buses, and you can arrange the layout as you want. > > Yes, there are some advantages to combining die within a package, but > there are lots of downsides too. The real issue is that it doesn't > solve any of the problems PCs are facing. The drivers might be a little > smaller, but they are still orders of magnitude bigger and slower than > staying on chip. The drivers are not a big issue - they are /much/ smaller and lower power than you need for separate packages. With die-on-die stacking, you need to drive your inter-chip buses over a length of perhaps 2 mm, compared to at least 20 cm on a motherboard. That's a factor of 100 difference. The inter-chip "buses" are far shorter than on-die buses. And as I explained above, there are many other factors making the buses far faster for die-on-die as compared to motherboard buses. The biggest issue with die-on-die stacking is getting the power into the part, and getting the heat out. Modern fast memory modules come with heat sinks and even fans - even without their driver circuits they still need a lot of power. > How fast does level 1 cache run? At the processor > clock speed in all cases I've seen. L1 cache is often slower than the processor clock, but wider than the cpu (especially for instruction cache). As always, details vary for different architectures. > Level 2 is a bit slower and I think > the main difference between level 2 and level 3 is not the speed, but > the complexity of the management (correct me if I am wrong). You are wrong. L3 runs at slower clock speeds and larger latencies than L2 - these are hierarchical. Depending on the architecture, L3 bandwidth might well be similar to L2 by using wider buses, but memory always has a tradeoff between speed, power-consumption and area. The reason you have different cache levels is to have different points in that trade-off curve. Additionally, different cache levels will have different types of associativity, and different ways of dealing with inter-cache coherence and multiple processors. The details here vary between architectures. > So even > level 3 cache runs at half the speed of the CPU or at minimum over a > GHz. L3 cache typically runs at far less than half the CPU clock on fast processors. > Going off the die you won't get that sort of speed and you still > have the same SI issues of boards (like ground bounce) even if they > aren't as pronounced. It is true that you will not get quite the same speeds if you go off-die, and you will see some SI issues (your lines no longer lie across power-planes, for example). But the whole point is that you get far faster buses, for much lower power, than if the memory was on the other side of the motherboard. /That/ is the comparison you need to make, not the comparison to on-die memory. Note that many processors have had off-die cache over the years - sometimes as separate chips, sometimes as separate dies within the same package. > > TI produced a version of their cell phone ARM chip which has the memory > chip soldered directly on top. That would be very close to a multichip > module. I don't know how popular it ended up being. They used it on > the BeagleBoard but I think for most apps and assembly houses this is > just *too* fancy. > > Multichip modules just plain cost too much for most uses. Chip-on-chip packaging is a definite hit for systems that need to be small (that's the main reason for this package, rather than speed). Any assembly house that is happy with these fine-pitched BGA's should be able to handle chip-on-chip. But you are right that it is an extra cost. Die-on-die stacking inside packages is in common use inside memory chips - both dynamic ram and flash chips use it. But in the great majority of cases so far, these are symmetrical - you have multiple identical dies. The challenge for cpu manufactures is to have different types of die in the same package, and especially for such high-power dies. > > >> There is significant work being done in making chip packaging and driver >> types for exactly this sort of arrangement. It is perhaps more aimed at >> portable devices rather than big systems, but the idea is the same. > > Do you know of anyone currently working to combine the CPU and main > memory? There are numerous reasons why this is a bad idea, even if they > are still separate chips. But that may change as requirements change. > Who knows? In the portable market there does seem to be a fat sweet > spot in the center of memory sizes where you could get by with a single > memory size. We may see a multichip module for that some day... but not > until it is actually solving some problem you can't get around using > separate packages. > <http://www.theregister.co.uk/2012/02/24/3d_chips/> In big systems, there will always be off-package memory as well of course.Article: 155492
This is a multi-part message in MIME format.
--------------000301080904010205040303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I am unsuccessfully trying to update Spartan6 CRC checksums after I make
packet modifications. This is not a problem for Virtex/E/2/2P/4/5/6/7
or for Spartan3E, but Spartan6 is a different story altogether. I
posted this same question on Xilinx Forums, but there have been no
responses.
I know that Spartan6 packets consist of 16-bit words, unlike the 32-bit
words of the other architectures listed above. UG380 also states that
"The Cyclic Redundancy Check register utilizes a standard 32-bit CRC
checksum algorithm." My perhaps incorrect assumption is that the
polynomial is the same CRC-32C (Castagnoli) polynomial as for
Virtex4/5/6/7 families. I am also assuming that only "payload words"
(after the packet header) factor into the calculation, just as with the
other architectures, and UG380 explicitly shows the address length as 6
bits.
Does anybody know how to calculate this correctly for Spartan6? If
anyone cares to see the logic I'm trying to use, it's quite similar to
what works correctly for all the other Xilinx architectures:
// begin CRC calculation
uint32_t address = 0;
iterator p = begin();
iterator e = end();
// CRC-32C (Castagnoli) polynomial for Virtex4/5/6/7 families
boost::crc_basic<32> crc32(0x1edc6f41, 0, 0, false, true);
while(p < e) {
// look up the current packet
const Spartan6Packet& packet = *p++;
// only process write packets with non-zero payload length
if(!packet.isWrite()) continue;
address = packet.getAddress();
uint32_t wordCount = packet.getWordCount();
if(wordCount == 0) continue;
// CRC register write (this is what compares the expected and
supplied CRC values)
if(address == crcRegister) {
printf("Expected CRC32: %8.8x\n", (uint32_t(packet[1]) <<
16) | packet[2]);
printf("Calculated CRC32: %8.8x\n", crc32.checksum());
*(p-1) = Spartan6Packet::makeType1Write(crcRegister,
crc32.checksum());
crc32.reset();
// reset CRC command
} else if(address == cmdRegister && wordCount >= 1 && packet[1]
== rcrcCommand) {
crc32.reset();
// process packet contents
} else {
uint32_t j;
uint32_t mask;
for(uint32_t i = 1; i <= wordCount; i++) {
uint32_t word = packet[i];
//printf("Address: %4.4x\n", address);
//printf("Word: %8.8x\n", word);
for(j = 0, mask = 1; j < 16; j++, mask <<= 1) {
crc32.process_bit((word & mask) ? 1 : 0);
}
for(j = 0, mask = 1; j < addressLength; j++, mask <<= 1) {
crc32.process_bit((address & mask) ? 1 : 0);
}
}
// process the Auto CRC
if(autoCrc && address == fdriRegister) {
printf("Expected Auto CRC32: %8.8x\n",
(uint32_t((*p)[0]) << 16) | (*p)[1]);
printf("Calculated Auto CRC32: %8.8x\n", crc32.checksum());
*p = Spartan6Packet(crc32.checksum()); // current
packet is FDRI, next is Auto CRC
crc32.reset();
}
}
}
--------------000301080904010205040303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I am unsuccessfully trying to update Spartan6 CRC checksums after I
make packet modifications. This is not a problem for
Virtex/E/2/2P/4/5/6/7 or for Spartan3E, but Spartan6 is a different
story altogether. I posted this same question on Xilinx Forums, but
there have been no responses.<br>
<br>
I know that Spartan6 packets consist of 16-bit words, unlike the
32-bit words of the other architectures listed above. UG380 also
states that "The Cyclic Redundancy Check register utilizes a
standard 32-bit CRC checksum algorithm." My perhaps incorrect
assumption is that the polynomial is the same CRC-32C (Castagnoli)
polynomial as for Virtex4/5/6/7 families. I am also assuming that
only "payload words" (after the packet header) factor into the
calculation, just as with the other architectures, and UG380
explicitly shows the address length as 6 bits.<br>
<br>
Does anybody know how to calculate this correctly for Spartan6? If
anyone cares to see the logic I'm trying to use, it's quite similar
to what works correctly for all the other Xilinx architectures:<br>
<blockquote><font color="#006600"><tt>// begin CRC calculation</tt></font><br>
<tt>uint32_t address = 0;</tt><br>
<tt>iterator p = begin();</tt><br>
<tt>iterator e = end();</tt><br>
<font color="#006600"><tt>// CRC-32C (Castagnoli) polynomial for
Virtex4/5/6/7 families</tt></font><br>
<tt>boost::crc_basic<32> crc32(0x1edc6f41, 0, 0, false,
true);</tt><br>
<tt>while(p < e) {</tt><br>
<font color="#006600"><tt> // look up the current packet</tt></font><br>
<tt> const Spartan6Packet& packet = *p++;</tt><br>
<font color="#006600"><tt> // only process write packets with
non-zero payload length</tt></font><br>
<tt> if(!packet.isWrite()) continue;</tt><br>
<tt> address = packet.getAddress();</tt><br>
<tt> uint32_t wordCount = packet.getWordCount();</tt><br>
<tt> if(wordCount == 0) continue;</tt><br>
<font color="#006600"><tt> // CRC register write (this is what
compares the expected and supplied CRC values)</tt></font><br>
<tt> if(address == crcRegister) {</tt><br>
<tt> printf("Expected CRC32: %8.8x\n",
(uint32_t(packet[1]) << 16) | packet[2]);</tt><br>
<tt> printf("Calculated CRC32: %8.8x\n", crc32.checksum());</tt><br>
<tt> *(p-1) = Spartan6Packet::makeType1Write(crcRegister,
crc32.checksum());</tt><br>
<tt> crc32.reset();</tt><br>
<font color="#006600"><tt> // reset CRC command</tt></font><br>
<tt> } else if(address == cmdRegister && wordCount
>= 1 && packet[1] == rcrcCommand) {</tt><br>
<tt> crc32.reset();</tt><br>
<font color="#006600"><tt> // process packet contents</tt></font><br>
<tt> } else {</tt><br>
<tt> uint32_t j;</tt><br>
<tt> uint32_t mask;</tt><br>
<tt> for(uint32_t i = 1; i <= wordCount; i++) {</tt><br>
<tt> uint32_t word = packet[i];</tt><br>
<font color="#006600"><tt> //printf("Address: %4.4x\n",
address);</tt><br>
<tt> //printf("Word: %8.8x\n", word);</tt></font><br>
<tt> for(j = 0, mask = 1; j < 16; j++, mask
<<= 1) {</tt><br>
<tt> crc32.process_bit((word & mask) ? 1 : 0);</tt><br>
<tt> }</tt><br>
<tt> for(j = 0, mask = 1; j < addressLength; j++,
mask <<= 1) {</tt><br>
<tt> crc32.process_bit((address & mask) ? 1 :
0);</tt><br>
<tt> }</tt><br>
<tt> }</tt><br>
<font color="#006600"><tt> // process the Auto CRC</tt></font><br>
<tt> if(autoCrc && address == fdriRegister) {</tt><br>
<tt> printf("Expected Auto CRC32: %8.8x\n",
(uint32_t((*p)[0]) << 16) | (*p)[1]);</tt><br>
<tt> printf("Calculated Auto CRC32: %8.8x\n",
crc32.checksum());</tt><br>
<tt> *p = Spartan6Packet(crc32.checksum()); <font
color="#006600">// current packet is FDRI, next is Auto CRC</font></tt><br>
<tt> crc32.reset();</tt><br>
<tt> }</tt><br>
<tt> }</tt><br>
<tt>}</tt><br>
</blockquote>
<br>
</body>
</html>
--------------000301080904010205040303--
Article: 155493rickman wrote: > On 7/1/2013 8:59 AM, Les Cargill wrote: >> rickman wrote: >>> On 6/30/2013 12:03 PM, Les Cargill wrote: >> >> I am examining the "isn't practical" premise, and trying to do that >> without any preconceptions. I've seen ... high levels of integration >> in real life before - stuff you wouldn't normally think of >> as practical. >> >> Of *course* i don't know for sure - I wasn't there when >> it wasn't done... :) > > I'm not saying you *can't* combine SDRAM and an x86 CPU. This may have > been done by someone at some point. I'm saying it isn't practical for > mainstream uses. It won't show up at Best Buy in the next five years. > But who knows beyond that? I think the PC market is headed for a > dramatic change within the next five years. Handhelds are taking > computing in a very new direction and the momentum is reaching the > critical point. > > We'll see. The problem I see now is connectivity. FireWire is ebbing out. Perhaps USB3.0 will be the bus of choice, or Thunderbolt. <snip> >>>> Phones and tablets are and will always be cheezy little non-computers. >>>> They don't have enough peripheral options to do anything >>>> besides post cat pictures to social media sites. >>> >>> Ok, another quote to go up there with "No one will need more than 640 >>> kBytes" and "I see little commercial potential for the internet for the >>> next 10 years." >>> >> >> Both of those are also true, given other constraints. I would say >> the commercial potential of the internet has been more limited >> than people would perhaps prefer. > > What?? We left 640 kB behind before we left MS-DOS behind!!! To an extent. I found it unusual to need more than realmode levels of memory prior to Windows. > The > Internet is the biggest commercial opportunity since the baby boom! > I must respectfully disagree. 90% of of it is noncommercial for one. Compared to the PC Revolution, it's just not one. It's Facebook, Twitter and Google plus online retail. I dunno - some friends of mine are doing quite well in that general arena ( not in Web stuff, and I don't want to say who they are ) but I just couldn't see doing it. > >>> I'll bet you have one of these things as a significant computing >>> platform in four years... you can quote me on that! >>> >>> >> >> We'll see - I can't find that today, and I have looked. Gave up in a >> fit of despair and bought a netbook. > > You can't find what today? > > A tablet I want to buy. <snip> >> We'll see. FWIW, the people that made this machine I am typing on now >> no longer make desktops, so I see something coming. Not sure what, >> though. > > That is the point. No one knows for sure or they would already be > there. As they push on the technology they make changes like DNA > evolving. Some survive some pass on. But with each generation we get > adaptation. When there is more severe pressure, there is greater > change. The change in technology provides fertile ground for mutations > and the change in computing happens faster giving use things we didn't > know we wanted. But we do want and we will change what we buy. > I know what I want to do with one. It's not there today. And the audience for mobile devices doesn't appear to me to want to do any heavy lifting with them. You can, for example, do recording with an iPad, but the "dock" for it is $3000. I don't think I can write 'C' programs to do signals processing with one. I've yet to see a Tcl interpreter for one. There is Python at least. > I just want a big screen and a keyboard... or so I think. I've been > thinking for the last few years a big flat TV would do nicely as my > screen We do that now with the netbook. > and I can have a keyboard with me even more easily than my 17" > laptop. So why wouldn't a tablet with say a 128 GB flash drive make my > day? Right now the only limitation is the lack of support for Android > by the FPGA software vendors. I can't imagine that isn't going to > change soon. > > We'll see. I am not sure how much of Linux is missing from Android; other than that it shouldn't be too bad. You will need a big ole screen, though. >>> I am pretty much a Luddite when it comes new technology. >> >> Skepticism != Luddism. > > Ok, I'm also a curmudgeon. > > >>> I think most >>> of it is bogus crap. But I have seen the light of phones and tablets >>> and I am a believer. I have been shown the way and the way is good. >>> >>> Here's a clue to the future. How many here want to use Windows after >>> XP? Who likes Vista? Who likes Win7? Win8? >> >> >> They're all fine, so far. No trouble with Win7 or Win8 here. Win8 is >> far too clever but it works. > > Ask around, very few here like anything after XP. > I've seen that and I don't see the problem. You can still buy XP if you don't have it. > >>> Is your new PC any faster >>> than your old PC (other than the increased memory for memory bound >>> apps)? >> >> Yes. But my old PC is a 3.0GHz monocore. >> >> The only reason I upgraded was that Silverlight stopped utilizing >> graphics cards. > > Silverlight was one of the first things I turned off! What does it do > that you or I need? > Netflix. When I was working remote, that's how I consumed Netflix. > >>> PCs are reaching the wall while hand held devices aren't. >> >> There is more than one wall. > > Uh, what? > > I/O. >>> Handhelds will be catching up in six years and will be able to do all >>> the stuff you want from your computer today. Tomorrow's PC's, >>> meanwhile, won't be doing a lot more. So the gap will narrow and who >>> wants all the baggage of traditional PCs when they can use much more >>> convenient hand helds? I/O won't be a problem. >> >> Uh huh. Right :) >> >>> I think all the tablets >>> plug into a TV via HDMI and you can add a keyboard and mouse easily. >> >> That's true enough. But that isn't all the I/O I would need. It isn't >> even the right *software*. > > Ok, what software do you need? It will be available on tablets running > either Android or who knows, MS may be able to throw their 600 pound > gorilla Windows into the tablet market. Maybe. > I mean, if the hardware keeps > pumping up and the market pressures squeeze Windows down to something > more like 2000 or XP in a couple more years it won't be the worst match > ever. > that is true. I don't believe we'll see that though. > >>> So >>> there you have all the utility of a PC in a tiny form factor along with >>> all the advantages of the handheld when you want a handheld. >>> >>> If the FPGA design software ran on them well, I'd get one today. But I >>> need to wait a few more years for the gap to close. >>> >> >> >> Ironically, I expect Apple to sell desktops for quite some time. Other >> than that, here's to the gamers. > > Some years ago when the fortunes of Apple was less certain I predicted > that my friend who worked at a newspaper would be switching to a PC > because Apple would be going under. Then they came out with I guess the > iPod... wow! Then the iPhone, more wow! So my predictions of their > demise was a bit premature... The point though is that the newspaper > was full of Macs because the software was so much better for their needs > than anything on the PC. Right. > Newspapers, etc will be running desktops for > some time because they need the BIG screens. But the software gap has > closed. So the PC is suitable for graphic arts now. Except that Adobe threw a cow in the Photoshop well... > Once they learn > that they don't need the hunk of iron to power their 26" screens > anymore, they will be changing. In fact, they may "get it" before the > rest of us. > That's entirely possible. -- Les CargillArticle: 155494
On Monday, July 1, 2013 1:46:02 PM UTC-4, glen herrmannsfeldt wrote: > It must help some, or Intel wouldn't have put the off chip > in package cache on some processors. Pentium pro if I remember, > and maybe Pentium 2. Not sure I'd pick Intel as the poster child of engineering excellence.Article: 155495
Athens, Greece =96 Jule 01, 2013 =96 Ajax Compilers, Inc., (http://www.ajax= compilers.com) announces the availability of a free evaluation version for = its flagship product, the HercuLeS high-level synthesis environment. The free evaluation is provided upon request; submit a request to info@ajax= compilers with "HercuLeS FREE evaluation" as part of the email subject. In = order for the request to be processed, do not forget to include the Etherne= t MAC address of your preferred machine, where HercuLeS HLS will be install= ed. Currently, a Windows XP SP2/SP3 release is available with support for W= indows 7 and 32-bit Linux due around July 20, 2013. According to Nikolaos Kavvadias, Ph.D., cofounder, CEO of Ajax Compilers: "= HercuLeS enables a seamless user experience from algorithm to hardware impl= ementation. HercuLeS uses a bit-accurate typed-assembly language for whole = program descriptions and supports the manipulation of a number of SSA-like = (Static Single Assignment) forms. It employs a modular, plug-in structure w= here frontends, analyses and optimizations can be added as self-contained e= xternal modules upon the core HLS engine. Further, HercuLeS does not rely o= n code templates since it uses a purely graph-based backend and utilizes op= en specifications such as Graphviz throughout the HLS process. The generate= d HDL code is completely vendor- and technology-independent. It is human-re= adable and allows for automatic third-party, IP integration through an open= process. As part of our overall marketing strategy, we decided to offer a free versi= on of HercuLeS in order to introduce our product to the users. There exist = three licensing plans for HercuLeS: FREE, BASIC and FULL, with increasing = number of features. It should be noted that we have not posed any time limi= tation to any version. The BASIC and FULL versions are available under comp= etitive pricing schemes, especially if you take account the extent of provi= ded support." The HercuLeS feature matrix listing all the supported features for each ver= sion can be downloaded in PDF format from http://www.ajaxcompilers.com/publ= ications/hercules/hercules-feature-matrix.pdfArticle: 155496
Thanks to all you guys for understanding what I am trying to do and why. The consensus is that it is difficult but possible. I think it is worth a try.Article: 155497
On Mon, 01 Jul 2013 18:04:35 -0400, rickman wrote: > On 7/1/2013 8:02 AM, Allan Herriman wrote: >> On Mon, 01 Jul 2013 00:58:08 -0400, rickman wrote: >>> >>> Looks like this FTDI chip could be a useful tool for JTAG debugging, >>> but it is a little hard to corral the hardware. >> >> >> I did something similar in a 2009 design; I had an embedded x86 that >> needed to configure a Xilinx FPGA, so I put an FT2232H on the board as >> a USB-JTAG converter. >> >> Avoid the FT2232D if you can; you need the -H or one of the newer parts >> to get 480Mb/s USB 2.0. 12Mb/s seems so slow these days. >> >> I'm an X and A guy (no experience with Lattice) but I would hazard a >> guess that many different types of JTAG probes would work with your >> FPGA, >> given suitable driver software. Reverse engineer a few and find one >> with a design you like. There's nothing restricting you to a design >> from a (clearly old) Lattice app note. > > Yes, that is what I am thinking. But I'm looking for hard info to > minimize my development time. The "suitable driver software" means > using the Lattice software which should just work. Once we are finished > testing the next batch of boards I will pry open the JTAG cable Lattice > sells. Although I bought it back in 2008 so it likely has the 2232D > design. > > I'm concerned about the software not liking what I build. It *is* > pretty touchy software and there is a small flash part that needs to be > programmed just right. > > What did you have to do to get yours to work with the X part? Where did > you get the flash programming file? I got it to work by kicking it over the wall to the software guy. He said that he found a generic driver (in source form) for the FTDI part and modified it to do exactly what was required. The "small flash part" was actually an EEPROM (IIRC, may be wrong) and we used some VID/PID values out of a range that was allocated to us by FTDI. The actual values didn't matter as we controlled the software. It's also possible to use port numbers to identify devices rather than VID/PID. That's what we do on a freshly manufactured board with blank eeproms. Some software identifies each USB device on the board from its location then programs the appropriate VID/PID into it. [OT] This reminds me of the first time I put a USB 3.0 host controller in a product. The device was a first generation part and it needed to load its firmware from an external flash. We weren't able to source the contents (that worked) from the manufacturer. When USB3 cards started appearing in shops [in 2010?] we bought one and cloned its flash. AllanArticle: 155498
On 02.07.2013 17:41, peter dudley wrote: > The consensus is that it is difficult but possible. > I think it is worth a try. Please, let us know about your experience. - Philip -- If your photographs aren't good enough, you aren't close enough. (Robert Capa)Article: 155499
This is a multi-part message in MIME format.
--------------030906010305020803050301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Someone pointed out to me that the necessary information can be inferred
from either of these files:
ISE/verilog/src/unisims/SIM_CONFIG_S6.v
ISE/vhdl/src/unisims/primitive/SIM_CONFIG_S6.vhd
Neil Steiner wrote:
> I am unsuccessfully trying to update Spartan6 CRC checksums after I
> make packet modifications. This is not a problem for
> Virtex/E/2/2P/4/5/6/7 or for Spartan3E, but Spartan6 is a different
> story altogether. I posted this same question on Xilinx Forums, but
> there have been no responses.
>
> I know that Spartan6 packets consist of 16-bit words, unlike the
> 32-bit words of the other architectures listed above. UG380 also
> states that "The Cyclic Redundancy Check register utilizes a standard
> 32-bit CRC checksum algorithm." My perhaps incorrect assumption is
> that the polynomial is the same CRC-32C (Castagnoli) polynomial as for
> Virtex4/5/6/7 families. I am also assuming that only "payload words"
> (after the packet header) factor into the calculation, just as with
> the other architectures, and UG380 explicitly shows the address length
> as 6 bits.
>
> Does anybody know how to calculate this correctly for Spartan6? If
> anyone cares to see the logic I'm trying to use, it's quite similar to
> what works correctly for all the other Xilinx architectures:
>
> // begin CRC calculation
> uint32_t address = 0;
> iterator p = begin();
> iterator e = end();
> // CRC-32C (Castagnoli) polynomial for Virtex4/5/6/7 families
> boost::crc_basic<32> crc32(0x1edc6f41, 0, 0, false, true);
> while(p < e) {
> // look up the current packet
> const Spartan6Packet& packet = *p++;
> // only process write packets with non-zero payload length
> if(!packet.isWrite()) continue;
> address = packet.getAddress();
> uint32_t wordCount = packet.getWordCount();
> if(wordCount == 0) continue;
> // CRC register write (this is what compares the expected and
> supplied CRC values)
> if(address == crcRegister) {
> printf("Expected CRC32: %8.8x\n", (uint32_t(packet[1])
> << 16) | packet[2]);
> printf("Calculated CRC32: %8.8x\n", crc32.checksum());
> *(p-1) = Spartan6Packet::makeType1Write(crcRegister,
> crc32.checksum());
> crc32.reset();
> // reset CRC command
> } else if(address == cmdRegister && wordCount >= 1 &&
> packet[1] == rcrcCommand) {
> crc32.reset();
> // process packet contents
> } else {
> uint32_t j;
> uint32_t mask;
> for(uint32_t i = 1; i <= wordCount; i++) {
> uint32_t word = packet[i];
> //printf("Address: %4.4x\n", address);
> //printf("Word: %8.8x\n", word);
> for(j = 0, mask = 1; j < 16; j++, mask <<= 1) {
> crc32.process_bit((word & mask) ? 1 : 0);
> }
> for(j = 0, mask = 1; j < addressLength; j++, mask <<= 1) {
> crc32.process_bit((address & mask) ? 1 : 0);
> }
> }
> // process the Auto CRC
> if(autoCrc && address == fdriRegister) {
> printf("Expected Auto CRC32: %8.8x\n",
> (uint32_t((*p)[0]) << 16) | (*p)[1]);
> printf("Calculated Auto CRC32: %8.8x\n",
> crc32.checksum());
> *p = Spartan6Packet(crc32.checksum()); // current
> packet is FDRI, next is Auto CRC
> crc32.reset();
> }
> }
> }
>
>
--------------030906010305020803050301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Someone pointed out to me that the
necessary information can be inferred from either of these files:<br>
<blockquote>ISE/verilog/src/unisims/SIM_CONFIG_S6.v<br>
ISE/vhdl/src/unisims/primitive/SIM_CONFIG_S6.vhd<br>
</blockquote>
Neil Steiner wrote:<br>
</div>
<blockquote cite="mid:51D21B66.5010105@east.isi.edu" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
I am unsuccessfully trying to update Spartan6 CRC checksums after
I make packet modifications. This is not a problem for
Virtex/E/2/2P/4/5/6/7 or for Spartan3E, but Spartan6 is a
different story altogether. I posted this same question on Xilinx
Forums, but there have been no responses.<br>
<br>
I know that Spartan6 packets consist of 16-bit words, unlike the
32-bit words of the other architectures listed above. UG380 also
states that "The Cyclic Redundancy Check register utilizes a
standard 32-bit CRC checksum algorithm." My perhaps incorrect
assumption is that the polynomial is the same CRC-32C (Castagnoli)
polynomial as for Virtex4/5/6/7 families. I am also assuming that
only "payload words" (after the packet header) factor into the
calculation, just as with the other architectures, and UG380
explicitly shows the address length as 6 bits.<br>
<br>
Does anybody know how to calculate this correctly for Spartan6?
If anyone cares to see the logic I'm trying to use, it's quite
similar to what works correctly for all the other Xilinx
architectures:<br>
<blockquote><font color="#006600"><tt>// begin CRC calculation</tt></font><br>
<tt>uint32_t address = 0;</tt><br>
<tt>iterator p = begin();</tt><br>
<tt>iterator e = end();</tt><br>
<font color="#006600"><tt>// CRC-32C (Castagnoli) polynomial for
Virtex4/5/6/7 families</tt></font><br>
<tt>boost::crc_basic<32> crc32(0x1edc6f41, 0, 0, false,
true);</tt><br>
<tt>while(p < e) {</tt><br>
<font color="#006600"><tt> // look up the current packet</tt></font><br>
<tt> const Spartan6Packet& packet = *p++;</tt><br>
<font color="#006600"><tt> // only process write packets with
non-zero payload length</tt></font><br>
<tt> if(!packet.isWrite()) continue;</tt><br>
<tt> address = packet.getAddress();</tt><br>
<tt> uint32_t wordCount = packet.getWordCount();</tt><br>
<tt> if(wordCount == 0) continue;</tt><br>
<font color="#006600"><tt> // CRC register write (this is
what compares the expected and supplied CRC values)</tt></font><br>
<tt> if(address == crcRegister) {</tt><br>
<tt> printf("Expected CRC32: %8.8x\n",
(uint32_t(packet[1]) << 16) | packet[2]);</tt><br>
<tt> printf("Calculated CRC32: %8.8x\n",
crc32.checksum());</tt><br>
<tt> *(p-1) = Spartan6Packet::makeType1Write(crcRegister,
crc32.checksum());</tt><br>
<tt> crc32.reset();</tt><br>
<font color="#006600"><tt> // reset CRC command</tt></font><br>
<tt> } else if(address == cmdRegister && wordCount
>= 1 && packet[1] == rcrcCommand) {</tt><br>
<tt> crc32.reset();</tt><br>
<font color="#006600"><tt> // process packet contents</tt></font><br>
<tt> } else {</tt><br>
<tt> uint32_t j;</tt><br>
<tt> uint32_t mask;</tt><br>
<tt> for(uint32_t i = 1; i <= wordCount; i++) {</tt><br>
<tt> uint32_t word = packet[i];</tt><br>
<font color="#006600"><tt> //printf("Address:
%4.4x\n", address);</tt><br>
<tt> //printf("Word: %8.8x\n", word);</tt></font><br>
<tt> for(j = 0, mask = 1; j < 16; j++, mask
<<= 1) {</tt><br>
<tt> crc32.process_bit((word & mask) ? 1 :
0);</tt><br>
<tt> }</tt><br>
<tt> for(j = 0, mask = 1; j < addressLength; j++,
mask <<= 1) {</tt><br>
<tt> crc32.process_bit((address & mask) ? 1 :
0);</tt><br>
<tt> }</tt><br>
<tt> }</tt><br>
<font color="#006600"><tt> // process the Auto CRC</tt></font><br>
<tt> if(autoCrc && address == fdriRegister) {</tt><br>
<tt> printf("Expected Auto CRC32: %8.8x\n",
(uint32_t((*p)[0]) << 16) | (*p)[1]);</tt><br>
<tt> printf("Calculated Auto CRC32: %8.8x\n",
crc32.checksum());</tt><br>
<tt> *p = Spartan6Packet(crc32.checksum()); <font
color="#006600">// current packet is FDRI, next is Auto CRC</font></tt><br>
<tt> crc32.reset();</tt><br>
<tt> }</tt><br>
<tt> }</tt><br>
<tt>}</tt><br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------030906010305020803050301--
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