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
Hi ! I'm lookink for a quartus web edition for Linux. I read some news but I don't manage to find if a such version exist. If it exists, where can I download it ? ( on altera website, I see quartus 4 bus this version doesn't work under linux). Thank's a lot, -- LaurentArticle: 68526
lbroto <lbroto_ARONDBAS_@free.fr> wrote: : Hi ! : I'm lookink for a quartus web edition for Linux. : I read some news but I don't manage to find if a such version exist. : If it exists, where can I download it ? ( on altera website, I see : quartus 4 bus this version doesn't work under linux). As Altera (like Xilinx) uses Mainwin as porting Library, they have to pay Mainwin for every license they give out. So you need to buy the linux Software. Ask the distributor about the version... I'd wish they would use wine and talk to Codeweavers/WineX about maintanance. Their software mostly works already with wine used as an emulator... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 68527
Hello, I have installed the latest Quartus version for Linux, applied the service pack 1 and still have problem with it: as soon as I want to edit my VHDL top design file, Quartus crashes with no error message. I have removed all the accentuated letters but it did not resolved the problem. I am running a RedHat 9, I know it is not officialy supported but Altera did modify the scripts to include the magic LD_ASSUME_KERNEL variable to make it run. I can compile the design, simulate it but not editing it! Any clue? Thanks. -- Stéphane ACOUNIS "Oh le beau mur, il faut qu'je freine!" Ayrton SegaArticle: 68528
We provide ByteBlasterMV Download Cable for ALtera FPGA/CPLD, for detail information and buy on-line, please check at www.minford.ca. Thanks,Article: 68529
In my APEX board developpment Kit, I would like to store executable code in the On-chip RAM. But I can't download the srec code with SOPC builder, I always stay in "waiting for target... " state.Article: 68530
Christian Haase <nospams@today.de> wrote in message news:<4073cb1f$1@news.fhg.de>... > Hi Marija, > > maybe you didn't change your simulation resolution > to ps? (it is the -t option, or can also be found > in a pull down menu in the ModelSim GUI) > > Christian Another possibility is that your constraints are not actually constraining the signals you think they are. For PERIOD constraints make sure that you place the constraint after the DCM (pin period constraints don't always propagate through DCM or DLL). A good thing to check is the place and route report, which has a clock report and a constraint report at the end. Make sure your PERIOD constraints cover all listed clocks. Look at the constraint report for "N/A" entries which may indicate constraints that cover no paths.Article: 68531
> Is there anyway to merge the NGC cores from 3rd party vendors into my final > NGC file? > I found -read_cores YES only read in the NGC file for analysis... I think you have to instantiate your cores as black boxes for synthesis, and then integrate them into the design during the translate stage You can run PAR and use the floorplanner to capture your new (bigger) NGC core. XAPP 422 has all the details. That's the way I do it, but it may not be the only solution. Fernando OrtizArticle: 68532
You need to add both PPC in your device to JTAGPPC as documented on pg. 117ff in the "PowerPC 405 Processor Block Reference Guide". - Peter qudhs wrote: > Hi! > I am using a Virtex2PV20, and one PPC core is used in my design. > I drag a PPC Jtag controller core into the design in order to debug my > SW code. however, I failed to program the device with the generated > bitstream. iMPACT reports the DONE pin doesn't go high. In Bitgen, Jtag > clock has been explicitly specified. I think the main reason of > programming failure is that some wrong options were selected in Bitgen > phase due to the fact that I am not familiar with how JTAG works. could > someone guide me how to work out the problem? > thank you! > BRs. > --yang >Article: 68533
"Eric Paillet" <epaillet@antwerpen.be> wrote in message news:4073b644$0$1991$ba620e4c@news.skynet.be... > This guy has got the schematics on his website. It is labelled Byteblaster > MV, but it is the Byteblaster II though (as you can see by the name of the > file). The schematics are indeed quite ... simple > > http://www.fuw.edu.pl/~gkasprow/ > > I've built the thing, and it seems to work. Thanks Eric. I downloaded the file and got it converted to ASCII format by someone with Protel, so I can read it into Pulsonix. It's definitely a lot different from the MV - uses three '244 chips and a transistor. I'll be making a PCB for it and putting the design on my web site. If anyone else wants the ASCII Protel file I can make it available. LeonArticle: 68534
All tool vendor decisions like this are market driven (as opposed to standards driven). It was VHDL -87 because for a long time because the majority of designs were done in ASICs and their users wanted the default to match what the market leader (at the time) of ASIC synthesis (Synopsys) could handle at the time. Now the majority of designs are done in FPGAs. The market leaders of the FPGA synthesis market seem to support current language features. So now by market request it changes to -2002, something much more useful. So the market driven picture is this. A vendor will not invest in new language features out of good will. They will invest only by market (user) request. So as VHDL (and Verilog/SV) evolve, if you see a feature you want, make sure to tell your EDA vendor you want it. This is particularly effective around the time you are renewing licenses - they seem to listen better to $$$. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Allan Herriman wrote: > On Mon, 05 Apr 2004 07:53:14 -0700, Jim Lewis <Jim@SynthWorks.com> > wrote: > > >>Rajeev, >>Make sure to turn on the VHDL-93 switch. >> >>You can do this in the compile options menu item under >>compile in 5.7. > > > Why do you suppose Modelsim defaults to -93 off? > Perhaps someone should report this as a bug. > > Allan.Article: 68535
"John Adair" <newsreply@loseinspace.co.uk> wrote in message news:<XVOcc.2$bb6.0@newsr2.u-net.net>...
> Usually your best chance of getting it is with a CASE statement. No
> guarantees though as synthesisers are notoriously unpredictable.
>
> You can also try structuring your VHDL to suggest a element layout.
>
> Instantiating macros in your HDL will give you a more exact structure.
>
> --
> John Adair
> Enterpoint Ltd.
> http://www.enterpoint.co.uk
>
> This message is the personal opinion of the sender and not that necessarily
> that of Enterpoint Ltd.. Readers should make their own evaluation of the
> facts. No responsibility for error or inaccuracy is accepted.
>
>
> "Matthew E Rosenthal" <mer2@andrew.cmu.edu> wrote in message
> news:Pine.GSO.4.58-035.0404070358320.7554@unix3.andrew.cmu.edu...
> > I am trying to get XST to infer an 8:1 or even a 4:1 mux, instead of using
> > several 2:1 muxs'.
> > Is there a suggested coding style to get xst to infer the larger muxes or
> > how would i hardcode them to make larger muxes?
> >
> > Thanks
> >
> > Matt
look in the XST templates.
In Verilog
x <=
(sel==0)? a0 :
(sel==1)? a1 :
(sel==2)? a2 :
(sel==3)? a3 :
an
and so on works for me. I've gone to 8 no problem. But occasional use
of hardcoding a MUXxyz can help to build the top stage if you need to
combine say a 2->1 with an earlier 4->1 and so on. There are quite a
few app nots in the xapp dir.
regards
johnjakson_usa_com
Article: 68536
Hello,
I am trying to add user logic to an EDK project. I have tried attching to both the OPB and PLB busses using the ssp0 reference designs. I have striped down the user logic portion of the reference designs to be like a RAM that I can write to /read from. I can download the design to the development board, but the data that I read back is garbage.
In the MHS file for the core, I have:
BEGIN plb_simple_core
PARAMETER INSTANCE = plb_simple_core_0
PARAMETER C_BASEADDR = 0xD0000000
PARAMETER C_HIGHADDR = 0xD000FFFF
PARAMETER c_mir_baseaddr = 0xD0010100
PARAMETER c_mir_highaddr = 0xD00101FF
BUS_INTERFACE SPLB = plb
PORT plb_clk = sys_clk
END
And in the C code I have:
#define CORE_ADDR XPAR_PLB_SIMPLE_CORE_0_BASEADDR
Xuint32 reg_0;
// Write data to core
XIo_Out32( (CORE_ADDR + 0x0000), 0x00000000); // or some other data
// Read data from core
reg_0 = XIo_In32((CORE_ADDR + 0x0000));
xil_printf("Data at address 0 is: %d \r\n", reg_0);
Is this the correct method for reading/writing to the core?
If so any idea where else my error could be?
Thanks,
Joe
Article: 68537All, Benchmarks can be organized to demonstrate just about anything you want. We try to be as fair as possible, as we are interested in evaluating the strengths of the competition, not just the weaknesses. Caution! Since the VII Pro is 40% faster than Stratix, and Stratix Two will be (as claimed, once they have silicon and test it) to be 50% faster than Stratix One, that makes Stratix Two roughly at parity with Virtex II Pro from Altera's claims when compared against our extensive 200+ simulations of customer designs thru both sets of tools using real speeds files from 2+ years of silicon. We will release the results of our suite of 200+ actual customer designs results being pushed thru the respective tools soon. So at that seminar, ask: how many designs? where did they come from? do they target device specific features? how much of the part is being used? what is the speed data based on? If the answers are not: 200+, customers, yes, all (>80%), and real silicon, then 'caveat emptor'. So, for what it is worth, the two parts look like they are going to be roughly equivalent in fabric performance. Virtex II Pro also has (today) the 405PPC, the MGTs, the DCMs, and the SRL16s. One maxim of marketing is to take whatever you think you are strong in, and the competitor is weak in (real or imagined), and make that the issue. Don't talk about anything else. Bang the drum with a loud and consistent message. Hey, that is fair. If the fabric is predicted to be at parity, or slightly better, make a big deal out of it. I prefer to analyse all the strengths and weaknesses as an engineer, and see how that relates to my application. Stratix Two will be 90nm technology. Virtex II Pro is 130 nm, and going on 2 1/2 years old right now. Virtex 4 (the 90nm version) is yet to be revealed, and that would be the real apples to apples product face-off. In my opinion, the 90nm parts should outperform the 130 nm parts (or why bother?). The dissapointment is that it appears that it will be only one speed grade faster in the fabric, and still lack many features. So, if you want speed, just order one speed grade faster in 130 nm today! AustinArticle: 68538
Update: version_0.8 of the not yet finished synthesizable vhdl ARM model is ready. Slowly but shurely we aproach a working version. It takes longer than expected... Update: version_0.8 snap: http://www.tamaki.de/data/vhdl_06_04_2004.tar.gzArticle: 68539
"Eric Paillet" <epaillet@antwerpen.be> wrote in message news:4073b644$0$1991$ba620e4c@news.skynet.be... > This guy has got the schematics on his website. It is labelled Byteblaster > MV, but it is the Byteblaster II though (as you can see by the name of the > file). The schematics are indeed quite ... simple > > http://www.fuw.edu.pl/~gkasprow/ > > I've built the thing, and it seems to work. Eric, what programming format did you use? That schematic looks nothing like the insides of the ByteBlaster II cable I had (I've just shipped it off to a client and am awaiting a new one). NialArticle: 68540
I'm not certain about XST but my favorite trick with Synplify is to define
my selection as an 8-bit wire and select one of the bits. Simple! XST ?
(Verilog)
wire [2:0] Sel;
wire [7:0] MuxItems = {In1, InA, InB, Out1, Mid7, Result, whatA, whatB};
wire MuxOut = MuxItems[Sel];
"Matthew E Rosenthal" <mer2@andrew.cmu.edu> wrote in message
news:Pine.GSO.4.58-035.0404070358320.7554@unix3.andrew.cmu.edu...
> I am trying to get XST to infer an 8:1 or even a 4:1 mux, instead of using
> several 2:1 muxs'.
> Is there a suggested coding style to get xst to infer the larger muxes or
> how would i hardcode them to make larger muxes?
>
> Thanks
>
> Matt
Article: 68541
Hello,
I realized a design with two Microblaze with XPS 6.1, in a Virtex II-pro.
The two processors are independant, execpt for the clock and reset signals.
This design works well.
My aim is to separate nom the two microblazes in distinct VHDL entities.
Thus I exported the design in Projnav, creating a top-level entity ("stub")
and a sub-module containing all the wrappers. All that is generated by XPS.
If I program it without changing anything, it works.
Then I created a new VHDL entity and copied all that concerned the second
Microblaze in that new entity. The implementation reports no problems, but
on the FPGA; it doesn't work.
Then I tried something simpler: to delete the second processor from the
design, but it doesn't work either.
I think maybe there is a memory allocation problem, I don't really know how
to deal with the BMM files in that case. Or maybe ISE 6.1 doesn't support a
two-microblaze architecture???
Amaury Anciaux
Article: 68542That's what I think too. I tried to make a BM without any component but wires, but it doesn't work, the compiler XDL wants to route only wires that link instantiated components. It's a bit a waste of space to use TBUFs because the majority of the signals won't change of direction in the design, but for now I don't have any other solution. Amaury "Kelvin" <kelvin8157@hotmail.com> wrote in message news:c4p4id$sm1$1@mawar.singnet.com.sg... > > "Amaury Anciaux" <amaury.anciaux@tiscali.be> wrote in message > news:c4gqjm$a54$1@ail.sri.ucl.ac.be... > > The bus macro doesn't seem to lack anything, but I discovered that if I > route the concerned signal to a "pip" further to the left, the design > finally routes. So it seems that the PAR needs to have that first part of > the path to route the signal. > > > > Another question, are the bus macro really compulsory? If I use a custom > bus macro, without TBUFs, just to be sure that the signal passes through the > same nets, will it work? > > > > > I am sure the given bus macro is not the only solution...you may try build a > BM with two registers or only > four TBUFs, thus only occupies two slices...but the principle of no-crossing > of two adjacent module is > compulsory...The TBUF is intended to as a precaution for contention I > guess...Am I right? > > Kelvin > > > > > > > > > > > > > > > > > > > Your help was very useful. > > > > Regards, > > Amaury Anciaux > > > > > Yes, but in this case, even in the final assembly, this signal stays > > > unrouted. > > > I attach some example files: the NCD routed designs of the two modules, > and > > > the final assembly. > > > The signals conerned are controlL<3> and controlL<7> (in module 1 and > final > > > assembly). Other unrouted signals in the modules are normal. > > Try the following at the command prompt: > > > > xdl -ncd2xdl bm_v2p_4b.nmc > > > > This converts the bus macro to an XDL-description. Have a look at the > > .XDL-file this generates. For each net, there should be a section where > > it specifies which PIPs to use and such. For each net there should be an > > attribute like this: > > > > cfg "_NET_PROP::IS_BUS_MACRO:" , > > > > If there isn't, par sometimes doesn't route the corresponding output > > net. I have no idea why that is... In case this attribute is not set for > > the fourth bit of your bus macro, it could help to insert it manually in > > the .XDL-file and convert that back to ncd-format: > > > > xdl -xdl2ncd bm_v2p_4b.xdl > > > > This gives you an .ncd-file which you have to rename to .nmc to be able > > to use it as a macro. > > > > Don't know if this will help you, but I always had to manually insert > > the above attribute for all nets in the macros I did myself in FPGA > > Editor. FPGA Editor always seems to "forget" that, for whatever reason. > > > > BTW, I'm not sure if all of this works satisfactory with ISE6.1/6.2... > > When using XDL in ISE6, I always get a warning that "this is a new > > revision ncd, some features might be lost" or something. > > > > > As you can see, they are connected to the same TBUF in both bus macros. > > > BTW, do you know if the T input of a TBUF has to be "1" or "0" to be in > high > > > impedance? > > "1" disables the tristate buffer, so "1" for high impedance. > > > > -- > > Best regards, > > Sean Durkin > > > > > >Article: 68543
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:407421d3$0$31700$fa0fcedb@lovejoy.zen.co.uk... > > "Eric Paillet" <epaillet@antwerpen.be> wrote in message > news:4073b644$0$1991$ba620e4c@news.skynet.be... > > This guy has got the schematics on his website. It is labelled Byteblaster > > MV, but it is the Byteblaster II though (as you can see by the name of the > > file). The schematics are indeed quite ... simple > > > > http://www.fuw.edu.pl/~gkasprow/ > > > > I've built the thing, and it seems to work. > > Eric, what programming format did you use? > > That schematic looks nothing like the insides of the > ByteBlaster II cable I had (I've just shipped it off > to a client and am awaiting a new one). What chip(s) did it use? If I know the logic family, I can probably work the rest of it out for myself. LeonArticle: 68544
"Matthew E Rosenthal" <mer2@andrew.cmu.edu> wrote in message news:Pine.GSO.4.58-035.0404070358320.7554@unix3.andrew.cmu.edu... > I am trying to get XST to infer an 8:1 or even a 4:1 mux, instead of using > several 2:1 muxs'. > Is there a suggested coding style to get xst to infer the larger muxes or > how would i hardcode them to make larger muxes? > > Thanks > > Matt I don't understand how you would make a 4:1 mux in a Xilinx without making it out of smaller muxes. The LUTs only have 4 inputs, so you can't make a 4:1 mux out of a single LUT. You need two LUTs plus another F5 mux. -KevinArticle: 68545
Austin Lesea <austin@xilinx.com> wrote: > All, > > Benchmarks can be organized to demonstrate just about anything you want. > We try to be as fair as possible, as we are interested in evaluating > the strengths of the competition, not just the weaknesses. > > Caution! > > Since the VII Pro is 40% faster than Stratix, and Stratix Two will be > (as claimed, once they have silicon and test it) to be 50% faster than > Stratix One, that makes Stratix Two roughly at parity with Virtex II Pro > from Altera's claims when compared against our extensive 200+ > simulations of customer designs thru both sets of tools using real > speeds files from 2+ years of silicon. > > We will release the results of our suite of 200+ actual customer designs > results being pushed thru the respective tools soon. So at that > seminar, ask: > > how many designs? > where did they come from? > do they target device specific features? > how much of the part is being used? > what is the speed data based on? > > If the answers are not: 200+, customers, yes, all (>80%), and real > silicon, then 'caveat emptor'. URKH! Do we really need aggresive marketing wars in this newsgroup? -- Sander +++ Out of cheese error +++Article: 68546
> Altera only mentions the ByteBlaster II for programming Cyclone devices. > Presumably the ByteBlasterMV doesn't have the right voltage thresholds, > strictly speaking, but I was wondering if it could be used in a pinch. I > made my own from the published schematic (it works fine with Flex10K > devices), and would rather avoid having to buy the II, or make my own clone > of it. The ByteBlasteMV works quite well with the Cyclone. I'm using it in the JTAG mode. Martin -- ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 68547
Leon Heller wrote: > "Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message > news:407421d3$0$31700$fa0fcedb@lovejoy.zen.co.uk... > >>"Eric Paillet" <epaillet@antwerpen.be> wrote in message >>news:4073b644$0$1991$ba620e4c@news.skynet.be... >> >>>This guy has got the schematics on his website. It is labelled > > Byteblaster > >>>MV, but it is the Byteblaster II though (as you can see by the name of > > the > >>>file). The schematics are indeed quite ... simple >>> >>>http://www.fuw.edu.pl/~gkasprow/ >>> >>>I've built the thing, and it seems to work. >> >>Eric, what programming format did you use? >> >>That schematic looks nothing like the insides of the >>ByteBlaster II cable I had (I've just shipped it off >>to a client and am awaiting a new one). > > > What chip(s) did it use? If I know the logic family, I can probably work the > rest of it out for myself. > > Leon > > My local FAE told that the original BBII uses transistors for it's logic due to the 1.5V io requirement, but if you use 3.3V IO, it's perfectly possible to use som 74's to do it. I've done mine with 126 (to avoid the transistor used as a inverter in the schematic above mentioned) and it works just fine. Bye, RicardoArticle: 68548
Amaury,
ISE does not know whether there are 2 or more microblazes in the
deisgn. Microblaze is just like anyother HDL module of your system, as
far as ISE is concerned.
Once you separated the design into two parts, how are you connecting
them together. This will change your design hierarchy and hence BMM/UCF
files will change too. Also, double check to make sure you are
connecting all the clocks appropriately.
Amit.
Amaury Anciaux wrote:
> Hello,
>
> I realized a design with two Microblaze with XPS 6.1, in a Virtex II-pro.
> The two processors are independant, execpt for the clock and reset signals.
> This design works well.
> My aim is to separate nom the two microblazes in distinct VHDL entities.
> Thus I exported the design in Projnav, creating a top-level entity ("stub")
> and a sub-module containing all the wrappers. All that is generated by XPS.
> If I program it without changing anything, it works.
>
> Then I created a new VHDL entity and copied all that concerned the second
> Microblaze in that new entity. The implementation reports no problems, but
> on the FPGA; it doesn't work.
> Then I tried something simpler: to delete the second processor from the
> design, but it doesn't work either.
>
> I think maybe there is a memory allocation problem, I don't really know how
> to deal with the BMM files in that case. Or maybe ISE 6.1 doesn't support a
> two-microblaze architecture???
>
> Amaury Anciaux
>
>
>
Article: 68549
The C-code you are referring to appear to be from Xilinx drivers. Did
you modify the driver for your own IP. Also, what driver have you
assigned to this IP in the MSS file.
Amit.
Joe wrote:
> Hello,
>
> I am trying to add user logic to an EDK project. I have tried attching
> to both the OPB and PLB busses using the ssp0 reference designs. I have
> striped down the user logic portion of the reference designs to be like
> a RAM that I can write to /read from. I can download the design to the
> development board, but the data that I read back is garbage.
>
> In the MHS file for the core, I have:
> BEGIN plb_simple_core
> PARAMETER INSTANCE = plb_simple_core_0
> PARAMETER C_BASEADDR = 0xD0000000
> PARAMETER C_HIGHADDR = 0xD000FFFF
> PARAMETER c_mir_baseaddr = 0xD0010100
> PARAMETER c_mir_highaddr = 0xD00101FF
> BUS_INTERFACE SPLB = plb
> PORT plb_clk = sys_clk
> END
>
> And in the C code I have:
> #define CORE_ADDR XPAR_PLB_SIMPLE_CORE_0_BASEADDR
>
> Xuint32 reg_0;
>
> // Write data to core
> XIo_Out32( (CORE_ADDR + 0x0000), 0x00000000); // or some other data
>
> // Read data from core
> reg_0 = XIo_In32((CORE_ADDR + 0x0000));
> xil_printf("Data at address 0 is: %d \r\n", reg_0);
>
> Is this the correct method for reading/writing to the core?
>
> If so any idea where else my error could be?
>
> Thanks,
> Joe
>
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