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 21, 10:47 am, rickman <gnu...@gmail.com> wrote: > On Mar 21, 1:14 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > On Mar 21, 12:12 am, rickman <gnu...@gmail.com> wrote: > > > > On Mar 20, 3:15 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On Mar 20, 2:58 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > On Mar 20, 1:41 pm, Mike Treseler <mtrese...@gmail.com> wrote: > > > > > > > jleslie48 wrote: > > > > > > > and when I added some digital outputs, the %'s went up, but then I > > > > > > > added a whole bunch of logic, and nothing changed, > > > > > > > If the number of cells or Pterms used didn't change at all, > > > > > > I would expect that a "whole bunch" of logic does not make it > > > > > > out to a pin. I would run a sim to check. > > > > > > > -- Mike Treseler > > > > > > ahhh, well that is a bummer. I just tied the output to a pin and now > > > > > I"m getting: > > > > > > Fitting... > > > > > . > > > > > ERROR:Cpld:1063 - Design requires at least 947 macrocells, exceeds > > > > > device limit > > > > > 512. > > > > > ERROR:Cpld:1062 - Design contains 2004 unique product terms, exceeds > > > > > device > > > > > limit 1536. > > > > > ERROR:Cpld:1064 - Design rules checking error. Fitting process > > > > > stopped. > > > > > ...o > > > > > ERROR:Cpld:868 - Cannot fit the design into any of the specified > > > > > devices with > > > > > the selected implementation options. > > > > > > any idea on how to make it fit? > > > > > ok, before I added my functionality, I had: > > > > Macrocells Used Pterms Used Registers Used Pins Used Function > > > > Block Inputs Used > > > > 379/512 (75%) 831/1536 (55%) 354/512 (70%) 118/176 (68%) > > > > 779/1280 (61%) > > > > > so from my errors, I can see I added some 600 macrocells, and 1200 > > > > pterms, > > > > > how can I find out who is the piggy, and what can I due to trim things > > > > down? > > > > I don't think you really got an answer to this question. To some > > > extent you can look at the code and estimate the number of macrocells > > > or other logic elements used. But to measure it, you need to break > > > the code into modules and let the tool tell you about each module > > > separately. In an FPGA the logic has a finer grain, so there are not > > > as much optimizations to affect these counts when you use the block > > > all together. But a CPLD can put a lot of logic into each macrocell > > > and will be much more limited by the FF count. Your design counts > > > above indicate that your design uses 1300 FFs and your CPLD only has > > > 512 FFs. Not a good fit! > > > > You won't find much in the way of optimizations that will make this > > > fit. The best thing to trim your logic is to change your algorithm. > > > If there are parts of your design that can run slowly compared to the > > > clock rate, you can let them run sequentially rather than in > > > parallel. But if your design has to run at the full rate of the clock > > > with everything in parallel, you just need a larger part. So take a > > > good, hard at your design and see if there is anything you can do to > > > reduce it. > > > > > also, what is a macrocell and pterm? > > > > I think these got answered, but a little more detail... A macrocell > > > is the unit block of a CPLD. It typically include one or two FFs, an > > > output, often to a pin along with some amount of logic. The logic in > > > a macrocell is made of p-terms and OR gates. P-terms are very wide > > > AND gates with inputs from all of the inputs to that block, all of the > > > FFs in that block as well as, in some devices, some inputs from other > > > macrocell p-terms. The p-terms of a given macrocell are OR'd together > > > to produce the input to the FF or it can be routed directly to the > > > output. There is also a p-term or two devoted to controlling the tri- > > > state driver on the output. The OR gate and FF outputs are connected > > > back to the logic matrix for use in other or the same macrocells. > > > Some devices have "buried" FFs which allow some of the logic in the > > > macrocell to be split off and used with this second FF, but the output > > > can only be routed back to the routing matrix, not an output pin. > > > > That is a lot to absorb from a description. I am sure the data sheet > > > has a picture that is very clear and can portray the detail better. > > > The main thing to understand is that the p-term (and) are unlimited > > > (or more accurately only limited by the inputs to the block routing) > > > and an FPGA typically has much smaller LUTs, usually 1 LUT per FF or > > > sometimes 4 LUTs to 3 FFs. So a CPLD is often FF count limited while > > > an FPGA is mostly LUT count limited. Certainly there are things you > > > can change in your design to use more logic and fewer FF to target > > > CPLDs. But I think it will be a major job to cut the design size by > > > more than half! > > > > > I originally ran this program on a virtexII, and everthing looked > > > > liked it > > > > was pretty small and effecient: > > > > > Device Utilization Summary > > > > [-] > > > > Logic Utilization > > > > Used > > > > Available > > > > Utilization > > > > Note(s) > > > > Number of Slice Flip Flops > > > > 1,282 > > > > 27,392 > > > > 4% > > > > > Number of 4 input LUTs > > > > 1,545 > > > > 27,392 > > > > 5% > > > > > Logic Distribution > > > > > Number of occupied Slices > > > > 1,302 > > > > 13,696 > > > > 9% > > > > > Number of Slices containing only related logic > > > > 1,302 > > > > 1,302 > > > > 100% > > > > > Number of Slices containing unrelated logic > > > > 0 > > > > 1,302 > > > > 0% > > > > > Total Number of 4 input LUTs > > > > 1,589 > > > > 27,392 > > > > 5% > > > > > Number used as logic > > > > 1,545 > > > > > Number used as a route-thru > > > > 44 > > > > > Number of bonded IOBs > > > > Number of bonded > > > > 15 > > > > 556 > > > > 2% > > > > > IOB Flip Flops > > > > 1 > > > > > Number of RAMB16s > > > > 2 > > > > 136 > > > > 1% > > > > > Number of BUFGMUXs > > > > 3 > > > > 16 > > > > 18% > > > > > but I cant seem to compare these two chips, the VIRTEX II vs the > > > > XCR3512XL-12-PQ208 > > > > its apples to oranges, how does it work? > > > > The 3512 has 512 FFs in the macrocells. (I think they also have input > > > FFs) The FPGA is using some 1300 out of 27,000! The FPGA is using > > > 1500 LUTs for logic. It does not look to me like that couldn't fit in > > > the logic of 512 macrocells. But the number of FFs has to be > > > reduced. Are they all necessary? > > > > Rick > > > "But I think it will be a major job to cut the design size by more > > than half!" > > > Well this is what has me scratching my head, I only added one uart to > > the 3512, the listing from the Virtex II has two > > separate UARTS, to make up the 1300 slice flip flops. I've only > > moved one of the uarts to the 3512 so far and it blew its top. I > > can't see how one uart can take up the entire chip, Or that the > > difference between the $90 3512 and the > > $1200 Virtex II Pro? > > Somewhere we did not communicate. The VIIP part has some 27,000 FFs. > Yes, that was 27 *thousand* FFs. The 3512 has 512 FFs for logic. So > there is no way that you can expect the CPLD to hold anywhere near the > same number of UARTs as the FPGA you are using. The two UARTs in the > VIIP are using 1300 FFs. Divide that by two (assuming they don't > share any logic like the baud rate generator) and you get 650 FFs per > UART. Will that fit into 512 FFs in the CPLD? It is very likely that > the UART you are using is very much more complex than you really > need. I expect you could fit some 10 or more UARTs into this CPLD if > they are streamlined a bit. A UART is nothing but a pair of shift > registers with some control logic and should fit into a couple of > dozen FFs if coded minimally. To do that requires that you understand > how to design hardware so that you know what you want from the HDL > code and then to code the HDL to produce that hardware. > > > I'm not sure of what you are getting out with me reducing the number > > of FF's, I'm just getting the hand of VHDL but I'm not aware of what > > code makes up the FF's, I inlcuded the code I put in up above, It > > seems very straight-forward, state machine, > > > "The FPGA is using some 1300 out of 27,000! " I'm assuming you mean > > the 1282/27,392 number. What I'm guessing is that in order for this > > design I have to get these 1282 to fit into the the 512 macrocells of > > the 3512 but I can only put 1 in each macrocell, aka I've got to get > > down to under 512 slice FF. Thats not counting the problem I'm having > > with the pterms, > > Yes, that is what you need to do. I'm not sure what the p-term count > is a problem. > > > > > > ERROR:Cpld:1062 - Design contains 2004 unique product terms, exceeds > > > > > device > > > > > limit 1536. > > If you get your FF count down, the p-term count will also likely > decrease as well. But I'm not clear on why there are so few p-terms > in this device. A typical CPLD will have macrocells with a range of p- > terms per macrocell of 4 to 12 or more. I would have to look at the > data sheet of the 3512 to see how they are organized. > > Ahhh... I found your culprit. > > architecture arch of fifo is > type reg_file_type is array (2**W-1 downto 0) of > std_logic_vector(B-1 downto 0); > signal array_reg: reg_file_type; > > This FIFO is implemented using memory resources in the FPGA. In the > CPLD there are no memory resouces... at least in Xilinx CPLDs. Other > brands have memory. With 8 bits and 16 words, each FIFO uses 128 > FFs. A UART has two FIFOs using 256 FFs. That's half the CPLD right > there! > > If you want a UART in the CPLD you need to take out the FIFOs. If you > are still running the same code for the Hello World program, you don't > need the FIFOs anyway. Instead of letting the data generator push > chars into the FIFO, let the data generator be throttled by the UART > handshake directly. > > The UART clearly has other complexities that is eating up FFs. You > need to find or code a simpler UART to suit your requirements. Think > of the CPLD as an MCU with only 2 kB of program space. You wouldn't > pull the UART driver out of Linux and try to use it in that device > would you? In essence, that is what you are doing. > > Rick AHHH!!! This sounds exactly like the tumor I'm looking for. This will be the first order of business on monday. If you look, I have changed my UART driver, its as simple as they get, a state machine with a bit shift, and I *thought" my fifo was just as simple; but the fifo was definitely designed with the Spartan 3 in mind, and I suspect that the Spartan-3 also has memory resources. BTW, where exactly is the list of ingredients for these chips? I didn't know to ask for the "memory resources" data on the coolrunner. It would be so nice if these chips had one of those Ralph Nader listings like on the real chips, you know the "Nutrition Facts" listing on the back of the package of Lay's potato chips? Only for this chip, saturated fat would be FF, and sodium would be LUT's, etc. Xilinx has a terrible habit of completely overwhelming us with documentation, 99.999% of it useless and as a result anything useful is hidden. This is a pure CYA attitude; they can claim its all documented but for all practical purposes, it might as well not be.Article: 139126
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 FFs, or > in your case, a small number of macrocells. I expect it to be easy 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 transmission > 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 Commercial 90nm > > Technology 1.2V 676-Pin FCBGA > > Cross to Alternate Parts by selecting most important features and > > 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 its 219 > > pages... > > They are all the same die and will likely all run the same bitstream. > You really only need to worry about the package you are using unless > 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 number > 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 suffix > is the package. Mostly all the different sized parts have similar > timing. But some timing numbers are different. Anything 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 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 pins. > Otherwise you should have no problems. > > > 3) The raggedstone1 has an added feature that I was told to consider, > > 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 Ocsillator > > 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 use 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 what $60? so for $14 I get 100x the power? This is a no-brainer IMO for a production run of less than 10,000 and your total system cost is over $1000. Especially 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 fighting with the $14 decision to go with the coolrunner on a subsystem vs something 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 looking 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... don't even get me started on 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...Article: 139127
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 as > 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/techitips/techitips.html. > > John Adair > Enterpoint Ltd. > > On 21 Mar, 05:14, jleslie48 <j...@jonathanleslie.com> wrote: > > > On Mar 21, 12:12 am, rickman <gnu...@gmail.com> wrote: > > > > On Mar 20, 3:15 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On Mar 20, 2:58 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > On Mar 20, 1:41 pm, Mike Treseler <mtrese...@gmail.com> wrote: > > > > > > > jleslie48 wrote: > > > > > > > and when I added some digital outputs, the %'s went up, but then I > > > > > > > added a whole bunch of logic, and nothing changed, > > > > > > > If the number of cells or Pterms used didn't change at all, > > > > > > I would expect that a "whole bunch" of logic does not make it > > > > > > out to a pin. I would run a sim to check. > > > > > > > -- Mike Treseler > > > > > > ahhh, well that is a bummer. I just tied the output to a pin and now > > > > > I"m getting: > > > > > > Fitting... > > > > > . > > > > > ERROR:Cpld:1063 - Design requires at least 947 macrocells, exceeds > > > > > device limit > > > > > 512. > > > > > ERROR:Cpld:1062 - Design contains 2004 unique product terms, exceeds > > > > > device > > > > > limit 1536. > > > > > ERROR:Cpld:1064 - Design rules checking error. Fitting process > > > > > stopped. > > > > > ...o > > > > > ERROR:Cpld:868 - Cannot fit the design into any of the specified > > > > > devices with > > > > > the selected implementation options. > > > > > > any idea on how to make it fit? > > > > > ok, before I added my functionality, I had: > > > > Macrocells Used Pterms Used Registers Used Pins Used Function > > > > Block Inputs Used > > > > 379/512 (75%) 831/1536 (55%) 354/512 (70%) 118/176 (68%) > > > > 779/1280 (61%) > > > > > so from my errors, I can see I added some 600 macrocells, and 1200 > > > > pterms, > > > > > how can I find out who is the piggy, and what can I due to trim things > > > > down? > > > > I don't think you really got an answer to this question. To some > > > extent you can look at the code and estimate the number of macrocells > > > or other logic elements used. But to measure it, you need to break > > > the code into modules and let the tool tell you about each module > > > separately. In an FPGA the logic has a finer grain, so there are not > > > as much optimizations to affect these counts when you use the block > > > all together. But a CPLD can put a lot of logic into each macrocell > > > and will be much more limited by the FF count. Your design counts > > > above indicate that your design uses 1300 FFs and your CPLD only has > > > 512 FFs. Not a good fit! > > > > You won't find much in the way of optimizations that will make this > > > fit. The best thing to trim your logic is to change your algorithm. > > > If there are parts of your design that can run slowly compared to the > > > clock rate, you can let them run sequentially rather than in > > > parallel. But if your design has to run at the full rate of the clock > > > with everything in parallel, you just need a larger part. So take a > > > good, hard at your design and see if there is anything you can do to > > > reduce it. > > > > > also, what is a macrocell and pterm? > > > > I think these got answered, but a little more detail... A macrocell > > > is the unit block of a CPLD. It typically include one or two FFs, an > > > output, often to a pin along with some amount of logic. The logic in > > > a macrocell is made of p-terms and OR gates. P-terms are very wide > > > AND gates with inputs from all of the inputs to that block, all of the > > > FFs in that block as well as, in some devices, some inputs from other > > > macrocell p-terms. The p-terms of a given macrocell are OR'd together > > > to produce the input to the FF or it can be routed directly to the > > > output. There is also a p-term or two devoted to controlling the tri- > > > state driver on the output. The OR gate and FF outputs are connected > > > back to the logic matrix for use in other or the same macrocells. > > > Some devices have "buried" FFs which allow some of the logic in the > > > macrocell to be split off and used with this second FF, but the output > > > can only be routed back to the routing matrix, not an output pin. > > > > That is a lot to absorb from a description. I am sure the data sheet > > > has a picture that is very clear and can portray the detail better. > > > The main thing to understand is that the p-term (and) are unlimited > > > (or more accurately only limited by the inputs to the block routing) > > > and an FPGA typically has much smaller LUTs, usually 1 LUT per FF or > > > sometimes 4 LUTs to 3 FFs. So a CPLD is often FF count limited while > > > an FPGA is mostly LUT count limited. Certainly there are things you > > > can change in your design to use more logic and fewer FF to target > > > CPLDs. But I think it will be a major job to cut the design size by > > > more than half! > > > > > I originally ran this program on a virtexII, and everthing looked > > > > liked it > > > > was pretty small and effecient: > > > > > Device Utilization Summary > > > > [-] > > > > Logic Utilization > > > > Used > > > > Available > > > > Utilization > > > > Note(s) > > > > Number of Slice Flip Flops > > > > 1,282 > > > > 27,392 > > > > 4% > > > > > Number of 4 input LUTs > > > > 1,545 > > > > 27,392 > > > > 5% > > > > > Logic Distribution > > > > > Number of occupied Slices > > > > 1,302 > > > > 13,696 > > > > 9% > > > > > Number of Slices containing only related logic > > > > 1,302 > > > > 1,302 > > > > 100% > > > > > Number of Slices containing unrelated logic > > > > 0 > > > > 1,302 > > > > 0% > > > > > Total Number of 4 input LUTs > > > > 1,589 > > > > 27,392 > > > > 5% > > > > > Number used as logic > > > > 1,545 > > > > > Number used as a route-thru > > > > 44 > > > > > Number of bonded IOBs > > > > Number of bonded > > > > 15 > > > > 556 > > > > 2% > > > > > IOB Flip Flops > > > > 1 > > > > > Number of RAMB16s > > > > 2 > > > > 136 > > > > 1% > > > > > Number of BUFGMUXs > > > > 3 > > > > 16 > > > > 18% > > > > > but I cant seem to compare these two chips, the VIRTEX II vs the > > > > XCR3512XL-12-PQ208 > > > > its apples to oranges, how does it work? > > > > The 3512 has 512 FFs in the macrocells. (I think they also have input > > > FFs) The FPGA is using some 1300 out of 27,000! The FPGA is using > > > 1500 LUTs for logic. It does not look to me like that couldn't fit in > > > the logic of 512 macrocells. But the number of FFs has to be > > > reduced. Are they all necessary? > > > > Rick > > > "But I think it will be a major job to cut the design size by more > > than half!" > > > Well this is what has me scratching my head, I only added one uart to > > the 3512, the listing from the Virtex II has two > > separate UARTS, to make up the 1300 slice flip flops. I've only > > moved one of the uarts to the 3512 so far and it blew its top. I > > can't see how one uart can take up the entire chip, Or that the > > difference between the $90 3512 and the > > $1200 Virtex II Pro? > > > I'm not sure of what you are getting out with me reducing the number > > of FF's, I'm just getting the hand of VHDL but I'm not aware of what > > code makes up the FF's, I inlcuded the code I put in up above, It > > seems very straight-forward, state machine, > > > "The FPGA is using some 1300 out of 27,000! " I'm assuming you mean > > the 1282/27,392 number. What I'm guessing is that in order for this > > design I have to get these 1282 to fit into the the 512 macrocells of > > the 3512 but I can only put 1 in each macrocell, aka I've got to get > > down to under 512 slice FF. Thats not counting the problem I'm having > > with the pterms,- Hide quoted text - > > > - Show quoted text - John, You have me very interested in this board and your products. I imagine I will be getting one to try out very soon. I am concerned though, you have put on the raggedstone1 board voltage regulators right in the middle of the GPIO pin layouts. In 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. You have a similar arrangement on the LHS as well. I 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.Article: 139128
On 21 Mar, 14:13, rickman <gnu...@gmail.com> wrote: > On Mar 21, 2:38=A0am, Jacko <jackokr...@gmail.com> wrote: > > > On 21 Mar, 04:30, rickman <gnu...@gmail.com> wrote: > > > > On Mar 20, 7:39=A0pm, Jacko <jackokr...@gmail.com> wrote: > > > > > > This would imply a 5bit wide word, which is obviously not > > > > > the case ? > > > > > The implication of the extra bit 'needed' is not a true account of > > > > functioning. > > > 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 ')') > > > Ah, but it is. =A0In your specific implementation, you have not only = a > > > fifth bit, but also a sixth, seventh all the way up to 16th, no? =A0Y= ou > > > have a 16 bit instruction word and only 17 opcodes; 0 through 15 are > > > the ones you list, and 16 through 65535 is the LIT or CALL instructio= n > > > (I'm not sure which). > > > (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 instruction > 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 , , ; > 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 assembly > 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. > 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. =A0= 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. =A0That is the target of my CPU. =A0I am hoping 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 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. > Have you read Koopman's book on stack CPUs? =A0He 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. 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). 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." 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." cheers jackoArticle: 139129
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 as > > 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/techitips/techitips.html. > > > John Adair > > Enterpoint Ltd. > > > John, > > You have me very interested in this board and your products. I > imagine I will be getting one to try out very soon. I am concerned > though, you have put on the raggedstone1 board voltage regulators > right in the middle of the GPIO pin > layouts. In 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. You have a similar arrangement on the LHS > as well. I 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. I'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/craignell.html I love the size of these guys, and If I'm not mistaken they have all the "nutrition facts" that I need. why would these not be appropriate vs the raggedstone1? I guess I'm looking for a comparison sheet for all three of these boards.Article: 139130
I think the AND gate was between the MEM_BEN signals and drives the MEM_CEN of the flash? <Antti.Lukats@googlemail.com> schrieb im Newsbeitrag news:7529e819-c268-4db4-85b3-caaa879b3dc5@e18g2000yqo.googlegroups.com... On Mar 21, 12:51 pm, "Kristian Klaus" <kristian.kl...@gmx.de> wrote: > I forgot to say, that I want the DATA_WIDTH_MATCHING option set to 1 > because > I want the emc to be fully transparent to the operating system (32 bit > writes). > > Kristian > > "Kristian Klaus" <kristian.kl...@gmx.de> schrieb im > Newsbeitragnews:gq2f5g$eph$1@hahn.informatik.hu-berlin.de... > > > Hello, > > > I am trying to connect a 16 bit Intel Strataflash to the > > xps_mch_emc_v2_00_a. My problem is, that the flashwriter.tcl application > > stops after some percents (13% or later) and never comes to 100%. > > > In the microblaze-uclinux archive, I found two old posts: > > >http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2005/0... > > and > >http://osdir.com/ml/linux.uclinux.microblaze/2004-02/msg00046.html > > > Can anybody confirm, that this also works with the new xps_mch_emc? > > > -- > > Kristian upon the times when EDK was so young i designed a special IP core FIX that reparaired the EMC and did allow flash writing when widtht matching is on. it was for MANY years. I assumed the problem is now fixed by Xilinx? but i havent worked with EMC for long time at the old times, the EMC fix was basically an AND gate that removed some extra pulse that made the CFI interface go nuts. AnttiArticle: 139131
On Mar 21, 7:51=A0pm, "Kristian Klaus" <kristian.kl...@gmx.de> wrote: > I think the AND gate was between the MEM_BEN signals and drives the MEM_C= EN > of the flash? > think so yes, the problem was extra "dummy" CE pulse AnttiArticle: 139132
On Sat, 21 Mar 2009 08:09:34 -0700 (PDT), John Adair <g1@enterpoint.co.uk> wrote: >If you search as a UK customer some parts don't appear. This might >explain why you didn't find it. I have seen that before but it tends to be whole product ranges or manufacturers - this was just a case of missing parametric data - They've replied saying they'll be fixing it. If only Farnell's parametric data was a fraction as good as Digikeys (usually) is.... >John Adair >Enterpoint Ltd. > >On 20 Mar, 13:39, Mike Harrison <m...@whitewing.co.uk> wrote: >> On Fri, 20 Mar 2009 14:25:10 +0100, "StoneThrower" <digi_64-public[removethis]@yahoo.com> wrote: >> >> Digikey only stock the straight version (-DSA) >> >?! >> >Digikey p/n H10644-ND, FX2-100S-1.27DS, right-angled (~as nicely shown on >> >pics): >> >http://parts.digikey.com/1/parts/287861-conn-recept-r-a-100pos-1-27mm... >> >> Thanks - I did several searches & failed to find it - seems like they forgot to put the pin count >> in the item data so when I filtered to 100 pin, it didn't find it! >> Their parametric data is usually very good so I don't tend to look further if the search doesn't >> find something - have emailed them.Article: 139133
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??? 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. > > > (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. How does this instruction > > 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 = 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. 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. > > Your obfuscation is getting to be annoying. You never explain what > > you mean, you speak in crypto language and you seem intent on never > > really explaining the principles of your design. Even your assembly > > 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. 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. > > 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. 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. > > 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! 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 words when often only one will do, or better less than one. Is it efficient to use 32 bits to insert a -1 in your code? > 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? 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! RickArticle: 139134
On Mar 21, 12:52=A0pm, 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. =A0A UART can be done in a small number of FFs, o= r > > in your case, a small number of macrocells. =A0I expect it to be easy t= o > > get ten UARTs into the 3512. =A0But the code you have for a UART is ver= y > > 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 enough > > > 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 90n= m > > > 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&storeI= d... > > > > 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 bitstream. > > You really only need to worry about the package you are using unless > > you want to target different boards. > > > The first digit after the dash -4 or -5 is the speed of the part. =A0Th= e > > 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 number > > 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 suffix > > is the package. =A0Mostly all the different sized parts have similar > > 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 limit > > your design to the I/O pins that are used on the smallest package. =A0S= o > > 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 consid= er, > > > 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 Ocsillator > > > 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 use th= e > > 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. 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 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 with > the $14 decision to go with the coolrunner on a subsystem vs something > 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 looking > 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 on > 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? ;^) RickArticle: 139135
On Mar 21, 12:28 pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Mar 21, 10:47 am, rickman <gnu...@gmail.com> wrote: > > > If you get your FF count down, the p-term count will also likely > > decrease as well. But I'm not clear on why there are so few p-terms > > in this device. A typical CPLD will have macrocells with a range of p- > > terms per macrocell of 4 to 12 or more. I would have to look at the > > data sheet of the 3512 to see how they are organized. > > > Ahhh... I found your culprit. > > > architecture arch of fifo is > > type reg_file_type is array (2**W-1 downto 0) of > > std_logic_vector(B-1 downto 0); > > signal array_reg: reg_file_type; > > > This FIFO is implemented using memory resources in the FPGA. In the > > CPLD there are no memory resouces... at least in Xilinx CPLDs. Other > > brands have memory. With 8 bits and 16 words, each FIFO uses 128 > > FFs. A UART has two FIFOs using 256 FFs. That's half the CPLD right > > there! > > > If you want a UART in the CPLD you need to take out the FIFOs. If you > > are still running the same code for the Hello World program, you don't > > need the FIFOs anyway. Instead of letting the data generator push > > chars into the FIFO, let the data generator be throttled by the UART > > handshake directly. > > > The UART clearly has other complexities that is eating up FFs. You > > need to find or code a simpler UART to suit your requirements. Think > > of the CPLD as an MCU with only 2 kB of program space. You wouldn't > > pull the UART driver out of Linux and try to use it in that device > > would you? In essence, that is what you are doing. > > > Rick > > AHHH!!! This sounds exactly like the tumor I'm looking for. This > will be the first order of business on monday. If you look, I have > changed my UART driver, its as simple as they get, a state machine > with a bit shift, and I *thought" my fifo was just as simple; but the > fifo was definitely designed with the Spartan 3 in mind, and I suspect > that the Spartan-3 also has memory resources. BTW, where exactly is > the list of ingredients for these chips? I didn't know to ask for the > "memory resources" data on the coolrunner. 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. I suspect you need a rewite of the UART code to make is completely streamlined doing only what you really need from it. For example, does this have a programmable baud rate generator and do you just need a single rate? > It would be so nice if these chips had one of those Ralph Nader > listings like on the real chips, you know the "Nutrition Facts" > listing on the back of the package of Lay's potato chips? Only for > this chip, saturated fat would be FF, and sodium would be LUT's, > etc. > > Xilinx has a terrible habit of completely overwhelming us with > documentation, 99.999% of it useless and as a result anything useful > is hidden. This is a pure CYA attitude; they can claim its all > documented but for all practical purposes, it might as well not be. Reading data sheets is also a skill. There is a lot in these parts that is very complex and really needs to be well documented. I understand what you mean about the info you need hiding in the volume, but I wouldn't characterize the volume as "useless". If anything the issue is just one of organization and references. I once had a ... discussion ... about how the pullups on the Spartan 3 parts were documented. It was all there, and over there, and some more here and more there. So if you had read every page of the data sheet you would have everything you needed. But even just the info on the pullups needed to make configuration work was not on a single page. After, discussing, this in this newsgroup, some changes were made to the doc. But it took a large stick to get anyone to admit that a change was needed. RickArticle: 139136
On Mar 20, 3:23=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> I know this is too much to hope solution, but maybe..
>
> the winter 2008 SBT tools seem to generate a multi boot header for
> cold boot only (works ok)
>
> trying warm-boot with the same multiboot applet doesnt seem to work
> however :(
>
> any help?
> (yes i have submitted help request to SBT)
>
> Antti
Hi Antti,
Make sure that you have at least iCEcube 2008.12.sp1, which is
available for download from the SiliconBlue web site.
http://www.siliconbluetech.com/iCECube_development_software.aspx
For WarmBoot to work, you also need to instantiate the SB_WARBOOT
primitive and connect up the select lines (pointing to one of four
configuration images stored in SPI FlashPROM) and the active-High BOOT
signal that trigger reconfiguration. The BOOT signal needs to be High
for 200 ns or more to be recognized.
SB_WARMBOOT SB_WARMBOOT_inst (
.S1(<select1>),
.S0(<select2>),
.BOOT(<activeHiTrigger>)
);
When you generate the configuration image, you then need to load the
WarmBoot bitstreams for each of the four select values (S[1:0]).
I haven't tried this in hardware myself. I did make it work with an
earlier version of iCEcube by handcrafting a bitstream.
-- Steve Knapp
Prevailing Technology, Inc.
www.prevailing-technology.com
Article: 139137On Mar 18, 10:04=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > There is a new question: If there is a more clever idea to do the same > things to avoid the 63-bit dead-lock situation from happening? > > Weng From the description, I'm not sure exact what you want to do here. You can avoid the all '1's deadlock buy using XNOR feedback. For modulo 63, you will need to feedback from bits 1 and 6 or from bits 5 and 6. If you just want the psuedo-random pattern, simply tap off someplace in the feedback chain. If you want a terminal count or something that only goes High every 63 clock cycles, you need to decode one of the 63 possible states. There are ways to build LFSR counters with different modulos or even make if count to the full 2^n. Here's a link to an old paper on the subject originally written for the XC2000 family (old tricks still work). See pages 18 through 21. http://www.fpga-site.com/publications/counter_examples.pdf -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 139138
On Sat, 21 Mar 2009 08:10:07 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote: >On Mar 21, 8:42 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> On Fri, 20 Mar 2009 17:56:39 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> >Hey everybody, thanks for all the good suggestions. > >1) So it is reasonable to conclude that the cold runner 3512 is way >too small to even run a uart yes? I would expect it can easily handle a UART - or several. But a UART and whatever else lies behind it - that could be another matter. >2) is the board that Brian suggested, the raggedstone1 with the >spartan XC3S1500 is big enough? Seems well over 10x the chip you have now. And there are XC3S2000 and 4000 if it isn't... > >Whats the deal withe the "PACKAGE" ( 676FCBGA) well it's not something you'd hand solder... >I see from AVNET that the XC3S1500 comes in lots of flavors: >XC3S1500-4FG320C >XC3S1500-4FG456C >XC3S1500-4FG676C 3 packages, 2 speed grades (say 15-20% apart), leaded/lead-free, commercial/industrial speed grades, but basically all the same chip. Take your pick. (The larger 2000/4000 devices may only be available in the largest package) >3) The raggedstone1 has an added feature that I was told to consider, >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 Ocsillator >and then I'm good to go yes? I'd guess you can power it and use the headers for I/O even without the PCI header. It's far from being the only option but it's an attractively large FPGA for the money. (If the package, or hand soldering, is an issue, look at the DIP or pin-grid-array replacements on the same site). If you need to save every milliwatt, stay with the Coolrunner. 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? - BrianArticle: 139139
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> > wrote: > > >On Mar 21, 8:42 am, Brian Drummond <brian_drumm...@btconnect.com> > >wrote: > >> On Fri, 20 Mar 2009 17:56:39 -0700 (PDT), jleslie48 <j...@jonathanlesl= ie.com> > >Hey everybody, thanks for all the good suggestions. > > >1) So it is reasonable to conclude that the cold runner 3512 is way > >too small to even run a uart yes? > > I would expect it can easily handle a UART - or several. > But a UART and whatever else lies behind it - that could be another matte= r. > > >2) is the board that Brian suggested, the raggedstone1 with the > >spartan XC3S1500 is big enough? > > Seems well over 10x the chip you have now. > And there are XC3S2000 and 4000 if it isn't... > > > > >Whats the deal withe the "PACKAGE" ( 676FCBGA) > > well it's not something you'd hand solder... > > >I see from AVNET that the XC3S1500 comes in lots of flavors: > >XC3S1500-4FG320C > >XC3S1500-4FG456C > >XC3S1500-4FG676C > > 3 packages, 2 speed grades (say 15-20% apart), leaded/lead-free, > commercial/industrial speed grades, but basically all the same chip. > Take your pick. (The larger 2000/4000 devices may only be available in th= e > largest package) > > >3) The raggedstone1 has an added feature that I was told to consider, > >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 Ocsillator > >and then I'm good to go yes? > > I'd guess you can power it and use the headers for I/O even without the P= CI > header. It's far from being the only option but it's an attractively larg= e FPGA > for the money. (If the package, or hand soldering, is an issue, look at t= he DIP > or pin-grid-array replacements on the same site). > > If you need to save every milliwatt, stay with the Coolrunner. > > 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 tryi= ng 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??? We have yet to discuss a unit of measure for the size of the executable, is that something else I'm overlooking? Is that an Issue with the enterpoint solutions? I'm assuming I can load the program into the enterpoint solutions and on powerup they start to function...The coolrunner was able to do that, although I dont know about any limitation to the executable size on the coolrunner that I'm having trouble with other than the resource issues that started this conversation. 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. Meantime they forgot this whole set of functionality and now have to patch it in somehow. So they brought me in. On the one card that is freed up, they have the coolrunner chip, and as I was having so much fun with fpga-vhdl up until a month ago, I figured I could use it and not have to add any hardware components to the project. this was a very attractive solution to the PM (program manager) The board is going to be re-spun anyway to fix some cross talk issues, so breaking out a few of the unused pins on the coolrunner for the added functionality wasn't really going to impact the project at all. So while I got the new functionality to work on my virtex II chip, the hardware boys built me a jury-rigged daughter board for the old coldrunner board: they actually hand soldered 30 gauge wire to the pins of the coolrunner, broke it out to a DB15 where I could attach a daughter board to get the digital I/O onto a scope/leds/level shifters. All was going well until I popped the FF thing on the coolrunner. So I Imagine I'm gonna either get it all to fit on the coolrunner, or go with a new card, those cards from enterpoint look quite reasonable, especially the really small ones. That solution is gonna add to my footprint, the boss is gonna be pissed but hey, at least its no longer a dead fish. SWAP is more of an issue than even the money. Actually I don't even care about Power, its just the size and weight. Those really little cards will be a lot easier to sell than the bigger raggedstone1. So back to the issue at had, the 1) Drigmorn1 has a XC3S500E-4CPG132C spartan-3 chip: Xilinx XC3S500E-4CPG132C FPGA Spartan=AE-3E Family 500K Gates 10476 Cells 572MHz Commercial 90nm (CMOS) Technology 1.2V 132-Pin CSBGA Package 132CSBGA Family Name Spartan=AE-3E Device Logic Cells 10476 Device Logic Units 1164 Device System Gates 500000 Number of Registers 9312 Maximum Internal Frequency 572 MHz Typical Operating Supply Voltage 1.2 V Maximum Number of User I/Os 92 RAM Bits 368640 Re-programmability Support Yes 2) the Craignell has a (Xilinx XC3S500E) Spartan-3E chip as well, 3) the Raggedstone1 has a XC3S1500 chip: Xilinx XC3S1500-4FG320C FPGA Spartan=AE-3 Family 1.5M Gates 29952 Cells 630MHz Commercial 90nm Technology 1.2V 320-Pin FPBGA Package ??? 320FPBGA ???? 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 221 RAM Bits 589824 Re-programmability Support Yes Which of these products will do the job and not be too small like the coolrunner?Article: 139140
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 FFs, o= r > > > in your case, a small number of macrocells. I expect it to be easy t= o > > > get ten UARTs into the 3512. But the code you have for a UART is ver= y > > > large and overly complex if you just want to do serial transmission > > > 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 enou= gh > > > > 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 Commercial 9= 0nm > > > > Technology 1.2V 676-Pin FCBGA > > > > Cross to Alternate Parts by selecting most important features and > > > > 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&stor= eId... > > > > > 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 its 21= 9 > > > > pages... > > > > They are all the same die and will likely all run the same bitstream. > > > You really only need to worry about the package you are using unless > > > you want to target different boards. > > > > The first digit after the dash -4 or -5 is the speed of the part. Th= e > > > 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 number > > > and says this has to be the die temperature) and I for industrial (-2= 0 > > > to +85 C with the same issue as commercial). The rest of the suffix > > > is the package. Mostly all the different sized parts have similar > > > timing. But some timing numbers are different. Anything 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 limi= t > > > your design to the I/O pins that are used on the smallest package. S= o > > > make sure every package you want to use supports all of those pins. > > > Otherwise you should have no problems. > > > > > 3) The raggedstone1 has an added feature that I was told to consid= er, > > > > mounting into a PC. Initially I want to put it a stand alone box, s= o I > > > > will need to order the board, the PCI I/O header, and the Ocsillato= r > > > > 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 use th= e > > > 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 what > > $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 and > > your total system cost is over $1000. Especially 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 fighting with > > the $14 decision to go with the coolrunner on a subsystem vs something > > 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 looking > > 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... don't even get me started on > > 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? ;^) > > 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. "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.Article: 139141
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 AlfkeArticle: 139142
On Mar 22, 2:13=A0am, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > On Mar 20, 3:23=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > Hi > > > I know this is too much to hope solution, but maybe.. > > > the winter 2008 SBT tools seem to generate a multi boot header for > > cold boot only (works ok) > > > trying warm-boot with the same multiboot applet doesnt seem to work > > however :( > > > any help? > > (yes i have submitted help request to SBT) > > > Antti > > Hi Antti, > > Make sure that you have at least iCEcube 2008.12.sp1, which is > available for download from the SiliconBlue web site.http://www.siliconbl= uetech.com/iCECube_development_software.aspx > > For WarmBoot to work, you also need to instantiate the SB_WARBOOT > primitive and connect up the select lines (pointing to one of four > configuration images stored in SPI FlashPROM) and the active-High BOOT > signal that trigger reconfiguration. =A0The BOOT signal needs to be High > for 200 ns or more to be recognized. > > =A0 =A0 SB_WARMBOOT SB_WARMBOOT_inst ( > =A0 =A0 =A0 =A0 .S1(<select1>), > =A0 =A0 =A0 =A0 .S0(<select2>), > =A0 =A0 =A0 =A0 .BOOT(<activeHiTrigger>) > =A0 =A0 ); > > When you generate the configuration image, you then need to load the > WarmBoot bitstreams for each of the four select values (S[1:0]). > > I haven't tried this in hardware myself. =A0I did make it work with an > earlier version of iCEcube by handcrafting a bitstream. > > -- Steve Knapp > =A0 =A0Prevailing Technology, Inc. > =A0 =A0www.prevailing-technology.com Hi Steve, eh you can belive i tried everything ok, the BOOT=3D1 high DOES force the reconfiguration.. so the warmboot is connected ok and i belive the multi-boot applet is correct too as the COLD BOOT switches work, i can start 4 different images from at hard reset/ config now when i trigger warm boot, then DONE goes off if i had selected SAME bitstream, it remains working (my warmboot test has LED ON, this LED remains ON but done is OFF) if i try to configur from other config then just the done off, and the bitstream doesnt work hm, my warmboot config bitstream is config 4 (last one) so i start it witg CBSEL0=3DCBSEL1=3D1 but that should not be a problem, the warmboot should work another problem, i want the warmboot to enabled but cold boot disabled! but icecube only generated 1 type of the multiboot applet and that eanbles cold boot as much as i can see but.. i just realized i had the SP1 not installed!! anyway, can you confirm that you REALLY got warmboot to work? did you use multi boot applet similar as icecube does? or maybe can you post the warmboot applet hex code? (if it is different) i am installing SP1 now, maybe it is ok now AnttiArticle: 139143
On Mar 22, 2:13=A0am, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > On Mar 20, 3:23=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > Hi > > > I know this is too much to hope solution, but maybe.. > > > the winter 2008 SBT tools seem to generate a multi boot header for > > cold boot only (works ok) > > > trying warm-boot with the same multiboot applet doesnt seem to work > > however :( > > > any help? > > (yes i have submitted help request to SBT) > > > Antti > > Hi Antti, > > Make sure that you have at least iCEcube 2008.12.sp1, which is > available for download from the SiliconBlue web site.http://www.siliconbl= uetech.com/iCECube_development_software.aspx > > For WarmBoot to work, you also need to instantiate the SB_WARBOOT > primitive and connect up the select lines (pointing to one of four > configuration images stored in SPI FlashPROM) and the active-High BOOT > signal that trigger reconfiguration. =A0The BOOT signal needs to be High > for 200 ns or more to be recognized. > > =A0 =A0 SB_WARMBOOT SB_WARMBOOT_inst ( > =A0 =A0 =A0 =A0 .S1(<select1>), > =A0 =A0 =A0 =A0 .S0(<select2>), > =A0 =A0 =A0 =A0 .BOOT(<activeHiTrigger>) > =A0 =A0 ); > > When you generate the configuration image, you then need to load the > WarmBoot bitstreams for each of the four select values (S[1:0]). > > I haven't tried this in hardware myself. =A0I did make it work with an > earlier version of iCEcube by handcrafting a bitstream. > > -- Steve Knapp > =A0 =A0Prevailing Technology, Inc. > =A0 =A0www.prevailing-technology.com hm i checked the release notes v 12 (what i was using) should support the warmboot.. there are no changes to that in SP1 so the problem most likely isnt in SP1 AnttiArticle: 139144
On Mar 19, 1:19=A0pm, SUMAN <suman...@gmail.com> wrote: > Hi i am interfacing c3038 (352x288 pixels) camera module to microblaze > using spartan 3a dsp 1800a board. The frame grabber module is > perfectly working and i have even tested in ise using chipscope pro. > The camera sends after every 112ns(8.093MHz) . I want to store data in > sdram. I am trying to interface it using user logic fifo service. Is > thera any alternate way for doing this??????????? yes MPMC VFBC port AnttiArticle: 139145
Hi the datasheet has been updated 18 march but the download link doesnt work from SBT web, correct URL is http://www.siliconbluetech.com/media/iCE65Datasheet.pdf AnttiArticle: 139146
On Mar 22, 3:19=A0am, 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 DuranArticle: 139147
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 Good morning. "Of course, you are aware that you need the FPGA + some sort of device to boot it." 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?Article: 139148
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%20User%20Guide.pdf 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?Article: 139149
Hello all, I am facing a weired problem with my stratix 3 device. There is a controller on an external board that apply writes data to my altera. For example it applys re_, we_, and one signlas of '1'. this '1' turns into two signals of '1' on the pcb (short-circuited). these two signals are then connected to two input pins on the startix 3 device. When I look on these signals from the signal - tap, these signals arent identical which means that i have a cross-talk issue inside the altera. what to do? thanks alot, Guy
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