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
Unfortunately, the generate statement only allows conditionally including concurrent statements. You must use subprograms or if- statements based on generics for conditionally executing sequential code. And while you can't conditionally declare objects, you can make unconditional declarations dependent upon generic parameters (constants can be initialized by a function call that takes a generic). Generate does allow a local declarative region for the concurrent statement(s) that are included, but those declarations are not visible outside of it. In most cases you can use a constant anywhere you could use a generic. You can use a generic anywhere you could use a deferred constant (beware locally static restrictions). With generic driven packages in the new standard, the (dis)advantages of generics vs package of constants may get more blurred. AndyArticle: 142001
On Jul 21, 4:18=A0am, "Fredxx" <fre...@spam.com> wrote: > Actually running Chipscope at a higher multiple of the clock is very good= at > seeing timing errors. =A0Ideal if you have a spare DCM! Except inserting chipscope alters the timing, so it may help you find timing errors that were not there to begin with, or mask timing errors that are there without it. AndyArticle: 142002
Andy wrote: > On Jul 21, 4:18 am, "Fredxx" <fre...@spam.com> wrote: >> Actually running Chipscope at a higher multiple of the clock is very >> good at seeing timing errors. Ideal if you have a spare DCM! > > Except inserting chipscope alters the timing, so it may help you find > timing errors that were not there to begin with, or mask timing errors > that are there without it. > > Andy Maybe, but I would hope that the timing criteria would have been tied down so waveforms didn't change on every compilation. I was thinking more of interface issues, rather than "intermediate failiures" where I assume there is some internal timing failure within the device. It should be possible to overcome or identify these sorts of failures by entering timing information in the UCF file, or by following good practice if crossing clock domains.Article: 142003
On Jul 17, 11:48=A0pm, "MM" <mbmsv@yahoo.com> wrote: > Does anyone know if I can run DDR1 type of memory at double the frequency= ofMPMC4.03 (EDK10.1) main clock? Or is this possible for DDR2 only? I am > having difficult time trying to understand this from the datasheet. So, > before digging into the MPMC source code I thought I would try asking... > > Thanks, > /Mikhail Hi Mikhail In MPMC v4.03 I don't find any hint that 1:2 clock ratio is not allowed for DDR1. In v5.02 the 1:2 clock ratio is described in chapter Performance... Have fun FlorianArticle: 142004
Hi, We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 dram chip. The coregen thing seems to successfully build a dram interface that's claimed to work up to 133 MHz. The DRAM is spec'd to work down to 128 MHz, so there's a small overlap window. We'd run at 128. Our Xilinx FAE seems to be discouraging us from doing this, without saying precisely why, suggesting some other parts. Spartan 6 would be ideal (hard dram controller as I understand it) but are unavailable for some vague time. We'd rather not use a new part for a single project, since we will cut over to the s6's when they are available. Has anyone done DDR2 from a Spartan 3? Success/horror stories? JohnArticle: 142005
Hi there, I'm wondering is it possible to encrypt an already existing unencrypted bit file with BitGen, with out any files from the implementation step?Article: 142006
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:e4nb65t2drpjnba1453ms7541utu8lojf3@4ax.com... > Hi, > > We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 > dram chip. The coregen thing seems to successfully build a dram > interface that's claimed to work up to 133 MHz. The DRAM is spec'd to > work down to 128 MHz, so there's a small overlap window. We'd run at > 128. > > Our Xilinx FAE seems to be discouraging us from doing this, without > saying precisely why, suggesting some other parts. Spartan 6 would be > ideal (hard dram controller as I understand it) but are unavailable > for some vague time. We'd rather not use a new part for a single > project, since we will cut over to the s6's when they are available. > > Has anyone done DDR2 from a Spartan 3? Success/horror stories? > > John > Spartan 3 doesn't have any of the Virtex 4 (and later) type of regional IOB group clocking, so doing DDR and/or DDR2 memory interfaces is tougher and certainly will limit your max data rate. Can you get Spartan 3 to work at 4ns data rate? Probably, but if you have the option you should use a later family. Even with the families that have regional clocking that can be strobed by DQS, it's still a challenge. You have to be super careful about which pins you use and be aware of the "reach" of the local clocking resources in terms of the data bits associated with each DQS and also the reach of the divided local clock that feeds the fifo that is the interface into the fabric (proper). It sure would have been nice if the DRAM manufacturers would have provided a CONTINUOUS read clock rather than a freeking dual purpose read/write strobe (DQS). My hair would be darker. Bob -- == All google group posts are automatically deleted due to spam ==Article: 142007
10000 floating point! That's a huge multiplier. First point, think whether that's the best way to do your image processing. And then, this is what you have to read to do it: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F9047%2F28700%2F01287799.pdf&authDecision=-203. You may need to implement a 8-bit adder and a 24-bit multipler for each multiplication. My best was 190 MHz on a Virtex II family. I used a 8 stage pipeline for FP multiplication. Never gone beyond that. It was part of a big project, not something that I did for fun. http://sunnyeves.blogspot.com/ >On Jul 16, 8:07=A0pm, Martin Thompson <martin.j.thomp...@trw.com> wrote: >> Nauman Mir <m...@hotmail.com> writes: >> > hi Good Day! >> > =A0 I hope you all are fine. Actually i want to take some technical >> > input. I want to build 10,000 floating point multiplier in FPGA >> > fabric. So >> >> That's a lot of multipliers! =A0Unfortunately I have only more questions >> for you: >> >> What are you doing that needs this qty of multipliers? =A0Do you really >> need floating point? =A0What word size? =A0What data rate? >> >> > =A0> Kindly suggest me Is it possible ? >> >> Not taking your query at face value - a single-precision FP multiplier >> from Xilinx Coregen runs to 1000 or so LUTs (IIRC), so that's a 10MLUT >> FPGA... (actually, DSP blocks would probably be the limiting factor >> anyway, but it's still infeasible!). =A0The largest Virtex 6 looks like >> about 450k LUTs... >> >> Now, if you actually need to do 10,000 multiplies one after the other, >> that's very different story... >> >> > =A0> How we can implement ? (my suggestion is MicroBlaze soft processor= >) >> >> Only if you want the answer realtively slowly, in which case a normal >> processor rather than an FPGA would better suit the problem. =A0That woul= >d >> also be a sequential solution. >> >> > =A0> Which Chip_Set is best for this purpose ? >> >> Insufficient data. =A0sorry! >> >> Cheers, >> Martin >> >> -- >> martin.j.thomp...@trw.com >> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w= >ww.conekt.net/electronics.html > >Thanks for your concern ......... > > >> word size is 8-bit >> Definatly i necer lose precession so that i use Floating point >> I want to do this maximum in 13Cycles , after pipeline >> I want to do this all Concurrently >> i use this in image matching algorithm for medical machine development > >Best Regards > >Nauman Mir >Article: 142008
> I'm wondering is it possible to encrypt an already existing > unencrypted bit file with BitGen, with out any files from the > implementation step? The only way I found for my projects was to use the .ncd file.Article: 142009
> Why do you call "mkdosfs -F 16 -R 1 -I /dev/sdc (for the whole disk)" ? It was a test, because I couldn't get the partitioned disk to work. It's not the call I used to format the partition. > What version of mkdosfs do you use? My gentoo tells my I'm using dos-tools 3.0.2 But thanks, I think I found my mistake... It looks like a partition with a small size like 64MB has to be FAT12 formatted, I discovered this after it worked with a 97MB partition (wrong line on the numblock...). I typed in the wrong column, it worked, and since then I never had a problem. AndreasArticle: 142010
"Florian" <googlegroups@47110815.com> wrote > > In MPMC v4.03 I don't find any hint that 1:2 clock ratio is not allowed > for DDR1. From looking at the source code I don't believe it will work... I don't think it will work with v5.0 either... /MikhailArticle: 142011
On Tue, 21 Jul 2009 08:31:47 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >Hi, > >We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 >dram chip. The coregen thing seems to successfully build a dram >interface that's claimed to work up to 133 MHz. The DRAM is spec'd to >work down to 128 MHz, so there's a small overlap window. We'd run at >128. > >Our Xilinx FAE seems to be discouraging us from doing this, without >saying precisely why, suggesting some other parts. Spartan 6 would be >ideal (hard dram controller as I understand it) but are unavailable >for some vague time. We'd rather not use a new part for a single >project, since we will cut over to the s6's when they are available. > >Has anyone done DDR2 from a Spartan 3? Success/horror stories? > >John > We're using the XC3S1400A with DDR2 using a pair of Gb memory. We're also using a Virtex 5 with DDR2. The Spartan-3A interface to DDR2 was done using the coregen thing since the consultants that did the code for this part of the project only had the skills to do drop-in cores. We used the pinout from the demo board since that was a known working configuration and the wiring produced a nearly optimal layout. If you let the coregen do it's own pinout selection, you will end up with a horrible wiring mess. The consultants got it working, but it was a fight. If you read the documentation, you soon find out that using the coregen requires a lot of fiddling with the config files, making sure that pin functions are grouped in certain ways. The consultants assured us that the coregen was an easy way to do memory interface, but obviously they didn't heed the warnings - Xilinx peppers their notes with "may" and "might". The memory coregen is a horrible piece of crap. Plus, the documentation is extremely confusing on how you deal with trace length between memory and FPGA and a delay line required for the Spartan-3. We finally found the correct answer in their on-line answer bank. We did the Virtex 5 DDR2 interface in-house. We produced a much more elegant interface than the coregen. Oh, if you place the memory right next to the FPGA and optimize the pinout, you can leave all the termination resistors out. We ran a bunch of simulations which shows that this is possible. In practice, we got beautiful looking waveforms using a GHz scope and a differential probe on single ended lines. It saves a huge amount of space and power. By putting in terminations, it requires that you need terminations because of all the excess wiring you need! This was done on both the Spartan and Virtex. All traces were buried. I think you'll find that Xilinx cores are generally poorly done except for a few things. Lots of bugs and poor functionality. They generally require huge amounts of space to do things not quite right. Don't get me started on their bloody buggy tools!!!! -- MarkArticle: 142012
On Jul 21, 6:08=A0am, Andy <jonesa...@comcast.net> wrote: > Unfortunately, the generate statement only allows conditionally > including concurrent statements. You must use subprograms or if- > statements based on generics for conditionally executing sequential > code. And while you can't conditionally declare objects, you can make > unconditional declarations dependent upon generic parameters > (constants can be initialized by a function call that takes a > generic). Generate does allow a local declarative region for the > concurrent statement(s) that are included, but those declarations are > not visible outside of it. > > In most cases you can use a constant anywhere you could use a generic. > You can use a generic anywhere you could use a deferred constant > (beware locally static restrictions). > > With generic driven packages in the new standard, the (dis)advantages > of generics vs package of constants may get more blurred. It may be convenient to use generics to control a generate which instantiates entities. -aArticle: 142013
Sorry to start from scratch yet again, but I don't know where to begin. In the past I've had log file info dump out onto a UART as necessary. The UART is slow, and requires an additional device to capture the datastream. I want to be able to write to a removable memory stick, or compact flash card, but I don't have any idea how to do it. When the FPGA is powered up it should start a new "file" on the compact flash card, and start writing to it. On commanded bit or powerdown, the file should be closed, and stored such that I can pull the card, plug it into a PC and read the file with notepad or such. The fpga should be able to read a small config file, and then write it back out, for example a file with the filename in it logfilen.txt: 0000000 -------------------------- the fpga reads the line ( 0000000 ) and knows filename should be that plus one say 0000001.txt and then it updates/rewrites/deletes and posts a logfilen.txt: 00000001 this way the filenames of the log files keeps changing. I'm looking for ideas on how to get this accomplished. Thanks, JonArticle: 142014
On Jul 21, 3:56=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > Sorry to start from scratch yet again, but I don't know where to > begin. > > In the past I've had log file info dump out onto =A0a UART as > necessary. =A0The UART is slow, and requires an additional device to > capture the datastream. > > I want to be able to write to a removable memory stick, or compact > flash card, but I don't have any idea how to do it. =A0When the FPGA is > powered up it should start a new "file" on the compact flash card, and > start writing to it. =A0On commanded bit or powerdown, the file should > be closed, and stored such that I can pull the card, plug it into a PC > and read the file with notepad or such. > > The fpga should be able to read a small config file, and then write it > back out, for example a file with the filename in it > > logfilen.txt: > 0000000 > -------------------------- > > the fpga reads the line ( 0000000 ) and knows filename should be that > plus one say 0000001.txt > and then it updates/rewrites/deletes and posts a > > logfilen.txt: > 00000001 > > this way the filenames of the log files keeps changing. > > I'm looking for ideas on how to get this accomplished. > > Thanks, > > Jon If you wanted to use CompactFlash, you could use Xilinx'x SystemAce chip and their libraries for interfacing to it with an embedded processor like Microblaze or the PowerPC. If you wanted to roll your own CF interface, it's basically an IDE interface, so you might be able to find the spec and go at it, or find a free core on opencores.org. If you wanted to use Secure Digital, you can do that with a SPI interface to implement the sector reads/writes and find some FAT32 code to put on top of in, of course in an embedded processor. There's also a product called DosOnChip which takes care of a lot of the filesystem stuff for you: http://www.sparkfun.com/commerce/product_info.php= ?products_id=3D8215 Hope this gives you some ideas. DaveArticle: 142015
John, The size is probably manageable, but we don't need the extra features. How about this possibility: Darnaw 1 with the non-PCI Ethernet module. We have to make a carrier board for our circuitry anyway. So we put the Darnaw on one side, the Ethernet on the opposite side and our circuits wherever they will fit. That has the appeal of getting only what we need to keep the cost and power down. A few more questions if you don't mind. I could not find answers on your web site. 1. Size of the Darnaw. I estimate about 2.8" square from the picture. 2. Does the Ethernet module have a PHY or a MAC/PHY? What device? 3. Does the Ethernet module have an oscillator? I can't tell from the Xilinx documentation if the 1200E DLLs can internally handle 800MHz (25MHz = (32MHz * 25) / 32). I guess we could put a separate oscillator on our board if we have to. 4. The Darnaw manual says that the regulators get very hot. Will they survive being enclosed in a small volume, say 4"x3"x2", with no airflow? Thanks for your patience. Larry >Larry > >The size of the board is about 67.5mm x 96.5mm. It is a lot bigger >than the related Craignell2 because it has expansion headers, usb, >display, accelerometer that make it bigger. > >The board has our standard dil header arrangement that you can see on >several of our boards and we do have a phy module for these headers so >you can probably have the configuration you want asumig the size meets >the requirement. > >John Adair >Enterpoint Ltd. > >On 18 July, 14:25, "AstroLad" <Astro...@cox.net> wrote: >> John, >> >> Can you give me a few details? Will the new board be the same, or roughly >> the the same size as the Craignell2? What about Ethernet? We want a 10/100 >> PHY (best), or MAC/PHY. The reason the PHY is best for us is that I already >> developed a simplified MAC tuned to our processor core. It doesn't take >> much space and not much support code. >> >> Thanks, >> >> Larry Dingle >> >> >> >> >> >> >We have a product coming shortly based on our Craignell2 but a >> >development board format that might offer an alternative. If you have >> >a few weeks then wait and see if suits your application. >> >> >John Adair >> >Enterpoint Ltd. >> >> >On Jul 6, 2:19=A0pm, "AstroLad" <Astro...@cox.net> wrote: >> >> Does anyone know of anything similar to the Suzaku SZ030/SZ130? It's >> just >> >> about a perfect fit for a short production run product I'm helping a >> frie= >> >nd >> >> with. Perfect that is except the price. What we need is an FPGA as good >> o= >> >r >> >> better than a XC3S1000, 1MB or more of RAM (SRAM or SDRAM) and 100MB >> >> Ethernet. It does not absolutely have to be a Spartan. An Altera >> Cyclone = >> >of >> >> some flavor would do if the price were right. We already have a lot of >> >> development done using Digilent Spartan boards. We don't need the >> >> Microblaze as we have a CPU from OpenCores that is adequate.- Hide quoted text - >> >> - Show quoted text - > >Article: 142016
On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesandy@comcast.net> wrote: >Unfortunately, the generate statement only allows conditionally >including concurrent statements. so does that mean that, for example, you couldn't use it to conditionally exclude particular case branches in a case structure? >You must use subprograms or if- >statements based on generics for conditionally executing sequential >code. And while you can't conditionally declare objects, you can make >unconditional declarations dependent upon generic parameters >(constants can be initialized by a function call that takes a >generic). Generate does allow a local declarative region for the >concurrent statement(s) that are included, but those declarations are >not visible outside of it. > >In most cases you can use a constant anywhere you could use a generic. >You can use a generic anywhere you could use a deferred constant >(beware locally static restrictions). > >With generic driven packages in the new standard, the (dis)advantages >of generics vs package of constants may get more blurred. > >Andy The replies so far suggest to me that it could get far more complicated than it would be if a #ifdef type feature were available, which would be universally applicable to any type of construct. I've yet to look in detail but it seems like the code/project structure has to be significantly designed around the need to handle variants. ISPLever can specify pin mapping within the VHDL, so this would also provide a way to handle pinout differences between boards. I can't immediately see any way to make ISPLever select different preferences files based on a simple option - any suggestions/examples on this would be appreciated.Article: 142017
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes: > Hi, > > We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 > dram chip. The coregen thing seems to successfully build a dram > interface that's claimed to work up to 133 MHz. The DRAM is spec'd to > work down to 128 MHz, so there's a small overlap window. We'd run at > 128. > If it's any help - I've done DDR (not DDR2) with S3ADSP3400-4. I used the MIG tool which, contrary to others, I found to work well, as long as the documented limits (esp. on pin placement) are followed. Given that the ultimate target was to use XPS's memory controller (MPMC), which uses a MIG physical layer, I didn't think rolling my own controller was worth the hassle. And indeed, the board worked first time (4 independent x16 DDR chips, 4 MIGs/MPMCs @ 125MHz). On the bench, I pushed the clock up to 140MHz, and used the chipscope VIO core (which MIG builds in) to push the timing over to one "side", but it just sat there and took it - one channel would fail at the most extreme sampling point offset I could set. I used series terminators on the signal lines, but to be honest that was maybe paranoia. The sims did show rather more overshoot that I wanted with fast-edge models, so I put them in. I also turned down the drive strength on the data lines in the MIG/MPMC config. > Our Xilinx FAE seems to be discouraging us from doing this, without > saying precisely why, suggesting some other parts. Spartan 6 would be > ideal (hard dram controller as I understand it) but are unavailable > for some vague time. We'd rather not use a new part for a single > project, since we will cut over to the s6's when they are available. > > Has anyone done DDR2 from a Spartan 3? Success/horror stories? > I don't know how much of DDR reads over to DDR2, but hopefully the above is of interest! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 142018
On Jul 21, 7:13=A0pm, "Fredxx" <fre...@spam.com> wrote: > Andy wrote: > > On Jul 21, 4:18 am, "Fredxx" <fre...@spam.com> wrote: > >> Actually running Chipscope at a higher multiple of the clock is very > >> good at seeing timing errors. Ideal if you have a spare DCM! > > > Except inserting chipscope alters the timing, so it may help you find > > timing errors that were not there to begin with, or mask timing errors > > that are there without it. > > > Andy > > Maybe, but I would hope that the timing criteria would have been tied dow= n > so waveforms didn't change on every compilation. > > I was thinking more of interface issues, rather than "intermediate > failiures" where I assume there is some internal timing failure within th= e > device. =A0It should be possible to overcome or identify these sorts of > failures by entering timing information in the UCF file, or by following > good practice if crossing clock domains. Thanks alot all for helping me out with your valuable ideas and experiences. Actually, I dont see a timing problem there. Had it been a timing problem, it should have given me the same problem on the first FPGA board which is identical. As I said earlier, I have identical Spartan3AN boards. The same code works on one board but fails on the other in a strange manner which I have explained in my opening post. It seems something has really gone wrong with the FPGA fabric as Antii said. I was more interested to find out is there really something wrong with the FPGA and if so, how to authenticate it! Thanks anyway. CiaoArticle: 142019
jleslie48 <jon@jonathanleslie.com> writes: > Sorry to start from scratch yet again, but I don't know where to > begin. > > In the past I've had log file info dump out onto a UART as > necessary. The UART is slow, and requires an additional device to > capture the datastream. > How fast do you need? FTDIs UART-USB (TTL-232R-3V3) cable will go @ 3Mbps IIRC. It's an extra cable, hardly a device though, unless you count the PC as well? http://apple.clickandbuild.com/cnb/shop/ftdichip?productID=53&search=usb+uart+cable&op=catalogue-product_info-null > I want to be able to write to a removable memory stick, or compact > flash card, but I don't have any idea how to do it. When the FPGA is > powered up it should start a new "file" on the compact flash card, and > start writing to it. On commanded bit or powerdown, the file should > be closed, and stored such that I can pull the card, plug it into a PC > and read the file with notepad or such. Is this sort of thing any use? http://www.vinculum.com/ Easy modules: http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=57&title=VDIP1 I've never used them, but it looks like a simple way to add use-storage to a system. Failing that, glue a USB host controller on the side and run linux on a microblaze. [BTW, even though I sound like an FTDI salesman I have no affiliation with FTDI, other than having used various of their products!] Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 142020
On Jul 11, 8:26=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > I have a question about DSP's data width. > > Why do both Xilinx and AlteraDPSuse 18*18? > > Is it determined by hardware algorithms in order to save time or by > meeting most DSP data real needs? or any other reasonning? > > Weng On Sat, 11 Jul 2009 08:26:48 -0700 (PDT), Weng Tianxiang <wtxwtx@gmail.com> wrote: >Hi, >I have a question about DSP's data width. > >Why do both Xilinx and Altera DPS use 18*18? > >Is it determined by hardware algorithms in order to save time or by >meeting most DSP data real needs? or any other reasonning? > >Weng (the following may well be fiction) At the dawn of time, there was darkness and void, and FPGAs were without block RAMs or multipliers. And it came to pass that a traveler told and listened to the stories among the chosen, the enlightened, the designers that had completed more than one FPGA design. And many were the opinions of what would be really neat to have on a next generation FPGA. And lo, the largest lump that floated to the top was block RAMs. And many were the opinions of what it should look like. And the traveler sifted and sorted the many stories and multitude of opinions, and divined that block RAMs with 8 data bits and 1 parity bit and 2048 such words, would make most of the chosen, happy. Especially if it could also be 16+2 bits by 1K words, and 32+4 bits and 512 such words. And, dual port would be really neat, since most designers wanted FIFOs, and so would synchronous control, for memories (sorry for the pun) of the evils of asynchronous RAMs were still fresh on the mind of the designers, and the traveler. And the traveler took the stories he had heard, and carefully inscribed them on the finest parchment scrolls, and presented these to the high priests. The high priests new sedition when they saw it, and cast the traveler to the underworld, and buried the parchment under a pile of peat. And there it remained for a few years. Then one day, a competitor announced their newly born FPGA, and to the amazement of all, it had block RAM! Though they could hardly spell dual port, and were unaware of the law of zero hold time, the gauntlet was clearly upon the ground. A desperate call rose up from the ranks of the guild of marketing, and the parchment scrolls were remembered, and hastily they were dug up, and most of the peat was cleaned off. And thus the path to 2K Byte (with parity, and reconfigurable depth) dual port, synchronous, block RAM, was truly started. (As the chronicler of this ancient tale, I have noticed that while many insisted that it was imperative to include the 9th bit for parity, almost no-one ever used it for that purpose. Instead it was greeted with great enthusiasm, for such purposes such as tagging message starts and ends, or for marking a position in a FIFO, or for sideband data). As time went on, the next generation of FPGA was planned, and the traveler's scrolls were consulted, and the next largest lump to float to the top, were DSP applications. But not all designers had need for these strange incantations, and so the cost of adding these incantations needed to be minimized. High among the guiding lights of the of the traveler's clan were the realtors guild. They divided the land into pico-hectares, and charged mightily for each and every one used. The traveler noted that 3 score and 10 percent of all the pico-hectare of all FPGAs were made up of the roadways, the intersections, and even the drive-ways (especially the driveways) linking the roads to the LUTs and the BRAMs. The traveler said "Let us make good use of the pico-hectares we have already committed to the roads and driveways, and use them also to visit the Multipliers, for these are the essence of DSP". And let us also have accumulators, and shifters, and register files, and forwarding logic, and an ALU, and ....". And the high priests struck down the traveler, shouting "Enough! ... You get multipliers, and that's it". And it was many more years, and much more peat until these fine appendages were added. And that's why the multipliers are 18x18 bits with 36 bit results. ------ PhilipArticle: 142021
Mike Harrison : > On Sun, 19 Jul 2009 18:39:46 +0200, Bert_Paris <do_not_spam_@me> wrote: >> 12.8 Mbits is : >> * clearly out of reach for USB 1.1 like for FTDI Fifo or RS versions >> (2232 or 4232 OTOH). > > FYI I've just been playing with the FT2232H for outputting from the PC to an > FPGA, and this will sustain 20MBytes/second one-way. > This is in parallel sync mode - the async modes are constrained by the async > bus timing. Thanks Mike, I missed the "H" at the end. The "old" FT2232 is USB1.1 so limited to ~1Mbyte/s, and I haven't use the USB2.0 "H" version yet. But now we are much more focused on Ethernet (especially Gigabit which is much faster & easier than USB2.0), so it may not happen soon. BertArticle: 142022
On Jul 22, 5:09=A0am, Mike Harrison <m...@whitewing.co.uk> wrote: > On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wr= ote: > >Unfortunately, the generate statement only allows conditionally > >including concurrent statements. > > so does that mean that, for example, you couldn't use it to conditionally= exclude particular case > branches in a case structure? > Generate statements would not be used to conditionally exclude particular case branches, they can only exclude concurrent statements or instantiation of entities. I don't see much utility you would get from excluding particular case branches at all. The case conditions by definition must be - mutually exclusive - cover all cases Excluding a particular branch condition with an #ifdef would either violate the 'cover all cases' rule or force that particular branch to now follow the 'when others' default path. I haven't run across a situation where I've ever wanted to code something like that. In any case, you can still use the 'if...then' inside the case branch to branch around the code you would like to exclude. It's roughly the same amount of typing so it shouldn't be any extra work one way or the other. > > The replies so far suggest to me that it could get far more complicated t= han it would be if a #ifdef > type feature were available, which would be universally applicable to any= type of construct. > I've yet to look in detail but it seems like the code/project structure h= as to be significantly > designed around the need to handle variants. > 'Far more' complicated and 'significantly designed' are relative measures that people will disagree on, one can always concoct an example that will showcase any language in either it's worst light or it's best depending on what you would like to demonstrate. You should probably consider looking a bit more in detail as well as come back with more specific examples of "code/project structure has to be significantly designed around the need to handle variants" to make the conversation a bit less abstract. > ISPLever can specify pin mapping within the VHDL, so this would also prov= ide a way to handle pinout > differences between boards. Just because it 'can' doesn't mean that you 'should' do it that way. Pin mapping specifications in VHDL are not standardized (although the method used to implement them 'attributes' is part of the language). Maybe you don't care now that this would be non-portable, but down the road you might. Pin mappings, timing requirement specifications, I/O drive strength, voltage standards, etc. are all examples of things that you 'could' specify in VHDL by using attributes (if the particular synthesis tool allows it), but they are all examples of things that you most likely should not specify this way. No matter how you cut it, a real design will have more to its specification than what you would find in the VHDL, there will always be a project file that will contain some or all of these specifications. > I can't immediately see any way to make ISPLever select different prefere= nces files based on a > simple option - any suggestions/examples on this would be appreciated.- H= ide quoted text - > Here might be your example of where upon first inspection an #ifdef might be thought to be useful since to define the pin number for a signal in VHDL you would most likely need to do this by assigning some form of pin number VHDL attribute to the I/O signal. If you have a need to do so, assigning the attribute value via a function probably is a bit clunkier than the #ifdef (not by much). The reason though that this is not really all that useful after all is - Pin numbers on physical parts never have a need to 'move'. A given board will have a given part which will have pins connected to specific other pins on that board. There will not be any reason to vary these pin numbers for a given design while also maintaining the old pin numbers. - Pin numbers are specific to a given part and the synthesis tool will need to know the target part. Where is that stored? The pin number info would best be stored in that place as well (which will be the synthesis tool's project file). - Migrating a design to a new environment (i.e. the 'variants') means either changing parts or changing the target board with different pinouts (although I would think that if the same part is plopped down on to a new board, that new board would be best off to use the old pinouts). In any case, to get to the final bitstream/JEDEC file you'll need a new project for the synthesis tool...the pinouts belong in there. Kevin JenningsArticle: 142023
Martin Thompson <martin.j.thompson@trw.com> wrote: > jleslie48 <jon@jonathanleslie.com> writes: > > Sorry to start from scratch yet again, but I don't know where to > > begin. > > > > In the past I've had log file info dump out onto a UART as > > necessary. The UART is slow, and requires an additional device to > > capture the datastream. > > > How fast do you need? FTDIs UART-USB (TTL-232R-3V3) cable will go @ > 3Mbps IIRC. It's an extra cable, hardly a device though, unless you > count the PC as well? If you go with the FT245 or FT2232 in 245 mode, rate can even be higher, at the cost of more pins. Requirements on the PC side are the same. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142024
Hi, What is the minimum time(setup time) for the input D with respect to Clk in ISERDES block of virtex 4 fpga?. I am doing 400 Mhz DDR data capture.upto behavioral simulation it is ok...but failed in post route simulation. Can anyone help?
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