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 Mar 22, 1:44=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Mar 22, 7:41 am, djj08230 <djj08...@gmail.com> wrote: > > > > > On Mar 22, 3:19 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > So back to the issue at had, the > > > > 1) Drigmorn1 has a XC3S500E-4CPG132C spartan-3 chip: > > > > 2) the Craignell has a (Xilinx XC3S500E) Spartan-3E chip as well, > > > > 3) the Raggedstone1 has a XC3S1500 chip: > > > > Which of these products will do the job and not be too small like the > > > coolrunner? > > > IMHO any of these should be enough. A UART can be made very simple, or > > it may have lots of bells and whistles. > > The good thing is that you can run place and route and see what device > > fits better. > > You really should. > > Of course, you are aware that you need the FPGA + some sort of device > > to boot it. > > > Good luck. > > > Josep Duran > > Now you got me all freaked out again. > > I'm looking at this wonderful manual:http://www.enterpoint.co.uk/techitip= s/Programming%20Raggedstone1%20Us... > > and its beautiful. =A0why xilinx can't make something like this is > ridiculous. =A0This is what is needed. > > Anyway, it seems to me on page 23 of this guide it is programming a > PROM. =A0I read this as the raggedstone1 has built in a "some sort of > device to boot it." =A0as in the FPGA that is on the card will boot from > its own onboard PROM. =A0I'm also assuming that the PROM is big enough > so I can load my UART program into this PROM, power down the unit and > when I power it up the program starts up, starts talking on the UART, > blinking whatever LED's I tell it to blink, etc... > > I ASSUMED the other two devices the craig and the drigmorn were > similiar, Can someone confirm or deny this? I've been reading the thread, and I may have missed something. The responses you get are from 'experts' so there really is nothing I can add. Raggedstone and the other products from ENTERPOINT are complete boards that include the FPGA and all the support needed to make a fully functional board. (May include other unneeded functionality). If I recall correctly, Raggedstone board actually includes an interface to a PCI BUS. I was under the impresion that you wanted to replace a Coolrunner for an FPGA in order to get more gates. If this is so, just be aware that the spartan-3 series usually need and external memory to load the configuration at power on. You also need 3 different supplies 3.3v, 2.5v and 1.2v. (not sure if 3.3v is mandatory) And of course some sort of external oscillator that you probably already have. (as somenone already mentioned, the Spartan3AN has some flash memory on chip) I am also under the impresion that you are in a hurry. If this is so, probably your best move would be get help from a professional external source. Not that this is rocket science, but you should expect to be bitten by the tools in the first few weeks. I never meant to scare you, this is just my point of view. Josep DuranArticle: 139151
On Mar 21, 10:52=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 21, 3:47=A0pm, Mawafugo <cco...@netscape.net> wrote: > > > In xapp460 the DVI/HDMI transmitter & receiver is implemented but the > > max throughput limit to somewhat 750 Mb/s, which can handle up to > > 1080i or 720p resolution. =A0The 1080p, however needs twice of that > > > The question is how can we crank up the throughput to about 1.5 Gb/s ? > > answer is: it is not doable with S3A > > Antti Oh thanks, Sounds like there's noway around the MGT then, but it is costly $$$Article: 139152
Hi, I'm using the Spartan 3 XC3S400-TQ144. Does this device have internal 100-ohm termination for LVDS input pairs, or must I use an external 100-ohm resistor? When I designed my board, I assumed internal termination would be enabled automatically by instantiation of the IBUFGDS; but looking at my signal levels, although my board is working, I would say there is no termination. The only statement I can find in the datasheet is note 5 hidden away below table 37, which I think I can be forgiven for overlooking. I only have two input pairs, and it's a prototype board, so I can just solder 0201 resistors between the pins; but maybe someone here knows better ... TIAArticle: 139153
On Mar 22, 3:49=A0pm, halong <cco...@netscape.net> wrote: > On Mar 21, 10:52=A0am, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > On Mar 21, 3:47=A0pm, Mawafugo <cco...@netscape.net> wrote: > > > > In xapp460 the DVI/HDMI transmitter & receiver is implemented but the > > > max throughput limit to somewhat 750 Mb/s, which can handle up to > > > 1080i or 720p resolution. =A0The 1080p, however needs twice of that > > > > The question is how can we crank up the throughput to about 1.5 Gb/s = ? > > > answer is: it is not doable with S3A > > > Antti > > Oh thanks, > > Sounds like there's noway around the MGT then, but it is costly $$$ well MGT can not do TMDS/DVI, only S3A can! so you need to wait S6/V6 and hope they can do it AnttiArticle: 139154
On Mar 22, 9:10 am, djj08230 <djj08...@gmail.com> wrote: > On Mar 22, 1:44 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On Mar 22, 7:41 am, djj08230 <djj08...@gmail.com> wrote: > > > > On Mar 22, 3:19 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > So back to the issue at had, the > > > > > 1) Drigmorn1 has a XC3S500E-4CPG132C spartan-3 chip: > > > > > 2) the Craignell has a (Xilinx XC3S500E) Spartan-3E chip as well, > > > > > 3) the Raggedstone1 has a XC3S1500 chip: > > > > > Which of these products will do the job and not be too small like the > > > > coolrunner? > > > > IMHO any of these should be enough. A UART can be made very simple, or > > > it may have lots of bells and whistles. > > > The good thing is that you can run place and route and see what device > > > fits better. > > > You really should. > > > Of course, you are aware that you need the FPGA + some sort of device > > > to boot it. > > > > Good luck. > > > > Josep Duran > > > Now you got me all freaked out again. > > > I'm looking at this wonderful manual:http://www.enterpoint.co.uk/techitips/Programming%20Raggedstone1%20Us... > > > and its beautiful. why xilinx can't make something like this is > > ridiculous. This is what is needed. > > > Anyway, it seems to me on page 23 of this guide it is programming a > > PROM. I read this as the raggedstone1 has built in a "some sort of > > device to boot it." as in the FPGA that is on the card will boot from > > its own onboard PROM. I'm also assuming that the PROM is big enough > > so I can load my UART program into this PROM, power down the unit and > > when I power it up the program starts up, starts talking on the UART, > > blinking whatever LED's I tell it to blink, etc... > > > I ASSUMED the other two devices the craig and the drigmorn were > > similiar, Can someone confirm or deny this? > > I've been reading the thread, and I may have missed something. The > responses you get are from 'experts' so there really is nothing I can > add. > > Raggedstone and the other products from ENTERPOINT are complete boards > that include the FPGA and all the support needed to make a fully > functional board. (May include other unneeded functionality). If I > recall correctly, Raggedstone board actually includes an interface to > a PCI BUS. > > I was under the impresion that you wanted to replace a Coolrunner for > an FPGA in order to get more gates. If this is so, just be aware that > the spartan-3 series usually need and external memory to load the > configuration at power on. You also need 3 different supplies 3.3v, > 2.5v and 1.2v. (not sure if 3.3v is mandatory) And of course some sort > of external oscillator that you probably already have. > (as somenone already mentioned, the Spartan3AN has some flash memory > on chip) > > I am also under the impresion that you are in a hurry. If this is so, > probably your best move would be get help from a professional external > source. Not that this is rocket science, but you should expect to be > bitten by the tools in the first few weeks. > > I never meant to scare you, this is just my point of view. > > Josep Duran Ahh!!! ok whew!!!! My first choice is to get it all to fit on the coolrunner: I'm not sure it will, but I'm not convinced it won't either. This is the best path as it requires the least amount of re-engineering of the hardware. Replacing the coolrunner chip is probably the best solution, but it will be a huge effort, and is not in the time constraints I have. I'd love to replace the coolrunner CHIP on the custom made interface board, but that will not be something I can do quick. I realize that. The entire board will have to be redone to match the new chip, the traces all redone, etc, plus there is an old program written for the coolrunner and if nothing else all its pins have to be moved to the new chip, let alone any programming subtilties that might pop up. No I would not attempt this without knowing full well what the coolrunner was doing originally, and making sure the new chip meets that needs. That's not going to be a quick fix. No, at this time, I'm just hoping to ADD an entire new card to do the functionality that I need, That's the best I can hope for in my timeframe. The idea is to get one of the three (I'll probably buy all three just to try them out.) to do my UART thing, and then just program the old coldrunner with some new digital outputs and inputs to tell the new board to start, stop, ack etc. An ugly patch job, but it will work, SO LONG AS WHATEVER BOARD I USE BOOTS UP, AND RUNS THE NEW UARTS. The boss will hate it, but at least it will work. That's a whole lot better than the paperweight he has now. Next time he should of spec- ed out the scope of the functionality a bit better. Also the pred- ecessors should of been a little more forward thinking of growth. It is ridiculous that they picked a $75 coolrunner and loaded it up to 70% of capacity. I'm looking at the Spartan chips, at $20- $70 that are 10-50x more powerful, and shaking my head as to why they went with the coolrunner. The guy that picked it is long gone. My guess is that he used it before, and knew it would do what he was asked to do. My rule of thumb is for a first prototype is to never be more than 25% of capacity. When you have to a production run of more than 1000 units, then you worry about right-sizing. Meantime the spartan would still have been way cheaper anyway for all their "right-sizing" effort. Right-sizing is only important if it saves you something. I looked over the BOM for the box. These knuckleheads managed to find a $30 momentary switch to use as a reset switch on the box and then tell me they saved money by right-sizing the chip...Article: 139155
On Mar 21, 10:32=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Mar 21, 6:33 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 21, 12:52 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > On Mar 21, 12:11 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 21, 11:10 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > 1) So it is reasonable to conclude that the cold runner 3512 is w= ay > > > > > too small to even run a uart yes? > > > > > I would not say that. =A0A UART can be done in a small number of FF= s, or > > > > in your case, a small number of macrocells. =A0I expect it to be ea= sy to > > > > get ten UARTs into the 3512. =A0But the code you have for a UART is= very > > > > large and overly complex if you just want to do serial transmission > > > > and reception of data. =A0If you just want to *send* data the size = can > > > > be reduced further. > > > > > > 2) is the board that Brian suggested, the raggedstone1 with the > > > > > spartan XC3S1500 is big enough? > > > > > Certainly an XC3S1500 is plenty large enough for four UARTs. =A0In = that > > > > size part you could have not only the UARTs, but also the CPU! > > > > > > 2A) I really want to put 3 or 4 UARTS onto the chip, Is it big en= ough > > > > > for that? > > > > > Yes. =A0If four UARTs is all you want, the XC3S1500 is very much > > > > overkill. > > > > > > 2B) The specs for the =A0XC3S1500 are: > > > > > > Xilinx XC3S1500-4FG676C > > > > > FPGA Spartan=AE-3 Family 1.5M Gates 29952 Cells 630MHz Commercial= 90nm > > > > > Technology 1.2V 676-Pin FCBGA > > > > > Cross to Alternate Parts by selecting most important features and > > > > > values below and then search again > > > > > =A0 =A0 =A0 =A0 Search within this category only > > > > > =A0 =A0 =A0 =A0 Search within this manufacturer only > > > > > =A0 =A0 =A0 =A0 Feature Description =A0 =A0 Feature Value > > > > > =A0 =A0 =A0 =A0 Package =A0 =A0 =A0 =A0 676FCBGA > > > > > =A0 =A0 =A0 =A0 Family Name =A0 =A0 Spartan=AE-3 > > > > > =A0 =A0 =A0 =A0 Device Logic Cells =A0 =A0 =A029952 > > > > > =A0 =A0 =A0 =A0 Device Logic Units =A0 =A0 =A03328 > > > > > =A0 =A0 =A0 =A0 Device System Gates =A0 =A0 1500000 > > > > > =A0 =A0 =A0 =A0 Number of Registers =A0 =A0 N/A > > > > > =A0 =A0 =A0 =A0 Maximum Internal Frequency =A0 =A0 =A0630 MHz > > > > > =A0 =A0 =A0 =A0 Typical Operating Supply Voltage =A0 =A0 =A0 =A01= .2 V > > > > > =A0 =A0 =A0 =A0 Maximum Number of User I/Os =A0 =A0 487 > > > > > =A0 =A0 =A0 =A0 RAM Bits =A0 =A0 =A0 =A0589824 > > > > > =A0 =A0 =A0 =A0 Re-programmability Support =A0 =A0 =A0Yes > > > > > > Whats the deal withe the "PACKAGE" ( 676FCBGA) > > > > > > I see from AVNET that the XC3S1500 comes in lots of flavors: > > > > > >http://avnetexpress.avnet.com/store/em/EMController?langId=3D-1&st= oreId... > > > > > > XC3S1500-4FG320C > > > > > XC3S1500-4FG456C > > > > > XC3S1500-4FG676C > > > > > XC3S1500-4FGG456C > > > > > XC3S1500-5FG456C > > > > > XC3S1500-5FGG456C > > > > > XC3S1500-4FGG320C > > > > > XC3S1500-4FGG320I > > > > > XC3S1500-5FGG676C > > > > > XC3S1500-4FGG676C > > > > > XC3S1500-4FG320I > > > > > XC3S1500-4FG456I > > > > > XC3S1500-4FG676I > > > > > XC3S1500-4FGG456I > > > > > XC3S1500-4FGG676I > > > > > XC3S1500-5FG320C > > > > > XC3S1500-5FG676C > > > > > XC3S1500-5FGG320C > > > > > XC3S1500-5FGG320 > > > > > > how interchangeable are these parts? =A0the ds0099.pdf data sheet= is not > > > > > geared towards just eh xc3s1500, I'm getting confused within its = 219 > > > > > pages... > > > > > They are all the same die and will likely all run the same bitstrea= m. > > > > You really only need to worry about the package you are using unles= s > > > > you want to target different boards. > > > > > The first digit after the dash -4 or -5 is the speed of the part. = =A0The > > > > parts are the same, but they are tested to different speeds. =A0The > > > > letter at the end is the temperature rating, C for commerical > > > > (normally 0 to 70 C ambient, but I think Xilinx specs a higher numb= er > > > > and says this has to be the die temperature) and I for industrial (= -20 > > > > to +85 C with the same issue as commercial). =A0The rest of the suf= fix > > > > is the package. =A0Mostly all the different sized parts have simila= r > > > > timing. =A0But some timing numbers are different. =A0Anything that = is > > > > widely distributed across the chip has further to go in the larger > > > > chips, so it runs slower. > > > > > If you want to design for a range of packages you mainly need to li= mit > > > > your design to the I/O pins that are used on the smallest package. = =A0So > > > > make sure every package you want to use supports all of those pins. > > > > Otherwise you should have no problems. > > > > > > 3) The raggedstone1 =A0has an added feature that I was told to co= nsider, > > > > > mounting into a PC. Initially I want to put it a stand alone box,= so I > > > > > will need to order the board, the PCI I/O header, and the Ocsilla= tor > > > > > and then I'm good to go yes? > > > > > The board will need power. =A0Other than that, you need to consult = the > > > > data sheet for the board. =A0They should provide specs on how to us= e the > > > > board stand alone. > > > > > Rick > > > > "Yes. =A0If four UARTs is all you want, the XC3S1500 is very much > > > overkill. " > > > > I don't get this, but I get it from a lot of hardware folks. =A0The > > > s1500 is a $74 chip. the coolrunner, that is 1/100 the chip, is what > > > $60? =A0 so for $14 I get 100x the power? > > > Coolrunner chips are not about "logic" power. =A0They are about Watt > > power. =A0They are very low current, require no booting, and power up > > immediately (ns) rather than requiring some milliseconds before they > > can operate. > > > > This is a no-brainer IMO for a production run of less than 10,000 and > > > your total system cost is over $1000. =A0Especially when you are > > > basically prototyping. The system I'm supposed to integrate with has > > > in the box a green hills stack with a 1553 card, the 1553 card alone > > > is $16,000. The amount of engineering time I've spent =A0fighting wit= h > > > the $14 decision to go with the coolrunner on a subsystem vs somethin= g > > > bigger and a .001% increase in cost (to the whole system) is > > > ridiculous. =A0If I can't get this to fit on the coolrunner I'm looki= ng > > > at adding another card and as such all the implications to SWAP (size > > > weight and power) , that it in-tails, re-laying out the box, etc, all > > > for a $14 decision on a $25,000 box... =A0don't even get me started o= n > > > how stupid the the sub-system card was laid out. You can't even tell > > > if it gets power, it doesn't have a single LED on it... > > > Well, you could always bring in a consultant to help fit your logic > > into the device or even redesign the card with the Coolrunner on it. > > What is the cost of further schedule delays? =A0;^) > > > Rick > > Ok, so the coolrunner was a total mis-cue from the ancestors on this > project. =A0They are looking at powering > PC104 stacks, they've got a 28volt power supply in this beast, plus > who knows what else; I'm sure why the coolrunner was picked had > nothing to do with Watt power or boot up speed, that pc104 stack is a > dog and a FPGA bootup is small potatos in the scheme of things. It's hard to say why they picked the parts they did. Is this a custom board the coolrunner is on? Is this a complex board? If not, this can be redone with a different part without too much difficulty or time. Board houses can turn a board in literally a couple of days if you don't mind paying a premium. But then you said you were out of hardware money. > "Actually, after I made the post I realized that the generic W > defaults > to 4, specifying 16 bytes in the FIFO, but is set to 2 in the calling > code specifying only 4 registers. =A0Still, that is 64 FFs even if it > doesn't get you back under the wire, it will help." > > Ah yes, that is true, but what isn't made clear is that my data is no > longer 8 bit ASCII. =A0Its a 64 bit custom bitstream, so those 4 > registers are holding 64 bit data not 8. =A0How does that FF calcuation > work again against the coolrunners jury-rigged, FF based registers? > I'm hoping this is the solution, get rid of the FIFO and the simple > state machine, bit shifting UART is tiny. Actually, I said the above wrong. The default for W is something like 16 registers in the FIFO. The value passed into the FIFO code is 4 which means it is only using 64 FFs for the FIFO buffer, plus what ever shakes out in the control logic. If you have a 64 bit register, and it is custom, do you really need a UART? Does this need to be async serial? If you are receiving this in another controlled device SPI would let you do what you want and be simpler. SPI is like a UART, but no start/stop bits, just data. Plug a byte into the shifter and it sends out the data; keep plugging in bytes until your burst is done and the whole thing is transferred as if it were one word. SPI transmit and receive use the same register, so that also cuts resource usage. A lot of this depends on what the other logic is like. However, CPLDs tend to be rich in logic so you should be able to generate the data in this part if you can get the FF count down. But the devil is in the details. If you are sending this to a PC serial port then you need to keep the UART, just make a very simple UART. In the thread where you are discussing the boot prom with Josep, yes, most FPGAs require a boot prom or direct boot control by a CPU. Some have internal Flash, Lattice parts notably. But certainly any board level product will include at least one means of booting the FPGA if not several. RickArticle: 139156
On Sat, 21 Mar 2009 19:19:09 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote: >On Mar 21, 8:39 pm, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> On Sat, 21 Mar 2009 08:10:07 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> >> Otherwise given the cost constraints you mentioned, I'd say you shouldn't be >> wasting time trying to fit a too-small device. Is your software team trying to >> keep their executable below 4K? >> >> - Brian > > >"Is your software team trying to keep their executable below 4K?" > >first off the software team is me. For 20 years now I keep getting >suckered into these solo missions into [the companies] no man land... > >I'm sorry are you referring to $4k or some size requirement of 4k??? I meant 4k bytes. As in, I was trying to find the SW equivalent of squeezing a hardware design into a Coolrunner... It's a valid thing to do ... sometimes. If it's easy to eliminate the large storage that is currently causing problems, and that avoids a board re-spin for example. But often it's a waste of time to conserve a low value resource. I'm sorry I was unclear. > I'm assuming I can load the program >into the enterpoint solutions and on powerup they start to >function... Look for configuration storage, such as... "Drigmorn1 have a M25P40 (4 Mbit) serial flash that is used for both configuration of the FPGA and ..." so I'd have to say yes for that one. >The guys on this project have blown their budget for hardware already, >at least for this next deliverable, so any $$$ I spend (not counting >labor) are being watched carefully. >1) Drigmorn1 has a XC3S500E-4CPG132C spartan-3 chip: > Xilinx XC3S500E-4CPG132C >FPGA SpartanŽ-3E Family >500K Gates > Number of Registers 9312 > RAM Bits 368640 >Which of these products will do the job and not be too small like the >coolrunner? I would expect any of them to be overkill, quite frankly. It should be a few minutes work to select say the Spartan3-100 (the smallest available on Drigmorn) and synthesize the current design for that, and see how much space is left over. Alternatively you mentioned a PC104 stack - have you seen the Hollybush I and II PC104 cards from the same site? I don't know how PC104 cards stack but it's possible you may just have to plug one of these straight in. Or a larger one may swallow some of the functionality from the rest of the stack. - BrianArticle: 139157
On Mar 22, 10:13 am, rickman <gnu...@gmail.com> wrote: > On Mar 21, 10:32 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On Mar 21, 6:33 pm, rickman <gnu...@gmail.com> wrote: > > > > On Mar 21, 12:52 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On Mar 21, 12:11 pm, rickman <gnu...@gmail.com> wrote: > > > > > > On Mar 21, 11:10 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > > 1) So it is reasonable to conclude that the cold runner 3512 is= way > > > > > > too small to even run a uart yes? > > > > > > I would not say that. A UART can be done in a small number of FF= s, or > > > > > in your case, a small number of macrocells. I expect it to be ea= sy to > > > > > get ten UARTs into the 3512. But the code you have for a UART is= very > > > > > large and overly complex if you just want to do serial transmissi= on > > > > > and reception of data. If you just want to *send* data the size = can > > > > > be reduced further. > > > > > > > 2) is the board that Brian suggested, the raggedstone1 with the > > > > > > spartan XC3S1500 is big enough? > > > > > > Certainly an XC3S1500 is plenty large enough for four UARTs. In = that > > > > > size part you could have not only the UARTs, but also the CPU! > > > > > > > 2A) I really want to put 3 or 4 UARTS onto the chip, Is it big = enough > > > > > > for that? > > > > > > Yes. If four UARTs is all you want, the XC3S1500 is very much > > > > > overkill. > > > > > > > 2B) The specs for the XC3S1500 are: > > > > > > > Xilinx XC3S1500-4FG676C > > > > > > FPGA Spartan=AE-3 Family 1.5M Gates 29952 Cells 630MHz Commerci= al 90nm > > > > > > Technology 1.2V 676-Pin FCBGA > > > > > > Cross to Alternate Parts by selecting most important features a= nd > > > > > > values below and then search again > > > > > > Search within this category only > > > > > > Search within this manufacturer only > > > > > > Feature Description Feature Value > > > > > > Package 676FCBGA > > > > > > Family Name Spartan=AE-3 > > > > > > Device Logic Cells 29952 > > > > > > Device Logic Units 3328 > > > > > > Device System Gates 1500000 > > > > > > Number of Registers N/A > > > > > > Maximum Internal Frequency 630 MHz > > > > > > Typical Operating Supply Voltage 1.2 V > > > > > > Maximum Number of User I/Os 487 > > > > > > RAM Bits 589824 > > > > > > Re-programmability Support Yes > > > > > > > Whats the deal withe the "PACKAGE" ( 676FCBGA) > > > > > > > I see from AVNET that the XC3S1500 comes in lots of flavors: > > > > > > >http://avnetexpress.avnet.com/store/em/EMController?langId=3D-1&= storeId... > > > > > > > XC3S1500-4FG320C > > > > > > XC3S1500-4FG456C > > > > > > XC3S1500-4FG676C > > > > > > XC3S1500-4FGG456C > > > > > > XC3S1500-5FG456C > > > > > > XC3S1500-5FGG456C > > > > > > XC3S1500-4FGG320C > > > > > > XC3S1500-4FGG320I > > > > > > XC3S1500-5FGG676C > > > > > > XC3S1500-4FGG676C > > > > > > XC3S1500-4FG320I > > > > > > XC3S1500-4FG456I > > > > > > XC3S1500-4FG676I > > > > > > XC3S1500-4FGG456I > > > > > > XC3S1500-4FGG676I > > > > > > XC3S1500-5FG320C > > > > > > XC3S1500-5FG676C > > > > > > XC3S1500-5FGG320C > > > > > > XC3S1500-5FGG320 > > > > > > > how interchangeable are these parts? the ds0099.pdf data sheet= is not > > > > > > geared towards just eh xc3s1500, I'm getting confused within it= s 219 > > > > > > pages... > > > > > > They are all the same die and will likely all run the same bitstr= eam. > > > > > You really only need to worry about the package you are using unl= ess > > > > > you want to target different boards. > > > > > > The first digit after the dash -4 or -5 is the speed of the part.= The > > > > > parts are the same, but they are tested to different speeds. The > > > > > letter at the end is the temperature rating, C for commerical > > > > > (normally 0 to 70 C ambient, but I think Xilinx specs a higher nu= mber > > > > > and says this has to be the die temperature) and I for industrial= (-20 > > > > > to +85 C with the same issue as commercial). The rest of the suf= fix > > > > > is the package. Mostly all the different sized parts have simila= r > > > > > timing. But some timing numbers are different. Anything that is > > > > > widely distributed across the chip has further to go in the large= r > > > > > chips, so it runs slower. > > > > > > If you want to design for a range of packages you mainly need to = limit > > > > > your design to the I/O pins that are used on the smallest package= . So > > > > > make sure every package you want to use supports all of those pin= s. > > > > > Otherwise you should have no problems. > > > > > > > 3) The raggedstone1 has an added feature that I was told to co= nsider, > > > > > > mounting into a PC. Initially I want to put it a stand alone bo= x, so I > > > > > > will need to order the board, the PCI I/O header, and the Ocsil= lator > > > > > > and then I'm good to go yes? > > > > > > The board will need power. Other than that, you need to consult = the > > > > > data sheet for the board. They should provide specs on how to us= e the > > > > > board stand alone. > > > > > > Rick > > > > > "Yes. If four UARTs is all you want, the XC3S1500 is very much > > > > overkill. " > > > > > I don't get this, but I get it from a lot of hardware folks. The > > > > s1500 is a $74 chip. the coolrunner, that is 1/100 the chip, is wha= t > > > > $60? so for $14 I get 100x the power? > > > > Coolrunner chips are not about "logic" power. They are about Watt > > > power. They are very low current, require no booting, and power up > > > immediately (ns) rather than requiring some milliseconds before they > > > can operate. > > > > > This is a no-brainer IMO for a production run of less than 10,000 a= nd > > > > your total system cost is over $1000. Especially when you are > > > > basically prototyping. The system I'm supposed to integrate with ha= s > > > > in the box a green hills stack with a 1553 card, the 1553 card alon= e > > > > is $16,000. The amount of engineering time I've spent fighting wit= h > > > > the $14 decision to go with the coolrunner on a subsystem vs someth= ing > > > > bigger and a .001% increase in cost (to the whole system) is > > > > ridiculous. If I can't get this to fit on the coolrunner I'm looki= ng > > > > at adding another card and as such all the implications to SWAP (si= ze > > > > weight and power) , that it in-tails, re-laying out the box, etc, a= ll > > > > for a $14 decision on a $25,000 box... don't even get me started o= n > > > > how stupid the the sub-system card was laid out. You can't even tel= l > > > > if it gets power, it doesn't have a single LED on it... > > > > Well, you could always bring in a consultant to help fit your logic > > > into the device or even redesign the card with the Coolrunner on it. > > > What is the cost of further schedule delays? ;^) > > > > Rick > > > Ok, so the coolrunner was a total mis-cue from the ancestors on this > > project. They are looking at powering > > PC104 stacks, they've got a 28volt power supply in this beast, plus > > who knows what else; I'm sure why the coolrunner was picked had > > nothing to do with Watt power or boot up speed, that pc104 stack is a > > dog and a FPGA bootup is small potatos in the scheme of things. > > It's hard to say why they picked the parts they did. Is this a custom > board the coolrunner is on? Is this a complex board? If not, this > can be redone with a different part without too much difficulty or > time. Board houses can turn a board in literally a couple of days if > you don't mind paying a premium. But then you said you were out of > hardware money. > > > "Actually, after I made the post I realized that the generic W > > defaults > > to 4, specifying 16 bytes in the FIFO, but is set to 2 in the calling > > code specifying only 4 registers. Still, that is 64 FFs even if it > > doesn't get you back under the wire, it will help." > > > Ah yes, that is true, but what isn't made clear is that my data is no > > longer 8 bit ASCII. Its a 64 bit custom bitstream, so those 4 > > registers are holding 64 bit data not 8. How does that FF calcuation > > work again against the coolrunners jury-rigged, FF based registers? > > I'm hoping this is the solution, get rid of the FIFO and the simple > > state machine, bit shifting UART is tiny. > > Actually, I said the above wrong. The default for W is something like > 16 registers in the FIFO. The value passed into the FIFO code is 4 > which means it is only using 64 FFs for the FIFO buffer, plus what > ever shakes out in the control logic. > > If you have a 64 bit register, and it is custom, do you really need a > UART? Does this need to be async serial? If you are receiving this > in another controlled device SPI would let you do what you want and be > simpler. SPI is like a UART, but no start/stop bits, just data. Plug > a byte into the shifter and it sends out the data; keep plugging in > bytes until your burst is done and the whole thing is transferred as > if it were one word. SPI transmit and receive use the same register, > so that also cuts resource usage. A lot of this depends on what the > other logic is like. However, CPLDs tend to be rich in logic so you > should be able to generate the data in this part if you can get the FF > count down. But the devil is in the details. > > If you are sending this to a PC serial port then you need to keep the > UART, just make a very simple UART. > > In the thread where you are discussing the boot prom with Josep, yes, > most FPGAs require a boot prom or direct boot control by a CPU. Some > have internal Flash, Lattice parts notably. But certainly any board > level product will include at least one means of booting the FPGA if > not several. > > Rick Morning Rick. > It's hard to say why they picked the parts they did. Is this a custom > board the coolrunner is on? Is this a complex board? If not, this > can be redone with a different part without too much difficulty or > time. Board houses can turn a board in literally a couple of days if > you don't mind paying a premium. But then you said you were out of > hardware money. Its a custom board, and we've already allocated $$$ to the re-sping to the board house. When I say we are out of money its that there is nothing left for anything new. Actually that's a load of bunk anyway, we have a deliverable and we are going to pay to whatever we have to to make sure we deliver, but I best do my due-diligence to make it as least painful as possible. Every time we go to the board houses its a mess. it always takes the hardware boys 3-4 times to get it right. I don't have the time for that to fix this problem. It's bad enough they will have to modify the current board for the additonal features, If the pin layout is different, voltage levels different, etc, (and I'm sure they are) Its gonna be a big mess. > If you have a 64 bit register, and it is custom, do you really need a > UART? Does this need to be async serial? If you are receiving this > in another controlled device SPI would let you do what you want and be > simpler. SPI is like a UART, but no start/stop bits, just data. Plug > a byte into the shifter and it sends out the data; keep plugging in > bytes until your burst is done and the whole thing is transferred as > if it were one word. yes it has to be async serial. Its not my protocol, its a functional spec. and have you looked at my UART? all it is is a shifter, I don't think is can get any simpler. I think you really hit the nail on the head before with the fifo que not being efficient in a coolrunner environment. I'll be trying that out first thing on Monday. > But certainly any board > level product will include at least one means of booting the FPGA if > not several. -- yeah, josep and I had a mis-communication. He thought I was just looking at a replacement chip for the custom board that is currently housing the coolrunner chip. I was talking about using the enterpoint BOARDS as a stand alone solution to my communcations needs. I'll be on the phone with enterpoint on monday morning and clarifying this stuff. I'll be able to push through the purchase of the boards; so long as they get the job done. If they don't work then I'm in trouble. My biggest problem is that I set the expectation that I could get it done with the coolrunner as it is, with ZERO addtional hardware. I know I told them that there might be a space problem and I might have to go with a second board, but that of course is the first thing the PM has forgotten. All he remembers is that I said no additional hardware and now I'm looking at a new board for the stack. I shoulda sent a memo... From pcw@www.karpy.com Sun Mar 22 07:44:01 2009 Path: flpi141.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Sun, 22 Mar 2009 09:44:29 -0500 From: Peter Wallace <pcw@www.karpy.com> Subject: Re: Spartan 3 LVDS Date: Sun, 22 Mar 2009 07:44:01 -0700 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: <pan.2009.03.22.14.44.00.712281@www.karpy.com> Newsgroups: comp.arch.fpga References: <Kmrxl.223082$Dz4.54592@newsfe20.ams2> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 20 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 66.80.167.54 X-Trace: sv3-EkEFlgi0i33Y98O8C4kn5ssN3f8gJdL50IaVPjSOdSxbC35KEdo1fUFIBu5LyUkPAlAnLLkoeAKrLTS!gZfecSH4zKkC/r0RmgQvKDrLE6q0dz2eTNqndUH5p6dLtky0Ave1p9bp474yGslAk8X1i453tWGs!ypXcG3Azx7TI X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: prodigy.net comp.arch.fpga:152537 X-Received-Date: Sun, 22 Mar 2009 10:44:31 EDT (flpi141.ffdc.sbc.com) On Sun, 22 Mar 2009 13:50:36 +0000, Andrew Holme wrote: > Hi, I'm using the Spartan 3 XC3S400-TQ144. Does this device have internal > 100-ohm termination for LVDS input pairs, or must I use an external 100-ohm > resistor? When I designed my board, I assumed internal termination would be > enabled automatically by instantiation of the IBUFGDS; but looking at my > signal levels, although my board is working, I would say there is no > termination. The only statement I can find in the datasheet is note 5 > hidden away below table 37, which I think I can be forgiven for overlooking. > I only have two input pairs, and it's a prototype board, so I can just > solder 0201 resistors between the pins; but maybe someone here knows better > ... > > TIA It does have internal termination but termination depends on the reference resistors connected to the VRP and VRN pins on the bank that needs termination, Are these installed? Peter WallaceArticle: 139158
On Mar 22, 10:23 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sat, 21 Mar 2009 19:19:09 -0700 (PDT), jleslie48 <j...@jonathanleslie.= com> > wrote: > > > > >On Mar 21, 8:39 pm, Brian Drummond <brian_drumm...@btconnect.com> > >wrote: > >> On Sat, 21 Mar 2009 08:10:07 -0700 (PDT), jleslie48 <j...@jonathanlesl= ie.com> > >> Otherwise given the cost constraints you mentioned, I'd say you should= n't be > >> wasting time trying to fit a too-small device. Is your software team t= rying to > >> keep their executable below 4K? > > >> - Brian > > >"Is your software team trying to keep their executable below 4K?" > > >first off the software team is me. For 20 years now I keep getting > >suckered into these solo missions into [the companies] no man land... > > >I'm sorry are you referring to $4k or some size requirement of 4k??? > > I meant 4k bytes. As in, I was trying to find the SW equivalent of squeez= ing a > hardware design into a Coolrunner... > > It's a valid thing to do ... sometimes. If it's easy to eliminate the lar= ge > storage that is currently causing problems, and that avoids a board re-sp= in for > example. > > But often it's a waste of time to conserve a low value resource. > > I'm sorry I was unclear. > > > I'm assuming I can load the program > >into the enterpoint solutions and on powerup they start to > >function... > > Look for configuration storage, such as... > "Drigmorn1 have a M25P40 (4 Mbit) serial flash that is used for both > configuration of the FPGA and ..." so I'd have to say yes for that one. > > >The guys on this project have blown their budget for hardware already, > >at least for this next deliverable, so any $$$ I spend (not counting > >labor) are being watched carefully. > >1) Drigmorn1 has a XC3S500E-4CPG132C spartan-3 chip: > > Xilinx XC3S500E-4CPG132C > >FPGA Spartan=AE-3E Family > >500K Gates > > Number of Registers 9312 > > RAM Bits 368640 > >Which of these products will do the job and not be too small like the > >coolrunner? > > I would expect any of them to be overkill, quite frankly. > > It should be a few minutes work to select say the Spartan3-100 (the small= est > available on Drigmorn) and synthesize the current design for that, and se= e how > much space is left over. > > Alternatively you mentioned a PC104 stack - have you seen the Hollybush I= and II > PC104 cards from the same site? > > I don't know how PC104 cards stack but it's possible you may just have to= plug > one of these straight in. Or a larger one may swallow some of the functio= nality > from the rest of the stack. > > - Brian Ok good. this is all falling into place now. That's what I wanted to hear: "I would expect any of them to be overkill" I am sick to death of busting out the resources of a device. I want from now on 10x capable size growth... It just seems so ridiculous in a prototyping environment to right-size this low-cost items. These chips are under $100 and in that price range you can get hundreds of times the performance from one chip to another. This is not the area to be worrying about overkill. I saw that holly bush too. Those guys (ok there were some other software guys on the team, but strictly C programmers on the PC 104 stack) have managed to make that PC104 stack 5+ cards already, I'm pretty sure they said they were over the limit already. Besides I'm not going near that stack for what they paid for it. That's the stack that has the $16,000 1553 card, And I'm pretty sure they paid over $100,000 for some green hills programing suite. And now my PM is gonna give me a hard time for $700 worth of FPGA boards. How stupid is that...Article: 139159
On 21 Mar, 22:28, rickman <gnu...@gmail.com> wrote: > On Mar 21, 1:43 pm, Jacko <jackokr...@gmail.com> wrote: > > > On 21 Mar, 14:13, rickman <gnu...@gmail.com> wrote: > > > > On Mar 21, 2:38 am, Jacko <jackokr...@gmail.com> wrote: > > > > > That would be like saying you need the extra )s on the front of > > > > numbers when you do arithmetic on paper. > > > > Extra what??? =A0Actually, you are quoting your own comment. > > > Zero's in the Most Significant Digits. (shift ')') > > This why people have no idea what you are talking about. =A0How does ')' > imply a zero??? It doesn't imply a zero but infering a zero as being on the same key is well ... > Back to the point, the issue is not the notation that the opcodes from > 0 to 15 have to have zeros in front, the issue is that your opcode is > N bits wide, not 4! =A0The point is that there are only 17 opcodes in > your machine and each one uses a full word for storage. =A0The logic in > this CPU may be small, but the program storage is nothing like > compact. The subroutine threading is very compact, although not token threading level compact. I would assume an FPGA needing this compaction, would not use token threading, but would use an indirection table for all subroutine addresses and literal constants. To imply the advanced branch as one opcode misses the point entirely. One semantic yes but definatly different codes. As you point out if you choose not to optimize the section of memory containing the primitive 16 opcode subroutines then yes you will have some space occupied by zeros. In a typical small forth system, the primitive code requirements are small, and so I think your dislike is mis-respresentative of the compact size a system may be programmed in. > > > > (Depends on the subroutine start address) all subroutines are calls= , > > > > so they are all calls, just one is LIT. > > > > I have no idea what you are talking about. =A0How does this instructi= on > > > set specify literals? > > > The instuction set does not specify literals, BUT it does specify > > enough variety of instuction to write a subroutine to load a literal. > > On calling this subroutine, the return address is on the R stack, and > > is loaded, used as an index to memory to fetch the literal with post > > increment. It is then save back to R stack to allow contiuation of the > > instruction stream on exit from the subroutine. The fetched literal in > > the accumulator is stacked onto the stack before return. > > > : LIT RI ( get return address ) FI ( get literal at return address > > post increase also ) RO ( save new return address =3D addr+1 ) SO > > ( stack the fetched literal ) BA ( exit from subrotine ) ; ( well a > > code def may be better ) > > > : LITERAL ['] LIT , , ; > > I would say this is also very, very inefficient. =A0Try reading > Koopman's book on stack computers. =A0His data indicates that LIT is the > second most frequent Forth operation (on average) in terms of > occurrence in the code and sixth most frequent in terms of execution. > Having to embed a literal in the code and then call a subroutine to > get it put on the stack may be novel and interesting, but very > inefficient. And having a (P)->(S) double memory access opcode as a primitive opcode within the basic suported set, leads to quite a miss-match to a single memory access per instruction architecture. A descision was made at design time to limit meory accesses per instruction for the simple reason of size of design, and scalabiltiy of multiple dispatch algorithms. I do not consider load literal to TOS in anyway primitive in this sense. Hardware efficiency for a particular task, can be implemented by subroutine hardwiring. > Funny, often the goal of literal instructions is to optimize small > magnitude literals since they are more frequent than larger > magnitudes. =A0This is especially true for relative addressing due to > the locality in time and space for memory accesses. =A0Your scheme of > using those low magnitude literals for opcodes shoots that in the > foot. Relative addressing? This definitly does not scale as well as stack or direct addressing. Like I said, the instruction set is designed for scaling option. Forcing certain instructions into hardware as must haves, destroys scalability options. > > > Your obfuscation is getting to be annoying. =A0You never explain what > > > you mean, you speak in crypto language and you seem intent on never > > > really explaining the principles of your design. =A0Even your assembl= y > > > language is some new symbolism that just serves to isolate what you > > > are doing and thinking rather than to be at all useful for > > > communication. > > > I am open to anyone developing a 'longwind' instruction mnemonic set, > > there is no ONE CORRECT way to symbolize function. > > No, there is no one way to do something correctly. =A0But there are an > unbounded number of ways to do it poorly. =A0The question is are you > documenting it so others will understand it or just for your own > amusement? =A0If the former I think the response you are getting is > telling you it isn't working. =A0If the later, only you can judge. Well maybe the sylabic mnemonic set was for my own ammusement, or though ideas, and as such I did it that way. If people feel/require/ need it to be another way, then they are able to do it that way themselves. I am not an opcode translation service. Certain things get done free. If you want a free addition to the project, by all means make a request. If you want it doing right, right now, by some 'my way' standard, do it yourself. > > > None of the rest of this is at all useful. =A0You are presuming that = I > > > am making some sort of statement or that I am looking at your > > > processor from a very different point of view. =A0I am doing neither. =A0I > > > am trying to understand your processor from the point of view of a > > > small, embeddable CPU for use in an FPGA and in particular, to be > > > programmable in Forth. =A0That is the target of my CPU. =A0I am hopin= g to > > > learn something about these processors that I don't know or that I > > > haven't thought to try. =A0What I am learning about this design is th= at > > > it seems to have been designed without regard to a lot of knowledge > > > available, not that I will ever know for sure because it will never > > > really be explained. > > > Without regard? So what would be the point of exploring the avenue of > > regard to convention? I understand it gets followed verbatum > > thoundsands of times on university degree programs, and it hasn't > > produced many major improvements in design. > > I don't think you understand what I am saying. =A0I am not suggesting > that you need to repeat the designs of others. =A0I am suggesting that > you might learn something from their failures (or just suboptimal > successes). =A0I have found a number of design decisions that make you > machine inherently limited and inefficient. =A0If you care about that, > you will read a few references to learn what others have found before > you. =A0Then you can improve on their work rather than to go off blindly > and make all your own mistakes. And a new way of thinking of literals, and restrictions on such, and the results when applied to scaled multi-processor/super-scalar have been tried by who? Just because all mainstream designs have literal instructions for 'performance reasons' does not in any way imply 'performance' has been a closed research field. > Of course this is assuming that making a useful design is your goal. > I don't know this is your goal. =A0You may well be doing this to amuse > yourself only. =A0The lack of any real communication regarding your > design tends to indicate the latter. Compared to many 8 bit designs this is both useful and effective. > > > Have you read Koopman's book on stack CPUs? =A0He covers a lot of gro= und > > > with that. > > > I think I did download it once, and have a long base of reading > > stretching from '82. > > > So you would be suggesting "literal common, need literal fast", where > > as I would suggest "literal in opcode create bulk" not in the > > instuction decode execute sense, but in the instruction representation > > sense. Literals by there nature are not nibble constrained, where as > > code/end-code definitions can be. > > I have no idea what you mean by any of this. =A0What does "nibble > constrained" mean? =A0As to the trade off between bulk and "speed", how > large is your code if you have to use some, what, four, five, six > words to insert a literal in your code -1, for example, versus a > command that inserts a literal using perhaps two words? =A0Koopman's > book says Literals are some 10% of the occurence of Forth words. =A0That > would mean your usage of Literal requires the code to be some 20 to > 30% larger! Subroutine only written once. 2 cells per literal. -! obviously can be 1 cell if it also becomes threaded. in fact any literal used more than 3 times can be more effectively shrunk to 1 cell per literal. (a subroutine) constrained =3D> made to fit within limits or bounds. (nibble constrained =3D 0 to 15). > That is what I mean... > > > Also say I have the subroutine for LIT at address $0101, there is > > nothing inherant in the design to prevent me adding a IR=3D$0101 > > comparator with (P)->S routing in a single fetch execute cycle. Such a > > design is still code compatable with nibz. Let's call this a hard > > wired subroutine option for purpose technique. It is not a default as > > it will make your code definitions bigger (not nibble wide without > > significant extra logic). > > Ok, this sounds a bit like the ZPU. =A0They have reserved a number of > opcodes for "emulate" instructions which can be a subroutine or done > with logic. =A0Of course that will work. =A0But it means you address spac= e > gets chopped up which is something to be avoided in a CPU addressing > limited internal FPGA memory. =A0It also is still not as efficient as > other schemes using two words when often only one will do, or better > less than one. =A0Is it efficient to use 32 bits to insert a -1 in your > code? ZPU emulate some essential instructions in hardware, yes kind of like, but all essential instructions are in hardware. Extra instructions have no fixed opcode, they have virtual subroutine addresses. So rather than soft instructions, why not have hard subroutines? From a microcode point of view, such things are closely related. > > Usual comment number 1: "I can't write primitives without literals!" - > > > > "Such a thing is not primitive." > > > Usual comment Number 2: "But nibbles waste memory in cells!" -> "The > > zero cell area can be factored to leave an area to place nibz in, or > > some other nibble oriented compaction protocol can be used." > > Again, I don't know what you are talking about. > > > Usual comment number 3: "Why don't you do everything at once!" -> > > "Because extra arms occupy more volume, and require more motor cortex, > > hence more volume, hence slower reaction time, hence no such thing is > > possible." > > This on the other hand is perfectly clear... =A0not! > > Do you really care if you make anyone understand what you are talking > about? making people understand? If people understand the y do, if people do not understand the may eventaually, if the is such an important need to indoctrinate people, making may be an unsavoury procedure. Really care? As opposed to virtually care? As in expressing a duty of care? Please elaborate using non circular arguments ... > I'm going to start calling your "Cryptoman"! =A0Your one weakness is > "Cryptonite", a substance that makes you communicate with perfect > lucidity and brings about your ultimate destruction! This would imply I am self destructive, by me not communicating my need to have the Cryptonite removed, as I would see my destruction, as I would see everything of my instamachinations for the concept of constrained infinite lucidity to be elaborated within me and flush out my band limited mouth to provide enlightenment to everyone within ear shot. Your statement is inconsistant bleep bleep, BA stack underflow ......Article: 139160
On Mar 21, 7:49=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Mar 18, 10:04=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > Hi, > > I want to generate a random number in a FPGA chip and in a natural way > > it leads to a famous paper Xilinx XAPP052 authored by Peter Alfke: > > "Efficient Shift Register, LFSR Counters, and Long Pseudo-Random > > Sequence Generators". > > > I have two problems with the note. > > > 1. I don't understand "Divide-by-5 to 16 counter". I appreciate if > > someone explain the Table 2 and Figure 2 in more details. > > > 2. In Figure 5, there is an equation: (Q3 xnor Q4) xor (Q1 and Q2 and > > Q3 and Q4). > > (Q3 xnor Q4) is required to generate 4-bit LFSR counter. (Q1 and Q2 > > and Q3 and Q4) is used to avoid a dead-lock situation from happening > > when Q1-Q4 =3D '1'. > > > Now the 4-bit LFSR counter dead-lock situation should be extended to > > any bits long LFSR counter if 2 elements XNOR operation is needed. > > Especially in Figure 5 for 63-bit LFSR counter. When all 63-bits are > > '1', it would be dead-locked into the all '1' position, because (Q62 > > xnor Q63) =3D '1' if both Q63 and Q62 are '1'. =A0But the situation is > > excluded into the equation in Figure 5. > > Weng, please explain why you need a 63-bit counter. > Even clocked at 1 GHz, it will take hundreds of years to "roll over". > The all-1s condition can only occur when you preset the counter to 63 > ones, so that it locks up. > (I prefer the all-ones as the illegal state to the all-zeros, because > FPGAs naturally reset their flip-flops.) > It's hard to help you when we do not understand your concerns. > Peter Alfke- Hide quoted text - > > - Show quoted text - Hi Peter, I am doing a home project which uses random number to detect design errors. 1. The random number must be not locked up; 2. The random number distribution characteristics are not important; 3. 63-bit LFSR is not specially required. My board clock is 66MHz. And I can change the length at any time based on the FPGA resources available. For a discussion convenience, I selected 63-bit LFSR. 4. Glen gave me a good suggestion that condition1 will never be met which saves me a lot of logic. Thank you. Weng I appreciate If you give me a digital example showing divided-by 16 counter. I don't understandArticle: 139161
"Peter Wallace" <pcw@www.karpy.com> wrote in message news:pan.2009.03.22.14.44.00.712281@www.karpy.com... > On Sun, 22 Mar 2009 13:50:36 +0000, Andrew Holme wrote: > >> Hi, I'm using the Spartan 3 XC3S400-TQ144. Does this device have >> internal >> 100-ohm termination for LVDS input pairs, or must I use an external >> 100-ohm >> resistor? When I designed my board, I assumed internal termination would >> be >> enabled automatically by instantiation of the IBUFGDS; but looking at my >> signal levels, although my board is working, I would say there is no >> termination. The only statement I can find in the datasheet is note 5 >> hidden away below table 37, which I think I can be forgiven for >> overlooking. >> I only have two input pairs, and it's a prototype board, so I can just >> solder 0201 resistors between the pins; but maybe someone here knows >> better >> ... >> >> TIA > > It does have internal termination but termination depends on the > reference resistors connected to the VRP and VRN pins on the bank that > needs termination, Are these installed? > > Peter Wallace That would be DCI, correct? I haven't fitted those reference resistors, and one of my pairs is in bank 5. Looks like popping an 0201 between the pins is still my best bet.Article: 139162
Hi Wang
I have always referred to that useful xilinx document for my shift random
generators. here is an example of my code for a 33 bits shift register,
hope it helps, I "believe" I didn't have any problems.
signal shift_reg : std_logic_vector(33 downto 1);
.....
process(reset, clk)
begin
if(reset = '1')then
shift_reg <= '0' & x"28EA5CB1"; -- seed
elsif(rising_edge(clk))then
shift_reg(1) <= shift_reg(33) xor shift_reg(20);
shift_reg(33 downto 2) <= shift_reg(32 downto 1);
end if;
end process;
kadhiem
Article: 139163I think that there is no particularly advantage of implementing DVI receiver and transmitter functions in FPGA. There are sophisticated solutions on the market for that, DVI/HDMI receiver and transmitter ICs are available for this task. These implementations are surely compatible with the standard, so you don't have to care about e.g. the eye-diagrams. Lot of circuits has features what cannot be implemented in FPGA: e.g. high and adaptive input equalization on TMDS, adjustable driver parameters, etc. If you use a separate DVI receiver, then you got the paralell pixel data and you can process it with an FPGA if you want. But if you implement the receiver function in FPGA then - due to the complicated standard - you will certainly not too much space to additional tasks and functions.. On Mar 21, 2:47=A0pm, Mawafugo <cco...@netscape.net> wrote: > In xapp460 the DVI/HDMI transmitter & receiver is implemented but the > max throughput limit to somewhat 750 Mb/s, which can handle up to > 1080i or 720p resolution. =A0The 1080p, however needs twice of that > > The question is how can we crank up the throughput to about 1.5 Gb/s ?Article: 139164
On Mar 22, 9:18=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > Hi Wang > > I have always referred to that useful xilinx document for my shift random > generators. here is an example of my code for a 33 bits shift register, > hope it helps, I "believe" I didn't have any problems. > > signal shift_reg : std_logic_vector(33 downto 1); > ..... > > process(reset, clk) > begin > if(reset =3D '1')then > =A0 =A0 =A0shift_reg <=3D '0' & x"28EA5CB1"; =A0 -- seed > elsif(rising_edge(clk))then > =A0 =A0 =A0 =A0 shift_reg(1) <=3D shift_reg(33) xor shift_reg(20); > =A0 =A0 =A0 =A0 shift_reg(33 downto 2) <=3D shift_reg(32 downto 1); > end if; > end process; > > kadhiem Hi kadhiem, 1. Your design has an error: not XOR, it should be XNOR. It may be a type. 2. Your design takes 33 flip-flops. Best way is to use shift function of distributed RAM in Xilinx. But Xilinx shift function has a limit: it cannot have an initial value. If the register is initialized, it would become individual FFs as in your case. WengArticle: 139165
Ok lets start with the easy thing and say Drigmorn1 is a development board version of Craignell. We added a serial port and made the JTAG and SPI 7x2 2mm headers and added a power jack. We lost a few I/O on the Drigmorn to the serial port but otherwise it is just an easier way to play with the same design as the Craignell. I will mention the new launch Craignell2 which a very big brother of Craignell1. Same concept as the original but starting at a DIL40 and going up. The team did a very good job on this new product and I have had it run our production I/O test running logic from about 1.2V up to about 5.5V without adjustment. I even JTAG programmed it at 2V a few times just to see if it would do it. Those out of spec voltages won't be officialy supported 3-5V will be the official range. Other nice things are the 128Mbit Flash and 256Mbit SDRAM so the Craignell2 is a serious processor taget. If you happen to be into older processors we also made a wide ramge of power pin options (solder bridge). Back to comparision I will list the following as short list bracket figure is Craignell/Drigmorn figure: Raggedstone General main headers I/O (not including PCI) - 116 (38) FPGA size - 400K or 1500K notional gates (100K or 500K gates) Board Size - 170x75mm (50x57mm not including pin overhand) Power - 5V + 3.3V (Single 5V) Price - From GBP=A3135 (from GBP=A340) Summary as play board the Drigmorn1 is a good basic board to start on. It can even be used as a Raggedstone1 (and others) co-processor if the I/O pins are changed to vertical types. We are currently increasing our GBP=A3 prices across the range mainly because of substantial increases in component pricing we have seen in the last few months. These increases due to the US dollar swing and other price increases we are seeing from major suppliers. Most these increases won't be seen by customers outside the UK as the dollar and euro swings are off-setting most of these increases to customers based in countries with those, and other, currencies. There is a special offer that starts today for FEDEX at GBP=A320 and thats for any quantity and any place. Details of that are in tomorrows newsletter for those that are on the list. We have some other things coming that might be of interest at the simplier end. Polmaddies2,3,4 and 5 will appear shortly. These simple boards are great for playing with. We aimed them at the student lab market and all 5 in the series have similar features the main one being 4 sets of traffic light LEDs Going back to the concerns on Raggedstone1. There are occasional foul problems on one of the regulators with new modules (supporting inner power pins). Usually the simple way with this is to used a spacer header or chop off the the inner module pins and take power from the top ones on the main run. We may be doing a an update on this board in the future and several improvements are planned including for this issue. The sister products Raggedstone2 and Raggedstone3 won't have this issue as they will have the full power strips that can be seen on the new product Mulldonnoch2. Regulator heating is not an issue on Raggedstone1. There are substantial thermal take away planes. Most implementations take between 0.2-1 amps through the regs which are rated for 4 amps. Even with a module fitted the ambient would have to be very warm for there to be any likelyhood of a thermal issue. John Adair Enterpoint Ltd. On 21 Mar, 17:46, jleslie48 <j...@jonathanleslie.com> wrote: > On Mar 21, 1:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > > On Mar 21, 10:14 am, John Adair <g...@enterpoint.co.uk> wrote: > > > > CPLDs are generally very small devices compared to a FPGAs. They are > > > generally slightly easier to use for the novice but I won't let that > > > put you off going for FPGA. Virtex-IIPro is a very old and expensive > > > familiy now. Xilinx offers 2 sets of families. The Virtex range is > > > big, very fast and expensive. Virtex-5 is readily available with > > > Virtex-6 just announced. The Spartan families go from small to medium > > > size in comparision. Coolrunner etc. I would describe as tiny to give > > > a reference. > > > > If you have the ability to choose a part now then the Spartan-3A or > > > Spartan-3AN are probably a good choice. The S3-A needs an external > > > Flash memory that is used to configure the device at power up. The S3= - > > > AN has an internal Flash that is used for that purpose. > > > > The smallest S3-AN is the XC3S50AN and it has about 1400 flip-flops a= s > > > a comparision to the Coolrunner with 512 macrocells which have 512 > > > flip-flops available. It is very difficult to make a simple > > > comparision between CPLD and FPGA technologies but I would suggest > > > just trail building the design in a XC3S50AN to get a better > > > comparision. ISE Webpack I presume you already have and it will only > > > take a few minutes to change the part type and re-build. > > > > If you do want a development board we supply lots of choice with some > > > more shortly in this market sector soon. You may find some of the > > > links on our Techitips page useful -http://www.enterpoint.co.uk/techi= tips/techitips.html. > > > > John Adair > > > Enterpoint Ltd. > > > John, > > > You have me very interested in this board and your products. =A0I > > imagine I will be getting one to try out very soon. =A0I am concerned > > though, you have put on the raggedstone1 board voltage regulators > > right in the middle of the GPIO pin > > layouts. =A0In the case of he RHS DIL headers, there is a voltage > > regulator (read: huge heat source that needs to be ventilated) between > > the mid and right column. =A0You have a similar arrangement on the LHS > > as well. =A0I will need to put a daughter board onto this card and I > > would love to snap it in right on top of the DIL headers, but I'll > > have to trap that voltage regulator on 4 sides, Its even worse since > > you put the ground on one column and power on the other so I can't > > even just have the daughter card on the two headers and skip the third > > letting the voltage regulator vent. > > Actually you have me very interested. =A0I've been poking around, what > about > these products? > > the drigmorn:http://www.enterpoint.co.uk/component_replacements/drigmorn1= .html > > the craignell:http://www.enterpoint.co.uk/component_replacements/craignel= l.html > > I love the size of these guys, and If I'm not mistaken they have all > the "nutrition facts" that I need. =A0why would these > not be appropriate vs the raggedstone1? > > I guess I'm looking for a comparison sheet for all three of these > boards.- Hide quoted text - > > - Show quoted text -Article: 139166
Hi Wang, I think either xnor or xor are possible. The effect is then choosing seed value. Implementation can be either in registers or memory. The choice is yours kadhiemArticle: 139167
>No I'm not aware, are you saying these devices can't be loaded with >the software so when they >power up they start running? Why haven't you looked at the data sheet? Yes, it's huge, but you should have looked close enough to found the section that describes loading it. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 139168
On Mar 22, 10:36=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > Hi Wang, > I think either xnor or xor are possible. The effect is then choosing seed > value. > > Implementation can be either in registers or memory. The choice is yours > > kadhiem The difference between XOR and XNOR is the illegal (lock-up) state. In one case it is all-ones, in the other it is all-zeros. Peter AlfkeArticle: 139169
On Mar 22, 10:51=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > On Mar 22, 10:36=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > > > Hi Wang, > > I think either xnor or xor are possible. The effect is then choosing se= ed > > value. > > > Implementation can be either in registers or memory. The choice is your= s > > > kadhiem > > The difference between XOR and XNOR is the illegal (lock-up) state. In > one case it is all-ones, in the other it is all-zeros. > Peter Alfke Hi Peter, I don't know if XOR will tranverse all data, excluding the lock-up state. Maybe there are some reasons why the original paper uses XNOR, not XOR. WengArticle: 139170
On Mar 22, 3:00=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > When you have to a production run of more than 1000 units, then you > worry about right-sizing. Meantime the spartan would still have been > way cheaper anyway for all their "right-sizing" effort. Right-sizing > is only important if it saves you something. > Please, allow me to point in a completely different direction. As you are a software guy, you have probably considered implementing the UARTS in a uC. I think a small AVR (or PIC) could easily handle 10 serial channels, particullarly at slow baud rates. Is there a reason why you wouldn't follow this path ? (I am talking about a complete software implementation here) It is not about cost, but about development time. Josep Dur=E0nArticle: 139171
Jacko wrote: > On 21 Mar, 22:28, rickman <gnu...@gmail.com> wrote: ... >> Do you really care if you make anyone understand what you are talking >> about? > > making people understand? If people understand the y do, if people do > not understand the may eventaually, if the is such an important need > to indoctrinate people, making may be an unsavoury procedure. > > Really care? As opposed to virtually care? As in expressing a duty of > care? Please elaborate using non circular arguments ... In other words, no. Advice to Rick: give up. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================Article: 139172
On Mar 22, 11:13 am, Jacko <jackokr...@gmail.com> wrote: > On 21 Mar, 22:28, rickman <gnu...@gmail.com> wrote: > > > On Mar 21, 1:43 pm, Jacko <jackokr...@gmail.com> wrote: > > > > On 21 Mar, 14:13, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 21, 2:38 am, Jacko <jackokr...@gmail.com> wrote: > > > > > > That would be like saying you need the extra )s on the front of > > > > > numbers when you do arithmetic on paper. > > > > > Extra what??? Actually, you are quoting your own comment. > > > > Zero's in the Most Significant Digits. (shift ')') > > > This why people have no idea what you are talking about. How does ')' > > imply a zero??? > > It doesn't imply a zero but infering a zero as being on the same key > is well ... This is the sort of obfuscation that you seem to revel in. Why infer or imply a zero when a zero could have been typed??? > > Back to the point, the issue is not the notation that the opcodes from > > 0 to 15 have to have zeros in front, the issue is that your opcode is > > N bits wide, not 4! The point is that there are only 17 opcodes in > > your machine and each one uses a full word for storage. The logic in > > this CPU may be small, but the program storage is nothing like > > compact. > > The subroutine threading is very compact, although not token threading > level compact. I would assume an FPGA needing this compaction, would > not use token threading, but would use an indirection table for all > subroutine addresses and literal constants. Yes, subroutine threading is compact. But your use of an word wide opcode for *every* instruction is not compact. > To imply the advanced branch as one opcode misses the point entirely. > One semantic yes but definatly different codes. > > As you point out if you choose not to optimize the section of memory > containing the primitive 16 opcode subroutines then yes you will have > some space occupied by zeros. In a typical small forth system, the > primitive code requirements are small, and so I think your dislike is > mis-respresentative of the compact size a system may be programmed in. If you think I am concerned with 16 words of memory lost to the opcodes, then you are confused about what I have said. There are two ways your instruction set is less than optimal. The encoding uses a full word for every instruction. Many MISC machines use opcodes of five bits. My machine uses opcodes of 8 or 9 bits depending on the implementation. Using 16 or 32 bits is very wasteful for the code using primitives. Even in higher level code a significant percentage of the codes is still primitives. The other inefficiency is the poor integration of literals into the instruction set. Needing to call a subroutine to load a literal is not an efficient use of memory or processor speed. Adding an optimization for direct implementation of the literal subroutine is still not an efficient use of memory, requiring two words for each literal. My main point is that you seem to be making your design decisions without the benefit of the work that has gone on before you. I am sure your design has advantages, although I doubt anyone here will ever know because of your poor attempts to communicate. > > > : LIT RI ( get return address ) FI ( get literal at return address > > > post increase also ) RO ( save new return address = addr+1 ) SO > > > ( stack the fetched literal ) BA ( exit from subrotine ) ; ( well a > > > code def may be better ) > > > > : LITERAL ['] LIT , , ; > > > I would say this is also very, very inefficient. Try reading > > Koopman's book on stack computers. His data indicates that LIT is the > > second most frequent Forth operation (on average) in terms of > > occurrence in the code and sixth most frequent in terms of execution. > > Having to embed a literal in the code and then call a subroutine to > > get it put on the stack may be novel and interesting, but very > > inefficient. > > And having a (P)->(S) double memory access opcode as a primitive > opcode within the basic suported set, leads to quite a miss-match to a > single memory access per instruction architecture. A descision was > made at design time to limit meory accesses per instruction for the > simple reason of size of design, and scalabiltiy of multiple dispatch > algorithms. I do not consider load literal to TOS in anyway primitive > in this sense. Hardware efficiency for a particular task, can be > implemented by subroutine hardwiring. I can't say anything about what is efficient in your machine. I do know that loading a literal is frequent in most CPU architectures and needs to be optimized over many other things. If you are designing a CPU for a large, complex CPU, then it will not be close to optimal for small machines. Is your stack in memory and not hardware? Since no one but yourself understands your instruction set, I can't tell what is happening with your code. > > Funny, often the goal of literal instructions is to optimize small > > magnitude literals since they are more frequent than larger > > magnitudes. This is especially true for relative addressing due to > > the locality in time and space for memory accesses. Your scheme of > > using those low magnitude literals for opcodes shoots that in the > > foot. > > Relative addressing? This definitly does not scale as well as stack or > direct addressing. Like I said, the instruction set is designed for > scaling option. Forcing certain instructions into hardware as must > haves, destroys scalability options. Why would relative addressing not scale? It is just a simple index off the PC. But since you have indicated that your goal is to have a scalable instruction set, I can understand why this machine will not be at all optimal for FPGA use where program memory is tight. > > > I am open to anyone developing a 'longwind' instruction mnemonic set, > > > there is no ONE CORRECT way to symbolize function. > > > No, there is no one way to do something correctly. But there are an > > unbounded number of ways to do it poorly. The question is are you > > documenting it so others will understand it or just for your own > > amusement? If the former I think the response you are getting is > > telling you it isn't working. If the later, only you can judge. > > Well maybe the sylabic mnemonic set was for my own ammusement, or > though ideas, and as such I did it that way. If people feel/require/ > need it to be another way, then they are able to do it that way > themselves. I am not an opcode translation service. Certain things get > done free. If you want a free addition to the project, by all means > make a request. If you want it doing right, right now, by some 'my > way' standard, do it yourself. No one gives a rat's rear what you *call* your instructions. No one understands what they do because you have not *documented* the instructions in a coherent way. I have no real interest in your project since I don't see any value in it. You seem to be trying to communicate to others here about your ideas and designs, but are failing to do so. That is the reason for my statements. I don't really care that much about understanding your project. I'm just pointing out that you seem to be failing in your goal. > > > > None of the rest of this is at all useful. You are presuming that I > > > > am making some sort of statement or that I am looking at your > > > > processor from a very different point > > of view. I am doing neither. I > > > > > > > am trying to understand your processor from the point of view of a > > > > small, embeddable CPU for use in an FPGA and in particular, to be > > > > programmable in Forth. That is the target of my CPU. I am hoping to > > > > learn something about these processors that I don't know or that I > > > > haven't thought to try. What I am learning about this design is that > > > > it seems to have been designed without regard to a lot of knowledge > > > > available, not that I will ever know for sure because it will never > > > > really be explained. > > > > Without regard? So what would be the point of exploring the avenue of > > > regard to convention? I understand it gets followed verbatum > > > thoundsands of times on university degree programs, and it hasn't > > > produced many major improvements in design. > > > I don't think you understand what I am saying. I am not suggesting > > that you need to repeat the designs of others. I am suggesting that > > you might learn something from their failures (or just suboptimal > > successes). I have found a number of design decisions that make you > > machine inherently limited and inefficient. If you care about that, > > you will read a few references to learn what others have found before > > you. Then you can improve on their work rather than to go off blindly > > and make all your own mistakes. > > And a new way of thinking of literals, and restrictions on such, and > the results when applied to scaled multi-processor/super-scalar have > been tried by who? Just because all mainstream designs have literal > instructions for 'performance reasons' does not in any way imply > 'performance' has been a closed research field. > > > Of course this is assuming that making a useful design is your goal. > > I don't know this is your goal. You may well be doing this to amuse > > yourself only. The lack of any real communication regarding your > > design tends to indicate the latter. > > Compared to many 8 bit designs this is both useful and effective. > > > > > > > Have you read Koopman's book on stack CPUs? He covers a lot of ground > > > > with that. > > > > I think I did download it once, and have a long base of reading > > > stretching from '82. > > > > So you would be suggesting "literal common, need literal fast", where > > > as I would suggest "literal in opcode create bulk" not in the > > > instuction decode execute sense, but in the instruction representation > > > sense. Literals by there nature are not nibble constrained, where as > > > code/end-code definitions can be. > > > I have no idea what you mean by any of this. What does "nibble > > constrained" mean? As to the trade off between bulk and "speed", how > > large is your code if you have to use some, what, four, five, six > > words to insert a literal in your code -1, for example, versus a > > command that inserts a literal using perhaps two words? Koopman's > > book says Literals are some 10% of the occurence of Forth words. That > > would mean your usage of Literal requires the code to be some 20 to > > 30% larger! > > Subroutine only written once. 2 cells per literal. -! obviously can be > 1 cell if it also becomes threaded. in fact any literal used more than > 3 times can be more effectively shrunk to 1 cell per literal. (a > subroutine) Since the literal instruction is used so often, and most literals are small values, the literal instruction can be smaller than a word on the average. In some MISC machines the literal instruction uses whatever is left of the current word. In my machine the literal (also used to specify addresses for calls and jumps) is the most optimized instruction with one bit plus the data field in the remaining bits. In the 9 bit instruction format, +127 -128 range takes a single byte and a 16 bit literal only takes two 9 bit bytes. Jumps and calls are further optimized by including a 5 bit field for the lsbs of the address calculation. There is nothing wrong with the way you are doing things. I thought you were optimizing for a small design for FPGA use. But I see now you have other priorities. > constrained => made to fit within limits or bounds. (nibble > constrained = 0 to 15). > > > That is what I mean... > > > > Also say I have the subroutine for LIT at address $0101, there is > > > nothing inherant in the design to prevent me adding a IR=$0101 > > > comparator with (P)->S routing in a single fetch execute cycle. Such a > > > design is still code compatable with nibz. Let's call this a hard > > > wired subroutine option for purpose technique. It is not a default as > > > it will make your code definitions bigger (not nibble wide without > > > significant extra logic). > > > Ok, this sounds a bit like the ZPU. They have reserved a number of > > opcodes for "emulate" instructions which can be a subroutine or done > > with logic. Of course that will work. But it means you address space > > gets chopped up which is something to be avoided in a CPU addressing > > limited internal FPGA memory. It also is still not as efficient as > > other schemes using two > > > ZPU emulate some essential instructions in hardware, yes kind of like, > but all essential instructions are in hardware. Extra instructions > have no fixed opcode, they have virtual subroutine addresses. So > rather than soft instructions, why not have hard subroutines? From a > microcode point of view, such things are closely related. Yes, I see your point (for once). I wonder how useful this really is compared to more conventional > > > Usual comment number 1: "I can't write primitives without literals!" - > > > > > "Such a thing is not primitive." > > > > Usual comment Number 2: "But nibbles waste memory in cells!" -> "The > > > zero cell area can be factored to leave an area to place nibz in, or > > > some other nibble oriented compaction protocol can be used." > > > Again, I don't know what you are talking about. > > > > Usual comment number 3: "Why don't you do everything at once!" -> > > > "Because extra arms occupy more volume, and require more motor cortex, > > > hence more volume, hence slower reaction time, hence no such thing is > > > possible." > > > This on the other hand is perfectly clear... not! > > > Do you really care if you make anyone understand what you are talking > > about? > > making people understand? If people understand the y do, if people do > not understand the may eventaually, if the is such an important need > to indoctrinate people, making may be an unsavoury procedure. > > Really care? As opposed to virtually care? As in expressing a duty of > care? Please elaborate using non circular arguments ... Yeah, I guess I just can't write clearly... > > I'm going to start calling your "Cryptoman"! Your one weakness is > > "Cryptonite", a substance that makes you communicate with perfect > > lucidity and brings about your ultimate destruction! > > This would imply I am self destructive, by me not communicating my > need to have the Cryptonite removed, as I would see my destruction, as > I would see everything of my instamachinations for the concept of > constrained infinite lucidity to be elaborated within me and flush out > my band limited mouth to provide enlightenment to everyone within ear > shot. Your statement is inconsistant bleep bleep, BA stack > underflow ...... Exactly!!! It worked just as I planned... BUWWWWWHHAAAHHAAA!!! RickArticle: 139173
On Mar 22, 2:12=A0pm, Elizabeth D Rather <erat...@forth.com> wrote: > Jacko wrote: > > On 21 Mar, 22:28, rickman <gnu...@gmail.com> wrote: > ... > >> Do you really care if you make anyone understand what you are talking > >> about? > > > making people understand? If people understand the y do, if people do > > not understand the may eventaually, if the is such an important need > > to indoctrinate people, making may be an unsavoury procedure. > > > Really care? As opposed to virtually care? As in expressing a duty of > > care? Please elaborate using non circular arguments ... > > In other words, no. =A0Advice to Rick: =A0give up. On one hand I would like to understand his thinking. On the other hand I also need to spend time thinking for myself and this is being a time sink. I think I may have pressed too hard and he is seeing me as an antagonist. So maybe it is time to stop pressing. RickArticle: 139174
On Mar 22, 1:41 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >No I'm not aware, are you saying these devices can't be loaded with
> >the software so when they
> >power up they start running?
>
> Why haven't you looked at the data sheet? Yes, it's huge, but
> you should have looked close enough to found the section
> that describes loading it.
>
> --
> These are my opinions, not necessarily my employer's. I hate spam.
I did and was comfortable that I saw I could load it up. However when
Josep
stated:
"Of course, you are aware that you need the FPGA + some sort of device
to boot it. "
I thought I mis-understood something. Josep is clearly warning me
that this needs some sort of device to boot it. The last thing I
need is to push a PO on my boss only to find out it isn't going to do
the job.
Plus I'm sorry these data sheets don't spell this stuff out. They
seem to spend a lot of time telling you stuff so they can say "it was
in the data sheet" meantime the data sheet doesn't say the basics in
plain english. for example in chapter 1, page one should be a heading
"FEATURES OF THIS BOARD "
1) xxx01 FF's
2) xxx02 macrocells
3) xxx03 pterms
4) onboard oscillator of xxx04 MHZ
5) slot for a different oscillator up to xxx05 MHZ
6) eprom for autoboot
7) xxx06-xxx07 input voltage range
8) peak amps: xxx08 ma
9) typical amps running: xxx09 ma
10) ) load your program from ISE Project manager into the onboard
prom.
11) load program using included xxx10 cable, or xxx11 cable (available
separately) or
xxx12 cable from xilinx...
12) <<detailed photograph of top side all lettering easily readable>>
13) <<detailed photograph of back side all lettering easily readable>>
14) <<detailed photographs of all sides if connectors are at 90
degrees>>
15) << one or two isometric views with either a ruler or some scale
reference (a pen, computer CD or such >>
16) << picture/drawing of expected runtime deployment environment>>
17) << picture/drawing of expected programming envionment>>
18) list of what is included in the package
19) list of what is not included but required to program/run
20) list of what are the optional parts.
21) ...
Plus every board should come with a "hello world" program, that the
user should be able to follow a step-by-step
guide and get results and thus confirm that all is in working order.
I see that the raggedstone1 has really tried to get that "hello world"
program and step-by-step guide in place:
http://www.enterpoint.co.uk/techitips/Programming%20Raggedstone1%20User%20Guide.pdf
On the strength of that document alone they are going to get me as a
customer. Its as good as I've seen, even though it fails to show the
cable connections for the board to the PC/ power supplies. I only
wish my diligent board and ISE 10.1 project navigator had a document
like that when I purchased that way back. If I had seen the
raggedstone1 then I would have bought 5 of those instead of the 1
diligent board.
That reminds me, I was looking at the waggle test for the drigmorn:
http://www.enterpoint.co.uk/component_replacements/drigmorn1_apps.html
in the user manual it said the the waggle test has a loopback for the
rs232 but I don't see th at in the .vhd code:
http://www.enterpoint.co.uk/component_replacements/DRIGMORN1_WAGGLE_TEST1.VHD
what's am I missing?
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