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 Jan 16, 12:21 am, "robj" <r...@abc.net> wrote: > "Douglas" <j.d.morri...@gmail.com> wrote in message > > news:1189491208.142555.102930@50g2000hsm.googlegroups.com... > > > On Sep 3, 7:59 pm, iko...@alumni.technion.ac.il wrote: > >> It's about half of Xilinx Coolrunner-II > >> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex) > >> for same functionality. > > > Which Xilinx parts you used as a comparison point? I don't have > > expertise on Actel parts, but they seem to have 'quite' optimistic > > marketing gates readings, so comparing 250k part to 250k part might > > not be fair. > > > On a related topic - does anyone have expertise about the trade-offs > > of Actel's "Versa-Tiles" vs. 4/6-LUTs. It seems like obviously > > wastefull configuration - how many thansistors they can really share > > between 3-LUT and D-FF? Is there some benefit in this configuration, > > or is this 'design choice' made just to avoid Altera and Xilinx > > patents? > > > - Doug > > I don't see it as wasteful. It's just a more granular and generic > architecture, which has some advantages. I would guess that lowering power > was also a big part of the equation. No idea about patent concerns. I agree. People hear about a feature and get wrapped around the axle about it, because they think it makes a big difference either good or bad. In reality "features" have pros and cons which have to be weighed. The best way to weigh them is to test a few designs not by analyzing it on paper. There have been a number of different "granules" tried in FPGAs. In the end most were neither better or worse. Most parts use 4 LUTs, for as much as any reason, because that is what the software is optimized for. The only caveat of considering an architecture that trades off logic and FFs is when you analyze (on paper) the size of your design, be sure to add the LUT and FF count instead of using the larger as is done in devices with both LUTs and FFs. As some posters have mentioned, there can be significant differences in speed which are not obvious without testing a design. Nothing beats a real design to evaluate products. RickArticle: 137476
On Jan 19, 3:29 pm, rickman <gnu...@gmail.com> wrote: > > I agree. People hear about a feature and get wrapped around the axle > about it, because they think it makes a big difference either good or > bad. In reality "features" have pros and cons which have to be > weighed. The best way to weigh them is to test a few designs not by > analyzing it on paper. There have been a number of different > "granules" tried in FPGAs. In the end most were neither better or > worse. Most parts use 4 LUTs, for as much as any reason, because that > is what the software is optimized for. > > The only caveat of considering an architecture that trades off logic > and FFs is when you analyze (on paper) the size of your design, be > sure to add the LUT and FF count instead of using the larger as is > done in devices with both LUTs and FFs. > > As some posters have mentioned, there can be significant differences > in speed which are not obvious without testing a design. Nothing > beats a real design to evaluate products. Another issue with the IGLOO parts is that they don't really do anything different that the "other" guys in terms of density vs. I/O count. My designs often require larger logic counts and lower I/O counts and are cramped for board space. I prefer not to use the more advanced package technologies to keep costs down. This leaves me with parts that have a maximum of about 3000 LUTs or in the IGLOO, 6000 versa-tiles (about the same). Actel does seem to be pushing some very small packages, such as a 4 x 4 mm chip scale and a 6 x 6 mm QFN. But these can cost more to mount on a board and are harder to probe in debug. Also, they are not supported for any of the larger device sizes anyway. To get a larger part than the 250 a CS196 has to be used which will cost more due to the higher pin count. I know some others have the same issues with the current range of packages and parts. But I guess we are still a minority and don't impact the vendor's bottom line. RickArticle: 137477
Could someone help please, I'm trying to get a differential bi-directional signal working in a VHDL design targeting a Virtex 5. I can change the signal to "in" and use a "IBUFDS" and that works. I can change the signal to "out" and use a "OBUFTDS" and that works. But when I change the signal to "inout" and use a "IOBUFDS" (or instantiate both a IBUFDS and a IOBUFDS) I get the following 2 errors. (the two differential I/O pads are ddr2_dqs and ddr2_dqs_n) ERROR:PhysDesignRules:368 - The signal <ddr2_dqs_n> is incomplete. The signal is not driven by any source pin in the design. ERROR:PhysDesignRules:10 - The network <ddr2_dqs_n> is completely unrouted. Any help would be appreciated DanArticle: 137478
Dan Kuechle wrote: > Could someone help please, I'm trying to get a differential bi-directional > signal working in a VHDL design targeting a Virtex 5. Infer the buffers from your code. Example: http://mysite.verizon.net/miketreseler/oe_demo.vhdArticle: 137479
On Jan 19, 5:43=A0pm, "Dan Kuechle" <danie...@visi.com> wrote:
> Could someone help please, I'm trying to get a differential bi-directiona=
l
> signal working in a VHDL design targeting a Virtex 5.
> I can change the signal to "in" and use a "IBUFDS" and that works.
> I can change the signal to "out" and use a "OBUFTDS" and that works.
> But when I change the signal to "inout" and use a "IOBUFDS" =A0(or instan=
tiate
> both a IBUFDS and a IOBUFDS) I get the following 2 errors.
> (the two differential I/O pads are ddr2_dqs and ddr2_dqs_n)
>
> ERROR:PhysDesignRules:368 - The signal <ddr2_dqs_n> is incomplete. The
> signal
> =A0 =A0is not driven by any source pin in the design.
>
> ERROR:PhysDesignRules:10 - The network <ddr2_dqs_n> is completely unroute=
d.
>
> Any help would be appreciated
>
> Dan
In a working example from MIG 2.3, the DQS lines are hooked up
like:
u_iobuf_dqs : IOBUFDS
port map (
O =3D> dqs_ibuf,
IO =3D> ddr_dqs,
IOB =3D> ddr_dqs_n,
I =3D> dqs_out,
T =3D> dqs_oe_n_r
);
where ddr_dqs and ddr_dqs_n are declared inout std_logic at the top
level.
Article: 137480On Jan 19, 11:10=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > reganirel...@gmail.com wrote: > > I am writing to a RAM at a 40MHz pixel input from a camera, but need > > to access it at 25MHz for VGA output. Is it fine to disable the RAM > > between storing/accessing and change the clocks and other lines over > > then re-assert the enable? Is there a better way to do this? > > Run the ram at 40MHz and synchronize the slow process > using a fifo, > > or handshakes:http://www.fpga4fun.com/CrossClockDomain2.htmlhttp://www.fp= ga4fun.com/CrossClockDomain3.html If you use an internal BlockRAM, you can use the dual-ported addressing structure to separate read and write. Peter AlfkeArticle: 137481
On Jan 20, 10:11 am, Peter Alfke <pe...@xilinx.com> wrote: > On Jan 19, 11:10 am, Mike Treseler <mtrese...@gmail.com> wrote: > > > reganirel...@gmail.com wrote: > > > I am writing to a RAM at a 40MHz pixel input from a camera, but need > > > to access it at 25MHz for VGA output. Is it fine to disable the RAM > > > between storing/accessing and change the clocks and other lines over > > > then re-assert the enable? Is there a better way to do this? > > > Run the ram at 40MHz and synchronize the slow process > > using a fifo, > > > or handshakes:http://www.fpga4fun.com/CrossClockDomain2.htmlhttp://www.fpga4fun.com... > > If you use an internal BlockRAM, you can use the dual-ported > addressing structure to separate read and write. > Peter Alfke Yes, doing this now with a BRAM. Looks quite simple and very effective. I've only found alot of these Xilinx IP Cores recently... much better than trying to achieve everything from first principles :) Will update on progressArticle: 137482
"rickman" <gnuarm@gmail.com> wrote in message news:48c1221d-1315-4fe6-86f4-9bc381229b7a@u14g2000yqg.googlegroups.com... > On Jan 19, 3:29 pm, rickman <gnu...@gmail.com> wrote: > Another issue with the IGLOO parts is that they don't really do > anything different that the "other" guys in terms of density vs. I/O > count. My designs often require larger logic counts and lower I/O > counts and are cramped for board space. I prefer not to use the more > advanced package technologies to keep costs down. This leaves me with > parts that have a maximum of about 3000 LUTs or in the IGLOO, 6000 > versa-tiles (about the same). Actel does seem to be pushing some very > small packages, such as a 4 x 4 mm chip scale and a 6 x 6 mm QFN. But > these can cost more to mount on a board and are harder to probe in > debug. Also, they are not supported for any of the larger device > sizes anyway. To get a larger part than the 250 a CS196 has to be > used which will cost more due to the higher pin count. > > I know some others have the same issues with the current range of > packages and parts. But I guess we are still a minority and don't > impact the vendor's bottom line. > > Rick Rick - I also stayed away from the 0.5mm packages due to PCB complexity and cost. I found the FG144 package (1mm pitch, 13x13mm package) to be a good compromise and that package spans almost the entire family. I'm not an Actel evangelist. This is only the second time I've used their parts, coincidently both in the last year. This project we picked them for ultra low power (IGLOO). The previous project we picked them for non-volatility (ProASIC3). They fill niches that the big boys don't currently go after and they do a good job. One issue we've run into repeatedly, though, is that very few third party IP vendors target Actel. Most IP will map fine to the architecture but the vendors have no experience (due to low demand). And Actel does not have a very impressive IP portfolio of their own. RobArticle: 137483
On Jan 19, 8:40=A0pm, "robj" <r...@abc.net> wrote: > "rickman" <gnu...@gmail.com> wrote in message > > news:48c1221d-1315-4fe6-86f4-9bc381229b7a@u14g2000yqg.googlegroups.com... > > > > > On Jan 19, 3:29 pm, rickman <gnu...@gmail.com> wrote: > > Another issue with the IGLOO parts is that they don't really do > > anything different that the "other" guys in terms of density vs. I/O > > count. =A0My designs often require larger logic counts and lower I/O > > counts and are cramped for board space. =A0I prefer not to use the more > > advanced package technologies to keep costs down. =A0This leaves me wit= h > > parts that have a maximum of about 3000 LUTs or in the IGLOO, 6000 > > versa-tiles (about the same). =A0Actel does seem to be pushing some ver= y > > small packages, such as a 4 x 4 mm chip scale and a 6 x 6 mm QFN. =A0Bu= t > > these can cost more to mount on a board and are harder to probe in > > debug. =A0Also, they are not supported for any of the larger device > > sizes anyway. =A0To get a larger part than the 250 a CS196 has to be > > used which will cost more due to the higher pin count. > > > I know some others have the same issues with the current range of > > packages and parts. =A0But I guess we are still a minority and don't > > impact the vendor's bottom line. > > > Rick > > Rick - > > I also stayed away from the 0.5mm packages due to PCB complexity and cost= . I > found the FG144 package (1mm pitch, 13x13mm package) to be a good comprom= ise > and that package spans almost the entire family. I can't say I have looked at the pricing of this particular package, but in general the more I/O pins, the higher the price. I have been told that is because of the added test time. That aside, a 1 mm pitch package is still a bit more difficult to work with than a 0.5 mm pitch QFP. What size via did you use between the pins? What trace width? I would have liked to have added an MCU to the last board I designed, but that was not possible because of board space. Not only was there not space for a second debug header, but there was no room for the processor chip! > I'm not an Actel evangelist. This is only the second time I've used their > parts, coincidently both in the last year. This project we picked them fo= r > ultra low power (IGLOO). The previous project we picked them for > non-volatility (ProASIC3). They fill niches that the big boys don't > currently go after and they do a good job. > > One issue we've run into repeatedly, though, is that very few third party= IP > vendors target Actel. Most IP will map fine to the architecture but the > vendors have no experience (due to low demand). And Actel does not have a > very impressive IP portfolio of their own. I expect they used a significant amount of resources to add an ARM core to their devices. In fact, they offer special versions of their chips just for that core. I don't understand how they are different. I think this was more of a marketing coup than it is a practical feature. I think hard CPU cores are better than soft ones although much more expensive for the vendor. RickArticle: 137484
Hey guys, Im nearly ready to test a camera link image processing design, but have a problem with mapping the design. The deserializer in XAPP485 decodes the camera link LVDS stream, and outputs the parallel-ised data with the differential clock, which is where my design begins. The problem is with the differential clock. When I instantiate a DCM with differential inputs to give me both 2X180 and CLK0 outputs, it puts an additional IBUFGDS on the differential signal before the DCM input. The mapping tools then error from this because the inputs to the IBUFGDS are not coming from PADS. Then I tried taking only the positive output of the deserializer and putting it straight into the DCM, but then it errors at mapping because there is no load on the negative pin. As you can see, I am not very knowledgable about clocks and buffering, any help or explanations would be great :) GintsArticle: 137485
Hi, I am trying to program Xilinx Virtex-5 PCI Express Development kit with Digilent USB programming cable with Digilent suuported programming software. So far I have not been able to program the FPGA. Does this cable or the software suuport Virtex5 series FPGA? Is there a link to those listed FPGA devices supported by Digilent USB cable and accompanied software ? ThanksArticle: 137486
On Jan 19, 11:39=A0pm, reganirel...@gmail.com wrote: > Hey guys, > > Im nearly ready to test a camera link image processing design, but > have a problem with mapping the design. > > The deserializer in XAPP485 decodes the camera link LVDS stream, and > outputs the parallel-ised data with the differential clock, which is > where my design begins. The problem is with the differential clock. > When I instantiate a DCM with differential inputs to give me both > 2X180 and CLK0 outputs, it puts an additional IBUFGDS on the > differential signal before the DCM input. The mapping tools then error > from this because the inputs to the IBUFGDS are not coming from PADS. > > Then I tried taking only the positive output of the deserializer and > putting it straight into the DCM, but then it errors at mapping > because there is no load on the negative pin. > > As you can see, I am not very knowledgable about clocks and buffering, > any help or explanations would be great :) > Gints The clock is only differential at the IOB pins. It can have only one differential buffer, and I'm guessing that the code you got from XAPP485 already instantiates this. You need to hook the output of the IBUFDS or whatever they used to the input of your DCM. If you use CoreGen or an architecture wizard to create your DCM module, don't select "external" as the clock source or you will get additional input buffers, whether single-ended or differential. XST has always had problems with clock input buffering, usually erring on the side of adding too many. Generally the workaround is to instantiate the clock input buffer (IBUFG, IBUFGDS, IBUF or IBUFDS depending on the family and IO standard) and then route the output of the buffer to the DCM's or BUFGMUX's or BUFG's that use it. Regards, GaborArticle: 137487
Hello frnds, I have to implement image enhancement techniques on fpga. Here, i have to give input image from ultrasonic machine or some image capture device. After image is processed on FPGA, the output should be displayed on monitor or it should be given to ultrasonic machine again (For ultrasonic input). How can I give input pixel values to FPGA from the capture device or ultrasonic machine. Can we directly interface capture device with FPGA or Should input image be first given to some software tool which converts image into pixel values and to equivalent binary values. thanxArticle: 137488
rickman wrote: > On Jan 16, 12:21 am, "robj" <r...@abc.net> wrote: <snip> >> I don't see it as wasteful. It's just a more granular and generic >> architecture, which has some advantages. I would guess that lowering power >> was also a big part of the equation. No idea about patent concerns. > > I agree. People hear about a feature and get wrapped around the axle > about it, because they think it makes a big difference either good or > bad. In reality "features" have pros and cons which have to be > weighed. The best way to weigh them is to test a few designs not by > analyzing it on paper. There have been a number of different > "granules" tried in FPGAs. In the end most were neither better or > worse. Most parts use 4 LUTs, for as much as any reason, because that > is what the software is optimized for. Can you elaborate on the << different "granules" tried in FPGAs. >> ? I knew the old MUX2-based FPGA from Actel (the A1020 that I studied and played with long ago in school), as well as the 4-LUT and dual 3-LUT, and the current 3-input tile from the Actel. What are the other granularities and architectures that have been tried ? My curiosity needs answers :-) > As some posters have mentioned, there can be significant differences > in speed which are not obvious without testing a design. Nothing > beats a real design to evaluate products. sure. > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 137489
On Tue, 20 Jan 2009 20:29:55 +0100, whygee wrote: >I knew the old MUX2-based FPGA from Actel (the A1020 that I studied >and played with long ago in school), as well as the 4-LUT and dual 3-LUT, >and the current 3-input tile from the Actel. > >What are the other granularities and architectures >that have been tried ? My curiosity needs answers :-) Crosspoint had a very fine-grained architecture, but didn't survive long enough even to publish a second edition of their databook AFAIR. The curious architecture that was developed by Pilkington and then taken over (and later dropped) by (I think) Motorola was also very fine-grained - right down to simple gates. There were a few others too, in the emergent days of FPGAs. Of course, routing density and speed would surely doom them all to an early demise. We can see that clearly today, but the area/performance/cost tradeoffs were somewhat different back when 0.35 micron was high-tech, and now it's routine for users to waste a couple of dozen SERDES, as many multipliers, perhaps a PowerPC or two.... just to get an FPGA with the pinout they want. It still goes against the grain to see all that profligacy, but the reality is that those resources are now absurdly cheap and the leading vendors do indeed have the balance roughly right. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137490
Hi ! Jonathan Bromley wrote: > On Tue, 20 Jan 2009 20:29:55 +0100, whygee wrote: >> What are the other granularities and architectures >> that have been tried ? My curiosity needs answers :-) > Crosspoint had a very fine-grained architecture, but > didn't survive long enough even to publish a second > edition of their databook AFAIR. Is it http://findarticles.com/p/articles/mi_m0EKF/is_/ai_12345853 ? Google gave me a few other results but i don't see anything that lets me understand it... But I found http://www.tutorial-reports.com/computer-science/fpga/logic-block.php and it looks very interesting. Too bad that the ACM and IEEE results in Google are not readable. > The curious architecture that was developed by > Pilkington and then taken over (and later dropped) > by (I think) Motorola was also very fine-grained - > right down to simple gates Is this http://findarticles.com/p/articles/mi_m0EKF/is_n1941_v38/ai_13074753 ? . Thank you for the pointers. It was interesting to see what has been attempted. And I believe that enough patents have now expired that it's possible to make one's own FPGA architecture... SiliconBlue rides this wave, among others. Is a new FPGA era coming ? BTW, I've also spotted M2000 which is now http://www.aboundlogic.com What are they really doing ? yg -- http://ygdes.com / http://yasep.orgArticle: 137491
Hi, I read xapp1117 and I need the associated matlab files, such as: gmsk_mod.mdl. But I cannot find it on Xilinx website. I even try the forum, it seems nowhere to post my request. Could you help me? Thanks, Could you tell me where I can find it?Article: 137492
Hi, I read xapp1113 and I need the associated matlab files, such as: gmsk_mod.mdl. But I cannot find it on Xilinx website. I even try the forum, it seems nowhere to post my request. Could you help me? Thanks, Could you tell me where I can find it?Article: 137493
On Tue, 20 Jan 2009 15:01:00 -0800 (PST), fl <rxjwg98@gmail.com> wrote: >Hi, > >I read xapp1113 and I need the associated matlab files, such as: >gmsk_mod.mdl. But I cannot find it on Xilinx website. I even try the >forum, it seems nowhere to post my request. Could you help me? >Thanks, >Could you tell me where I can find it? To get the mdl files you need to download the design files associated with xapp1113 which are contained in a zip file named xapp1113.zip which can be found by searching the xilinx.com for xapp1113. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137494
Hello, I have a Problem. I need a crashcours in using ethernet on a FPGA. I have the Xilinx Spartan-3A DSP Starter Kit and have to create a connection to a PC via Ethernet. My Problem is, I have ISE and EDK, but I have no idea, how to realize this connection. I couldn't find any Tutorial this way... I only want to send data to the PC. With 100MBit/s. Can you give me advises or links to a tutorial where I can learn how to implement Ethernet? I try to use MicroBlaze, but if there is any Softprocessor which is better in this case, please tell me. Thanks for your help!Article: 137495
On Jan 20, 2:29 pm, whygee <why...@yg.yg> wrote: > rickman wrote: > > On Jan 16, 12:21 am, "robj" <r...@abc.net> wrote: > <snip> > >> I don't see it as wasteful. It's just a more granular and generic > >> architecture, which has some advantages. I would guess that lowering power > >> was also a big part of the equation. No idea about patent concerns. > > > I agree. People hear about a feature and get wrapped around the axle > > about it, because they think it makes a big difference either good or > > bad. In reality "features" have pros and cons which have to be > > weighed. The best way to weigh them is to test a few designs not by > > analyzing it on paper. There have been a number of different > > "granules" tried in FPGAs. In the end most were neither better or > > worse. Most parts use 4 LUTs, for as much as any reason, because that > > is what the software is optimized for. > > Can you elaborate on the << different "granules" tried in FPGAs. >> ? > > I knew the old MUX2-based FPGA from Actel (the A1020 that I studied > and played with long ago in school), as well as the 4-LUT and dual 3-LUT, > and the current 3-input tile from the Actel. > > What are the other granularities and architectures > that have been tried ? My curiosity needs answers :-) Atmel is a forgotten FPGA vendor. They still sell an FPGA with an AVR included. This is based on their second generation FPGA with a (single) 3 input LUT, IIRC. Their first FPGA used a hard logic design with a FF, a 2 input (or was it three input) XOR and a couple of AND or NAND gates. Turns out you can use an XOR with the AND to form something equivalent to sum of products just like AND and OR gates. They also didn't have much in the way of routing other than the direct connections between adjacent cells. Since the cell was so simple, the rational was that you could burn them for routing. Another forgotten vendor is Motorola, most likely because their product was stillborn. I seem to recall that it was *very* fine grained although I can't say I ever read any details. I believe they called it "Crosspoint" or "Crossfield" or something like that. They contracted with NeoCAD for tools and when the chip design was bagged, I want to say that was the end of NeoCAD and they were bought by Xilinx, but I can't remember for sure if this was the trigger for NeoCAD passing on. There was another company called Plus Logic but I really just can't recall the structure of their devices. But I'm pretty sure they wern't 4 LUTs. RickArticle: 137496
On 2009-01-21, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: > You're welcome. I would love to see some of the FPGA > old-timers (where are you when we need you, Peter Alfke!) > write a definitive history of this stuff - I can easily > imagine the folklore being lost for ever, quite soon. The following URL may be of interest to you: http://www.eecg.toronto.edu/~jayar/pubs/kuon/foundtrend08.pdf "FPGA Architecture: Survey and Challenges" The history section is fairly short, but it is interesting to note that they claim the first SRAM based FPGA was proposed as early as 1967. The remaining part of this article is also full of much interesting information. I would also like to read some early FPGA development folklore, both hardware and software anecdotes. (I'm young enough to take HDL:s and decent CAD software for granted so the software side is also interesting to me. I have a feeling that I'm somewhat spoiled...) I'd be really interested in the architecture of the first Xilinx FPGAs for example, especially if accompanied with some nice die photos of for example a switchbox and a CLB. (I was planning to do something along these lines myself, even got so far as slaughtering a poor XC20???, but I somehow managed to lose the die.) Besides, I never figured out a good way to attach a camera to our microscope. For that matter, I would probably need a better microscope as well :) Perhaps this has already been written? Anyone know of a nice source for this? (I guess Xilinx early patents may hold important clues to the architecture, but you never know if the circuit is actually implemented as in the patent.) /AndreasArticle: 137497
Hi all, in PAR simulation I get the following warning from Modelsim: # ** Warning: /X_RAMB16_S1_S4 SETUP Low VIOLATION ON ADDRA(1) WITH RESPECT TO CLKA; # Expected := 0.377 ns; Observed := 0.007 ns; At : 606119.145 ns # Time: 606119145 ps Iteration: 1 Instance: / arp_top_level_arp_top_level_sch_tb/uut/xlxi_411/ xlxi_19_bu2_u0_grf_rf_mem_gbm_gbmg_gbmga_ngecc_bmg_blk_mem_generator_valid_cstr_ramloop_5_ram_r_v2_ram_dp1x4_ram # ** Warning: /X_RAMB16_S1_S 4SETUP Low VIOLATION ON ADDRA(13) WITH RESPECT TO CLKA; # Expected := 0.377 ns; Observed := 0.342 ns; At : 606119.145 ns # Time: 606119145 ps Iteration: 1 Instance: / arp_top_level_arp_top_level_sch_tb/uut/xlxi_411/ xlxi_19_bu2_u0_grf_rf_mem_gbm_gbmg_gbmga_ngecc_bmg_blk_mem_generator_valid_cstr_ramloop_5_ram_r_v2_ram_dp1x4_ram What I understand so far is that the setup time of ADDRA(1) is too low. What does the statement X_RAMB16_S1_S4 SETUP mean and how can I examine it in ModelSim? I know it's a stupid question but that is the first time I'm using a structure model of a BRAM IP-Core in PAR simulation. Hence I can't find the signal names of BRAM in ModelSim that the IP-Core generator has ganerated for behavioral simulation. Kindest regards SvenArticle: 137498
Hi, I would like to know the voltage that supplies the configuration logic in Virtex 5 , is it Vccaux ? thank youArticle: 137499
Hallo. I have a little configuration problem with a spartan3 module. Master-serial programming through a XCF04 works, but directly programming the device per (parallelport) jtag fails. After failing the direct fpga programming, IMPACT shows some status information about the fpga: CRC,DCM/DCI, Data ok. Everything looks like I'm just missing the startup to start (DONE stays low, according to these status-registers). 1 or 2 years ago, I've had the same problem, but it somehow disappeared for a while. There's an Answer record in the xilinx database telling this problem was a known issue with ISE9.4 (but for Spartan3a/an), but I'm also not fully sure if I was probably using some bitgen-switch when the problem disappeared. Gruss Jan Bruns
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