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
"Eric" <jonas@mit.edu> wrote in message news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com... > > Rob, > This is fantastic help, esp. since I just got quotes on IBIS > simulators that exceed my > entire budget for this project. :) I'm shooting for somewhere between > 125 MHz and 150 MHz > for my clock, and plan on having a very simple, bursty interface. > I'm basically trying to clock this thing as slowly as I possibly can. > I am using a single DDR2 > IC (16-bit wide) per interface which will be directly connected to the > FPGA as closely as possible. > > For the control signals, you recommend SSTL18_I_DCI on the FPGA side > and a pull-up > to VTT on the DDR2 side. > > You're then recommending using the SSTL_18_II IO standard for the DQ/ > DQS signals on > the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just > using ODT on > the DDR2 side. > > If I understand correctly we can't use ODT for the address/control > signals on the DDR2 side > because DDR2 only supports ODT on data-related signals. > > For your interface, did you use the Xilinx Memory Interface generator, > or do your own interface > by hand? MIG tries to place what seem like significant restrictions on > pin location, as well > as being a bit too general-purpose for our applications, but I'm > guessing if there > are pin constraints there's a reason for it. > > Also, may I ask how far away your DDR2 ICs were from your FPGA, and if > there was only > a single IC per interface or multiple ICs? > > > Thanks, > ...Eric > Eric Have you looked into running slower than 125 mhz (with the dll disabled)? I want to do this, at probably around 33mhz, but I'm having trouble getting any information about it: namely can I do it and will it work? Just wondering if you knew anything about that. DanArticle: 136101
Anybody had success in interfacing GDDR3 memory to FPGAs? If so, how did you do it, and what sort of performance did you achieve? Thanks PeteArticle: 136102
KJ wrote:
> As always (and I'm assuming that Mark has already done this), you
> always run the simulator first to make sure that the design is
> functionally correct. Optimization that changes the observable
> function is incorrect optimization.
Yes. It is not the job of synthesis to guess
the cases where I don't want register sharing or duplication.
If the netlist sims correctly, synthesis is correct.
To get a register to duplicate or not share as
I wish, I have to describe the requirement
as a device constraint, or change my logical description
to rule out the unwanted register usage.
For example, if I want to avoid sharing of the
second register in a synchronizer, I could
either make an explicit device-specific constraint,
or add a third flop to the synchronizer.
-- Mike
Article: 136103Hi Ales, > I have been using a DCR bus and I like it, but it will become obsolete > soon. Could you please elaborate on what you know about DCR obsolescence? > As far as I know MPMC bus bridging was removed from the core. Yeah, you are right, I forgot about it. I am still using MPMC2... /MikhailArticle: 136104
On Tue, 28 Oct 2008 09:38:18 -0500, "maxascent"
<maxascent@yahoo.co.uk> wrote:
>
>Hi
>
>I am trying to write a state machine in system verilog. I am using an enum
>for the states e.g.
>
>enum logic [1:0] {one, two, three} state, next;
>
>I have a sequential process which init the state to one e.g.
>
>always_ff @(posedge clk)
>begin
> if (~reset_n) begin
> state <= one;
> end else begin
> state <= next;
> end
>end
>
>When I try and sythesise it usingg Synplify it complains that :-
>
>Initial value is not supported on state machine state
>
>It doesnt seem to like the state <= one;
>
>I dont understand what is wrong with this, can anybody help?
I'm not sure, but I suspect it's the fact that you do not
have an *asynchronous* reset on "state". I can't easily
see anything wrong with what you've done.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 136105On Fri, 31 Oct 2008 11:12:50 -0600, "Dan Kuechle" <danielgk@visi.com> wrote: > >Have you looked into running slower than 125 mhz (with the dll disabled)? I >want to do this, at probably around 33mhz, but I'm having trouble getting >any information about it: namely can I do it and will it work? Just >wondering if you knew anything about that. Check a DDR2 memory datasheet for its minimum operating frequency. May be 83 or 125 MHz (I can't remember offhand); set by the internal DLL delay length used to generate signal timings. It is possible to turn the DLL off (with a mode register setting) - that may allow operation at lower speeds, but you're operating outside the datasheet and you'd beon your own as far as timings go. - BrianArticle: 136106
On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> But here's my worry: What if XST is actually right; and Quartus is one >> step behind the pack in its optimisation technology (generating correct >> but sub-optimal results)? >> > >As always (and I'm assuming that Mark has already done this), you >always run the simulator first to make sure that the design is >functionally correct. Optimization that changes the observable >function is incorrect optimization. OK, you're right. As long as the simulation test coverage is adequate, I was spouting nonsense there. - BrianArticle: 136107
Hi all! I have a working project with tight timing constraints which compiles successfully on ISE10.1 SP1. This is the successful router phase: Phase 1: 16814 unrouted; REAL time: 23 secs Phase 2: 15669 unrouted; REAL time: 25 secs Phase 3: 4742 unrouted; REAL time: 33 secs Phase 4: 4742 unrouted; (0) REAL time: 33 secs Phase 5: 4742 unrouted; (0) REAL time: 35 secs Phase 6: 4742 unrouted; (0) REAL time: 36 secs Phase 7: 0 unrouted; (0) REAL time: 48 secs Phase 8: 0 unrouted; (0) REAL time: 51 secs Phase 9: 0 unrouted; (0) REAL time: 1 mins 6 secs After installing the SP3, things goes worse. The timing score is a lot higher and the router issues the following warning: Phase 1: 16795 unrouted; REAL time: 14 secs Phase 2: 15658 unrouted; REAL time: 15 secs Phase 3: 4800 unrouted; REAL time: 20 secs Phase 4: 4800 unrouted; (845062) REAL time: 21 secs Phase 5: 4846 unrouted; (783315) REAL time: 23 secs Phase 6: 4846 unrouted; (783315) REAL time: 23 secs WARNING:Route:441 - The router has detected a very high timing score (783315) for this design. It is extremely unlikely the router will be able to meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the implementation or synthesis of logic in the critical timing path. If you would prefer the router continue trying to meet timing and you are willing to accept a long run time set the option "-xe c" to override the present behavior. Phase 7: 0 unrouted; (783315) REAL time: 28 secs Phase 8: 0 unrouted; (837862) REAL time: 31 secs Phase 9: 0 unrouted; (836853) REAL time: 42 secs The problem is: I tried the -xe c option (it is the "continue on impossible"), the warning disappears but I get two failed timing constraints anyway. All the options are the same, timing driven place and route, optimization for speed, etc etc. I even tried to set the "design goal" to "timing performance", which sets even more options for timing care, with no success. One of the suggestion of the timing wizard is to duplicate logic and prevent the tool from removing such duplication, but I don't know how to do it. Anyway, is there anybody else having such problems with SP3? Thanks in advance AlessandroArticle: 136108
On Nov 1, 12:05=A0pm, "Alessandro" <apo...@email.it> wrote: > Hi all! > > I have a working project with tight timing constraints which compiles > successfully on ISE10.1 SP1. > > This is the successful router phase: > > Phase 1: 16814 unrouted; =A0 =A0 =A0 REAL time: 23 secs > Phase 2: 15669 unrouted; =A0 =A0 =A0 REAL time: 25 secs > Phase 3: 4742 unrouted; =A0 =A0 =A0 REAL time: 33 secs > Phase 4: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 33 secs > Phase 5: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 35 secs > Phase 6: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 36 secs > Phase 7: 0 unrouted; (0) =A0 =A0 =A0REAL time: 48 secs > Phase 8: 0 unrouted; (0) =A0 =A0 =A0REAL time: 51 secs > Phase 9: 0 unrouted; (0) =A0 =A0 =A0REAL time: 1 mins 6 secs > > After installing the SP3, things goes worse. The timing score is a lot > higher and the router issues the following warning: > > Phase 1: 16795 unrouted; =A0 =A0 =A0 REAL time: 14 secs > Phase 2: 15658 unrouted; =A0 =A0 =A0 REAL time: 15 secs > Phase 3: 4800 unrouted; =A0 =A0 =A0 REAL time: 20 secs > Phase 4: 4800 unrouted; (845062) =A0 =A0 =A0REAL time: 21 secs > Phase 5: 4846 unrouted; (783315) =A0 =A0 =A0REAL time: 23 secs > Phase 6: 4846 unrouted; (783315) =A0 =A0 =A0REAL time: 23 secs > > WARNING:Route:441 - The router has detected a very high timing score > (783315) for this design. It is extremely unlikely > =A0 =A0the router will be able to meet your timing requirements. To preve= nt > excessive run time the router will change > =A0 =A0strategy. The router will now work to completely route this design= but > not to improve timing. This behavior will > =A0 =A0allow you to use the Static Timing Report and FPGA Editor to isola= te the > paths with timing problems. The cause of > =A0 =A0this behavior is either overly difficult constraints, or issues wi= th the > implementation or synthesis of logic in the > =A0 =A0critical timing path. If you would prefer the router continue tryi= ng to > meet timing and you are willing to accept a > =A0 =A0long run time set the option "-xe c" to override the present behav= ior. > > Phase 7: 0 unrouted; (783315) =A0 =A0 =A0REAL time: 28 secs > Phase 8: 0 unrouted; (837862) =A0 =A0 =A0REAL time: 31 secs > Phase 9: 0 unrouted; (836853) =A0 =A0 =A0REAL time: 42 secs > > The problem is: I tried the -xe c option (it is the "continue on > impossible"), the warning disappears but I get two failed timing constrai= nts > anyway. All the options are the same, timing driven place and route, > optimization for speed, etc etc. I even tried to set the "design goal" to > "timing performance", which sets even more options for timing care, with = no > success. > > One of the suggestion of the timing wizard is to duplicate logic and prev= ent > the tool from removing such duplication, but I don't know how to do it. > Anyway, is there anybody else having such problems with SP3? > > Thanks in advance > Alessandro Judging by the REAL time numbers in these reports, it looks like SP 3 isn't trying very hard, or that you have an extremely fast computer. Look at your settings for map and P&R. Normally to get the best timing, you need timing based packing and placement enabled in the Map phase. When this is enabled you can select a starting cost table entry (default is 1) for both Map and P&R. In this case the place & route cost table entry doesn't seem to matter as much as the Map cost table entry. This table entry is a seed for the initial placement and it allows you to start the recursive placement from different starting points when you change it. Often, especially when you have little or no floorplanning, this can make a huge difference in your final timing. You could try running multi-pass place and route or just go through a few table entries, one at a time manually. By the way this problem may have nothing to do with SP3, but just making the smallest change to the design can disrupt the initial placement enough to cause what you see. Floorplanning is generally the best way to fix these issues permanently, but if the design builds quickly, you can use the multi-pass place&route to let the tools do it for you. When you get a placement that works well, you can use guided placements for subsequent builds assuming your design changes are small. HTH, GaborArticle: 136109
axr0284 wrote: > 1) If my module detects an address parity error but bit 8 in the > command register used to turn on system error signaling is set to 0, > does my system > a) ignore the command > b) Responds normally ignoring parity checking > c) Takes possession of the request by asserting DEVSEL and then sends > back a target abort. I know very little about the PCI spec, but it seems to me that a or b would open the door to bugs that would be difficult to track down. --Mike TreselerArticle: 136110
Gabor wrote: > Judging by the REAL time numbers in these reports, it looks like SP 3 > isn't trying very hard, or that you have an extremely fast computer. First of all, thanks a lot for the useful information. I think the first, since it is a P4 3.2GHz (not dualcore or whatsoever). > phase. When this is enabled you can select a starting cost table > entry (default is 1) for both Map and P&R. In this case the place & Very interesting. I did activate the timing drive placement, but never modified that number. I will try to see how it improve the placement. > You could try running multi-pass place and route or just go through > a few table entries, one at a time manually. If I got it right, increasing this number makes the tool work harder? > By the way this problem may have nothing to do with SP3, but just > making the smallest change to the design can disrupt the initial > placement enough to cause what you see. Absolutely right. For a long time I've had to deal with an extremely unstable design, then I've got a tip of adding a BUFG over a clock line that was treated as a signal (it's generated by counters and comparators). > Floorplanning is generally the best way to fix these issues > permanently, but if the design builds quickly, you can use > the multi-pass place&route to let the tools do it for you. Not so quickly: it takes more than 10 minutes, so decided to learn about floorplanning. I've discovered several interesting things this afternoon. I finally understood what it meant when he said that the DCM and it's associated BUFG were not locked to good position, requiring a CLOCK_DEDICATED_ROUTE = FALSE constraint in order to proceed. By floorplanning I've been able to fix this, but here I have a question. The project uses two DCM in a spartan 3E-500. There is a 50MHz clock pin fed into the first DCM, which generates 0/90/180 phase clock for a DDR controller. Then, the CLK0_OUT also goes to the input of the second DCM (configured as internal clock, so there is no IBUFG on the clock input) which synthesizes a 85MHz clock for other processes. The problem was due to the fact that this fpga has only 4 BUFG on top and 4 on bottom, so with 5 outputs (0/90/180 on first DCM and CLK0/CLKFX on second) lead to the problem of having at least one BUFG on the opposite side of the chip. I managed it by stopping using the CLK0_OUT from the second DCM so that I could place it far away without any problem. The reason for having two dcm is that I've added the ddr controller later, while the 85MHz output was already there. Do you think I may try to use a single dcm to generate any clock? Also, BUFG are precious. I successfully tried to manually completely remove the CLK0_OUT signal from the second DCM, saving one BUFG. Now I have a neat placement with two dcm and four BUFG very close togheter. I've had to feed the dcm internal feedback with the CLK0_BUF (while before it was after the removed BUFG). Do you think that this may lead to problems? I would like to save the bufg because I will probably need it at a later stage. > When you get a placement that works well, you can use > guided placements for subsequent builds assuming your > design changes are small. I think you are several steps ahead on me about fpga :-) Thanks! AlessandroArticle: 136111
On Sat, 1 Nov 2008 18:05:34 +0100, "Alessandro" <apoppi@email.it> wrote: >Hi all! > >I have a working project with tight timing constraints which compiles >successfully on ISE10.1 SP1. >After installing the SP3, things goes worse. The timing score is a lot >higher and the router issues the following warning: > >Phase 1: 16795 unrouted; REAL time: 14 secs >Phase 2: 15658 unrouted; REAL time: 15 secs >Phase 3: 4800 unrouted; REAL time: 20 secs >Phase 4: 4800 unrouted; (845062) REAL time: 21 secs >Phase 5: 4846 unrouted; (783315) REAL time: 23 secs >Phase 6: 4846 unrouted; (783315) REAL time: 23 secs > >WARNING:Route:441 - The router has detected a very high timing score >(783315) for this design. It is extremely unlikely > the router will be able to meet your timing requirements. Look at the nature of the worst failing path. I have just had a similar message porting a 7.1 era design to ISE10. In my case, the signal paths looked about the same as before, but about -2.3 ns of clock skew had crept in. If this is the case for you, read on; otherwise ignore this post. My clock enters via IBUFGDS (then an implicit BUFG) to the main logic, and to some DCMs which generated related clocks in sync with the main clock. For some reason ISE10 (maybe just SP3) had started routing directly from the IBUFGDS to the DCMs, but inserted a BUFG as before (and as it should) in the clock to the main logic. This advanced all my subsidiary clocks by just over 2 ns. Which came as a bit of a surprise to me... I resolved it by moving the IBUFGDS to the top level and manually instantiating the following BUFG on the main clock signal. That gave XST no excuse for feeding the DCMs from anything else... - BrianArticle: 136112
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com... > On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net> > wrote: > >>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com> >>wrote: > >>> But here's my worry: What if XST is actually right; and Quartus is one >>> step behind the pack in its optimisation technology (generating correct >>> but sub-optimal results)? >>> >> >>As always (and I'm assuming that Mark has already done this), you >>always run the simulator first to make sure that the design is >>functionally correct. Optimization that changes the observable >>function is incorrect optimization. > > OK, you're right. As long as the simulation test coverage is adequate, I > was spouting nonsense there. > > - Brian Just be aware that there are occasions where the simulation can be incorrect; just the other day, I was modifying a [non-clocked] process, but forgot to add a key signal to the sensitivity list. So, simulation was 'incorrect'--at least, undesired--and synthesis would have produced the desired behavior. (In this case, it was in the test bench, so synthesis would have been immaterial.) I found and corrected it quickly, and there is a compiler option to warn about synthesis mismatch, but still.... It is possible to have simulation wrong and synthesis correct, as well as vice-versa. JTWArticle: 136113
On Nov 1, 11:13=A0pm, "jtw" <wrigh...@hotmail.invalid> wrote: > "Brian Drummond" <brian_drumm...@btconnect.com> wrote in message > > news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com... > > > > > On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> > > wrote: > > >>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com> > >>wrote: > > >>> But here's my worry: What if XST is actually right; and Quartus is on= e > >>> step behind the pack in its optimisation technology (generating corre= ct > >>> but sub-optimal results)? > > >>As always (and I'm assuming that Mark has already done this), you > >>always run the simulator first to make sure that the design is > >>functionally correct. =A0Optimization that changes the observable > >>function is incorrect optimization. > > > OK, you're right. As long as the simulation test coverage is adequate, = I > > was spouting nonsense there. > > > - Brian > > Just be aware that there are occasions where the simulation can be > incorrect; just the other day, I was modifying a [non-clocked] process, b= ut > forgot to add a key signal to the sensitivity list. =A0So, simulation was > 'incorrect'--at least, undesired--and synthesis would have produced the > desired behavior. =A0(In this case, it was in the test bench, so synthesi= s > would have been immaterial.) > > I found and corrected it quickly, and there is a compiler option to warn > about synthesis mismatch, but still.... =A0It is possible to have simulat= ion > wrong and synthesis correct, as well as vice-versa. > > JTW Two wrongs don't make a right. Wrong #1: describe the wrong logic (according to well defined, intentioned language semantics) by accidentally mis-typing the sensitivity list, then (wrong #2) claim that the synthesis tool ought to be ignoring the semantics of the language. While this would certainly not be the first time this has occurred (and I've probably been bitten by it, too), it's not really accurate to say "simulation is incorrect". - KennArticle: 136114
"Dan Kuechle" <danielgk@visi.com> wrote: > >"Eric" <jonas@mit.edu> wrote in message >news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com... >> >> Rob, >> This is fantastic help, esp. since I just got quotes on IBIS >> simulators that exceed my >> entire budget for this project. :) I'm shooting for somewhere between >> 125 MHz and 150 MHz >> for my clock, and plan on having a very simple, bursty interface. >> I'm basically trying to clock this thing as slowly as I possibly can. >> I am using a single DDR2 >> IC (16-bit wide) per interface which will be directly connected to the >> FPGA as closely as possible. >> >> For the control signals, you recommend SSTL18_I_DCI on the FPGA side >> and a pull-up >> to VTT on the DDR2 side. >> >> You're then recommending using the SSTL_18_II IO standard for the DQ/ >> DQS signals on >> the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just >> using ODT on >> the DDR2 side. >> >> If I understand correctly we can't use ODT for the address/control >> signals on the DDR2 side >> because DDR2 only supports ODT on data-related signals. You won't need ODT because you can run the address/control signal at half the memory frequency. You may even get away with LVCMOS signals with lower drive strenghts to reduce power even more. >> For your interface, did you use the Xilinx Memory Interface generator, >> or do your own interface >> by hand? MIG tries to place what seem like significant restrictions on >> pin location, as well >> as being a bit too general-purpose for our applications, but I'm >> guessing if there >> are pin constraints there's a reason for it. Be aware that the MIG tool tries to get the maximum speed from the FPGA for marketing purposes. If you roll your own interface and aim at a lower frequency, the pin restrictions vanish and the complexity of the interface is greatly reduced. >Have you looked into running slower than 125 mhz (with the dll disabled)? I >want to do this, at probably around 33mhz, but I'm having trouble getting >any information about it: namely can I do it and will it work? Just >wondering if you knew anything about that. The datasheet specifies a minimum operating frequency. But whats the use of DDR2 when using it at lower speeds? Perhaps DDR or SDRAM is a better choice in such situations. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 136115
On Sat, 1 Nov 2008 20:13:33 -0700, "jtw" <wrightjt@hotmail.invalid> wrote: >"Brian Drummond" <brian_drummond@btconnect.com> wrote in message >news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com... >> On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net> >> wrote: >> >>>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com> >>>wrote: >> >>>> But here's my worry: What if XST is actually right; and Quartus is one >>>> step behind the pack in its optimisation technology (generating correct >>>> but sub-optimal results)? >>> >>>As always (and I'm assuming that Mark has already done this), you >>>always run the simulator first to make sure that the design is >>>functionally correct. Optimization that changes the observable >>>function is incorrect optimization. >> >> OK, you're right. As long as the simulation test coverage is adequate, I >> was spouting nonsense there. >Just be aware that there are occasions where the simulation can be >incorrect; just the other day, I was modifying a [non-clocked] process, but >forgot to add a key signal to the sensitivity list. That's a good example of what I meant by "inadequate" test coverage; the simulator was accurately performing what you described; just not what you meant to describe! - BrianArticle: 136116
MM wrote: > Hi Ales, > >> I have been using a DCR bus and I like it, but it will become obsolete >> soon. > > Could you please elaborate on what you know about DCR obsolescence? I think this thread earlier this year may have started some rumors. http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/f902f659aab1fcc9/5199d4118b7b99e3?lnk=st&q=#5199d4118b7b99e3 I opened a webcase about DCR bus going away and was told DCR bus is still supported. Apparently some of the info in the thread was bogus or perhaps people were confusing microblaze support for DCR with support in the EDK and PPC. PLB and DCR are both parts of the IBM coreconnect standard and serve complimentary functions. I think it would be sort of silly to have PLB without DCR. -JeffArticle: 136117
i wrote a vhdl code for 8 bit adder, checked the syntax but there is
no syntax errors found. in the synthosis it is shoing synthe sis is
completed successfully but a warning simble is comming.
if want to simulate it shows error whih is bellow.
ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line
84. /= has two possible definitions in this scope.
Parsing "additest_beh.prj": 0.28
any body know the anser for this plese reply immediatly.
my code is:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity adder1 is
Port ( clock : in STD_LOGIC;
reset : in STD_LOGIC;
A : in STD_LOGIC_VECTOR (8 downto 0);
B : in STD_LOGIC_VECTOR (8 downto 0);
SUM : out STD_LOGIC_VECTOR (8 downto 0));
end adder1;
architecture Behavioral of adder1 is
begin
process(clock,reset)
begin
if (reset='0') then
sum<="000000000";
elsif(clock'event and clock='1') then
SUM <= A+B;
end if;
end process;
end Behavioral;
Article: 136118Even if I copy the example state machine from the Synplify help file that gives the same message. There is something in the Synplify docs about not supporting certain things in System Verilog at the moment so it could be something to do with that. However they shouldnt be giving example code that doesnt work.Article: 136119
Gabor wrote: > Judging by the REAL time numbers in these reports, it looks like SP 3 > isn't trying very hard, or that you have an extremely fast computer. ...but I've selected several timing-related options, and if I choose the timing as "goal" (which sets even more options for this purpose) I get a worse result. In the meantime I solved the problem I've had yesterday (SP3 also routes everything without timing issues) thanks to floorplan placement of the two DCM and related BUFG. Due to this improvement, however, I've been able to successfully increase the DDR speed from 50 to 85MHz (which an already-available clock in the design). Due to this, I went back to the problem: SP1 routes it, while SP3 gives three timing constraint problems. Four clock signal have now a period constraint of 11ns instead of previous 20 and this is the reason of the not-met constraints. > you can select a starting cost table entry (default is 1) for both Map and > P&R. In this case the place & > route cost table entry doesn't seem to matter as much as the Map cost > table entry. This table entry is a seed for the initial > placement and it allows you to start the recursive placement from > different > starting points when you change it. This point is not so clear to me. I'm now trying the multipass place and route with 10 retries, leaving the cost table at 1. If change this number I will get different results? > You could try running multi-pass place and route or just go through > a few table entries, one at a time manually. So if I change the cost table to, for example, 3 I get the same result I've got in retry number 3 when starting from table cost = 1? > Floorplanning is generally the best way to fix these issues > permanently, but if the design builds quickly, you can use > the multi-pass place&route to let the tools do it for you. Goood. I made floorplan for dcm and bufg, but floorplanning the signals seems too difficult to me > When you get a placement that works well, you can use > guided placements for subsequent builds assuming your > design changes are small. What is a guided placement? I can keep some of the previous good work locking it somehow? Ciao! AlessandroArticle: 136120
Hi! I'm using blockram which is initialized from a .coe file. I need to often change the initialization data, and every time I have to go through the IP core manager and rebuild the component. On my computer at home, furthermore, I'm unable to run the IP manager due to a lack of ram (512MB) which makes the stupid java machine unable to start. Is there a way to update the blockram content directly? Browsing the source file, I found this line: c_init_file_name => "mem_text.mif", and opening the .mif file resulted in a clearly readable ascii file with binary rapresentation of data, for example "00011100". Unfortunately, modifying this file does not change blockram content on next recompile, even after a cleanup of the project files. Any hint? Ciao and thanks in advance AlessandroArticle: 136121
On 1 Nov., 21:12, Mike Treseler <mtrese...@gmail.com> wrote: > axr0284 wrote: > > 1) If my module detects an address parity error but bit 8 in the > > command register used to turn on system error signaling is set to 0, > > does my system > > a) ignore the command > > b) Responds normally ignoring parity checking > > c) Takes possession of the request by asserting DEVSEL and then sends > > back a target abort. > > I know very little about the PCI spec, > but it seems to me that a or b > would open the door to bugs that > would be difficult to track down. But b) and c) can cause multiple targets to respond to the same cycle because the address is corrupted, which might have been caused at the receiver. I also don't have the spec handy during the weekend, but I would choose a). A corrupted address should not not be treated as an address match. Kolja SulimmaArticle: 136122
On Sun, 2 Nov 2008 08:00:30 -0800 (PST), subbu instru
<gsreddyeee@gmail.com> wrote:
>ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line
>84. /= has two possible definitions in this scope.
It's telling you that...
>library IEEE;
>use IEEE.STD_LOGIC_1164.ALL;
>use ieee.std_logic_unsigned.all;
... there's one definition in here...
>use ieee.std_logic_arith.all;
... and another one in here...
> SUM <= A+B;
... for the operand you use here.
The best solution is to delete BOTH those libraries; neither of them are
standards, and as you can see, they introduce confusing (and possibly
conflicting) definitions.
Then decide whether A, B and Sum are signed or unsigned.
Then use the appropriate type for them, from the ieee.numeric_std
library instead.
use ieee.numeric_std.all;
...
A : in UNSIGNED (8 downto 0);
B : in UNSIGNED (8 downto 0);
SUM : out UNSIGNED (8 downto 0));
...
SUM <= A+B;
...
And the design intent is clearer too.
- Brian
Article: 136123Hi All, I've written a JPEG encoder and inside the module I used the 2D DCT from the Xilinx ISE 7.1 Coregenerator which works very good. Now we want to use this encoder with a Virtex 5 FPGA which isn't supported by den ISE 7.1 but unfortunately the Coregenerator from the ISE 9.1 doesn't support the 2D DCT any more. In the web I found a posting telling that the 2D DCT isn't supported any more (why? ok I think I learned that I only should use the Coregenerator for trivial things like RAMs and FIFOs...) but there was a reference to xapp610 which describes the implementation of an 2D DCT algorithm including sample VHDL code. Unfortunately this code doesn't seem to work. It seems to ignore the bit 7 of the 8 bit inputdata so no negative values are possible and also the results for positive input data doesn't seem to be correct. What I'm looking for is an agorithm written in VHDL (or if that is not possible in Verilog) that performs the 2D DCT 8x8 points with 8 bit signed input data and at least 12 bit signed output data. Does anyone know of such a module or knows what's wrong with the example from the xapp610? Thanks very much for any suggestions. MichaelArticle: 136124
On Nov 3, 5:21=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sun, 2 Nov 2008 08:00:30 -0800 (PST), subbu instru > > <gsreddy...@gmail.com> wrote: > >ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line > >84. /=3D has two possible definitions in this scope. > > It's telling you that...>library IEEE; > >use IEEE.STD_LOGIC_1164.ALL; > >use ieee.std_logic_unsigned.all; > > ... there's one definition in here...>use ieee.std_logic_arith.all; > > ... and another one in here...> =A0 =A0SUM <=3D A+B; > > ... for the operand you use here. > > The best solution is to delete BOTH those libraries; neither of them are > standards, and as you can see, they introduce confusing (and possibly > conflicting) definitions. > > Then decide whether A, B and Sum are signed or unsigned. > Then use the appropriate type for them, from the ieee.numeric_std > library instead. > > use ieee.numeric_std.all; > ... =A0 > =A0 =A0 =A0 =A0 =A0 =A0A : in =A0UNSIGNED (8 downto 0); > =A0 =A0 =A0 =A0 =A0 =A0B : in =A0UNSIGNED (8 downto 0); > =A0 =A0 =A0 =A0 =A0 =A0SUM : out =A0UNSIGNED (8 downto 0)); > ... > =A0 =A0 =A0 =A0 SUM <=3D A+B; > ... > And the design intent is clearer too. > > - Brian hello brian, thank u for given ur valid solution, but still iam getting same error. plese help me with another good solution.
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