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 Georg, This could be the reason as well. However, do you know any source how exactly DRAMS works ? Especially about the timing what the dram does to any specific time? I actualy didn't know, after selecting the correct address (ras/cas), the dram selects a line and modify only particular bit on the line. After this it writes it back to the array. But some how it make perfect sense. regards roman Georg Acher wrote: > > In article <37394D92.7080B6C0@Sun.COM>, roman pollak <roman.pollak@Sun.COM> writes: > |> I'm currently develope a graphic interface for my 68040 board at home > |> using FPGA and VDRAM. > |> But I got a very fancy problem with it, which I can't get of it. > |> When the CPU is writing to the RAM, sometimes it also overwrite other > |> locations as well. > |> For example when the cpu is writing on the line X pos Y, it overwrites > |> also some other location on the same line. Could it be some kind of > |> reflection problem? Or some other effects, which I don't know about it? > |> I saw in other designs, they use resistors between DRAM and Mux on the > |> address lines. But some other designs don't. Some use thouse on RAS/CAS, > |> some don't. What is the point of thouse resistors? > > The resistors are some sort of series termination to avoid reflections, > especially useful on RAS/CAS. Modern DRAM can react so fast that they interprete > the RAS ringing as access termination and start. Since the DRAM had no time to > write its line buffer back (precharge), the whole line can be destroyed. The > problem you have is possibly a similar effect: If you violate the RAS-low > access time or the precharge time, you will get everything from one-bit-failures > to 4096bit-failures. > Try to relax the timing a bit... > -- > Bye > Georg Acher, acher@in.tum.de > http://www.in.tum.de/~acher/ > "Oh no, not again !" The bowl of petuniasArticle: 16301
I am looking at storing several bitstreams in a Flash part on an embedded processor board and I would like to consider compression of the data to save space. I seem to recall this topic being discussed here several months ago. I am planning on using the Lucent OR3T and OR2T parts which should be substantially similar to the XC4000 series. Has anyone looked at a method of compression which is easy to implement, uses a small amount of code, and runs quickly? Although I will have enough RAM available for temporary storage, I would prefer to not have to decompress the entire block of data. However, this is a secondary requirement and the other results are more important. What degree of compression is resonable given these constraints, 2:1, 5:1, 20:1? -- Rick Collins rick.collins@XYarius.com remove the XY to email me.Article: 16302
Nova Engineering has just the board you are looking for. Check out the
Constellation board at:
http://www.nova-eng.com/constellation.html
Edwin Grigorian
Carl Martin wrote in message <926356074.143.100@news.remarQ.com>...
>Looking for a 10k Altera prototype board with a
>pc104 or PC-isa or PC-pci interface on one side
>and maximum number of io pins on the other side.
>
>Found one from Nova engineering www.nova-eng.com
>are there others
>
>
>Thanks
>Carl R. Martin
>cmart@hypercon.com
>
>
>
Article: 16303Rickman wrote: <snip> > I am looking really hard at using an OR3T chip for the main FPGA on a > board I am designing and I would like to find out how you like the > software. I have read the data sheet on both the OR2t and OR3T parts and > like the chips alot, but I haven't had time yet to play with the > software. > > I have been using the Xilinx parts off and on for several years. I also > did a design once using an OR1C (ATT1C?) part. At that time the ODS > tools (as well as the Xilinx) were really pretty bad. The current Xilinx > tools are much improved over what they were even just a couple of years > ago. Can you compare the current Lucent tools with the current Xilinx > tools? > > Can you offer any cavets or point out any special bonuses to using the > Lucent tools over the Xilinx tools? > > For example, how do they handle timing constraints? Do they use a > constraints file like Xilinx? Or do they have some sort of GUI as the > latest Xilinx software supports? > The Lucent and Xilinx tools are very similar to each other, as they are based on the old NeoCad stuff. The Lucent tools accept constraints ( .prf preference file, similar to Xilinx .ucf) and can parse most of them right from the EDIF file into the preference file. The Lucent tools do not have a GUI in the same sense as the Xilinx tools do (and I consider that a good thing.... boy do I hate that Xilinx GUI!). What they do have is a GUI "shell" (descended from the Unix version) for each step, i.e. a map shell (mapsh), p&r (parsh), and bitgen (bitsh) where you select the options you want at each step (or load them from a previously saved .opt option file). The shell then executes the tools on the command line. Nice thing about that is you can easily determine what the commands and arguments are so you can wrap them into a DOS batch file or a make script. Like anything else they have come a long way but still show the occasional bugs. I don't really have a preference tool wise. I find Xilinx Tech support to be better, but like the 3T architecture better than 400XL. Just my $0.02 -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 16304
Hi. I heard that Motorola launched the FPGA which following the Xilinx XC6200 series.but can;t see the chip unitl now. Please know me how the project is going !!!! Thanks.Article: 16305
It's dead. In article <373e5df2.95932951@news.kreonet.re.kr> rubi@165.246.73.60 (Yoo) writes: > >Hi. > >I heard that Motorola launched the FPGA which following the Xilinx > >XC6200 series.but can;t see the chip unitl now. > >Please know me how the project is going !!!! > >Thanks. >Article: 16306
On Thu, 13 May 1999 15:58:11 GMT, Timothy Miller <tim@techsource.com> wrote: >I would like a trivial example of a circuit written in Verilog that can >be synthesized with Exemplar and loaded onto a Xilinx part. I just need >something that shows typical pin instantiations, etc. You do not do pin instantiation, buffer insertion, pin numbering, and most other device specific stuff in your Verilog. That is what the constraint editor and resulting control file is for. Instantiation of buffer types etc. is just regular structural port-mapping of a cell in Verilog so should not hold any surprises. >I have searched both Exemplar's web site and Xilinx's web site and have >found nothing of the sort. Try looking in the "demo" directory in your Spectrum installation directory. Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 16307
The approach Jamie specified works quite well. We had an I2C module running in a 4036xl. The rise time on I2C signals is spec'd at 2-300 ns and we found that the circuit was flakey. Simulations didn't help a bit and showed perfect functionality. After adding the low pass filter things got dramatically more reliable (I'd say the problem was fixed). My colleague located the Xilinx app note that described the same solution as outlined by Jamie. Whether this was a metastability problem or simply a problem of slow rise time isn't clear. (Nor do I really care.) Jamie Sanderson wrote: > > Add one or two stages to your flip-flop chain, bring it to three or four. > Then take all of the outputs to two logic functions, one which causes the > output to be high only when all flip-flop outputs are high, and one which > causes the output to be low only when all flip-flop outputs are low. That > output signal can also be run through a final flip-flop. > > It slows your signal down considerably, but acts like a low-pass filter. > > Cheers, > Jamie > -- Tim Davis Timothy Davis Consulting TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023Article: 16308
Yoo wrote: > Hi. > > I heard that Motorola launched the FPGA which following the Xilinx > > XC6200 series.but can;t see the chip unitl now. > > Please know me how the project is going !!!! > Motorola announced and even shipped a family of fine-grained SRAM-based FPGAs with a strong similarity to the Atmel and XC6200 devices. Motorola has cancelled that program a while ago, and Xilinx stopped manufacturing XC6200. The fine-grained architecture has not found wide acceptance. Peter AlfkeArticle: 16309
Yoo wrote: > Hi. > > I heard that Motorola launched the FPGA which following the Xilinx > > XC6200 series.but can;t see the chip unitl now. > > Please know me how the project is going !!!! > Motorola announced and even shipped a family of fine-grained SRAM-based FPGAs with a strong similarity to the Atmel and XC6200 devices. Motorola has cancelled that program a while ago, and Xilinx stopped manufacturing XC6200. The fine-grained architecture has not found wide acceptance. Peter AlfkeArticle: 16310
Rickman wrote: > > I am looking at storing several bitstreams in a Flash part on an > embedded processor board and I would like to consider compression of the > data to save space. I seem to recall this topic being discussed here > several months ago. I am planning on using the Lucent OR3T and OR2T > parts which should be substantially similar to the XC4000 series. > > [...] Yes boy, have a look at http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html ArminArticle: 16311
Olaf Birkeland wrote in message
<01be9deb$eeaf64e0$0801a8c0@pascal.fast.no>...
>RAS/CAS *must* come directly from a register to be reliable in a FPGA due
>to variations in routing between different synthesis runs, and even
>process variations. I made the fault of generating RAS/CAS by decoding the
>state machine registres in my first controller design (...some years
>ago...), and got errors very similar to the ones metioned ("random"
>destruction of data when doing an access).
>
>The cause was sub 1ns spikes in the RAS signal that sometimes occurred
>inbetween state changes. Took me quite some time (and a good scope!) to
>identify the cause. These did not show up in simulations, as these only
>covered worst case delays.
>
>If your FPGA allows it, also place the RAS/CAS registers in the I/O block
>to get much better control of the timing.
Also register the address bus outputs. That's a lesson learned the hard
way, too.
-- a
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu
"Space, reconnaissance, weather, communications - you name it. We use space
a lot today."
-- Vice President Dan Quayle
Article: 16312
Andy Peters wrote:
>
> Olaf Birkeland wrote in message
> <01be9deb$eeaf64e0$0801a8c0@pascal.fast.no>...
> >RAS/CAS *must* come directly from a register to be reliable in a FPGA due
> >to variations in routing between different synthesis runs, and even
> >process variations. I made the fault of generating RAS/CAS by decoding the
> >state machine registres in my first controller design (...some years
> >ago...), and got errors very similar to the ones metioned ("random"
> >destruction of data when doing an access).
> >
Agreed.
> >The cause was sub 1ns spikes in the RAS signal that sometimes occurred
> >inbetween state changes. Took me quite some time (and a good scope!) to
^^^^^^^^^^^^^^^^
> >identify the cause. These did not show up in simulations, as these only
> >covered worst case delays.
> >
> >If your FPGA allows it, also place the RAS/CAS registers in the I/O block
> >to get much better control of the timing.
>
> Also register the address bus outputs. That's a lesson learned the hard
> way, too.
In general, I disagree with this one. Setup and hold times for address
WRT RAS and CAS will generally require extra delay in the asynchronous
DRAM access cycle. I suspect that there were better solutions to
whatever problem that you were trying to solve. There are, I am sure,
cases where registering the address lines is a useful technique, but I
would never suggest this as a general solution.
But in any case, I strongly suggest the use of an oscilloscope to
actually observe the circuit in action.
>
> -- a
> ------------------------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters@noao.edu
>
> "Space, reconnaissance, weather, communications - you name it. We use space
> a lot today."
> -- Vice President Dan Quayle
--
Phil
Article: 16313
Ray-
This is what I mean by tools changing from release to
release. FPGA Express has supported user attributes
since 3.0 was released six months ago. I include an
example below showing how an RLOC property assigned in
a structural VHDL design and passed to Xilinx place
and route.
Of course, I'm a little surprised that this is the
criterion by which you judge a synthesis tool. The
whole reason for doing synthesis is to get away from
technology-specific, structural designs. If you need to
design this way, then the visual appeal of schematics
make more sense than VHDL, but let's not get into a
religious debate.
What I look for in synthesis is: 1) library coverage
(you can't synthesize what you can't target), 2) quality
of results, and 3) language support. There are other
things that are important, like ease of use, price, and
runtime performance, but these are the three biggies.
I've had experience with Leonardo (which also supports
user attributes), Synplify, and FPGA Express and can
honestly say that all three are competitive with regard
to libraries, performance, and language. With each new
release of any one of these tools, the library coverage
improves, the quality of results improves, and language
features are enhanced.
Over the last two years, the biggest improvements have
been in FPGA Express (although I may be suspect because
I resell it). Two years ago this tool was fourth in a
four man race -- even Aurora (derived from ViewSynthesis)
had better libraries and results. Today, FPGA Express
rivals Exemplar and Synplicity in supported vendors and
devices and Altera claims that only FPGA Express can
handle the new APEX20K family (but I'm sure that this will
change with the next releases of Leonardo and Synplify).
In terms of quality of results, I've seen the latest version
of FPGA Express (3.1) improved area and delay by over 30%
from the 2.x releases. FPGA Express (or, rather, the FPGA
synthesis competition) has also driven many language
enhancements into the Synopsys subset.
Synopsys has had to do a lot of catch up with FPGA Express.
They got into the FPGA synthesis game very late, but they
have a lot of resources and very clever people to throw
at this problem. I can send you an eval copy if you like.
Regards,
-Jim
Passing attributes to place and route
------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity testmac is
port (D, CLR, CE, C : in std_logic; Q : out std_logic);
end testmac;
architecture struct of testmac is
component FDCE is
port (D, CLR, CE, C : in std_logic; Q : out std_logic);
end component;
attribute RLOC : STRING;
attribute RLOC of U1 : label is "R1C0.FFY";
begin
U1 : FDCE port map (D, CLR, CE, C, Q);
end struct;
Ray Andraka wrote:
> FPGA express is not currently as capable as SYnplicity and Exemplar, at least
> from a standpoint of creating relatively placed macros. I do alot of structural
> instantiation with relative placement to get the performance and density I
> need. I previously was constrained to schematics to do this, but with the
> capability to support and pass user attributes through to the EDIF output, I
> know I can get the results I need from Synplicity, and while I haven't tried it
> in exemplar, I understnd their tool will do it too. FPGA express definitely
> does not.
>
> Jim Kipps wrote:
>
> > Different tools deliver different results. Different versions of the same
> > tool will also give different results. Further, the results can vary by the
> > type of design, style of VHDL coding, and target vendor and device.
> >
> > You received other emails pointing you towards Synplify from Synplicity
> > and Leonardo from Exemplar. You should also look at FPGA Express,
> > which is engineered by Synopsys and distributed through Viewlogic,
> > VeriBest and Xilinx. You can go to the Viewlogic (www.viewlogic.com)
> > to get evaluation software; you can also get evaluation software from
> > VeriBest and Xilinx.
> >
> > Regards,
> > -Jim
> >
> > Tippawan Aranwattananon wrote:
> >
> > > I have design a small core in VHDL and I would like to know if I use
> > > difference tools to synthesize my VHDL code, will the numbers of CLB from
> > > those tools be difference.
> > > And if you know any excellent tools for synthesize please recommend.
> > >
> > > realk@thaimail.com
> >
> > --
> > --------------------------------------------------------
> > James R. Kipps FPGA Marketing Manager
> > jkipps@viewlogic.com Phone: (508) 303-5246
> > --------------------------------------------------------
>
> --
> -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
--
--------------------------------------------------------
James R. Kipps FPGA Marketing Manager
jkipps@viewlogic.com Phone: (508) 303-5246
--------------------------------------------------------
Article: 16314In article <373CDE27.B8F24A8C@viewlogic.com>, Jim Kipps <jkipps@viewlogic.com> writes: > What I look for in synthesis is: 1) library coverage > (you can't synthesize what you can't target), 2) quality > of results, and 3) language support. There are other > things that are important, like ease of use, price, and > runtime performance, but these are the three biggies. I think that library coverage is a great goal, but what I really want is to be able to add or modify things in the library to make them do what I really need this time. Alternatively, I want to be able to get a higher quality result by making a libary element that fits the device I'm using today better that the ones provided. -- These are my opinions, not necessarily my employers.Article: 16315
> It is a good suggestion but I have some limitations as far as how fast I can > go in digital domain. The data rates are as high as 8Mbits. The highest I > can use in my system will be at 60 MHz. You can process things 2 (or more) bits at a time if you can find a 2x clock to sample the input data. The falling edge of the main clock will work if your clock duty cycle is tight enough. -- These are my opinions, not necessarily my employers.Article: 16316
> My digital design books don't cover synchronizers in detail. So I am > asking here and hoping for feedback. Basically I have an asynchronous > input signal and I want to synchronize this to the FPGA clock. This > can of course be done by simply sampling the signal with an input > flip-flop and depending on the clock rate and the characteristic of > the flip-flop I can estimate a MTBF. But how do I reduce this MTBF by > designing synchronizer? I know I can cascade two flip-flops, but are > there other/better ways? Here is the way I think about that area... The key idea is settling time. The MTBF gets exponentailly better if you want longer. The exponential is very important. You want to do everything you can to make that time longer. For the simple case of FF-FF, the settling time is the clock cycle time minus the clock-output time of the first FF, minus the routing time minus the setup time of the second FF. So the first thing to make sure you don't do is put the FFs on opposite sides of the chip and eat up a lot of settling time by going through lots of routing. Similarly, don't put any logic in between the FFs - the prop time through that logic would subtract from the settling time. Of course, if you have lots of extra time, then you can put logic in there (perhaps saving a whole cycle later on) as long as the MTBF is still good enough. With FPGAs, there is often a "free" layer of logic available. If the MTBF of the basic FF-FF circuit isn't good enough, then you can either find a slower clock (to get more settling time) or go FF-FF-FF... FF-FF-FF takes two cycles but doesn't work as well (lower MTBF) as FF-FF at half the clock speed because the setup and clock-output and routing times of the middle FF get subtracted off the (doubled) clock time. If anybody suggests some kludge circuit that will "solve" the problem and prevent metastability you should send them back to school or try to get them a job working for somebody else. Usually they make the MTBF worse and harder to analyze. -- These are my opinions, not necessarily my employers.Article: 16317
> Either way, I still think that two flip-flops chained together will give you > all the protection from metastability that is needed. Of course, I say this > from my perspective only, I'm not designing equipment for life support or > anything like that. How can you say that without knowing more about the system timing? With modern/fast FPGAs, it's quite reasonable to build designs that run fast enough to invite problems if you don't think carefully about metastability. Yes, two FFs is the right solution in most cases but we need to be careful to understand when they aren't good enough and why. -- These are my opinions, not necessarily my employers.Article: 16318
Jim Kipps wrote: > Ray- > > This is what I mean by tools changing from release to > release. FPGA Express has supported user attributes > since 3.0 was released six months ago. I include an > example below showing how an RLOC property assigned in > a structural VHDL design and passed to Xilinx place > and route. Hallelujah! To be honest, I haven't looked at FPGA express since last fall. > > > Of course, I'm a little surprised that this is the > criterion by which you judge a synthesis tool. The > whole reason for doing synthesis is to get away from > technology-specific, structural designs. If you need to > design this way, then the visual appeal of schematics > make more sense than VHDL, but let's not get into a > religious debate. Agreed, however I have been playing with structural VHDL for generation of fairly complex DSP macros that want to be relationally placed. The VHDL gives me the ability to parameterize and generate; a capability which is not currently available for schematics. It also allows me to still produce designs that push the capability of the silicon for those customers who want nothing to do with schematics (you know who you are). > > > What I look for in synthesis is: 1) library coverage > (you can't synthesize what you can't target), 2) quality > of results, and 3) language support. There are other > things that are important, like ease of use, price, and > runtime performance, but these are the three biggies. > These are all important too, although none of them currently give me the quality of results I need for some of my higher data rate designs (some data rates exceeding 100MSPS) without resorting to structural coding with placement. Library coverage for the major vendors seems to have been be pretty even. Sure one of you gets the new device out a few weeks before the others, but then the next new device belongs to another one of you first. The library coverage issue is for the most part really only an issue for the people using the less common devices like Atmel. Language support also has been pretty much neck and neck between exemplar and synplicity. You guys were way behind when I last looked, but again, I'll have to look at your new release to see where you stand. Full support of unconstrained vectors in the port list is a biggie for me. > I've had experience with Leonardo (which also supports > user attributes), Synplify, and FPGA Express and can > honestly say that all three are competitive with regard > to libraries, performance, and language. With each new > release of any one of these tools, the library coverage > improves, the quality of results improves, and language > features are enhanced. > > Over the last two years, the biggest improvements have > been in FPGA Express (although I may be suspect because > I resell it). Two years ago this tool was fourth in a > four man race -- even Aurora (derived from ViewSynthesis) > had better libraries and results. Today, FPGA Express > rivals Exemplar and Synplicity in supported vendors and > devices and Altera claims that only FPGA Express can > handle the new APEX20K family (but I'm sure that this will > change with the next releases of Leonardo and Synplify). > In terms of quality of results, I've seen the latest version > of FPGA Express (3.1) improved area and delay by over 30% > from the 2.x releases. FPGA Express (or, rather, the FPGA > synthesis competition) has also driven many language > enhancements into the Synopsys subset. > > Synopsys has had to do a lot of catch up with FPGA Express. > They got into the FPGA synthesis game very late, but they > have a lot of resources and very clever people to throw > at this problem. I can send you an eval copy if you like. > > Regards, > -Jim > > Passing attributes to place and route > ------------------------------------ > library ieee; > use ieee.std_logic_1164.all; > > entity testmac is > port (D, CLR, CE, C : in std_logic; Q : out std_logic); > end testmac; > > architecture struct of testmac is > component FDCE is > port (D, CLR, CE, C : in std_logic; Q : out std_logic); > end component; > attribute RLOC : STRING; > attribute RLOC of U1 : label is "R1C0.FFY"; > begin > U1 : FDCE port map (D, CLR, CE, C, Q); > end struct; > > Ray Andraka wrote: > > > FPGA express is not currently as capable as SYnplicity and Exemplar, at least > > from a standpoint of creating relatively placed macros. I do alot of structural > > instantiation with relative placement to get the performance and density I > > need. I previously was constrained to schematics to do this, but with the > > capability to support and pass user attributes through to the EDIF output, I > > know I can get the results I need from Synplicity, and while I haven't tried it > > in exemplar, I understnd their tool will do it too. FPGA express definitely > > does not. > > > > Jim Kipps wrote: > > > > > Different tools deliver different results. Different versions of the same > > > tool will also give different results. Further, the results can vary by the > > > type of design, style of VHDL coding, and target vendor and device. > > > > > > You received other emails pointing you towards Synplify from Synplicity > > > and Leonardo from Exemplar. You should also look at FPGA Express, > > > which is engineered by Synopsys and distributed through Viewlogic, > > > VeriBest and Xilinx. You can go to the Viewlogic (www.viewlogic.com) > > > to get evaluation software; you can also get evaluation software from > > > VeriBest and Xilinx. > > > > > > Regards, > > > -Jim > > > > > > Tippawan Aranwattananon wrote: > > > > > > > I have design a small core in VHDL and I would like to know if I use > > > > difference tools to synthesize my VHDL code, will the numbers of CLB from > > > > those tools be difference. > > > > And if you know any excellent tools for synthesize please recommend. > > > > > > > > realk@thaimail.com > > > > > > -- > > > -------------------------------------------------------- > > > James R. Kipps FPGA Marketing Manager > > > jkipps@viewlogic.com Phone: (508) 303-5246 > > > -------------------------------------------------------- > > > > -- > > -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 > > -- > -------------------------------------------------------- > James R. Kipps FPGA Marketing Manager > jkipps@viewlogic.com Phone: (508) 303-5246 > -------------------------------------------------------- -- -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: 16319
I'm designing a ISA and PCI card.However,I need a testbench to generate all signals.Thank for any info. -- Posted via Talkway - http://www.talkway.com Exchange ideas on practically anything (tm).Article: 16320
I know Motorola dismissed any activity on FPGAs On Fri, 14 May 1999 17:35:57, rubi@165.246.73.60 (Yoo) wrote: > > Hi. > > I heard that Motorola launched the FPGA which following the Xilinx > > XC6200 series.but can;t see the chip unitl now. > > Please know me how the project is going !!!! > > Thanks. > Damiano Rullo Trezzano S/N Milan, Italy http://members.it.tripod.de/Damianoux/index.html mailto: dmn@cheerful.com mailto: damiano@mclink.itArticle: 16321
In article <373CBABF.768BD300@nospam.ix.netcom.com>, pjs3@nospam.ix.netcom.com says... [snip] > But in any case, I strongly suggest the use of an oscilloscope to > actually observe the circuit in action. But make sure the probe capacitance doesn't swallow the spikes you're looking for! I'm sure we've all had problems where the act of measurement makes the effect go away :-) -- Steve Rencontre - Design Consultant http://www.rsn-tech.demon.co.uk/Article: 16322
Ray Andraka wrote in message <373B97D6.98A5BAE3@ids.net>... >FPGA express is not currently as capable as SYnplicity and Exemplar, at least >from a standpoint of creating relatively placed macros. I do alot of structural >instantiation with relative placement to get the performance and density I >need. I previously was constrained to schematics to do this, but with the >capability to support and pass user attributes through to the EDIF output, I >know I can get the results I need from Synplicity, and while I haven't tried it >in exemplar, I understnd their tool will do it too. FPGA express definitely >does not. I recently downloaded the FPGA Express 3.1 upgrade to Xilinx Foundation Express from the Xilinx website. Attribute passing is described in http://www.xilinx.com/techdocs/4392.htm. Alas, my hopes for explicitly floorplanned datapaths, via structural Verilog, via RLOC attributes on FMAP primitives, were dashed when I found that my explicitly instantiated FMAPs were swallowed by FPGA Express and were not copied into the output netlist. This is explained in http://www.xilinx.com/techdocs/4395.htm. As a workaround, I created a schematic macro named FMAP_, which contains a single FMAP primitive with an RLOC=R0C0 attribute, exported it as EDIF, and instantiated those through structural Verilog, applying RLOC attributes to my FMAP_ macros. Express kindly passes these through to my output netlist. With this technique, I was able to build a test section of a datapath with the right relative placement. However, if I recall correctly, when explicitly instantiating other device primitives, like INV, Express would sometimes emit its own FMAPs which covered the same nets as mine. This led to map failure. So, I defined and used my own INV_ macro instead, and this suppressed the undesired FMAPs on INVs. But this way lies madness. (If I am mistaken, or have overlooked something obvious, please let me know!) In other experiments, I tried something like an assign plus an FMAP assign o = ... a ... b ... c ... d ... ; FMAP_ fmo(.I1(a), .I2(b), .I3(c), .I4(d), .O(o)); //synopsys attribute RLOC "R0C0" but my fmo/fmap covered the same nets as the unattributed FMAP that Express emits for the assign, and again map fails. I briefly contemplated post-processing Express output netlists to either 1) remove Express FMAPs that covered my RLOC'd FMAPs, or 2) remove my FMAPs but propagate their attributes to the equivalent Express generated FMAPs, but this way too lies madness. (Maybe it would be nice if, as with my custom netlist generator, an assign which could be covered by a single FMAP could be attributed: assign o = ... a ... b ... c ... d ... ; // FMAP attribute RLOC "R0C0" but maybe not.) This is "pushing on a rope". You know exactly what you want -- a particular optimal, hand-mapped, hand-placed layout for your datapath -- but the tools get in the way, and you spend hours trying to discover an incantation that persuades the tools to emit the desired result. Do Synplicity or Exemplar honor explicit instantiations of FMAPs, and enable them to be attributed with RLOC constraints? If you will indulge me, here are two desiderata for FPGA and synthesis tools vendors to consider. HDL Floorplanning Desiderata 1. there should be straightforward way to take a schematic and write an equivalent structural HDL module. (Corollaries: 1.a. If I can specify attributes on components and nets in the schematic, then I can also attach them to the instances and nets in the structural HDL. 1.b. Just as with a schematic, if I DO instantiate a component, DO emit it to the netlist. 1.c. Just as with a schematic, if I DON'T instantiate a component, DON'T unhelpfully create one from whole cloth and emit it to the netlist.) 2. that way (1) should be standard across vendors Somehow I doubt that '//synopsys attribute RLOC "R0C0"' is going to have the desired effect when my design is built with Synplicity. While I admire synthesis vendor extensions which deliver new innovations, the issue of passing attributes seems so fundamental to quality FPGA design that I hope the FPGA and synthesis vendors can work together to define a common notation. Jan GrayArticle: 16323
Mark Summerfield <m.summerfield@ee.mu.oz.au> writes:
[...]
> On the other hand, I know very few engineers of any age who are
> socialists...
I know quite a few who are...
What was your point again?
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 16324Personally, I'm working on dynamic reconfiguration (PoliMorph Project, Politecnico of Milan), i.e. exactly what you guys are talking about. Despite the loads of projects in this promising field, though, I always notice that everybody neglects what I deem the most important problem of all. Steve himself pointed out that "the SW IS the computer", but maybe he forgot the implications: the biggest hurdle here is *not* the reconfigurable array (today's Xilinx could already provide us with outstanding results, were we able to use them fully), but a suitable and overall automatic way to take advantage of the beast. I mean, everybody can imagine a computer that goes on reconfiguring the FPGA on the fly and boosting performance like crazy, but as long as we don't have a sort of compiler that gets a standard C++ code or whatever and understands what portions of the code are to be implemented in Hardware and how, our vision will just remain what it is... a vision. That's why we at the Politecnico are working on the compiler better than on hardware issues: right now we already have a way to identify (in a standard C code) interesting portions (we called them MISO, for Multiple In Single Out, since they are kind of a generalization of a "normal" RISC instruction, where you have a number of input operands but just one output), we have a way to assess their value (GAIN heuristic, Gross Advantage INdex), and we're developing a genetic algorithm that, working on the Control Flow Graph and considering reconfiguration penalties, substitution policies and so forth, decides which MISOs should be implemented in hardware for real (GENIUS, GENetic Identification of Useful Superinstruction). It's REAL tough, I'm telling you, and that's why I'm all too convinced that here lies the S. Graal of reconfigurable computing. Remember, Steve, "the software IS the computer"... Aside from that, you can find info about DPGAs in the MIT web site: it was DeHon's PhD Dissertation. Guido Meardi
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