Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi.
I was wondering if anyone could help me out regarding an implementation
issue I have run into when using Xilinx Foundation F1.5.
I have implemented a design with the new F1.5 version and the results
were worse than with F1.4 (the opearting frequency dropped by a few
MHz). I also noticed a difference in implementation statistics going
from M1.3 to F1.4 to F1.5 as well.
I have used Synplify 5.06 to synthesize my VHDL code and to instantiate
some core generator black boxes (do I need to regenerate my F1.4 cores
with the new core generator 1.5?). The same XNF file was used for all
versions of the Foundation tools and targetted a xc4028EX-3HQ240 part.
I have also written a user constraint file (UCF) with basic clock period
and pin locking attributes in order to meet a required performance
(thanks to everyone who explained some of the constraints to me). All
the constraints remained the same for all implementations.
Anyhow, here are the results I got when going from one version to the
next (please see the end to see my conclusions):
->M1.3 (UNIX) :
-before place and route :
Minimum period: 5.496ns (Maximum frequency: 181.951MHz)
Maximum path delay from/to any node: 27.141ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 5.496ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 27.141ns
-after place and route :
Minimum period: 23.752ns (Maximum frequency: 42.102MHz)
Maximum path delay from/to any node: 37.324ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 23.752ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 37.324ns
->F1.4 (PC) :
-before place and route :
Minimum period: 5.496ns (Maximum frequency: 181.951MHz)
Maximum path delay from/to any node: 27.000ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 5.496ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 27.000ns
-after place and route :
Minimum period: 29.991ns (Maximum frequency: 33.343MHz)
Maximum path delay from/to any node: 54.635ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 29.991ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 54.635ns
->F1.5 (PC) :
-before place and route :
Minimum period: 27.000ns (Maximum frequency: 37.037MHz)
Maximum path delay from/to any node: 27.000ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 5.496ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 27.000ns
-after place and route :
Minimum period: 35.423ns (Maximum frequency: 28.230MHz)
Maximum path delay from/to any node: 35.423ns
Timing constraint:
TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ;
Minimum period is 21.653ns
TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ;
Maximum delay is 35.423ns
So based on these results, can I claim that design M1.3 will run at
42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why
does the older tool give a better result than the other two, and why
does the frequency degrade as the software gets better and better? It's
a little frustrating to see such behaviour when moving to an updated
version of the software.
It seems to me that for F1.5, the maximum frequency is determined by the
maximum delay based on the "FROM FFS TO FFS" constraint. In the
previous versions it was using the minimum period value (based on the
minimum clock net period, coming from the PERIOD constraint). I am very
curious to know why each design has a different operating frequency when
the design and the constraint files have not changed at all. The layout
of the placed design is also different between F1.4 and F1.5. Does
anyone know why this happens?
Also, for M1.5 I get this warning after running trace (trce) on the
routed design:
WARNING:bastw:544 - Clock nets using non-dedicated resources were found
in this design. Clock skew on these resources will not be automatically
addressed during path analysis. To create a timing report that analyzes
clock skew for these paths, run trce with the '-skew' option.
When I check in EPIC, the clock paths seem to be connected to the
dedicated net of the chip, and when I run the trce program with the
-skew option as they state I don't this warning, but the frequency is
still the same (28.230MHz).
Here's something I never thought could happen, but it did...
When I created the bitmap file using bitgen, I got a warning that an
antenna has been created and may be caused by an unrouted net or a stub.
All nets were routed so it seems like the second case applies. When I
view the placed and routed design in EPIC, indeed I see a route that is
just protruding out of the routed net. Any suggestions on how to
correct this type of problem.
Thanks in advance to anyone who can help me out with anything from the
above.
--
Nestor Caouras
nestor@ece.concordia.ca
http://www.ece.concordia.ca/~nestor/addr.html
|-------------------------------------------|
| Dept. of Electrical and Computer Eng. |
| Concordia University |
| 1455 de Maisonneuve Blvd (West) |
| Montreal, Quebec, Canada H3G 1M8. |
| Tel: (514)848-8784 Fax: (514)848-2802 |
|-------------------------------------------|
Article: 12276I forgot to mention that I manually instantiated a BUFG for the clock net and placed a constraint on the net at the output of the BUFG: fsa --> BUFG --> clk_net A constraint of 25ns was placed on clk_net, and one of 20ns FROM FFS TO FFS. Thanks for your help. Original Message Nestor Caouras wrote: > > Hi. > > I was wondering if anyone could help me out regarding an implementation > issue I have run into when using Xilinx Foundation F1.5. > > I have implemented a design with the new F1.5 version and the results > were worse than with F1.4 (the opearting frequency dropped by a few > MHz). I also noticed a difference in implementation statistics going > from M1.3 to F1.4 to F1.5 as well. > > I have used Synplify 5.06 to synthesize my VHDL code and to instantiate > some core generator black boxes (do I need to regenerate my F1.4 cores > with the new core generator 1.5?). The same XNF file was used for all > versions of the Foundation tools and targetted a xc4028EX-3HQ240 part. > I have also written a user constraint file (UCF) with basic clock period > and pin locking attributes in order to meet a required performance > (thanks to everyone who explained some of the constraints to me). All > the constraints remained the same for all implementations. > > Anyhow, here are the results I got when going from one version to the > next (please see the end to see my conclusions): > ->M1.3 (UNIX) : > -before place and route : > Minimum period: 5.496ns (Maximum frequency: 181.951MHz) > Maximum path delay from/to any node: 27.141ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.141ns > -after place and route : > Minimum period: 23.752ns (Maximum frequency: 42.102MHz) > Maximum path delay from/to any node: 37.324ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 23.752ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 37.324ns > > ->F1.4 (PC) : > -before place and route : > Minimum period: 5.496ns (Maximum frequency: 181.951MHz) > Maximum path delay from/to any node: 27.000ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.000ns > -after place and route : > Minimum period: 29.991ns (Maximum frequency: 33.343MHz) > Maximum path delay from/to any node: 54.635ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 29.991ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 54.635ns > > ->F1.5 (PC) : > -before place and route : > Minimum period: 27.000ns (Maximum frequency: 37.037MHz) > Maximum path delay from/to any node: 27.000ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.000ns > -after place and route : > Minimum period: 35.423ns (Maximum frequency: 28.230MHz) > Maximum path delay from/to any node: 35.423ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 21.653ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 35.423ns > > So based on these results, can I claim that design M1.3 will run at > 42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why > does the older tool give a better result than the other two, and why > does the frequency degrade as the software gets better and better? It's > a little frustrating to see such behaviour when moving to an updated > version of the software. > > It seems to me that for F1.5, the maximum frequency is determined by the > maximum delay based on the "FROM FFS TO FFS" constraint. In the > previous versions it was using the minimum period value (based on the > minimum clock net period, coming from the PERIOD constraint). I am very > curious to know why each design has a different operating frequency when > the design and the constraint files have not changed at all. The layout > of the placed design is also different between F1.4 and F1.5. Does > anyone know why this happens? > > Also, for M1.5 I get this warning after running trace (trce) on the > routed design: > > WARNING:bastw:544 - Clock nets using non-dedicated resources were found > in this design. Clock skew on these resources will not be automatically > addressed during path analysis. To create a timing report that analyzes > clock skew for these paths, run trce with the '-skew' option. > > When I check in EPIC, the clock paths seem to be connected to the > dedicated net of the chip, and when I run the trce program with the > -skew option as they state I don't this warning, but the frequency is > still the same (28.230MHz). > > Here's something I never thought could happen, but it did... > When I created the bitmap file using bitgen, I got a warning that an > antenna has been created and may be caused by an unrouted net or a stub. > All nets were routed so it seems like the second case applies. When I > view the placed and routed design in EPIC, indeed I see a route that is > just protruding out of the routed net. Any suggestions on how to > correct this type of problem. > > Thanks in advance to anyone who can help me out with anything from the > above. > > -- > Nestor Caouras > nestor@ece.concordia.ca > http://www.ece.concordia.ca/~nestor/addr.html > |-------------------------------------------| > | Dept. of Electrical and Computer Eng. | > | Concordia University | > | 1455 de Maisonneuve Blvd (West) | > | Montreal, Quebec, Canada H3G 1M8. | > | Tel: (514)848-8784 Fax: (514)848-2802 | > |-------------------------------------------| -- Nestor Caouras nestor@ece.concordia.ca http://www.ece.concordia.ca/~nestor/addr.html |-------------------------------------------| | Dept. of Electrical and Computer Eng. | | Concordia University | | 1455 de Maisonneuve Blvd (West) | | Montreal, Quebec, Canada H3G 1M8. | | Tel: (514)848-8784 Fax: (514)848-2802 | |-------------------------------------------|Article: 12277
In article <361BB37B.9540843C@synopsys.com>, Derek Palmer <derekp@synopsys.com> wrote: >Let's make rumor fact! >FPGA Express 3.0 will have VHDL 93 support. >Available on the Synopsys web site at the end of Oct. Great! Just like Metamor!! > >Derek Palmer >FPGA Express Team >Synopsys Corporation. > >Andy Peters wrote: > >> Hans Lindkvist wrote in message <3614BD09.E32A0E14@ldecs.ericsson.se>... >> Rickman wrote: >> Jake Janovetz wrote: >> One possibly big difference, depending on whether you have existing >> code, is that Synopsys does not support VHDL-93. They seem to be >> pretty >> stuck in VHDL-87. >> Otherwise, I can only stay that Synopsys is what comes with Xilinx >> Foundation, so a lot of Xilinx users have it! ;) >> >> I've heard from a Synopsys representative that vhdl-93 support is close. >> I just got the Xilinx Foundation 1.5 tools w/Synopsys FPGA Express, and >> there's support for *some* VHDL'93 things, like rising_edge() and >> falling_edge() and myprocess : process (yadda) IS. >> >> A start. >> >> -andy > > >Article: 12278
>michael_23@my-dejanews.com wrote: >> >> Hi all, >> I desperately need some help. I am doing my final year engineering >> project where I am designing a 16 bit Microprocessor. I am using the student >> version of Altera for this project, which gives me the EPF10K20RC240-4 device. > >...snip... In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com> writes: > snip >Or you can call Xilinx support at 800-624-4782. They may want you to >send them your design files to solve this. While Xilinx Tech support is well known for being helpfull, This problem is not likely to be something they can solve. :-) PhilipArticle: 12279
I'd emailed Altera to express my interest in someday having a version of Max+Plus II that runs under Linux. I figured I'd copy their reply for the sake of any interested parties out there. This is purely for the interested, I don't mean to imply any opinions on the letter's content (I'm feeling passive today). here 'tis... Hello Tim, I have documented your request for a Linux based Max+Plus II. We have looked into that option a bit, and the concensus was that there was not enough customer interest in Linux to make it a worthwhile investment. However, if more and more customers continue to request support for that operating system, it will eventually be looked at more seriously. One of the major problems with supporting Linux is the fact that there is no person or company who is responsible for supporting it. So if we made a version of software which would run on Linux and then there was an operating system problem----it would be our job to fix that, and we would have no Linux experts or designers to talk too. As far as I know, that fact and the lack of customer interest are the only reasons why such a version is not available right now. Thank you very much for the suggestion, it's always nice to know what else is needed in the market.. And please tell others who would like to see such support to e-mail us at sos@altera.com <mailto:sos@altera.com> so that their requests can be appropriately documented. Please feel free to contact me if you have more questions, or ideas about Linux based Max+PlusII. And remember that Altera Applications is always there to help you solve any problems you may experience with our products or software, don't hesitate to call them at 1800-800-EPLD if you are in need of support. Jeff Wimett Applications Engineer Altera Corporation E-mail: Jwimett@altera.com <mailto:Jwimett@altera.com> Phone: 1-800-800-EPLD ext. 4142Article: 12280
At the company I worked at, we looked at Exemplar, Synplicity, and Synopsys FPGA Express. I got the best and fastest design with Synplicity, Exemplar was a close 2nd. We ended up buying Exemplar because we got a good price when bundled with Model Tech's ModelSim. Both these products are very good and both have a path to ASIC design (though Exemplar is about 6 months ahead right now). FPGA Express was usable, but the results were not near as good as the other two. I have not looked at FPGA Express recently, but have heard its better now. You won't know until you try it on your own design. Rick Filipkiewicz <rick@algor.co.uk> wrote in article <361B7394.B3C009DF@algor.co.uk>... > Thanks for the various replies, it seems to be coming down to a choice > between Silos III and ModelSim with Fintronics on the outside [don't know > enough about it yet]. It seems that my $5K budget was a bit optimistic and > the sim. will probably come in about $7K. Still not bad in comparison with > a couple of years ago. > > Now there's the question of synthesis. Originally I was going to stick with > the Synopsis Express (***)I have as part of the Foundation package but I > do have the possible options of buying a synthesiser from Synplicity or > Exemplar [Leonardo]. Anybody have any comments on their quality ? > Particularly when Xilinx FPGAs are the target devices ? > > (***) BTW Does anybody know if a command line i/f has been added to > Foundation Express for the 1.5 release ? > > > >Article: 12281
Rick Filipkiewicz wrote in message <361B4477.C9F9BC62@algor.co.uk>... >Note that the PERIOD constraint on CLKx implies a From/To constraint of >the type: > > TSxx: FROM FFS(Connected to CLKx):TO:FFS(Connected to CLKx): 25 The "gotcha" with PERIOD is that you have to place it on the clock net AFTER the BUFGx, so you're outta luck if you're using VHDL (unless you want to look at the .xnf file and find out what the buffered clock net is called). It's noted in the timing constraints presentation that that little "feature" is a known problem that will be fixed eventually. -andy -- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 520-318-8191 apeters@noao.eduArticle: 12282
Nestor Caouras wrote in message <361BCC89.7FDD8B2D@ece.concordia.ca>... >Anyhow, here are the results I got when going from one version to the >next (please see the end to see my conclusions): >->M1.3 (UNIX) : > -before place and route : > Minimum period: 5.496ns (Maximum frequency: 181.951MHz) > Maximum path delay from/to any node: 27.141ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.141ns > -after place and route : > Minimum period: 23.752ns (Maximum frequency: 42.102MHz) > Maximum path delay from/to any node: 37.324ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 23.752ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 37.324ns Whoops! Look at the results for TS04 - you're constraining it to be 20 ns but the max delay is 37 ns! It didn't meet your timespec, so all bets are off! >->F1.4 (PC) : > -before place and route : > Minimum period: 5.496ns (Maximum frequency: 181.951MHz) > Maximum path delay from/to any node: 27.000ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.000ns > -after place and route : > Minimum period: 29.991ns (Maximum frequency: 33.343MHz) > Maximum path delay from/to any node: 54.635ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 29.991ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 54.635ns Still failing to meet your timespec here, too. > >->F1.5 (PC) : > -before place and route : > Minimum period: 27.000ns (Maximum frequency: 37.037MHz) > Maximum path delay from/to any node: 27.000ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 5.496ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 27.000ns > -after place and route : > Minimum period: 35.423ns (Maximum frequency: 28.230MHz) > Maximum path delay from/to any node: 35.423ns > Timing constraint: > TS01 = PERIOD TIMEGRP "fsa_grp" 25 nS HIGH 50.000 % ; > Minimum period is 21.653ns > TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS ; > Maximum delay is 35.423ns And here, too! >So based on these results, can I claim that design M1.3 will run at >42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why >does the older tool give a better result than the other two, and why >does the frequency degrade as the software gets better and better? It's >a little frustrating to see such behaviour when moving to an updated >version of the software. I don't think any of the frequencies given are valid, considering that your design doesn't meet the timing specs. >It seems to me that for F1.5, the maximum frequency is determined by the >maximum delay based on the "FROM FFS TO FFS" constraint. In the >previous versions it was using the minimum period value (based on the >minimum clock net period, coming from the PERIOD constraint). I am very According to that timing presentation (most recent version dated 7/28/98 and applicable to 1.5 tools) is that the timing priorities, from highest down, are: 1) FROM:THRU:TO (which you're not using) 2) FROM:TO (TS04) and then 3) PERIOD. I'm not sure what the previous order was. >curious to know why each design has a different operating frequency when >the design and the constraint files have not changed at all. The layout Again, the design fails to meet timing specs so who knows what's real? >of the placed design is also different between F1.4 and F1.5. Does >anyone know why this happens? Depends on a lot of things. Perhaps you've got it configured to do a more vigorous p & r (or less vigorous); maybe you've locked your pins down after the 1.3 implementation; maybe it's doing its best given that it's not meeting the design constraints in the first place. >Also, for M1.5 I get this warning after running trace (trce) on the >routed design: > >WARNING:bastw:544 - Clock nets using non-dedicated resources were found >in this design. Clock skew on these resources will not be automatically >addressed during path analysis. To create a timing report that analyzes >clock skew for these paths, run trce with the '-skew' option. Maybe you missed something? Schematic design or VHDL? >When I check in EPIC, the clock paths seem to be connected to the >dedicated net of the chip, and when I run the trce program with the >-skew option as they state I don't this warning, but the frequency is >still the same (28.230MHz). >Here's something I never thought could happen, but it did... >When I created the bitmap file using bitgen, I got a warning that an >antenna has been created and may be caused by an unrouted net or a stub. >All nets were routed so it seems like the second case applies. When I >view the placed and routed design in EPIC, indeed I see a route that is >just protruding out of the routed net. Any suggestions on how to >correct this type of problem. Check the design. -- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 520-318-8191 apeters@noao.eduArticle: 12283
As was mentioned earlier Fatal Error usually implies an Internal software error. I have actually come across some Fatal Erros in MAXPLUS2 8.1 when I was targetting a 10K20RC device. It turned out that I had multiple Always (verilog) blocks (more than 8) which used the same Clock signal. The CLK was not on a global CLK net and hence the partitioner bombed out on me for some reason. The way around this was to merge the Always (verilog) blocks. I would advise you to talk to Altera directly about this as they are very helpful. They will also try your design for you and tell you what options you will need to set. michael_23@my-dejanews.com wrote in message <6vftjf$52c$1@nnrp1.dejanews.com>... >Hi all, > I desperately need some help. I am doing my final year engineering >project where I am designing a 16 bit Microprocessor. I am using the student >version of Altera for this project, which gives me the EPF10K20RC240-4 device. >I have completed my design and I have been testing it as I go, so I know all >the components are working properly. Here is my problem, and it is a big >problem as the deadline is coming up very close and I am starting to panic. >I was going along fine until I hit this problem. Okay, so when I was at my >last step (I'm so close) when I was trying to compile the whole thing I got >the following error about half-way through compilation: >"Internal Error: (CMP) Fatal application error in Partitioner at 10%" > >Does anyone know what this means and what has caused it? > >I have done a LOT of fiddling around testing things and trying to figure >out the problem. I was thinking maybe I have run out of room on the device. >I broke the top level design up into 2 parts and compiled each one >seperately with no problems. When I looked at the report file, it says I >have used the following space: > >Mem bits Mem % LCs LCs % >4608 37% 597 51% First Half > >4096 33% 110 9% Second Half > >8704 70% 707 60% Total > >Looking at this, I have 30% of my memory bits free and 40% of my LCs free so >I shouldn't be out of room. >I am now thinking that maybe I have enough memory bits and LCs but not >enough connections between them free. Would this seem reasonable to you? I >was of the impression that you could use the memory bits without affecting >the use of the LCs and vice vera. That is by using some memory bits you >don't take room off the LCs. Is this right. > >As you can see I am in a horrible mess here and am in desperate need of a >solution. Does anyone know what I am doing wrong, and any ways of perhaps >fixing my problem? I would be eternally greatful. > >Perhaps there may be some way of changing the Global Logic Synthesis >settings that might use less space and allow me to fit it all on, or am I >completely on the wrong track here? > >If you have any suggestions at all, then can you PLEASE PLEASE send them to >me, even if you're not sure it'll work I'm willing to try everything. I've >tried all I can think of. > >Thanks so much, >Bruce. > >PS: I also checked the number of inputs and outputs, and they are all okay >too. > >PPS: Another thought, I wonder if there is a limit of the number of memory >elements I can use. It will let me use 3 RAM elements, but as soon as I use >a 4th (even if it is only 4 bits), it comes up with that error again. I have >a very strong suspicion this could be what's causing the problem. Can anyone >confirm this? > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12284
I wouldn't have thought so - It's an Altera problem ;-) Philip Freidin wrote in message ... >>michael_23@my-dejanews.com wrote: >>> >>> Hi all, >>> I desperately need some help. I am doing my final year engineering >>> project where I am designing a 16 bit Microprocessor. I am using the student >>> version of Altera for this project, which gives me the EPF10K20RC240-4 device. >> >>...snip... > >In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com> writes: >> snip >>Or you can call Xilinx support at 800-624-4782. They may want you to >>send them your design files to solve this. > >While Xilinx Tech support is well known for being helpfull, This problem >is not likely to be something they can solve. :-) > >Philip >Article: 12285
Jonathan Bromley <jsebromley@brookes.ac.uk> wrote: [snip] :Other posters have pointed out that a screwed-up state machine :(or anything) that subsequently recovers is, in a high-rel system, :hardly any better than a screwed-up state machine that stays :screwed-up. I beg to differ. OK, so the original problem :may have corrupted some data or transaction somewhere, but at :least your system is still running and you have a sporting :chance of detecting and correcting the error at some higher :level (maybe even software, if that isn't heretical here!) :where it is easier to implement redundancy. And there are many :situations (graphics systems, for example) where transient problems :are unpleasant but far from catastrophic, whereas a locked-up :state machine could mean effective total failure of the system. : :I wonder if there are any locked-up cycles in the state machines :in my car's engine management? Probably not, it's implemented :in software :-) Intel published an app note "Designing High Reliability Software for Automotive Applications" some 20 years ago. Very 8048-centred, but the techniques can be extrapolated. Some time ago, I did a system for automatically opening bottom-dump doors on 100-ton bulk rail wagons. The railroad were (very properly) much concerned to ensure the thing wouldn't dump inadvertently, with the train running at speed. The system was partly in firmware (with a standard watchdog arrangement), partly in an ASIC. Besides the actual output-circuit switches, there was a "safety catch" comprising a FET switch in the output-power line, whose gate was driven by a resonant L-C circuit feeding a diode. The L-C being AC coupled to a CPU output port. The software had to generate a run of several pulses (at the correct frequency) before the diode would pump up the FET gate. The time-constant of the L-C/FET being longer than that of the watchdog. Worked well. -- Dave Brooks <http://www.iinet.net.au/~daveb> PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or serversArticle: 12286
I have been using FPGA express and synplicity at both my job at Cisco
and now at the startup I'm at. I was really happy with Synplicity (I
used it at Cisco) and now use FPGA Express. I hate the lack of info I
receive from FPGA express and the bugs, but I did a few A/B
comparisons between Synplify and FPGA express and FPGA Express
synthesized better. My target is Xilinx FPGAs (4028 size) and I was
using about 60-80% of the CLBs. FPGA Express synthesized about 2-4 ns
better on synchronous sections than Synplify. Now, granted, in the
test I took code that was meeting timing in FPGA Express and just
dropped it into Synplify, so there was no optimization perfromed to
conform to Synplify. However, I'm one of these guys that writes purely
synchronous logic with little combo. I.E. 99% of the logic was "always
@(posedge clock)" and a few "assign" statements.
End result, I love Synplify, but it did not synthesize as well as FPGA
express.
We will look at them both again in the near future as we re-evaluate
our tools.
On the simulation tools question, we use the Veribest line of Verilog
simulation and waveform viewer. It is cheap, has some bugs, some of
the coding and features are hobby quality ("Why the *hell* did they do
that?!?!? Why didn't they ask someone who *uses* this how they would
like it done? etc.") and the waveform viewer is feature-empty, bare
bones. However, the customer support has been top notch and we have
been able to get the work done, so that says a lot. I would recommend
anyone wanting to buy a tool set to give them a look, but make sure
you look at the alternatives as well.
Feel free to call me if you want more info.
Todd
On Wed, 07 Oct 1998 14:58:45 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:
>Thanks for the various replies, it seems to be coming down to a choice
>between Silos III and ModelSim with Fintronics on the outside [don't know
>enough about it yet]. It seems that my $5K budget was a bit optimistic and
>the sim. will probably come in about $7K. Still not bad in comparison with
>a couple of years ago.
>
>Now there's the question of synthesis. Originally I was going to stick with
>the Synopsis Express (***)I have as part of the Foundation package but I
>do have the possible options of buying a synthesiser from Synplicity or
>Exemplar [Leonardo]. Anybody have any comments on their quality ?
>Particularly when Xilinx FPGAs are the target devices ?
>
>(***) BTW Does anybody know if a command line i/f has been added to
>Foundation Express for the 1.5 release ?
>
>
>
--
M. Todd Lawson InterProphet Corp
Member of Technical Staff 1999 S. Bascom Ave Ste 1020
408-371-8245 x102 Campbell, CA 95008
Article: 12287I have also seen a degradation using v1.5. The algorithmns must be different. And then of course there are the new bugs... -- Edward MooreArticle: 12288
Thanks for replying once again Andy. I thought that if the timespec is not met, then the placer would do its best to obtain an "otpimal" solution and then that would be the maximum operating frequency. I did not realize that a timing constraint not met could cause a possible invalid frequency. It makes sense though that since the timespec was not met then the design could not be used anyway. I believe for the previous versions, FROM:THRU:TO and FROM:TO had the same priority (it was something like a "bug" that xilinx corrected in F1.5. PERIOD was the last one. Maybe this affects placement and routing. > > >Also, for M1.5 I get this warning after running trace (trce) on the > >routed design: > > > >WARNING:bastw:544 - Clock nets using non-dedicated resources were found > >in this design. Clock skew on these resources will not be automatically > >addressed during path analysis. To create a timing report that analyzes > >clock skew for these paths, run trce with the '-skew' option. > > Maybe you missed something? Schematic design or VHDL? What I did is use the xc4000 library from Synplify (I don't know what tool you are using) to instantiate the BUFG and connect it as: fsa -> BUFG -> clk_net and use the following constraints to cover all the nets renamed to clk_net_c or something similar (luckily Synplify only appends characters to the VHDL net names): NET fsa* TNM = fsa_grp; NET clk* TNM = fsa_grp; TIMESPEC TS01 = PERIOD fsa_grp 25ns; I think I may need to use the new timing name net constraint as: NET fsa* TNM_NET = fsa_grp; NET clk* TNM_NET = fsa_grp; TIMESPEC TS01 = PERIOD fsa_grp 25ns; It used to work in the old versions of Foundation and Alliance, but I get this warning now. I emailed the Xilinx hotline and I am waiting for their response regarding this problem. I will post their answer to this newsgroup. Thanks for your help. -- Nestor Caouras nestor@ece.concordia.ca http://www.ece.concordia.ca/~nestor/addr.html |-------------------------------------------| | Dept. of Electrical and Computer Eng. | | Concordia University | | 1455 de Maisonneuve Blvd (West) | | Montreal, Quebec, Canada H3G 1M8. | | Tel: (514)848-8784 Fax: (514)848-2802 | |-------------------------------------------|Article: 12289
>Thanks for replying once again Andy. No probs... >I thought that if the timespec is not met, then the placer would do its >best to obtain an "otpimal" solution and then that would be the maximum >operating frequency. I did not realize that a timing constraint not met >could cause a possible invalid frequency. It makes sense though that >since the timespec was not met then the design could not be used anyway. I hope that if that's wrong, someone will correct me, but it makes sense. >I believe for the previous versions, FROM:THRU:TO and FROM:TO had the >same priority (it was something like a "bug" that xilinx corrected in >F1.5. PERIOD was the last one. Maybe this affects placement and >routing. Right! PERIOD was fixed in 1.5...but I checked the timing priorities and what I mentioned before (FROM:THRU:TO having highest priority) seems to be the way it is now. >> >WARNING:bastw:544 - Clock nets using non-dedicated resources were found >> >in this design. Clock skew on these resources will not be automatically >> >addressed during path analysis. To create a timing report that analyzes >> >clock skew for these paths, run trce with the '-skew' option. >> >> Maybe you missed something? Schematic design or VHDL? > >What I did is use the xc4000 library from Synplify (I don't know what >tool you are using) to instantiate the BUFG and connect it as: > >fsa -> BUFG -> clk_net Is Synplify smart enough to automatically insert clock buffers? FPGA Express (which I use) does; so does Metamor. >and use the following constraints to cover all the nets renamed to >clk_net_c or something similar (luckily Synplify only appends characters >to the VHDL net names): > >NET fsa* TNM = fsa_grp; >NET clk* TNM = fsa_grp; >TIMESPEC TS01 = PERIOD fsa_grp 25ns; > >I think I may need to use the new timing name net constraint as: > >NET fsa* TNM_NET = fsa_grp; >NET clk* TNM_NET = fsa_grp; >TIMESPEC TS01 = PERIOD fsa_grp 25ns; Try it and let us know what happens. >It used to work in the old versions of Foundation and Alliance, but I >get this warning now. I emailed the Xilinx hotline and I am waiting for >their response regarding this problem. > >I will post their answer to this newsgroup. Thanks - it's always good to know what the Big "X" says! -andyArticle: 12290
timo@novaengr.com (Tim O) writes (HE QUOTES, NOT WRITES):
Good flame bait, anyway.
> I have documented your request for a Linux based Max+Plus II.
> We have looked into that option a bit, and the concensus was that
> there was not enough customer interest in Linux to make it a
> worthwhile investment. However, if more and more customers continue
That's No. 1. standard answer from all of them.
> to request support for that operating system, it will eventually be
> looked at more seriously. One of the major problems with supporting
That's No. 1. standard closing clause, with high BSV :-)
> Linux is the fact that there is no person or company who is
> responsible for supporting it. So if we made a version of
> software which would run on Linux and then there was an operating
> system problem----it would be our job to fix that, and we would have
C'mon, man, you could do better than that !
- Linux is known to have bug fixes quicker than any commercial OS,
even though Linux is quite bug-free compared to some commercial ones.
- Still, AFAIK, you can buy commercial support, if you like.
- You can talk to thousands of programmers, if you care to look. For free.
- Every piece of Linux has a 'send bugreports to bugs@this.teams.address'
with a usual response time being between a day and a month.
Note, that response means 'fix' not 'we will look into it in the next
revision; please assure that you will recieve the upgrade pack when it
becomes available by filling the attached form and faxing it, with your
credit card details to ...'
You see, Linux is more about professional pride than making more money.
- How many times have say M$ fixed problems regarding EDA tools crashing
and taking the system with them ?
By the way, I seem to remember posts in this newsgroup regarding to bugs
in EDA tools that don't get fixed from one revision to another. I have
also reported bugs, sending the example which made the tool crash and got
a reply 'Yes, that indeed makes it crash.'. Very supportive.
Strange that supposed OS bugs are suddenly a major concern ...
Actually, I have also sent bug reports regarding to EDA tools running
under Linux and they fixed the bug quickly and without BS. Interesting.
> no Linux experts or designers to talk too. As far as I know, that
Now this is, pardon me, utter rubbish.
By the way, you have the source, documetation and assumedly some capable
programmers around, so what is your problem ?
> fact and the lack of customer interest are the only reasons why such a
> version is not available right now.
Yeah, right.
Actually, with a little knowledge about Linux much more plausible sounding
arguments could have been cranked out. Still, the attempt to create
arguments at all, even very weak ones is a nice try, quite respectable :-)
In contrast, this is what for example Symplicity wrote to me:
"We do not have current plans to port our software to Linux.
Feel free to check again with us next year."
Compared to this, the Altera one talks to you as if they almost
considered a Linux user being human :-)
Zoltan
--
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |
+--------------------------------+---------------------------------+
Article: 12291Gareth Baron wrote: > > I wouldn't have thought so - It's an Altera problem ;-) Opps. Maybe I should try actually READING the messages next time... 8-O > Philip Freidin wrote in message ... > >>michael_23@my-dejanews.com wrote: > >>> > >>> Hi all, > >>> I desperately need some help. I am doing my final year > engineering > >>> project where I am designing a 16 bit Microprocessor. I am using the > student > >>> version of Altera for this project, which gives me the EPF10K20RC240-4 > device. > >> > >>...snip... > > > >In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com> > writes: > >> snip > >>Or you can call Xilinx support at 800-624-4782. They may want you to > >>send them your design files to solve this. > > > >While Xilinx Tech support is well known for being helpfull, This problem > >is not likely to be something they can solve. :-) > > > >Philip > > -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12292
Rickman (spamgoeshere4@yahoo.com) wrote: : michael_23@my-dejanews.com wrote: : > : > Hi all, : > I desperately need some help. I am doing my final year engineering : > project where I am designing a 16 bit Microprocessor. I am using the student : > version of Altera for this project, which gives me the EPF10K20RC240-4 device. : > I have completed my design and I have been testing it as I go, so I know all : > the components are working properly. Here is my problem, and it is a big : > problem as the deadline is coming up very close and I am starting to panic. : > I was going along fine until I hit this problem. Okay, so when I was at my : > last step (I'm so close) when I was trying to compile the whole thing I got : > the following error about half-way through compilation: : > "Internal Error: (CMP) Fatal application error in Partitioner at 10%" : > : > Does anyone know what this means and what has caused it? : : ...snip... : : > PPS: Another thought, I wonder if there is a limit of the number of memory : > elements I can use. It will let me use 3 RAM elements, but as soon as I use : > a 4th (even if it is only 4 bits), it comes up with that error again. I have : > a very strong suspicion this could be what's causing the problem. Can anyone : > confirm this? : > : > -----------== Posted via Deja News, The Discussion Network ==---------- : > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own : : My suspicion is that you have found an internal error in the tools. Any : time you get a "Fatal Error" that is a good sign that you have not done : anything wrong. You have likely just done something that the tools don't : like. : : You sound like you have a good indicator in the number of RAM blocks. : There should be no limitation on that. I suggest that you try making : changes to your design just to find what will and won't crash the tool. : Or you can call Xilinx support at 800-624-4782. They may want you to : send them your design files to solve this. : : : -- : : Rick Collins : : redsp@XYusa.net : : remove the XY to email me. From my understanding of the student edition of MAX-PLUS, when you try and partition a design over multiple devices, either intentionally or because the device chosen is too small, the paritioner crashes, I guess so that you don't just buy a heap of smaller parts and use the free student edition. Why it doesn't give you a warning message, I don't know. Occasionally, MAX-PLUS also crashes for strange reasons, like when IO packing is turned on, so try altering your comile options. Dan.Article: 12293
This is a multi-part message in MIME format. --------------5A75399BC3BDBDA82E7635E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Daniel K Elftmann wrote: > Some actual number of antifuses for the Actel devices are as follows: > Arch Fuses Cost@$500 > A1010 -> 112,000 $56,000,000 > A1020 -> 186,000 $93,000,000 > A1225 -> 250,000 $125,000,000 > A1240 -> 400,000 $200,000,000 > A1280 -> 750,000 $375,000,000 > > Still not prices that the typical hacker can afford in my opinion. > > > > > Perhaps a study of the antifuse programming algorithms (which I won't go into here) would help you > to understand this, but in short the state of each individual antifuse cannot be determined even > from the programming circuitry once the entire device has been programmed, so take out your camera > again. As it has been explained to me, each fuse is verified after it is programmed, but > programming of subsequent fuses removes the capability to access inner device fuses, which is the > reason the checksum is programmed into the device for later identification versus just reading out > the state of each fuse and re-calculating the checksum. > OK! So its a bit harder than I thought :-) But there is still no way its a $375,000,000 problem. Firstly, I have more tools in my toolbox than FIB machines and TEM's, I could use a voltage contrast microscope to see which top metal wires had signal changes on them while running the circuit for example. Secondly, as a smart hacker I'd write some software to help my search. Most of the possible permutations of antifuses will be illegal so once I know the state of a few antifuses connected to a particular signal the chances are I can infer the state of many more. Thirdly I would not give up so quickly on using the programming circuitry to help me. I'd want to drive it in various ways and look at IDD. I'd want to try driving it while the circuit was running to see if I could induce faults and so on. I'd need to look in some detail at how the circuitry 'removes the capability', to see if it was really 'removed' or just made more difficult. > Tom, > > I don't see how antifuse devices have any application in reconfigurable computing? Is there still > a bit of Xilinx left in you that just can't have an antifuse advantage being posted in this group? > > Don't mean to be smug. I'm just trying to understand your biases. > I hope I'm not biased, I just hate having crazy numbers being thrown about. I agree that when used in the'normal' mode i.e. being loaded from a serial eprom SRAM FPGA's are less secure than antifuse. This is an antifuse advantage, no question. However: there is no way that it takes $375,000,000 to figure out the design in an antifuse part and $500 to figure out the design in an SRAM part. My guesstimate would be about $50,000 to $500,000 to figure out how to break the security on the antifuse chips and then about $1 to $5000 per design. > Good luck to Algotronix, I wish you well. Thanks. --------------5A75399BC3BDBDA82E7635E7 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Kean Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Tom Kean n: Kean;Tom org: Algotronix Ltd. adr: P.O. Box 23116;;;Edinburgh;;EH8 8YB;Scotland email;internet: tom@algotronix.com title: Director tel;work: UK +44 131 556 9242 tel;fax: UK +44 131 556 9247 note: Web Site: www.algotronix.com x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------5A75399BC3BDBDA82E7635E7--Article: 12294
On Wed, 07 Oct 1998 11:31:23 -0700, Derek Palmer <derekp@synopsys.com> wrote: >Let's make rumor fact! >FPGA Express 3.0 will have VHDL 93 support. >Available on the Synopsys web site at the end of Oct. What does "support" mean? How big (or small) will the subset be? Will it be 1076.6 compliant? I got a rude suprise once when trying to port some code from Galileo to FPGA Express. Couldn't convince the Synopsys tools to believe that a two dimensional array of std_logic was a valid type for a generic parameter. Sigh, Allan. >Derek Palmer >FPGA Express Team >Synopsys Corporation.Article: 12295
> At audio and telephony rates, you can take advantage of bit serial > algorithms for you processing. This greatly compresses the amount of logic > required to perform a particular function. There is no need to construct a > fully parallel filter (for example) that is capable of 50MHz sample rates > if you are passing 50KHz data. By using bit serial forms, you don't waste > gates on excess processing power you don't need. If you are unfamiliar > with bit serial arithmetic, there are two papers on my website that deal > with it: The first is an FIR filter implemented in '91 in an ATmel 6K > part. This filter does not use distributed arithmetic (the atmel part does > not implement tables easily), but does show how bit serial arithmetic is > used to pack a large number of multipliers in a single part. The second > paper is one that discusses bit serial design techniques for FPGAs. It > uses a bit serial CORDIC vector magnitude computer as an example. > Thank you for the last two informative emails. I definitely understand the need to have a different design philosophy when tackling hardware implementations of signal processing functions.A little off topic, I want to bounce this off you. I have been thinking of putting Viterbi algorithm for finding MLS onto an FPGA. Have you come across similar implementations and what is your take on the feasibility of putting the algorithm handling 32 states (5 memory elements) on a 100K FPGA?. I would appreciate any input from you, Thank you, Kartheepan, MArticle: 12296
> At audio and telephony rates, you can take advantage of bit serial > algorithms for you processing. This greatly compresses the amount of logic > required to perform a particular function. There is no need to construct a > fully parallel filter (for example) that is capable of 50MHz sample rates > if you are passing 50KHz data. By using bit serial forms, you don't waste > gates on excess processing power you don't need. If you are unfamiliar > with bit serial arithmetic, there are two papers on my website that deal > with it: The first is an FIR filter implemented in '91 in an ATmel 6K > part. This filter does not use distributed arithmetic (the atmel part does > not implement tables easily), but does show how bit serial arithmetic is > used to pack a large number of multipliers in a single part. The second > paper is one that discusses bit serial design techniques for FPGAs. It > uses a bit serial CORDIC vector magnitude computer as an example. > Thank you for the last two informative emails. I definitely understand the need to have a different design philosophy when tackling hardware implementations of signal processing functions.A little off topic, I want to bounce this off you. I have been thinking of putting Viterbi algorithm for finding MLS onto an FPGA. Have you come across similar implementations and what is your take on the feasibility of putting the algorithm handling 32 states (5 memory elements) on a 100K FPGA?. I would appreciate any input from you, Thank you, Kartheepan, MArticle: 12297
sometimes Maxplus does throw funnies like this the best thing is usually to delete everything in your working directory, other than the files that you actually need. So you should hang onto any TDFs, GDFs, SCFs and the ACF. This is assuming that you're using AHDL. That will often do the trick. Make sure you've got the partitioner turned off, if that seems to be what's crashing. good luck JamesArticle: 12298
David R Brooks wrote: [snip] > Some time ago, I did a system for automatically opening bottom-dump > doors on 100-ton bulk rail wagons. The railroad were (very properly) > much concerned to ensure the thing wouldn't dump inadvertently, with > the train running at speed. The system was partly in firmware (with a > standard watchdog arrangement), partly in an ASIC. Besides the actual > output-circuit switches, there was a "safety catch" comprising a FET > switch in the output-power line, whose gate was driven by a resonant > L-C circuit feeding a diode. The L-C being AC coupled to a CPU output > port. > The software had to generate a run of several pulses (at the correct > frequency) before the diode would pump up the FET gate. The > time-constant of the L-C/FET being longer than that of the watchdog. > Worked well. Interesting - I had to do something very similar to guarantee that a micro-based gadget would completely disconnect itself from a bunch of serial ports if it failed for any reason. Again, a simple and successful solution. Jonathan Bromley --Article: 12299
On Wed, 07 Oct 1998 11:31:23 -0700, Derek Palmer <derekp@synopsys.com> wrote: >Let's make rumor fact! >FPGA Express 3.0 will have VHDL 93 support. >Available on the Synopsys web site at the end of Oct. great news, and nice to see synopsys here. however, the last i heard from xilinx was that it would support "some" '93 features; they weren't specific. can you tell us more? does this mean (a) a normal synthesisable subset of '93, or (b) limited support of '93? and what about VSS/DC? will the new version be shipped with foundation, or will it be an (expensive) upgrade? evan
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