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
"rickman" <gnuarm@gmail.com> wrote in message news:d2fd7e80-2f5f-4366-b704-03fcee01bbfd@a28g2000hsc.googlegroups.com... >I am looking at a low end Dell laptop, the Vostro 1500, as a new > computer for work. I may supplement this later with a new desktop > unit for crunching FPGA designs, Consider a small form factor PC, they are small enough to carry home and you get all the power of a desktop. The only disadvantage is that you can't use them at an airport :-) > but I will also be using this laptop > for this sort of work. I am looking for advice on the differences in > CPUs for FPGA work and anything else that is relevant. > > I know that parallel ports are going the way of the serial port and > the dodo bird, but I can live with that. Most tools are available as > USB devices now. Correct, if you need a parallel port just look on ebay for a low-cost PCMCIA parallel port card (don't buy a USB to Parallel port cable since they do not work with dongles and apparently download cables). Serial ports are no problem, I bought a £7 USB to serial port cable and it works perfectly ( I use it with Teraterm to connect to my prototype board). > > This particular computer comes with WindowsXP rather than Vista. From > what I have heard, that is an advantage. Definitely, most EDA companies do not yet support Vista and if you don't care about wobbly windows then stick with XP. As suggested by Andy I would also recommend you set-up a dual boot with Linux. If you do this then I would recommend using Redhat or one of its clones like CentOS 4.4 (not 5). Linux is a great EDA environment although for some reason some EDA companies still like to charge extra for their Linux version. I would also suggest you keep your XP installation since you might nullify your warranty (completely brain-dead I know). > But I notice that the > internal bluetooth adapter is specific for XP and others from Dell are > specific for Vista. Any idea what is up with that? Is there any > significant advantage to using XP pro over XP home? > > This machine also has the "Intel(R) Integrated Graphics Media > Accelerator X3100". Is that just another way of saying "integrated > video"? Several of my other machines have had integrated video and it > does seem to drag down the CPU noticeably. Any idea if I will notice > the drag on the Core 2 Duo? > They also offer an Nvidia Gforce 8400 GS > adapter for $100 and an 8600 for $200 more. Any idea if these are > worth it? The 1500 says it has "VGA video output & S-Video". Does > that mean I can connect two monitors for dual display? If you want more screen area go for a single 24" (1920*1200) display since they are absolutely great. I used to have two 19" screens and I get tell you that a single 24" screen works much much better. Also most EDA tools require large high-res screens, look at the number of windows in Modelsim or HDL designer, you simply can not use them on anything less than 1280*1024 unless you are one of those persons that can watch and enjoy a video on your mobile (cell phone) :-) > > The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various > processors for significant money. The first step-up is to a T5470 (1.6 > GHz) for $75 and others range up to $575! I am thinking I can live > with the slower processor. The memory is 2GB. Go for 4Gbyte, this will make your P&R run a lot faster. Yes you can only use 3.2GByte under XP but even the extra 1.2Gbyte will make a difference. > > I was looking at the Vostro 1000 earlier this week with an AMD TK-53 > processor (1.5 GHz, 512 KB cache) and a smaller hard drive. It was > $50 more so the 1500 looks like the better deal. Are there any > significant differences in the two CPUs for FPGA work? I guess the > small cache of the TK-53 would make it significantly slower for FPGA > work. According to an English PC magazine both Rock and PCnextday (zoostorm) came out as one of the fastest laptops in their price class: http://www.rockdirect.com/ http://www.pcnextday.co.uk/ > > I saw a thread from earlier this year discussing some of this. I > wonder how much laptops have improved since then. > With the current speed of development I would say a year is just about long enough before it is time to pass on your laptop to your kids or family member :-) Hans www.ht-lab.comArticle: 126226
On Nov 14, 3:07 pm, cs_post...@hotmail.com wrote: > > The real problem is your insistence on using schematic entry for > things of moderate complexity. > > Learn a hardware description language and your life will be much > easier. Whilst, I accept that it is necessary to know HDL, I think this is an over-simplification of the issue. There seems to be a complete aversion by digital hardware engineers to graphical representation of problems, perhaps due to too many years of limited schematic tools. There seems to be a 'Code Warrior' mentality amongst many hardware engineers, that is reminds me of software development a few years back. I have heard comments from my colleagues, such as 'I look at the datasheet, and the code appears in my head'. This is hardly a consistent process. Considering the software case, generations of more complex languages have meant that it is no longer necessary to code at a low level all of the time. (Of course sometimes you need to). Graphical representation such as UML means that you just draw your state machines, rather than having to implement by hand. It is a lot easier to review diagrams than code. Now looking at hardware, whilst there may be a few occasions where it is necessary to tweak state machines due to silicon cost / performance, most of the time this is unecessary. Even if I am going to write a state machine in HDL, I would much rather draw it out on paper first, so that I can see if I have forgotten something. In common usage, there are only so many maintainable ways to implement a state machine, which means it is a sensible thing to template (or use a graphical tool). For those who argue about tweaking the state coding, this is only necessary in a few cases, as most of the time the synthesis tool will probably change it anyhow. This is why I have now moved to SystemVerilog enums for run of the mill state machines (much less hassle, allowing me to concentrate on the bigger picture). Of course, there are other instances e.g. RAM based state machines, where you may want to do something different, but this is the exception rather than the rule. Having come originally from a DSP background, drawing out dataflow diagrams of the progress of data makes sense during algorithm design. e.g. it is much easier to have idea of multirate / CIC filters etc. by drawing them out. Similarly, in my current non-DSP FPGA design by drawing a block diagram of the data flow through FIFOs, compare units, memory interface etc., I had a better idea of what was happening before I started to implement it. Whilst, detail may warrant the use of HDL, it is much easier to understand how something works at a macroscopic level by visualising it. Another example, would be the design of clock domain crossing schemes / handshaking etc. Personally, I find it much easier to draw out a bunch of latches, associated timing diagram, or even a petri net than leap straight in. That way there is no ambiguity about the functionality that I want to implement, and I can trace the signals round even before starting to write HDL. I think someone mentioned about all FPGAs being LUT4. This is not true, as Virtex-5s are LUT6. Implementation specific tweaks are always going to be necessary for some apps, but are a complete waste of time if you don't actually need them as they reduce the portability of your code. I doubt that everyone is working on the hairy edge all of the time. Of course, synthesis all the way down from a specification level description is not here. However, considered use of a combination of graphical and text based approaches can make life a lot easier.Article: 126227
dear In EDK 8.2, I am finding how to set up XST synthesis option "KEEP_HIERARCHY = YES", with no luck. Could someone tell me how to set "hierarchy" for synthesis step? Thank you in advanceArticle: 126228
I looked at XAPP0058 which describes some algorithms for in system programming of some Xilinx CPLDs. It appears that there are enough data to program a XPLA3 device once I have the binary data I want to program without needing any more tools/software/hoops_to_jump_through_I_havent_thought_of. However, given the long history of programming data secrecy (of not just Xilinx, they only pioneered that, I believe) I would like to get a confirmation by someone who has done it that this is actually possible for the XPLA3. Can I produce a binary using ABEL or whatever I can find in their free software (the way this used to be possible using PHDL before Xilinx bought and made the Coolrunner programming secret) and program it into their xpla3 parts _without_ using any JTAG tools/software other than those I make? Would I be able to utilize all CPLD resources with their free software (as far as producing the binary is concerned, that is)? I am using my own JTAG hardware/software, it runs under DPS, under which my logic compiler for the Philips coolrunner used to run (still does, just no parts available). Adapting it to do anything is not a problem, as long as "anything" is not kept secret. This may sound overly paranoid, but I do expect all sorts of catches nowadays not only from Xilinx, hence my question. IIRC Xilinx had something in the agreement with Philips to support all previous customers, but I am not in the mood for legal battles, I just need a usable CPLD (not one which comes with a PC/MS or whatever attached to it in order to be written to) without having to do a lot of reverse engineering. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 126229
Uzytkownik "Peter Alfke" <peter@xilinx.com> napisal w wiadomosci news:e137a2f3-69c2-429a-a660-6b824c41c9e7@b40g2000prf.googlegroups.com... >I agree with Ray (as always). > What is the data width and addressing depth of your synchronous FIFO? > Peter Alfke, Xilinx > data width is 36 bits or 128. Depth hmmmm .. I think about 100 words.. zlotawyArticle: 126230
Luc, Contact your disti or FAE. AustinArticle: 126231
u_stadler@yahoo.de wrote: > > thanks for the hint how to infer block ram. i will try that out! > (why istn't it a good idea to use the core generator for simple block > memory? just beauty reasons?) Beauty is one good reason. Then there is the need to fire up coregen and and involve a bunch of Xilinx libraries, and get those all compiled correctly. And changing a parameter, like width or depth requires another run of coregen. And then there is the issue that the Xilinx simulation models for the BRAMs are very slow. The inferred method simulates much faster. > i still would be curious though what's wrong the way i tried it?!? can > you give me a hint there? In your original posting, you said: > but whatever i do to the ports of the memory they always stay 'x'. > shouldn't at least the input port be '0' or '1' if i apply that > signal? Are you saying that WR and RD are always 'x'? If so, your problem is likely elsewhere, not with the BRAM model. That generally means you have two or more places where WR and RD are being driven, or nowhere where they are being driven.Article: 126232
psihodelia@googlemail.com wrote: > Conceptually VHDL is not bad at all, it supports a lot of things, well > in theory. But in praxis ... Here's my workaround using the thunderbird news reader: 1. Click on the OP's posting. 2. Message, Create Filter from Message, OK, Close. -- Mike TreselerArticle: 126233
Mike Treseler wrote: > Here's my workaround using the thunderbird news reader: > 1. Click on the OP's posting. > 2. Message, Create Filter from Message, OK, Close. Oh, that's how it is done! *plonk* To the rest: please don't feed the trolls. fArticle: 126234
HT-Lab wrote:
> <psihodelia@googlemail.com> wrote in message
> news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com...
>
>>Just look at its syntax. It is so archaic that anyone who had any deal
>>with Python will just laugh. Try, say, to create a simple VGA
>>controller, which is simply readable.
>
>
> Ok, in that case start writing your VGA controller in Python, then go to
> http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an
> FPGA prototype board and report back to us how incredible simple and quick
> it was.... :-)
I hope some one will take the project :-) (You'll need a development
version for VHDL conversion.) Here's what to expect.
The synthesizable RTL subset is what it is. Conceptually, there's little
to be gained from using MyHDL or whatever instead of VHDL for this.
There are good and bad ways to do it, but it will all be fairly "low level".
I'm not sure the OP understands that. It's not a syntax issue.
Having said that, MyHDL RTL has interesting features. In particular,
it has a "hardware designer's dream type" (or at least my dream):
a constrainable integer type like in VHDL (but not restricted to
32 bits ...), with an indexing and slicing interface for bit access.
All issues with signed/unsigned, resizing, casting, std_logic_arith
versus numeric_std, ... simply go away. The integer-like MyHDL type
simply works as integers do, and the convertor takes care of all
those low-level issues.
I'm still puzzled why nobody had this idea before (and why I'm not
getting more praise :-)), but in any case, it's not a matter
of syntax. I put it in, and I could specify how to do it in any
other language.
If you like dynamic languages (not everybody does), you'll enjoy
using MyHDL/python especially during verification. There you can
use the full power of python, which is in my opinion invariably
useful. Combined with a unit test framework such as py.test,
verification almost becomes fun :-)
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 126235I tried asking this in the Altera forum, but to no avail. The crux of my question is why the template that Quatus itself suggests results in a warning and how to fix that? For portability and readability I strongly prefer infering memory, but I seem to be having a very hard time getting Quartus II 7.2 to behave as expected. Quartus own template (pick edit -> insert template -> single port ram. The code included below) when translated produces this warning: "Warning: Inferred RAM node "ram~0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design." Indeed, the template is pass-through, but that is be directly supported by the M4K memory blocks in the context I'm using (no mixed port sizes or clocks). The setting "Add Pass-Through Logic to Inferred RAMs" defaults to "On", but I don't understand that option. It seems to me that setting it to "Off" would instruct Quartus II to infer logic that doesn't implement exactly what the Verilog specifies and would certainly cause a discrepancy when simulated with Icarus Verilog. To make matters even more entertaining, the online help disagrees with this template. Notably, the memory update is using a non-blocking assignment if (we) ram[addr] <= data and that doesn't infer the pass-through logic. Unfortunately, both infers Simple Dual RAM according to the Analysis & Synthesis RAM Summary. Is it even possible to infer Single Port RAM? (I care because I want to pack two single port rams into one M4K block). Help appreciated, Tommy .... code below .... // Quartus II Verilog Template // Single port RAM with single read/write address module single_port_ram ( input [(DATA_WIDTH-1):0] data, input [(ADDR_WIDTH-1):0] addr, input we, clk, output reg [(DATA_WIDTH-1):0] q ); parameter DATA_WIDTH = 8; parameter ADDR_WIDTH = 6; // Declare the RAM variable reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0]; always @ (posedge clk) begin // Write if (we) ram[addr] = data; // Read returns NEW data at addr if we == 1'b1. This is the // natural behavior of TriMatrix memory blocks in Single Port // mode q <= ram[addr]; end endmoduleArticle: 126236
[1] As others suggest, make sure that all inputs are known ... not X. X in results in X out. [2] The test bench should initialize memory first, then read data, OR use the initialization attributes of the BLKRAM to initialize values. I would try the latter first, since if you are relatively new to simulation, you can get the READ working before the WRITE. Take a look at your install directory /xilinx/doc/usenglish/books/docs/lib.pdf the section on RAMB for the syntax of initializing the device contents in your respective language (Verilog or VHDL). [3] You may have to add delays to your nets for some of your incoming signals relative to your clk. The unisim models perform timing checks, and if you violate setup and hold (as you do for RTL sims ... who cares ... we the sim model does), the model outputs X. [4] The suggestion to use inference of memories is a good one. For many years I instantiated BLKRAMs .... my rationale was I synthesized exactly what I wanted ... this was based on earlier experience of fighting tools to synthesize a certain configuration of memory. Anyway, a friend let me know this was terribly inefficient from a simulation point of view ... and I disagreed. So I coded up a testbench for bench marking purposes of instantiated blkram vs inferred memory, and the instantiated blkram ran 5x slower. Now if you were to pay your tool vendor for a simulator with 5x performance improvement, you might go bankrupt. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant phone : 303.926.0068 email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 126237
Didi wrote: > I looked at XAPP0058 which describes some algorithms for in system > programming of some Xilinx CPLDs. > It appears that there are enough data to program a XPLA3 device once > I have the binary data I want to program without needing any more > tools/software/hoops_to_jump_through_I_havent_thought_of. > However, given the long history of programming data secrecy (of > not just Xilinx, they only pioneered that, I believe) I would like to > get > a confirmation by someone who has done it that this is actually > possible for the XPLA3. > Can I produce a binary using ABEL or whatever I can find in their > free software (the way this used to be possible using PHDL before > Xilinx bought and made the Coolrunner programming secret) and > program it into their xpla3 parts _without_ using any JTAG > tools/software other than those I make? Would I be able to utilize all > CPLD resources with their free software (as far as producing the > binary > is concerned, that is)? > I am using my own JTAG hardware/software, it runs under DPS, > under which my logic compiler for the Philips coolrunner used to run > (still does, just no parts available). Adapting it to do anything is > not a problem, as long as "anything" is not kept secret. > This may sound overly paranoid, but I do expect all sorts of catches > nowadays not only from Xilinx, hence my question. > IIRC Xilinx had something in the agreement with Philips to support > all > previous customers, but I am not in the mood for legal battles, I just > need a usable CPLD (not one which comes with a PC/MS or whatever > attached to it in order to be written to) without having to do a lot > of > reverse engineering. > > Dimiter If you consider yourself the same as a programmer manufacturer : My device programmer lists PZ5032 PZ3032 XC3032XL XC2C32A so, that means the algorithms for all of those are published. -jgArticle: 126238
A few hours of digging later I found out that the JTAG sequences needed to write to a XPLA3 and Coolrunner-II are publically available. However, the JEDEC -> JTAGgable fuse address translation map is not (I do have that for the Philips Coolrunner, the bit locations in the JTAG sequence descriptions have nothing to do with the bit locations in the JEDEC file). The suggested way is to go through a variety of hoops, obviously for no other reason than to obscure the fact that one has to pay them up to translate the bit locations for me. Notice this fact is _very_ obscure, I am not sure many - if any - people realise it, apparently done so the user would discover that fact when it is too late (after having designed the part in). Do people know that? If I am more lucky, has anyone found the solution to that? (paying up for being allowed to program a part I have bought is not something I would consider, this is racket rather than business in my book). Thanks, Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 17, 6:00 pm, Didi <didi...@gmail.com> wrote: > I looked at XAPP0058 which describes some algorithms for in system > programming of some Xilinx CPLDs. > It appears that there are enough data to program a XPLA3 device once > I have the binary data I want to program without needing any more > tools/software/hoops_to_jump_through_I_havent_thought_of. > However, given the long history of programming data secrecy (of > not just Xilinx, they only pioneered that, I believe) I would like to > get > a confirmation by someone who has done it that this is actually > possible for the XPLA3. > Can I produce a binary using ABEL or whatever I can find in their > free software (the way this used to be possible using PHDL before > Xilinx bought and made the Coolrunner programming secret) and > program it into their xpla3 parts _without_ using any JTAG > tools/software other than those I make? Would I be able to utilize all > CPLD resources with their free software (as far as producing the > binary > is concerned, that is)? > I am using my own JTAG hardware/software, it runs under DPS, > under which my logic compiler for the Philips coolrunner used to run > (still does, just no parts available). Adapting it to do anything is > not a problem, as long as "anything" is not kept secret. > This may sound overly paranoid, but I do expect all sorts of catches > nowadays not only from Xilinx, hence my question. > IIRC Xilinx had something in the agreement with Philips to support > all > previous customers, but I am not in the mood for legal battles, I just > need a usable CPLD (not one which comes with a PC/MS or whatever > attached to it in order to be written to) without having to do a lot > of > reverse engineering. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------Article: 126239
Hi Jim, > My device programmer lists > > PZ5032 > PZ3032 > XC3032XL > XC2C32A > > so, that means the algorithms for all of those are published. do you mean there should be all data out there so one can write what it takes to program a device from a JEDEC file? So far I fail to find out how (all day), please send some more hint (also please take my other posting about JEDEC <-> JTAG mapping into account). Dimiter On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > > I looked at XAPP0058 which describes some algorithms for in system > > programming of some Xilinx CPLDs. > > It appears that there are enough data to program a XPLA3 device once > > I have the binary data I want to program without needing any more > > tools/software/hoops_to_jump_through_I_havent_thought_of. > > However, given the long history of programming data secrecy (of > > not just Xilinx, they only pioneered that, I believe) I would like to > > get > > a confirmation by someone who has done it that this is actually > > possible for the XPLA3. > > Can I produce a binary using ABEL or whatever I can find in their > > free software (the way this used to be possible using PHDL before > > Xilinx bought and made the Coolrunner programming secret) and > > program it into their xpla3 parts _without_ using any JTAG > > tools/software other than those I make? Would I be able to utilize all > > CPLD resources with their free software (as far as producing the > > binary > > is concerned, that is)? > > I am using my own JTAG hardware/software, it runs under DPS, > > under which my logic compiler for the Philips coolrunner used to run > > (still does, just no parts available). Adapting it to do anything is > > not a problem, as long as "anything" is not kept secret. > > This may sound overly paranoid, but I do expect all sorts of catches > > nowadays not only from Xilinx, hence my question. > > IIRC Xilinx had something in the agreement with Philips to support > > all > > previous customers, but I am not in the mood for legal battles, I just > > need a usable CPLD (not one which comes with a PC/MS or whatever > > attached to it in order to be written to) without having to do a lot > > of > > reverse engineering. > > > Dimiter > > If you consider yourself the same as a programmer manufacturer : > > My device programmer lists > > PZ5032 > PZ3032 > XC3032XL > XC2C32A > > so, that means the algorithms for all of those are published. > > -jgArticle: 126240
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:c657aada-8565-4ce8-a4c9-257914aff3b8@d21g2000prf.googlegroups.com... >I tried asking this in the Altera forum, but to no avail. > > The crux of my question is why the template that Quatus itself > suggests results in a warning and how to fix that? > If the design functions as you want it to and meets your performance requirements then what needs to be 'fixed'? Not every warning needs to be addressed as a design change, many should really just be 'note', not 'warning'. The comments in the template generated code, seem to indicate that this is how they intend it to work. If that is not exactly the function you want then don't use the template, code it to function how you need it to work. KJArticle: 126241
>If the design functions as you want it to and meets your performance >requirements then what needs to be 'fixed'? Not every warning needs to be >addressed as a design change, many should really just be 'note', not >'warning'. The usual reason for getting rid of warnings is so you don't have to think about them next time. Another reason is so that you don't miss an important one because it's lost in the clutter. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 126242
Didi wrote: > Hi Jim, > > >>My device programmer lists >> >>PZ5032 >>PZ3032 >>XC3032XL >>XC2C32A >> >>so, that means the algorithms for all of those are published. > > > do you mean there should be all data out there so one can write > what it takes to program a device from a JEDEC file? So far I > fail to find out how (all day), please send some more hint > (also please take my other posting about JEDEC <-> JTAG mapping into > account). Basically, yes. Clearly our programemr supplier (ee tools) has done this. Mostly they use the JTAG pins and pathway, tho some PLDs also have extra means to jtag-unlock, which needs more pins. It means that progamming documents must exist, and be sent to the programmer manufacturers. They may not be fully public, but they are not 'closed' either. So ask Xilinx for the info, explain you are manufacturing device programmers. If they prove too hard to work with, you could try Atmel etc They have appx equivalent devices to the smaller XPLA3 A working device programmer is also not a bad way to reality-check your work. eg You can pgm a part, and then confirm you can read it in your system, and then pgm in your system, and read/save the result, to analyse if some bits are in the wrong place. -jg > > Dimiter > > On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Didi wrote: >> >>>I looked at XAPP0058 which describes some algorithms for in system >>>programming of some Xilinx CPLDs. >>> It appears that there are enough data to program a XPLA3 device once >>>I have the binary data I want to program without needing any more >>>tools/software/hoops_to_jump_through_I_havent_thought_of. >>> However, given the long history of programming data secrecy (of >>>not just Xilinx, they only pioneered that, I believe) I would like to >>>get >>>a confirmation by someone who has done it that this is actually >>>possible for the XPLA3. >>> Can I produce a binary using ABEL or whatever I can find in their >>>free software (the way this used to be possible using PHDL before >>>Xilinx bought and made the Coolrunner programming secret) and >>>program it into their xpla3 parts _without_ using any JTAG >>>tools/software other than those I make? Would I be able to utilize all >>>CPLD resources with their free software (as far as producing the >>>binary >>>is concerned, that is)? >>> I am using my own JTAG hardware/software, it runs under DPS, >>>under which my logic compiler for the Philips coolrunner used to run >>>(still does, just no parts available). Adapting it to do anything is >>>not a problem, as long as "anything" is not kept secret. >>> This may sound overly paranoid, but I do expect all sorts of catches >>>nowadays not only from Xilinx, hence my question. >>> IIRC Xilinx had something in the agreement with Philips to support >>>all >>>previous customers, but I am not in the mood for legal battles, I just >>>need a usable CPLD (not one which comes with a PC/MS or whatever >>>attached to it in order to be written to) without having to do a lot >>>of >>>reverse engineering. >> >>>Dimiter >> >>If you consider yourself the same as a programmer manufacturer : >> >>My device programmer lists >> >>PZ5032 >>PZ3032 >>XC3032XL >>XC2C32A >> >>so, that means the algorithms for all of those are published. >> >>-jg > >Article: 126243
"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net... > >>If the design functions as you want it to and meets your performance >>requirements then what needs to be 'fixed'? Not every warning needs to be >>addressed as a design change, many should really just be 'note', not >>'warning'. > > The usual reason for getting rid of warnings is so you don't have to > think about them next time. > > Another reason is so that you don't miss an important one because > it's lost in the clutter. > Both of those are just 'motherhood and apple pie' statements though. Quartus will generate a 'warning' when it inserts a buffer to redrive a signal for whatever reason. Do you change the design so that the buffer doesn't get inserted? The answer there depends on performance. If the design meets the timing requirements and has adequate margin then you're best off leaving the design as is (thereby leaving the warning). In the OP's case of the RAM, he can probably change the function of the RAM to avoid use of the pass-thru mode and get rid of the warning, but if his design requires that mode of operation for whatever reason then he's broken the function of his design but gotten rid of the warning....bad tradeoff in my opinion. Don't break function to get rid of warnings. The nature of warnings should be understood. If the warning is a symptom of a design issue then they should be fixed; if not they can be either left alone or possibly fixed so they don't cause clutter...as long as cleaning clutter does not compromise function or performance. KJArticle: 126244
On Nov 17, 9:12 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in message > > news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net... > > >>If the design functions as you want it to and meets your performance > >>requirements then what needs to be 'fixed'? Not every warning needs to be > >>addressed as a design change, many should really just be 'note', not > >>'warning'. > > > The usual reason for getting rid of warnings is so you don't have to > > think about them next time. > > > Another reason is so that you don't miss an important one because > > it's lost in the clutter. > > Both of those are just 'motherhood and apple pie' statements though. > Quartus will generate a 'warning' when it inserts a buffer to redrive a > signal for whatever reason. Do you change the design so that the buffer > doesn't get inserted? The answer there depends on performance. If the > design meets the timing requirements and has adequate margin then you're > best off leaving the design as is (thereby leaving the warning). In the > OP's case of the RAM, he can probably change the function of the RAM to > avoid use of the pass-thru mode and get rid of the warning, but if his > design requires that mode of operation for whatever reason then he's broken > the function of his design but gotten rid of the warning....bad tradeoff in > my opinion. Don't break function to get rid of warnings. > > The nature of warnings should be understood. If the warning is a symptom of > a design issue then they should be fixed; if not they can be either left > alone or possibly fixed so they don't cause clutter...as long as cleaning > clutter does not compromise function or performance. But aren't you making an assumption that "the design functions as you want"? The OP may not have complained that it did not simulate correctly or that it did not meet performance. However, he is clearly concerned that it is not implementing as he requires. "Is it even possible to infer Single Port RAM? (I care because I want to pack two single port rams into one M4K block)." This sounds like it is not working as he wants it to. But then I don't think he should be using two single port rams. If I understand what he is doing, he may be asking the tool to be smarter than it is. Perhaps he needs to use a dual port ram and tie the high order address line high for one port and low for the other. Then the two ports should function as two single port rams with half the number of words.Article: 126245
I noticed that the Xilinx webpack version of ISE now runs in Linux. I seem to recall in the past that the webpack was a Windows only tool, so this seems like a signficant shift. Does anyone know if Altera has any plans to release a Quartus webpack for Linux? I still prefer Altera devices for my hobby work even though my current employer is 100% Xilinx. However, I'm looking down the barrel of Vista on my next system, and while I would prefer to migrate to Linux, I can't justify buying a license for Quartus to play at home. I suppose the other alternative is to bite the bullet, put my Altera dev boards away, and migrate to Xilinx dev boards.Article: 126246
>> The usual reason for getting rid of warnings is so you don't have to >> think about them next time. >> >> Another reason is so that you don't miss an important one because >> it's lost in the clutter. >> >Both of those are just 'motherhood and apple pie' statements though. I guess you go to a different church than I do. >The nature of warnings should be understood. If the warning is a symptom of >a design issue then they should be fixed; if not they can be either left >alone or possibly fixed so they don't cause clutter...as long as cleaning >clutter does not compromise function or performance. I'd claim that if they can't be "fixed" without breaking the design, then the tools are broken. I'm happy to add something to the code to tell the tools that I know about this case. I want warnings when I might be doing something wrong or even slightly fishy. Leaving them alone is not a sensible approach if there are more than a few. The clutter gets in the way of finding important warnings. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 126247
>Both of those are just 'motherhood and apple pie' statements... What?Article: 126248
Hi, I have a verilog module in my project, which is instantiated in the design 3 times, each time with different parameters. I generated 3 different vqm files outside the Quartus project (with Synplify), one for each instantiation. How can I tell Quartus which vqm file should be linked to its appropriate block? With regards, HeziArticle: 126249
> So ask Xilinx for the info, explain you are manufacturing device > programmers. > > If they prove too hard to work with, you could try Atmel etc > They have appx equivalent devices to the smaller XPLA3 Well thanks, Jim, sounds encouraging. Have not wasted any time talking programming data to their support for years, time to try again may be. I strongly suspect I know what the result will be, though. > It means that progamming documents must exist, and be sent to the > programmer manufacturers. Are you saying you can program a Coolrunner using a non-Xilinx programmer and a _JEDEC_ file? Without the programmer using (or asking you to use) some paid Xilinx software to do some fuse address mapping? Generally this is the question Xilinx' documents do not answer (and seem to deliberately obscure). > A working device programmer is also not a bad way to reality-check your > work. > eg You can pgm a part, and then confirm you can read it in your system, > and then pgm in your system, and read/save the result, to analyse if > some bits are in the wrong place. Oh I do not need that, last time I did it for the original Coolrunner it took me weeks rather than months to do the whole thing having just the data and a few chips. It totally took me about 3 months to write a suitable logic compiler (similar - not directly compatible - to PHDL, but more flexible/powerful, with all the DPS scripting. macros etc.) and some reverse engineering I had to do because I did not have all the data (Philips were easier to deal with than Xilinx - I guess everyone is that - but sent me only _most_ of the data, omitted a significant part of them...). Programming a device via JTAG is a lot easier than they make it sound (and cash in for), one just needs the device documentation. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 18, 2:41 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > > Hi Jim, > > >>My device programmer lists > > >>PZ5032 > >>PZ3032 > >>XC3032XL > >>XC2C32A > > >>so, that means the algorithms for all of those are published. > > > do you mean there should be all data out there so one can write > > what it takes to program a device from a JEDEC file? So far I > > fail to find out how (all day), please send some more hint > > (also please take my other posting about JEDEC <-> JTAG mapping into > > account). > > Basically, yes. Clearly our programemr supplier (ee tools) has done this. > > Mostly they use the JTAG pins and pathway, tho some PLDs also have > extra means to jtag-unlock, which needs more pins. > > It means that progamming documents must exist, and be sent to the > programmer manufacturers. > > They may not be fully public, but they are not 'closed' either. > > So ask Xilinx for the info, explain you are manufacturing device > programmers. > > If they prove too hard to work with, you could try Atmel etc > They have appx equivalent devices to the smaller XPLA3 > > A working device programmer is also not a bad way to reality-check your > work. > eg You can pgm a part, and then confirm you can read it in your system, > and then pgm in your system, and read/save the result, to analyse if > some bits are in the wrong place. > > -jg > > > > > Dimiter > > > On Nov 18, 12:43 am, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>Didi wrote: > > >>>I looked at XAPP0058 which describes some algorithms for in system > >>>programming of some Xilinx CPLDs. > >>> It appears that there are enough data to program a XPLA3 device once > >>>I have the binary data I want to program without needing any more > >>>tools/software/hoops_to_jump_through_I_havent_thought_of. > >>> However, given the long history of programming data secrecy (of > >>>not just Xilinx, they only pioneered that, I believe) I would like to > >>>get > >>>a confirmation by someone who has done it that this is actually > >>>possible for the XPLA3. > >>> Can I produce a binary using ABEL or whatever I can find in their > >>>free software (the way this used to be possible using PHDL before > >>>Xilinx bought and made the Coolrunner programming secret) and > >>>program it into their xpla3 parts _without_ using any JTAG > >>>tools/software other than those I make? Would I be able to utilize all > >>>CPLD resources with their free software (as far as producing the > >>>binary > >>>is concerned, that is)? > >>> I am using my own JTAG hardware/software, it runs under DPS, > >>>under which my logic compiler for the Philips coolrunner used to run > >>>(still does, just no parts available). Adapting it to do anything is > >>>not a problem, as long as "anything" is not kept secret. > >>> This may sound overly paranoid, but I do expect all sorts of catches > >>>nowadays not only from Xilinx, hence my question. > >>> IIRC Xilinx had something in the agreement with Philips to support > >>>all > >>>previous customers, but I am not in the mood for legal battles, I just > >>>need a usable CPLD (not one which comes with a PC/MS or whatever > >>>attached to it in order to be written to) without having to do a lot > >>>of > >>>reverse engineering. > > >>>Dimiter > > >>If you consider yourself the same as a programmer manufacturer : > > >>My device programmer lists > > >>PZ5032 > >>PZ3032 > >>XC3032XL > >>XC2C32A > > >>so, that means the algorithms for all of those are published. > > >>-jg
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