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
The SDRAM has been in my XILINX FPGA board, I can't change the SDRAM's layout, I mean how can i do some change in software of EDK. Thanks for your advice.Article: 84151
it works thankyou very much for commentArticle: 84152
Joesph, I agree with Ben. With so many variables and so much marketing B.S., your best bet is to compile using both a V4 and SII. I've found that performance is highly dependent on implementation, synthesis tools, and how full the device is. These are all variables outside of your FPGA vendor selection. You also note that you're probably going with the slowest speed grade, so I assume cost is an issue. A true comparison cannot be made with cost included. In addition, you should also consider whether EasyPath for Xilinx or Hardcopy for Altera are alternatives to help lower your cost. Finally, I would like to make one point about interconnect. Who cares if V4 or SII is slightly faster? It's the routing software that is going to make the major difference. Whichever software requires me to do the least amount of floorplanning is the one that wins. Also, how well does the software perform as the chip gets full? Personally, I think the floorplanning tools of ISE are easier to use than Quartus. However, I think Quartus does a much better job at placement and routing as a design gets very full (>90% utilization). JohnArticle: 84153
Hi ,
I want to use the following component instantiation
in my VHDL testbench:
entity tb_test is
end tb_test;
architecture testbench of tb_test is
component test
port ( Reset : in std_logic;
Clk : in std_logic;
Bidir_data : inout std_logic_vector(7 downto 0);
Dir : in std_logic;
Nxt : in std_logic;
Stp : out std_logic
...
);
end component;
signal t_Reset : std_logic;
signal t_Clk : std_logic;
signal t_Bidir_data : std_logic;
signal t_Dir : std_logic;
signal t_Nxt : std_logic;
signal t_Stp : std_logic;
.=2E.
signal t_tx_data : std_logic_vector(7 downto 0)
signal t_drive_tx_data : std_logic;
signal t_rx_data : std_logic_vector(7 downto 0);
begin
uut : test
port map ( Reset =3D> t_Reset,
Clk =3D> t_Clk,
Bidir_data =3D> t_Bidir_data,
Dir =3D> t_Dir,
Nxt =3D> t_Nxt,
Stp =3D> t_Stp
);
t_Bidir_data <=3D t_tx_data when t_drive_tx_data=3D'1' else (others =3D>
'Z');
t_rx_data <=3D t_Bidir_data when t_drive_tx_data=3D'0' else (others =3D>
'0');
process
begin
-- Generate t_tx_data, t_drive_tx_data
-- in this process
end process;
end testbench;
My question :
In the port map
Bidir_data =3D> t_Bidir_data
an INOUT port of the unit under test is connected to a signal within
the testbench.
Will the Tristate Description shown work ? (Which "direction does
"t_Bidir_data" have ?)
The testbench "t_tx_data" generation takes over the tristate bus master
role.
Thank you for your help
Rgds
Andr=E9
Article: 84154Hallo, I have made a microcontroller with keyboard (16 key). I have a C function to handle interrupt that comes from keyboard when a key is pressed. I should make a C software (not graphic) with a menu. Every key must corresponds to a option of the menu and when I push one key the software must load the appropriate function. In what way can be realized in C? Thanks MarcoArticle: 84155
Jim, I have been corrected by many. No, they are not all the same (in the hardware, and as an IC designer, I already knew that). However, in the past they were treated as all equal (for efficiency, finding and using the faster path is not necessarily a big benefit). I do not know if the paths are treated the same or not (on the 4LUT) in V4 p&r. I am sure someone will tell me (now). I think the point I was trying to make is that the 4LUT is faster than the ALM for a class of functions (4 inputs or less), and slower for wider functions (on some pins). So, the quality of the synthesis, followed by the place and route (constraints) will make a huge difference in the performance. I have been told that for every design that is better in S2, after some work, can be made even better than S2 in V4. I do not doubt that Altera can, and does, make the exact same claim. I disagree that the ultimate (best) performance in S2 is better, as that is not what our research has shown. Again, Altera has their own suite of XX designs that they use to benchmark their device, and they also make exactly the same claim. Given the state of the marketing wars (see the "mine is...." thread), I think I'll stay safely in the engineering camp, and say: if you are really adamant about comparing the two, go take your finished design, and run it through both design tools, and make your own decision. Our FAEs are available to help you with that chore. And please take into account that we offer: DSP48, EMAC, PPC, FIFO-BRAM that can be used to even greater advantage. AustinArticle: 84156
"ARRON" <mlpei279@gmail.com> wrote in message news:ee8e3ab.1@webx.sUN8CHnE... > The SDRAM has been in my XILINX FPGA board, I can't change the SDRAM's > layout, I mean how can i do some change in software of EDK. Thanks for > your advice. write your software such that it does a byte write not a word write.Article: 84157
Hi FPGA experts I am a little bit desperate. We have designed a hardware module in EDK 6.2 which was working properly on our ML300 Board. We tested the logical bahaviour with thousands of testcases, and on the Board we executed 8000 instruction. In the end it output the correct result. Now we switched to EDK 7.1 and guess what happend... the module doesnt work anymore. The exact same core already outputs the false result in the first execution of a digit-multiplier. Its really strange as here 25 iterations are required to return the result. Finally exactly 1!!!! bit is incorrect. I have no clue what the problem could be. Is there a possibility that the mapping process somehow failed? Or that the board is broken? Any other ideas what could cause this problems? Cheers for any helpful comment PhilippArticle: 84158
Michael Dreschmann wrote: > Hello, > > in my actual design im using a few picoblazes. Now I wonder if it is > possible to update the code in the bitstream without a new > implementation run like it is possible with the microcblaze. I checked > data2bram but it allows only an update of 16 Bit wide Brams, not the > necessary 18 Bit. > > Thanks, > Michael Check out Ken Chapmans reply to this in the PicoBlaze forum: http://toolbox.xilinx.com/cgi-bin/forum?50@171.5RzZaQ3QgOp.0@.ee8a991Article: 84159
Gabor wrote: > Michael Dreschmann wrote: > > Hello, > > > > in my actual design im using a few picoblazes. Now I wonder if it is > > possible to update the code in the bitstream without a new > > implementation run like it is possible with the microcblaze. I > checked > > data2bram but it allows only an update of 16 Bit wide Brams, not the > > necessary 18 Bit. > > > > Thanks, > > Michael > > Check out Ken Chapmans reply to this in the PicoBlaze forum: > > http://toolbox.xilinx.com/cgi-bin/forum?50@171.5RzZaQ3QgOp.0@.ee8a991 Darn... the link is broken... Here's the post: Ken Chapman - 03:54am Dec 14, 2004 PST (#1 of 1) Reply A new version of DATA2MEM is in development and will support the update of the 1024x18 memory used for a KCPSM3 program. I have carried out some initial tests last week and it worked for me. Please contact me directly (ken.chapman@xilinx.com) if you would like to help me verify it further. Thanks to the Xilinx Software Development team for adding support of BRAM in this aspect ratio. Regards, KenArticle: 84160
Austin Lesea wrote: > Jim, > ... > > I disagree that the ultimate (best) performance in S2 is better, as that > is not what our research has shown. Again, Altera has their own suite > of XX designs that they use to benchmark their device, and they also > make exactly the same claim. Austin, to settle this argument once and for all, why not take a bunch of designs that are freely available on OpenCores, and present utilization and performance reports without doing any tweaking of the designs ? There are many VHDL and Verilog deigns available on OpenCores from CPUs, to Crypto cores to communication cores. Both companies could present their own results including with a script as to how to reproduce the results, in case somebody wanted to double check. If you could agree to do this fir Xilinx, and perhaps we ghet a volunteer from the Altera Camp, we can openly chose some designs ... Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 84161
That's why the best way to implement is to create an interrupt service routine (ISR) that respond to the UART. This way, even if you do slow-speed processing, in background, the ISR will respond quickly to the UART. Sooner or later, you may have parts of your code that start taking more time and have slower response time. Of course, you're the one who know what requirement your application have. If you think that 16-bytes buffer would be well enough, then no need to trouble with interrupts ;)Article: 84162
"Philipp" <grabherp23@yahoo.de> schrieb im Newsbeitrag news:1115997464.049933.72870@g43g2000cwa.googlegroups.com... > Hi FPGA experts > > I am a little bit desperate. We have designed a hardware module in EDK > 6.2 which was working properly on our ML300 Board. We tested the > logical bahaviour with thousands of testcases, and on the Board we > executed 8000 instruction. In the end it output the correct result. Now > we switched to EDK 7.1 and guess what happend... the module doesnt work > anymore. The exact same core already outputs the false result in the > first execution of a digit-multiplier. Its really strange as here 25 > iterations are required to return the result. Finally exactly 1!!!! bit > is incorrect. I have no clue what the problem could be. Is there a > possibility that the mapping process somehow failed? Or that the board > is broken? Any other ideas what could cause this problems? > > Cheers for any helpful comment > Philipp > Hi Phipp welcome to the real world. EVERY EDK update (incl service pack) may make your working design non working. this may be either hardware issue or newly introduced compiler erratic behaviour. I have updated projectects from V2PDK to 7.1, and I just know. It is like that. In some cases you may be lucky and all works, in other cases you need to change your source code or some settings, etc, to make the working design to work again. Sometimes its not fun at all. AnttiArticle: 84163
Rudi, nice idea, but it won't work, with the two companies involved. Many years ago, there was PREP, with a very similar idea. It died because the FPGA manufacturers could not resist the temptation to tinker with the results ( I used the words "lied and cheated"). Our "friends" presented designs with "virtual" flip-flops, to improve the packing density. It became one big shouting match. The stakes are just too high for either of the marketing departments to admit "defeat", and there are too many subtle aspects of designing with FPGAs, hardware and software. "Everybody is the winner" will be the unavoidable outcome. It seems that the user community likes the intense competition and diversity. And we like the fact that FPGAs have not become a commodity where price is the only differentiator. There is still lots of room for creativity and innovation. Peter AlfkeArticle: 84164
Warning: Ranty, opinionated (and quite probably wrong): Stupid question on the X vs A urination (in a hurricane) contest: How much does performance really matter? First, how many FPGA tasks are not defined by an external clock or clocks? If you are doing GigE, your clock is 125 MHz (8 bit path) or 62.5 MHz (16 bit path). The PCI-X bus is 33/66/99/133 MHz. Second, how many designs have single-cycle latency requirements? PCI does, but your part either can or can't make the PCI spec with the provided IP core (so thats a pass/fail metric, not a performance metric). If the task is latency bound overall, then performance matters. But otherwise, just add more registers & pipeline more finely. Thus I personally wonder whether the primary focus of the pissin match should be mostly about tools (both the vendor tools and support for third party tools, especially easy floorplanning, datapath aware placement, & retiming), density ($/LE), and features (Brand X has a big lead here), rather than who's lut is 10% faster on what functions, and who's interconnect might be slightly faster on some designs and slower on others. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 84165
Rudi, No offense taken at all. If you have any sort of Altera question you think is suitable for the news group, feel free to ask here and I'd say there is a good likelihood of it getting answered. I think David's comment below reflects the personalities of the individuals from A & X who post here pretty accurately. On your other question about leading edge designs - the people who will see this each day are the sales/FAE staff for each company. My intuition and customer experience tells me that the competition is fierce and both companies' products are used in leading edge designs in all sorts of markets, but any more (from me) would be pure speculation. Jesse Kempa AlteraArticle: 84166
Rob Gaddi wrote: > To whom it may concern: > > Page 53 of the Spartan-3 Starter Kit User's Guide claims that: > > The A1 expansion connector shares connections with the 256Kx16 SRAM > devices, specifically the SRAM address lines, and the OE# and WE# > control signals. Similarly, the JTAG chain is available on pins 36 > through 40. Pin 20 is the FPGA DOUT/BUSY configuration signal and > toggles during the FPGA configuration process. > > This, while accurate, is not the entire case. The A1 connector also > shares connection with 8 of the SRAM data lines, though this is not > indicated in any way by Table 13-2. This information, in fact, can only > be deduced by close examination of the schematics, or alternatively when > PACE informs you that the pins to your SRAM and the pins making hard > connections to the board you've already spun are on the same pin of the > FPGA. Had this information been made clear in the user's guide, rather > than left out of the explicit statement of connection, I would now be > saved a good deal of fairly extensive blue-wiring trying to save this > project. > > Please update the User's Guide as soon as possible regarding this point, > in the interests of saving a future customer my current aggravation. > > Regards, > Rob Gaddi Just got an emailed response from Steve Knapp over in Xilinx AE. The docs have now been updated to note this connection, link to the updated documentation is http://www.xilinx.com/bvdocs/userguides/ug130.pdfArticle: 84167
Thank you for your feedback on the Spartan-3 Starter Kit Board User Guide. Please also accept my apologies for the inconvenience that this obviously caused. The user guide has since been updated with the requested change and is now available at the following link. UG130: Spartan-3 Starter Kit User Guide http://www.xilinx.com/bvdocs/userguides/ug130.pdf Please also note that you can submit feedback about Xilinx documentation directly to datasheet-feedback#NOSPAM#@xilinx.com, minus the "#NOSPAM#". --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. "Rob Gaddi" <rgaddi@bcm.YUMMYSPAMtmc.edu> wrote in message news:d609hv$t61@gazette.corp.bcm.tmc.edu... > Peter, Austin, someone Xilinxy, can anyone possibly put this in hands > where it'll do some good? The cost of updating online PDF documentation > is really pretty trivial. > > -- > > To whom it may concern: > > Page 53 of the Spartan-3 Starter Kit User's Guide claims that: > > The A1 expansion connector shares connections with the 256Kx16 SRAM > devices, specifically the SRAM address lines, and the OE# and WE# > control signals. Similarly, the JTAG chain is available on pins 36 > through 40. Pin 20 is the FPGA DOUT/BUSY configuration signal and > toggles during the FPGA configuration process. > > This, while accurate, is not the entire case. The A1 connector also > shares connection with 8 of the SRAM data lines, though this is not > indicated in any way by Table 13-2. This information, in fact, can only > be deduced by close examination of the schematics, or alternatively when > PACE informs you that the pins to your SRAM and the pins making hard > connections to the board you've already spun are on the same pin of the > FPGA. Had this information been made clear in the user's guide, rather > than left out of the explicit statement of connection, I would now be > saved a good deal of fairly extensive blue-wiring trying to save this > project. > > Please update the User's Guide as soon as possible regarding this point, > in the interests of saving a future customer my current aggravation. > > Regards, > Rob GaddiArticle: 84168
"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag news:d61gcq$qu0$1@nobel.pacific.net.sg... > Peter Sommerfeld wrote: > [snip] > Jesse, Pete, > > I did not intend to offend anybody. I am sure there are many > great guys here from both camps. My point was that I seem more > tough discussions in the Xilinx camp. > > I don't know what the cause for that is. Are Altera user not > doing any (b)leading edge designs ? Are they not using any > fancy features of the devices, are they not pushing the devices > to the limit ? I don't know. It's just my personal observation ... > > Regards, > rudi Hi Rudi, there defenetly are bleading edge designg on Altera devices. what might interest you is that the only really available low cost ($795) FPGA PCIe board is based on Altera and not on Xilinx silicon. Altera also claims that the Stratix-GX based PCIe solution passed compliance testing in full. Thats of course BS as the Stratix-GX has about the same amount of PCIe compliance issues as rocketIO/X (pre V4) but the Stratix-GX can pass PCIe compliance on the PCIe plugfest even if it is not fully compliant to the PCIe spec (those non compliance issues dont actually matter in most real life applications). And as it has been said here the new GX FPGA is coming too... AnttiArticle: 84169
Mike Lewis wrote: > "ARRON" <mlpei279@gmail.com> wrote in message > news:ee8e3ab.1@webx.sUN8CHnE... > > The SDRAM has been in my XILINX FPGA board, I can't change the SDRAM's Your Won't waste 24 bit of SDRAM if your buffer 4 bytes and then write to SDRAM and let the software application know about this ....Article: 84170
"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag news:d62jct$gjj$1@nobel.pacific.net.sg... > Austin Lesea wrote: > > > Jim, > > > ... > > > > I disagree that the ultimate (best) performance in S2 is better, as that > > is not what our research has shown. Again, Altera has their own suite > > of XX designs that they use to benchmark their device, and they also > > make exactly the same claim. > > Austin, > > to settle this argument once and for all, why not take a bunch > of designs that are freely available on OpenCores, and present > utilization and performance reports without doing any tweaking > of the designs ? There are many VHDL and Verilog deigns available > on OpenCores from CPUs, to Crypto cores to communication cores. > > Both companies could present their own results including with > a script as to how to reproduce the results, in case somebody > wanted to double check. > > If you could agree to do this fir Xilinx, and perhaps we ghet a > volunteer from the Altera Camp, we can openly chose some designs ... > > Best Regards, > rudi Rudi, it would not work that way and you get nil support to the idea (officially at least) from any FPGA vendor. There is just too much on the stake. But some companies are doing something similar by having test environment which are run agains the latest tools for multi FPGA vendors. Those are the companies that design FPGA/ASIC tools. And to my knowledge most of those companies are pissed to FPGA companies because ah their bread is getting less as the FPGA vendor tools are getting better (or including new functionality in it) and I think there are some other problems also. Anyway those companies run testbenches. For a little different reason, but I think they pretty much 'see' and 'know' the differencies between the FPGA fabrics from different vendors. But all that benchmarking is strictly inside those companies and there is no public info. The 'fpga' benchmarking in open, has failed. It is virtually not possible to be done wihout some kind of biasing and the results are not useable without very strict explanatians under what circumstances the compare results are valid. The hdl to fabric mapping is too complex (the all process) and there are too many small things that may or may not have impact on the results. Antti with his last 2 cents :)Article: 84171
Hello, >> http://toolbox.xilinx.com/cgi-bin/forum?50@171.5RzZaQ3QgOp.0@.ee8a991 >Darn... the link is broken... Here it works, thanks for your help MichaelArticle: 84172
W A wrote: > How to turn off auto bufg insertion in ISE 7.1 ??? when using *schematic* > entry?? It's messing up my design. > > Anyone? In older versions the ECS schematic would not insert these, but for HDL you would attach a BUFFER_TYPE attribute to the net. Check out the constraints guide to see how.Article: 84173
I am product manager at AccelChip, one of the tools mentioned by Stanley earlier in the thread. As he notes, our tool is primarily intended for algorithms beginning in MATLAB. Typically our customers would have an algorithm such as this in MATLAB. A benefit of MATLAB is that there are preexisting functions such as polyval() that perform functions like polynomials in one variable quite compactly. Tools like AccelChip and System Generator have generally presumed the design will be put into fixed-point form which has numerous advantages over floating point. The trick is determining how much precision is truly required and this ultimately takes knowledge of the design and its system requirements. It's not immediately clear to me how much precision you will require, but 7 decimal places in fixed-point is about 23 bits which is well within the precision ranges of these tools. Best regards, --EricArticle: 84174
Rudi, The problem is that without any regard to device specific features, the results will vary by a tremendous amount. Austin
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