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 biggest problem with async circuits is verification, not constructing them. Construction does require a few more rules and considerably more care than a synchronous circuit but it can be done and could even be synthesized. Verification opens a whole can of worms that just aren't issues with synchronous circuits. Besides, there is the scare factor. If the same thing can be done synchronously, then why scare your boss/customer/client with an asynch circuit and all the extra verification headache it brings? Jonathan Bromley wrote: > Of course you are right; but all your points would be answered by a > synthesis methodology that could develop a truly self-timed logic > system (so that manufacturing tolerances *don't* cause trouble) from > a suitable functional description. AFAIK the basic theory needed to > underpin such a methodology is already in place; I think you will find > that, at least in principle, your "worst problem" is *not* insoluble. > Self-timed logic gurus, where are you now? > > Jonathan Bromley -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14601
Is it possible to do dual-port RAM in an XC4000 (no E)? I want two read ports, rather than read and write (it's not for a FIFO). I assume not, since there's nothing at Xilinx's web site about it, but you never know. thanks, Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14602
Peter Alfke wrote: > > kebm@flash.net wrote: > > > While I agree that it does sound like satish is whining or > > trying to lay > > blame for why he hasn't gotten started on his project yet, > > it really is the > > responsibility of the local reps to keep the customer > > happy. If they can't > > help this guy out before he gets frustrated enough to post > > a message like > > this, perhaps one of their competitors can... > > > > Let's put this silly case to rest. Right after I read the > original posting, I forwarded it to our office in Hong-Kong, > who forwarded it to our Indian rep. And satish is happy and > has apologized profusely about his posting, as you can read > here: > > "I am sorry to put the blame on such an well established > company. After my > request the local rep. has turned to me. Any how I apologise > for putting this > in the net." > > Serving a subcontinent that has a relatively small revenue > base, is not easy. And just flaming on the internet is not > the appropriate complaint procedure. End of story. > > Peter Alfke, Xilinx Applications > hmmm, interesting, you have to whine on the net to get support? ;-)Article: 14603
i work in the field of reconfigurable computing and i will never get used to the following message from my FPGA back-end tools: no placement/routing found ... or, if i was lucky enough, the tool found a fit after several hours. but, c'mon, synthesizing the damn thing with a state-of-the-art tool took a couple minutes! so i think its time to post something about this matter and see what the net thinks about it: if you've done some serious FPGA designs, you probably know the facts of routability: 1. re-running P&R doesn't help! some algorithms are non-deterministic, so why not try one more time? since for some FPGAs its worse than winning in a lottery! 2. decreasing device utilization doesn't help! sometimes - especially when you have pin constraints - not even decreasing it to a ridiculously low 50% helps! 3. there are no better P&R tools! unfortunately, there is no 3rd party supply for P&R tools (unlike for synthesis), so you're stuck with the vendors tools. and their tools seem not to be too concerned about routability. hey, they want to sell silicon, and when they get you down to 50% device utilization, they'll suceed! :-> 4. you cannot re-synthesize for improved routability! knowing, that no synthesis tool supports "synthesis for routability" (at least i don't know any), all you can do is switch off all the optimizations (you're down at 50% device utilization so what do you care about one more LUT?). or if you've optimized for area (delay), you now optimize for delay (area). as an EDA developer i know that there are algorithms avail, that estimate routability in synthesis, that can improve routability (e.g. thru replication of logic, or running a different decomposition). also, there are more decent P&R algorithms avail, than the ones you get with your vendors P&R tool. all i want is a *robust* FPGA design flow, but why can't i buy any? my explanation is: there is no demand for it! Endric (speaking for himself, not for his employer)Article: 14604
Asawaree, The reason you don't see the XLA technology is because it doesn't appear until Synplify ver. 5.0.7. However, you really want to use ver. 5.0.8 (current version as of this post) because Xilinx changed their speed grades. That is, Synplicity 5.0.7 supports -2, -1 and -09 but ver 5.0.8 supports the current -09, -08 and -07 grades. To make a long story short, upgrade your software to 5.0.8. and life will be good. By the way, Xilinx decided not to offer the XX4036XLA in a HQ304 package due to the smaller die size of the XLA architecure. (Just an important safety tip.) :-) I have had favorable results with Synplicity ver 5.0.8 and Xilinx M1.5i using the XLA architecture. Hope this helps. Matt Bielstein Asawaree Kalavade wrote in message <79ctas$d88@nntpa.cb.lucent.com>... >Synplify/Xilinx4085XLA question > >I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP) >device. >I don't see the XLA series under technology. Is there a comparable >technology/part I could use? (There is no 208 package for 4085 XL.) > >What am I missing here? > >thanks, >asa >kalavade@bell-labs.comArticle: 14605
Phil Hays wrote: > > Don Husby wrote: > > > Area (PFU) Speed (MHz) > > Schematic 21 95.2 > > Exemplar 30 75.6 > > Synplicity(1) 33 57.4 > > Synplicity(2) 32 67.2 > > Synplify(3) 38 clb(par) 142.8 + > Point (3) is wrong. I quoted the time that TRCE reported, but TRCE didn't tell quite the whole truth. Reading the data sheet is still a required engineering function. Xilinx RAM is limited to a clock period of 7.4 ns in a -09 part, or about 135 MHz. Both Synplify and Schematics would give the same speed result. Phil Just talking to myself. And answering.Article: 14606
rk wrote: > unfortunately, the "just hit one button and your problems are solved" > goal for hdl's are not here yet. I doubt it that will ever be the case for all users. I've worked on designs that didn't push the technology, and the one button interface is getting close to solving that problem, given a reasonable person pushing the button and looking at the outputs. The answers that the tools give are usually B- or so. Not as good as a human could do, but usually not so bad. More good enough for quite a few cases. For the test case that started this thread, Synplify does just as good as any schematic tool (or anything else) could do targeting Xilinx XC4000XL's: exceed the speed of the internal RAMs. I've also worked on designs that push the technology. B- isn't always quite good enough. For the speed end of this, I have been able to meet speed goals by starting with a pure behavioral design and improving it where needed. The main tools to improve are floorplanning and/or physical VHDL. Figure out what cells you need and where they need to be, just as you do with a schematic, write a physical VHDL design with fixed names, floorplan that section, and get the result you need. For cost reduction, if you have the volume to care if the design is in a part costing 4 US$ more or even 40 US$ more, perhaps a similar method would work. Build it with pure behavioral code, find the space wasting sections, hand map these as needed to fit into the cheaper part. The initial design would allow for startup, with cost reductions following, getting both a timely introduction (beating the handcrafted schematic competition to market :-) ) and a reduction in cost as production continues (allowing you to match the schematic competition's prices once they do make it to market ;-) ). -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 14607
When I did the pin locking in FPGA Express v2.1, sometimes the Alliance PAR tool failed to route a design which is only 62% utilization. But, when I did the pin locking in the user constraint file (UCF) and no pin locking during synthesis, the same design routed with no problem. The number of CLBs used between the method was also different. Does anybody have this experience or know to explain this problem? HandiArticle: 14608
As far as I remember, the dual ports in the XC4000 seties (at least XL),
had two ports.
One port was read-only
The other port could be either written or read
So I assume this suits your application
(refer to the databooks of Xilinx for more info)
Hamish Moffatt wrote:
> Is it possible to do dual-port RAM in an XC4000 (no E)? I want two read
> ports, rather than read and write (it's not for a FIFO). I assume not,
> since there's nothing at Xilinx's web site about it, but you never know.
>
> thanks,
> Hamish
>
> --
> Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au
>
> Rising Software Australia Pty. Ltd.
> Developers of music education software including Auralia & Musition.
> 31 Elmhurst Road, Blackburn, Victoria Australia, 3130
> Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839
> Internet: http://www.rising.com.au/
--
Koenraad SCHELFHOUT
Alcatel Telecom
Switching Systems Division http://www.alcatel.com/
Microelectronics Department - VA21 _______________
________________________________________\ /-___
\ / /
Phone : (32/3) 240 89 93 \ ALCATEL / /
Fax : (32/3) 240 99 47 \ / /
mailto:koenraad.schelfhout@alcatel.be \ / /
_____________________________________________\ / /______
\ / /
Francis Wellesplein, 1 v\/
B-2018 Antwerpen
Belgium
Article: 14609Koenraad Schelfhout <koenraad.schelfhout@alcatel.be> wrote: > As far as I remember, the dual ports in the XC4000 seties (at least XL), > had two ports. > One port was read-only > The other port could be either written or read > So I assume this suits your application > (refer to the databooks of Xilinx for more info) The only mention of dual-port I could find on the Xilinx site was in XC4000E and later devices -- I'm using XC4000, the suffix-less, disowned version. thanks, Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14610
Please visit and comment on my Electronics and Electrical Engineering pages located at: http://www.users.globalnet.co.uk/~metad/eee.htm Containing: Introduction to EEE Resources (over 100 web links) Employment Statistics and newspaper excerpts Engineering Poems, Quotations and Jokes EEE at Glasgow University In addition my homepage (http://www.users.globalnet.co.uk/~metad/) contains: A section about me My CV A James Bond Section A guestbook Humour 500+ cool links in the "new look" bookpage Cool background MIDI and graphics Literary quotations Photo Album Student Resources Awards Page Poems... Basically, something for everyone! PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS! Please send you comments via the guestbook or by Email (containing your full name and Email and webpage addresses) and visit via http://www.users.globalnet.co.uk/~metad/. Thanks Scott Johnston metad@globalnet.co.ukArticle: 14611
> The > initial design would allow for startup, with cost reductions following, > getting both a timely introduction (beating the handcrafted schematic > competition to market :-) ) and a reduction in cost as production > continues (allowing you to match the schematic competition's prices once > they do make it to market ;-) ). Unless you either type REALLY fast, and make NO mistakes in your HDL, and the tools behave right on (for the hour) AND the person you are competing against with schematics draws them with stone and chisel, drinks heavily, and bashes his/her thumb with the hammer, this just isn't how it's gonna play out. And your 'cost reduction' can take from a lot more time to never. I'm not talking about using 30 CLBs....that's hardly a real world test, and if, without much effort, an HDL can't keep up with schematic in a 30 CLB test case, that would call for immediate expulsion. How many times have you actually done this and seen the results you tout? In the dozen or more cases I have seen (and fixed), your belief just doesn't hold up.Article: 14612
Phil Hays wrote: > rk wrote: > > > unfortunately, the "just hit one button and your problems are solved" > > goal for hdl's are not here yet. > > I doubt it that will ever be the case for all users. I've worked on > designs that didn't push the technology, and the one button interface is > getting close to solving that problem, given a reasonable person pushing > the button and looking at the outputs. The answers that the tools give > are usually B- or so. Not as good as a human could do, but usually not > so bad. More good enough for quite a few cases. For the test case that > started this thread, Synplify does just as good as any schematic tool > (or anything else) could do targeting Xilinx XC4000XL's: exceed the > speed of the internal RAMs. i would basically agree here, although i've heard too many people say, 'just specify constraints and the synthesizer will do the work.' nope. now, if i need some quick test circuitry and don't push speed or densiity but just want it to be logically correct and be done with it, for many circuits a B- is good enough (assuming you're over the so-called "learning curve" of the hdl and the tool and the tool's version). also note from previous post, that some circuits are so large that you'd want hdl (or some other cae tool) to do some work for you, as logic reduction/mapping by hand can be, well, not practical. otoh, giving the hdl control can give you the wrong answer; perhaps logically correct but a circuit that a human would not design for reliability reasons. ============================================ > I've also worked on designs that push the technology. B- isn't always > quite good enough. For the speed end of this, I have been able to meet > speed goals by starting with a pure behavioral design and improving it > where needed. The main tools to improve are floorplanning and/or > physical VHDL. Figure out what cells you need and where they need to > be, just as you do with a schematic, write a physical VHDL design with > fixed names, floorplan that section, and get the result you need. this sounds like more of a software development flow than a hardware flow, with software "timing" tools not being all that great. write your code in C or whatever, hook up the logic analyzer, run it, and see where it's taking too much time. then re-write that in assembly code, giving mixed hll/assembly software. here i would partially agree. for the most part, it's not that hard to see which blocks are going to be critical in speed or where you want to carefully control the implementation and those need further control. the other ones may be best off done in hdl, unless your synthesizer decides to participate in "hardware bloat," but that's another story. anyways, instead of messing with structural VHDL and typing in names for each component, which is incredibly tedious, it's easier and far more readable (imo) to do that with a schematic. then take a top level schematic, and hook up your blocks consisting of either lower level schematics or vhdl. an alternative, if one "draws" the same structural or mixed rtl/structural block over and over with perhaps some different options or widths or whatever, is to write a program to algorithmically generate the structural vhdl based on user input, with known labelling for each critical cell so you can easily talk to the other tools about your block. this is an area where we're spending quite a bit of time, since we can have a computer program write code that a human would not want to do by hand, or could not do by hand. it's also, we found out, a good method for letting the synthesizer chew on code written in different styles, as coding style can have a quite large effect on the so-called "quality of results." ===================================================== > For cost reduction, if you have the volume to care if the design is in a > part costing 4 US$ more or even 40 US$ more, perhaps a similar method > would work. Build it with pure behavioral code, find the space wasting > sections, hand map these as needed to fit into the cheaper part. The > initial design would allow for startup, with cost reductions following, > getting both a timely introduction (beating the handcrafted schematic > competition to market :-) ) and a reduction in cost as production > continues (allowing you to match the schematic competition's prices once > they do make it to market ;-) ). here i would, i think, agree a bit less. the 'fuss factor with hdl's, for many types of logic blocks, do not make them much if any faster than a schematic and can even by slower; that's one reason why i still do schematics and not a pure hdl flow. for some blocks hdl is faster. while i tend to do very low volume designs, with low spin count (preferably one), for high volumes, you may have some extra, hidden costs. supporting multiple versions of the design in the field, stocking multiple versions of a fpga type (different speed grades) or even different part numbers would complicate things, etc., etc. i did medium volume commercial a number of years ago, and designs that involved changes over time were supported, but were discouraged because of stocking costs, changing manufacturing instructions, service manuals, programming changes, parts lists, etc., etc., a bit of a ripple effect. just a few thoughts, rkArticle: 14613
On Sat, 6 Feb 1999 01:13:21 +0000, Edward Moore <edmoore@edmoore.demon.co.uk> wrote: >I've been doing exactly what you describe for the last two years, using >Exemplar Leonardo, and I know other people are doing it too. > >I've posted on this issue before, as have other people. In fact, a few >months back Evan from Riverside-machines posted the web address of some >VHDL examples he created for Synplicity, with a short tutorial. For anyone who's still interested: http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm I wrote the code for Leonardo, but I had a synplicity dongle for a couple of days, and I checked most (but not all) of it for Synplicity as well. I'm not sure from Ray's comments whether this covers exactly what he wants, though. The code uses generates to parameterise the width of a block, and it would be a simple extension to pass in generics to make this more general-purpose. IIRC, you posted a few months ago saying that you had a mechanism to calculate the size of a block in advance, and then to modify the placement of multiple blocks to take this into account - is that right? It sounds like you couldn't get any more general purpose than this. Ray - who don't you post some pseudo-code, or a more complete description, of a placement for a particular example? This should let us confirm whether or not it's possible in your case. >Which vendors have you approached ?. I gather FPGA Express can't cope, >due to poor old Synopsis only implementing a rather lame subset of the >VHDL language. I got user-defined attributes into the current 1076.6/Level 2 (the RTL synthesis standard), but it won't be out for about a year. We also need to make sure that they get passed through to the netlist; this should ensure that we can do this sort of thing with all tools... eventually... EvanArticle: 14614
On 5 Feb 1999 07:56:35 GMT, "Lars Fomsgaard" <lars_fomsgaard@danfoss.com> wrote: <snipped> I agree - I didn't mean to imply that the test wasn't relevant, just that you can't use the result of a test like this to decide that you shouldn't use a synthesiser. There are times when you have to use a synthesiser to meet cost and time-to-market goals - Phil had a good example (not to mention, of course, minimising that 10-input combinatorial function or recoding that state machine). If the synthesis screws up in some cases, then you have to know about it. If I understand correctly (?), the 2 main problems reported here didn't happen with Synplify targetting Xilinx. EvanArticle: 14615
On Fri, 05 Feb 1999 22:56:20 +0000, Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk> wrote: > PAR2SER_HF_PRO: process (CLK_LD_IN, CLK_SHIFT_IN) > begin > > if CLK_LD_IN'event and CLK_LD_IN = '0' then -- Load new data > > AUXIN <= DATA_IN; > > elsif CLK_SHIFT_IN'event and CLK_SHIFT_IN = '1' then -- convert >and output data > > AUXIN <= '0' & AUXIN(7 downto 1); > DATA_OUT <= AUXIN(0); > > end if; > > end process PAR2SER_HF_PRO; Think hardware. You're asking the synthesiser to produce a clocked element, which has (a) two clocks (one of which has a higher priority than the other), (b) one output which is loaded on both clocks, and (c) another output which is loaded on only the second clock, but only if there's no edge on the first clock. Your synthesiser doesn't create new clocked elements - stick with the hardware in your technology library. EvanArticle: 14616
Also make sure you have the latest XLA speed files for M1.5i. These can be downloaded from the Xilinx web site, and make a huge difference. The delays in the middle of the carry chains are almost half those reported in the initial releases of M1.5i. In article <79ggdt$l2d@bgtnsc02.worldnet.att.net>, Matt Bielstein <mbielstein@worldnet.att.net> writes >Asawaree, > >The reason you don't see the XLA technology is because it doesn't appear >until Synplify ver. 5.0.7. However, you really want to use ver. 5.0.8 >(current version as of this post) because Xilinx changed their speed grades. >That is, Synplicity 5.0.7 supports -2, -1 and -09 but ver 5.0.8 supports the >current -09, -08 and -07 grades. To make a long story short, upgrade your >software to 5.0.8. and life will be good. >By the way, Xilinx decided not to offer the XX4036XLA in a HQ304 package due >to the smaller die size of the XLA architecure. (Just an important safety >tip.) :-) > >I have had favorable results with Synplicity ver 5.0.8 and Xilinx M1.5i >using the XLA architecture. > >Hope this helps. > >Matt Bielstein > > >Asawaree Kalavade wrote in message <79ctas$d88@nntpa.cb.lucent.com>... >>Synplify/Xilinx4085XLA question >> >>I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP) >>device. >>I don't see the XLA series under technology. Is there a comparable >>technology/part I could use? (There is no 208 package for 4085 XL.) >> >>What am I missing here? >> >>thanks, >>asa >>kalavade@bell-labs.com > > -- Edward MooreArticle: 14617
Hmm, I evaluated both synplicity and exemplar a while back and could not get either to do it. I spent a good part of DesignCon this past week talking to both and pretty much got the same answer from the FAEs. Exemplar's FAE was the one that said that it wasn't the spirit of synthesis. Nevertheless, I plan on re-evaluating both in the coming weeks. I already am aware the FPGA express won't do it. I'm downloading Evan's page as I type. I was encouraged by synplicity...their FAE said that this capability is supported in the next release. Edward Moore wrote: > I've been doing exactly what you describe for the last two years, using > Exemplar Leonardo, and I know other people are doing it too. > > I've posted on this issue before, as have other people. In fact, a few > months back Evan from Riverside-machines posted the web address of some > VHDL examples he created for Synplicity, with a short tutorial. > > Which vendors have you approached ?. I gather FPGA Express can't cope, > due to poor old Synopsis only implementing a rather lame subset of the > VHDL language. > > It is ridiculous for these features to only be available on high'ish-end > Synthesis tools, when in fact no actual synthesis is involved. The tools > don't need to understand much, just pass attributes through to the > EDIF/XNF file. (though the ability to pass strings and booleans via > Generics helps). > > My commiserations on having to use the floorplanner, anyway. > > ****** > > The floor is now open for people to step in and tell me I should be > using schematics, even though I am completely happy with my approach, > and happier still that other people (ie competitors) haven't cottoned on > to its advantages. > > In article <36BB769C.6D41556E@ids.net>, Ray Andraka <randraka@ids.net> > wrote > >As most of you know, I prefer schematics for the type of designs I am > >usually involved in (heavily data path, high data rate DSP designs). I > >think a few additions to the HDL tools would make them alot more attractive > >in cases like mine. See the problem is in many cases, I already know what > >the optimal subcircuit is and what its placement needs to be. I'd like to > >use that circuit as a macro in an HDL, which I can do now by instantiating > >it as a black box. That doesn't buy me much though. What I really need is > >to be able to use a generate to create a parameterizable macro including a > >hierarchical relative placement. For example, I might want to create a > >CORDIC block which consists of a pair of cross-coupled adder-subtractor > >chains. I know from past experience how it needs to be laid out to get the > >maximum performance and density. The algorithm for the placement is fairly > >simple. I can code it structurally in the HDL and put no-touch attributes > >on it so I get the logic I want, but now I have to go into the floorplanner > >everytime I use the macro (including on different designs) to lay it out. > >Then I find I need to increase the width by a bit and I have to start all > >over. If the HDL folks would just give me the ability to do this low level > >design AND HIERARCHICAL placement, it would make HDLs alot more attractive > >in applications like these. The overwhelming response from the vendors: > >That is not the spirit of synthesis. How 'bout it guys, it seems like the > >hooks are there to do this, and it certainly would not have to be used by > >those who don't think they need it. > > > >Don Husby wrote: > > > >> thor@sm.luth.se (Jonas Thor) wrote: > >> > On Fri, 29 Jan 1999 22:05:42 GMT, husby@fnal.gov (Don Husby) wrote: > >> > Does really the synthesizer provide any information about where to > >> > place the flip-flops? From my experience the synthesizer only produces > >> > a netlist with primitives or macros. Then it is up to the placer to > >> > place the primitives/macros. > >> > >> You're right. Apparently what happened is that Synpicity generated > >> "replicated logic" and so had two flip-flops per signal. The Lucent > >> mapper had to place both flip flops in separate blocks. Replicated > >> logic was clearly uncalled for here, since the fanout was only 2-3 > >> loads. > > > > > > > >-- > >-Ray Andraka, P.E. > >President, the Andraka Consulting Group, Inc. > >401/884-7930 Fax 401/884-7950 > >email randraka@ids.net > >http://users.ids.net/~randraka > > > > > > -- > Edward Moore -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14618
Evan thanks. I've downloaded your page. I'm going to be running evals of both leonardo and synplicity again either next week or the following one. I will be looking specifically at this issue. ems@riverside-machines.com.NOSPAM wrote: > On Sat, 6 Feb 1999 01:13:21 +0000, Edward Moore > <edmoore@edmoore.demon.co.uk> wrote: > > >I've been doing exactly what you describe for the last two years, using > >Exemplar Leonardo, and I know other people are doing it too. > > > >I've posted on this issue before, as have other people. In fact, a few > >months back Evan from Riverside-machines posted the web address of some > >VHDL examples he created for Synplicity, with a short tutorial. > > For anyone who's still interested: > > http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm > > I wrote the code for Leonardo, but I had a synplicity dongle for a > couple of days, and I checked most (but not all) of it for Synplicity > as well. I'm not sure from Ray's comments whether this covers exactly > what he wants, though. The code uses generates to parameterise the > width of a block, and it would be a simple extension to pass in > generics to make this more general-purpose. > > IIRC, you posted a few months ago saying that you had a mechanism to > calculate the size of a block in advance, and then to modify the > placement of multiple blocks to take this into account - is that > right? It sounds like you couldn't get any more general purpose than > this. > > Ray - who don't you post some pseudo-code, or a more complete > description, of a placement for a particular example? This should let > us confirm whether or not it's possible in your case. > > >Which vendors have you approached ?. I gather FPGA Express can't cope, > >due to poor old Synopsis only implementing a rather lame subset of the > >VHDL language. > > I got user-defined attributes into the current 1076.6/Level 2 (the RTL > synthesis standard), but it won't be out for about a year. We also > need to make sure that they get passed through to the netlist; this > should ensure that we can do this sort of thing with all tools... > eventually... > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14619
In article <36bc4962.10840645@news.dial.pipex.com>, ems@riverside- machines.com.NOSPAM writes > >IIRC, you posted a few months ago saying that you had a mechanism to >calculate the size of a block in advance, and then to modify the >placement of multiple blocks to take this into account - is that >right? It sounds like you couldn't get any more general purpose than >this. The mechanism is: Each lower level module that generates RLOC'd components has a package with a function that can be called by a higher level module. The function is passed the same parameters that would be passed as generics to the lower level module, and returns the number of RLOC columns or rows used. These return values can then be used to RLOC the next module. For example, imagine a KCM module with generic data widths, in a huset starting at RLOC 0, 0. If you wanted to place an adder immediately after the KCM you would need to know how many columns the KCM used. First you instantiate the KCM with say a generic data with of 16 bits, then call get_kcm_size passing 16 as a parameter. get_kcm_size returns a value of 7, which you use to instantiate the adder in the same huset starting at RLOC 7, 0. It becomes the responsibilty of the person who writes an RLOC-able module to also include the corresponding get_size function. -- Edward MooreArticle: 14620
Try doing a little floorplanning. Also, keep in mind how the design will get implemented as you do the design. Try to avoid routing congestion. Now, if you are dealing with partial reconfiguration, you shouldn't be using synthesis. With partial configuration it is important that the pieces of the design that are to stay in-place remain untouched...this means implementation, placement and routing. This calls for a structural code, and is extremely tedious to do. Endric Schubert wrote: > i work in the field of reconfigurable computing and i will never get > used to the following message from my FPGA back-end tools: > > no placement/routing found ... > > or, if i was lucky enough, the tool found a fit after several hours. > but, c'mon, synthesizing the damn thing with a state-of-the-art tool > took a couple minutes! > > so i think its time to post something about this matter and see what the > net thinks about it: > > if you've done some serious FPGA designs, you probably know the facts of > routability: > > 1. re-running P&R doesn't help! > some algorithms are non-deterministic, so why not try one more time? > since for some FPGAs its worse than winning in a lottery! > > 2. decreasing device utilization doesn't help! > sometimes - especially when you have pin constraints - not even > decreasing it to a ridiculously low 50% helps! > > 3. there are no better P&R tools! > unfortunately, there is no 3rd party supply for P&R tools (unlike for > synthesis), so you're stuck with the vendors tools. and their tools seem > not to be too concerned about routability. hey, they want to sell > silicon, and when they get you down to 50% device utilization, they'll > suceed! :-> > > 4. you cannot re-synthesize for improved routability! > knowing, that no synthesis tool supports "synthesis for routability" (at > least i don't know any), all you can do is switch off all the > optimizations (you're down at 50% device utilization so what do you care > about one more LUT?). or if you've optimized for area (delay), you now > optimize for delay (area). > > as an EDA developer i know that there are algorithms avail, that > estimate routability in synthesis, that can improve routability (e.g. > thru replication of logic, or running a different decomposition). also, > there are more decent P&R algorithms avail, than the ones you get with > your vendors P&R tool. > > all i want is a *robust* FPGA design flow, but why can't i buy any? > > my explanation is: there is no demand for it! > > Endric > > (speaking for himself, not for his employer) -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14621
On 6 Feb 1999 09:40:53 GMT, Hamish Moffatt <hamish@rising.com.au> wrote: >Koenraad Schelfhout <koenraad.schelfhout@alcatel.be> wrote: >> As far as I remember, the dual ports in the XC4000 seties (at least XL), >> had two ports. >> One port was read-only >> The other port could be either written or read > >> So I assume this suits your application >> (refer to the databooks of Xilinx for more info) > >The only mention of dual-port I could find on the Xilinx site was >in XC4000E and later devices -- I'm using XC4000, the suffix-less, >disowned version. > Why not duplicate a single-port memory? (Which is pretty much what the dual-port RAM cell does internally, so you won't be losing any efficiency) - BrianArticle: 14622
Hi, I think I've invented a neat circuit for a specialized digital PLL, and of course I want to keep it proprietary. So if I make a product using a Xilinx FPGA, the config bitstream can't be hidden from a competitor who gets his greedy hands on one. I assume that an outright copy is a copyright violation, so I'm not too worried about that. So here's the issue: Is it feasible that someone could decompile the stream and recover the circuit CONCEPT? Are there any tools to help them do this? Would it be easy, or an enormous task? (Yes, I could maybe patent it, but that's a nuisance... I'd rather just keep it a secret). John -- ********************************************************************h John Larkin, President phone 415 753-5814 fax 753-3301 Highland Technology, Inc 320 Judah Street jjlarkin@worldnet.att.net San Francisco, CA 94122 http://www.highlandtechnology.comArticle: 14623
If you really have invented something useful then patent it! Otherwise, stop whinning! John Larkin wrote: > Hi, > > I think I've invented a neat circuit for a specialized digital PLL, and > of course I want to keep it proprietary. So if I make a product using a > Xilinx FPGA, the config bitstream can't be hidden from a competitor who > gets his greedy hands on one. I assume that an outright copy is a > copyright violation, so I'm not too worried about that. So here's the > issue: Is it feasible that someone could decompile the stream and > recover the circuit CONCEPT? Are there any tools to help them do this? > Would it be easy, or an enormous task? > > (Yes, I could maybe patent it, but that's a nuisance... I'd rather just > keep it a secret). > > John > > -- > > ********************************************************************h > > John Larkin, President phone 415 753-5814 fax 753-3301 > Highland Technology, Inc > 320 Judah Street jjlarkin@worldnet.att.net > San Francisco, CA 94122 http://www.highlandtechnology.comArticle: 14624
Not to mention that one clock is used as rising edge and the other uses a falling edge! ems@riverside-machines.com.NOSPAM wrote: > Think hardware. You're asking the synthesiser to produce a clocked > element, which has (a) two clocks (one of which has a higher priority > than the other), (b) one output which is loaded on both clocks, and > (c) another output which is loaded on only the second clock, but only > if there's no edge on the first clock. Your synthesiser doesn't create > new clocked elements - stick with the hardware in your technology > library. > > Evan -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>
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