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 all, is it possible - in VHDL - to connect the signal from a std./normal IO-Pin with one of the internal BUFGS Clock driver?? markusArticle: 35601
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3BC4C920.7BB7FA99@algor.co.uk>... > > On the specific point you are right in that Synplify doesn't appear to > be using resources efficiently in this case. Esp since it does the reset > function by first inverting the reset input and then feeding the > inverted value into the adder LUTs - missing a clear opportunity to > optimise. The MAP program may do this for you later on. It would have been somewhat impressive if it managed to work the reset function into the adder LUTs. At least this wouldn't have cost anything in terms of size. Instead, it inserted the reset logic after the adder carry chain. The mapper isn't (and shouldn't be) smart enough to fix this. > A work-around is to use an async reset. It would have taken me longer to restructure my logic to use an async reset than it would to simply instantiate the 56 flip-flops. Besides, async resets bring bad luck. :) > On the more general case IMO you are missing some of the idea behind > synthesis from HDLs. This is to get the results you need from the most > portable/maintainable/reuseable/retargetable source format. I'm not missing the point. I'd dearly like to beleive the dogma, but time and time again, I've found that it doesn't even pay to try it. The reality is that the design entry is about 20% of the job for a high speed FPGA design. Far more time is spent trying to figure out how to convince the tools to implement it sensibly. Usually this involves instatiating technology-specific library components. I've found that the fastest way to do a design is to throw away any illusions of portability, etc., and code in a way that allows good control of mapping and placement if needed later. And it WILL be needed for some small percentage of the design. (If you doubt the 20% number, take the example I gave. It takes less than a minute to describe a 56-bit counter. It takes tens of minutes to compile the design, find out that the counter isn't meeting spec, push into the chip editor or floorplanner to find out why, and then hack at the code to fix it. Of course this doesn't count the extra time spent whining about it on comp.arch.fpga) > This is very much in the spirit of the `C' vs. Assembler > debate of long ago. It's similar, but not the same thing. For an FPGA design, there is usually a hard performance limit. There is a fixed clock rate, and a fixed number of resources. When the design violates those limits, it doesn't work. Software has soft limits. It has nearly unlimited virtual memory, and time limited only by the user's patience. A factor of 2 performance hit doesn't break the software. > Again IMO the question you need to ask is whether the synth'ed result > meets your needs in terms of speed/timing. If not then the second level > question is whether, in a time2market dominated industry, going up a > speed grade is better than spending a lot of time hand-tuning the logic. > Its always possible to hand-craft technology specific logic that goes > faster - the question is whether its worth it. YMMV.Article: 35602
Hello All, I've inherited a design from a departed employee who was kind enough to route all of his 23 (yes, 23!!!) FPGA clock signals on general routing resources in an Altera FLEX 10KA. Of course, I saw this and attempted to re-architect the clocking scheme and place all clocks on GLOBAL buffers. Apparently, the use of a GLOBAL in 10KA requires availability of the associated pin. Unfortunately, all 4 of the pins associated with GLOBALs are already being used for standard I/O. I've been told board-level mods are out of the question for the features I'm adding to the FPGA, so swapping pins at this point is not an option. My question is this: Does placing an internal signal on a GLOBAL macro cause the associated pin to be driven by that internal signal or is the pin just tri-stated and unavailable for use? Thanks, Stephen ByrneArticle: 35603
On 11 Oct 2001 05:12:33 -0700, eas@bi.net.tr (eas) wrote: >"Bhaskar Thiagarajan" <bhaskart@my-deja.com> wrote in message news:<9q1sqq$loqqh$1@ID-82263.news.dfncis.de>... >> Clock recovery is a very important part of receivers and is discussed pretty >> much in every communications text. There are various methods to perform this >> function, but some of the common methods are well described (Ray just >> described one using PLLs). >> If you want to perform this block in real time at that kind of data >> rates...FPGAs/ASICs are your only choice. But if you can store a large >> amount of data and post process this, you can probably do this on a DSP. >> Search for key words like clock recovery, Costas Loop, etc. I doubt if you >> will find detailed examples of implementation other than descriptions on how >> this is typically done. >> -- >> Cheers >> Bhaskar >> Note: I do *not* check the listed email address. >> > >OK. Now I have to ask some question: >1. Where can I find the basic building blocks examples to perform the >clock recovery in FPGA? Can't help ya there. >2. Some texts explain clock recovery for NRZ data, How should I >process IQ data to put in a suitable form? You need to find a suitable phase detector for your data, but it only needs to be applied to either I or Q, not necessarily both. >3. I read a text that DPLL is suitable for data rates <10Mbps. Is this >true? It depends on the implementation. Usually a DDS (aka NCO) is used to generate the recovered clock, and if the input system clock to the DDS is not sufficiently higher than the symbol rate, you may wind up with an unacceptably jittery output clock. Since it is not uncommon to clock DDS blocks, even in FPGAs, at hundreds of MHz now, it shouldn't be tough to go well beyond 10Mbaud. How high you can get will still depend on your implementation. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://home.earthlink.net/~ejacobsensprintArticle: 35604
Hi all,
For an airborne hardware project, we are considering the use of FPGA's. The product must be designed in accordance with DO-254/ED-80 "Design assurance guidance for airborne electronic hardware", which is, as you may know, the relatively new hardware counterpart of DO-178B. Part of the design for which an FPGA seems a good technical solution, is considered to be level A. The DO-254 requires any tools used for development of such parts to be qualified, to minimise the risk of introduction of errors by the design tool. Tool qualification is apparently far from trivial, and therefore not an option to perform as part of the project. Does anyone know whether DO-254-qualified design tools (e.g. synthesizer, mapper) exist at all?
Thanks in advance for your help,
Alte
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Note: when replying by email, please remove
the spam block from my e-mail address
Article: 35605
Unfortunately, it does not seem to recognize the use of GSR. If you put a global
reset on everything, it stays in your design. TO get it to come out, you then put a
ROC or startup component (black box) on the global reset and the mapper will take it
out....If you put the global reset on all inferred registers. As Allan points out,
if you need to preset registers, you need the global reset in there, otherwise
everything clears on start up. The only work around I have found to date is to
instantiate FDR's when I need them. Not too clean.
It is a basic problem that stems from the primitive models I think, since there is
no global reset pin on them the global reset can't be shown as a net in the HDL.
The work around has been to put the GSR into the reset pin on the FFs, which works
only if your local reset is also async (the synthesis ORs them).
Allan Herriman wrote:
> On Thu, 11 Oct 2001 13:56:02 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >If you have a global reset in your design, synplicity won't also use the reset
> >input to the FF because it doesn't recognize the global reset as being a hidden
> >dedicated net. I still have not found a satisfactory work around for this.
>
> Hi Ray,
>
> It used to recognise the global reset. This led to a problem with
> 6.0.0 in that it would remove the redundant reset from the EDIF which
> in turn meant that it didn't retain the reset value (0 or 1) that you
> had asked for. The back end tools would substitute the default (0).
>
> Bad luck if you wanted 1.
>
> AFAIK I was the first user to report this bug (and it took some weeks
> to convince them that it was a bug). I wonder if the fix in more
> recent versions of Synplify involved removing the ability to recognise
> the use of GSR?
>
> Regards,
> Allan.
>
> >Andrew Brown wrote:
> >
> >> The designers code was very clear and stated exactly what he wanted ! Maybe
> >> synthesis vendors forget that their tools should synthesis out code - we
> >> won't code to suit them. Code should be oriented toward fast and efficient
> >> simulation where most designer time is spent. I wouldn't change code just
> >> to make synthesis work a little better (back to the point about not minding
> >> a few extra gates). But i do expect synthesis tools to learn how to
> >> implement the code better - as for the architecture - the origional post
> >> didn't specify the device (xilinx infered?) so i don't know if an explicit
> >> synchronous reset is available - i assume it is - in which case it should
> >> have been used.
> >>
> >> A.
> >>
> >> P.S. since we started on coding style :? is outlawed in C these days - it
> >> should probably so the same way in verilog !
> >>
> >> "Lähteenmäki Jussi" <jusa@cc.tut.fi> wrote in message
> >> news:9q3saf$hqh$1@news.cc.tut.fi...
> >> > Don Husby <husby_d@yahoo.com> wrote:
> >> >
> >> > I dont know that much about verilog, but what I see in your
> >> > code is (in my opinion :) ) a synchronous reset, which ofcourse can
> >> > not be fed directly to the asynchronous reset inputs of the flip-flops.
> >> >
> >> > So the counter is actually very optimized, its the designer who is not
> >> > in this case :) Furthermore, counters synthesize very efficiently in
> >> > todays tools, if used properly (the hdl code is clear). In any
> >> > commercial product I would advise to construct all counters from smaller
> >> > counters, say 4-bit counters. It eases the final production testing.
> >> >
> >> > cya,
> >> > juza
> >
> >--
> >--Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930 Fax 401/884-7950
> >email ray@andraka.com
> >http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35606Rick Filipkiewicz schrieb: > > much in the spirit of the `C' vs. Assembler debate of long ago. Memory > got bigger and cheaper, uPs got faster, and compilers got better => > Assembler went Dodo for all but a handful of special cases. Similarly > FPGA and ASICs are getting bigger and faster so the inefficiencies of > synthesised code will become less important [synth tools are getting > better as well, as are FPGA/ASIC P&R tools]. Sadly, you are right. BUT my inner voice says DONT LETS THOSE SOFTWARE-CRAP BE YOUR GUIDE. I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP. I wont complain about a few LUTs or FF wasted, an for many design the speed limit of the FPGA is far higher than required, but in general I would like to do good, fast and slim designs. Not this loser C++ crap ;-) -- MFG FalkArticle: 35607
Don Husby schrieb: > > It would have taken me longer to restructure my logic > to use an async reset than it would to simply instantiate > the 56 flip-flops. Besides, async resets bring bad luck. :) Simply synchonize it, so its synchronus again but uses the advantages of the asynchronous inputs. -- MFG FalkArticle: 35608
Markus Meng schrieb: > > Hi all, > > is it possible - in VHDL - to connect the signal from a > std./normal IO-Pin with one of the internal BUFGS Clock > driver?? AFAIK yes, bacaus in the XL, the buffers can be driven from any internal net. But the delay pad-buffer will be different, so the timing at the IO is different. -- MFG FalkArticle: 35609
On Thu, 11 Oct 2001 10:29:35 +0000 (UTC), Lähteenmäki Jussi <jusa@cc.tut.fi> wrote: >Don Husby <husby_d@yahoo.com> wrote: > > I dont know that much about verilog, but what I see in your >code is (in my opinion :) ) a synchronous reset, which ofcourse can >not be fed directly to the asynchronous reset inputs of the flip-flops. >Furthermore, we cannot implement such a huge counter with only 56 LUTs. >Normally, LUTs are say 4 input memory blocks, in which case we can do >any logical function of four inputs and one output. However, the highest >bit of the 56-bit counter needs the 55 lower bits in its enable input >plus the one used for enabling the actual counter. This is true for all >the bits, which increases the number of LUTs signicantly. I would bet >that 8-bit counter of the same type would consume about 12 LUTs (without >knowing the targer device). I dont know much about anything, but what I see in your answer (in my opinion :) ) is that you dont know much about common current FPGAs . While Don did not mention which FPGAs he is targetting, almost all FPGAs with 4 input LUTs have something called Carry-Logic, which means that they can implement a counter at a cost of 1 LUT per bit. In Xilinx Virtex, Virtex-E, Virtex-EM, Virtex-II, and Spartan-II parts, all the flipflops include synchronous or asynchronous reset capability. Your following recomendation of cutting the counter up into little 4 bit pieces might make sense if you were still playing with 74161 type devices, but it has not been true of RAM based FPGAs ever! (May still be appropriate for antifuse FPGAs, but no-one uses them). (in my opinion :) ) Philip >So the counter is actually very optimized, its the designer who is not >in this case :) Furthermore, counters synthesize very efficiently in >todays tools, if used properly (the hdl code is clear). In any >commercial product I would advise to construct all counters from smaller >counters, say 4-bit counters. It eases the final production testing. > >cya, >juza Philip Freidin FliptronicsArticle: 35610
Austin Lesea schrieb: > > > I hope you (soon) encounter a requirement where Virtex II is a suitable > choice. I hope too. BUT, in a current design (got a V200-E on it) it was a really HARD fight to convince the other guys (especially our customer) to use the FPGA and not an ASSP, they all were afraid of the development failure (or at least heavy delay) possibility. Finally they could not reject the FPGA, because space was absolutely not available (unless we start soldering the BGAs vertically ;-) Again, does anyone have some pointers to ressources regarding DDR Xmission (not just Xilinx papers). I had a look at some JEDEC standards, but this is not that valueable. -- MFG FalkArticle: 35611
As someone who has several years experience writing complex designs in VHDL and C++, in a friendly way I urge you to consider that as your experience grows you may come to see the meaning of 'good', 'fast' and 'slim' in different ways. If C++ or VHDL allows a good, fast, and slim - and solid, reusable - specification of your design at that high level, that may be worth a hundred times over any wasted gates and slow speed in the result, so long as its implementation performance is adequate. In that sense then, your design continues to be good, fast and slim, probably more so than ever before. Specifically on C++, it really is worth persuing the tenets of that faith before writing it off - it may change your view of things. However, if you take heed or not, best of luck! |Sadly, you are right. BUT my inner voice says | |DONT LETS THOSE SOFTWARE-CRAP BE YOUR GUIDE. | |I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP. |I wont complain about a few LUTs or FF wasted, an for many design the |speed limit of the FPGA is far higher than required, but in general I |would like to do good, fast and slim designs. Not this loser C++ crap |;-) | |-- |MFG |Falk -- Posted using Nographer - News in your Browser http://www.nographer.com - free, open source, and smartArticle: 35612
> Andrew Gray wrote: > > Here is my code: > -------------------------------------------------------------------------------- > -- Specify Libraries. > -------------------------------------------------------------------------------- > library IEEE; > use IEEE.std_logic_1164.all; > use IEEE.std_logic_arith.all; > use IEEE.std_logic_unsigned.all; > use IEEE.std_logic_signed.all; DON'T use both std_logic_unsigned and std_logic_signed in the same entity. Things get mighty confused re: operator overload. Use numeric_std instead. --aArticle: 35613
TEAC Inc. www.teacinc.com successfully does BGA placement for our company. Regards, Alex "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message news:3BC45F0F.76249EF@egr.msu.edu... > Can anyone recomend a contract assembler for a few small printed > circuit boards that will contain a BGA based package? The production > quantities will be quite small (10 pieces for the first run, no more > than 50 pieces for subsequent runs) but I cannot assemble or inspect BGA > packages. I am especially interested in manufacturers in the midwestern > USA and especially in Michigan. > > Thanks, > Theron Hicks > >Article: 35614
"Falk Brunner" <Falk.Brunner@gmx.de> wrote > Again, does anyone have some pointers to ressources regarding DDR > Xmission (not just Xilinx papers). I had a look at some JEDEC standards, > but this is not that valueable. Try the Micron site and the Advanced Memory Systems (AMS.org????) site.Article: 35615
Thanks for the defense, but please be careful with attributions. You made it look like I wrote that nonsense instead of Lähteenmäki Jussi. Philip Freidin <philip@fliptronics.com> wrote in message news:<9vjbst4i5ma5f3jn08vtqds10dvrnkhtjb@4ax.com>... > On Thu, 11 Oct 2001 10:29:35 +0000 (UTC), Lähteenmäki Jussi <jusa@cc.tut.fi> > wrote: > >Don Husby <husby_d@yahoo.com> wrote: > > > > I dont know that much about verilog, but what I see in your > >code is (in my opinion :) ) a synchronous reset, which ofcourse can > >not be fed directly to the asynchronous reset inputs of the flip-flops. > >Furthermore, we cannot implement such a huge counter with only 56 LUTs. > >Normally, LUTs are say 4 input memory blocks, in which case we can do > >any logical function of four inputs and one output. However, the highest > >bit of the 56-bit counter needs the 55 lower bits in its enable input > >plus the one used for enabling the actual counter. This is true for all > >the bits, which increases the number of LUTs signicantly. I would bet > >that 8-bit counter of the same type would consume about 12 LUTs (without > >knowing the targer device). > > I dont know much about anything, but what I see in your answer > (in my opinion :) ) is that you dont know much about common current > FPGAs . > > While Don did not mention which FPGAs he is targetting, almost all > FPGAs with 4 input LUTs have something called Carry-Logic, which > means that they can implement a counter at a cost of 1 LUT per bit. > > In Xilinx Virtex, Virtex-E, Virtex-EM, Virtex-II, and Spartan-II parts, all > the flipflops include synchronous or asynchronous reset capability. > > Your following recomendation of cutting the counter up into little 4 > bit pieces might make sense if you were still playing with 74161 > type devices, but it has not been true of RAM based FPGAs ever! > (May still be appropriate for antifuse FPGAs, but no-one uses them). > > (in my opinion :) ) > > Philip > > >So the counter is actually very optimized, its the designer who is not > >in this case :) Furthermore, counters synthesize very efficiently in > >todays tools, if used properly (the hdl code is clear). In any > >commercial product I would advise to construct all counters from smaller > >counters, say 4-bit counters. It eases the final production testing. > > > >cya, > >juza > > Philip Freidin > FliptronicsArticle: 35616
No one seem to make any comments about this topic, so I will chip in
my two cents.
OpenCores.org (http://www.opencores.org) seems to be working on a PCI
IP core of their own (http://www.opencores.org/cores/pci/), but it
doesn't look like it is done, and it is written in Verilog.
According to the OpenCores.org PCI IP core project page under "Links
to related sites and documents"
(http://www.opencores.org/cores/pci/pci_links.shtml) a company called
MaxLock (http://www.maxlock.com) used to offer a free PCI IP core in
VHDL, but it seems like it no longer does.
So, in my opinion, there is no free lunch in this world.
From my own experience developing (still not done completely)
a PCI IP core in Verilog using Xilinx ISE WebPack, it takes some time
(several months working part-time on this) to do the RTL part of it.
After the RTL part is done, you have to do Place & Route (P&R) to fit
the design into the chip, but I think that is where things get tough.
In 33MHz PCI, Tsu (setup time) has to be within 7ns, and Tval
(Clock-to-Output Valid) has to be within 11ns.
For P&R, I only used only User Constraint File (.UCF), and didn't use
Floorplanner.
After P&R, the input pin that had the worst Tsu was around 9ns, and
the output pin that had the worst Tval was around 15ns.
Those results were for Xilinx Spartan-II 150K system gates part speed
grade -5, and if I used speed grade -6 (which is not an option in my
case), the input pin that had the worst Tsu came down to around 7.7ns,
and the output pin that had the worst Tval came down to around 12ns.
Speed grade -5 violated about 75 constraints compared to about 58 for
speed grade -6.
So, at least in my case, my HDL-based PCI IP core cannot meet the
timings of 33MHz PCI for Spartan-II speed grade -5 or -6 with only
automatic P&R.
Therefore, from my experience, just because you got a synthesizable
PCI IP core from somewhere doesn't mean that such IP core can meet PCI
timings.
I used Insight Electronics Spartan-II PCI development board which has
Xilinx Spartan-II 150K system gates part (XC2S150, speed grade -5, 208
pin PQFP package) on it with 8MB of SDRAM on board for only $145
without Xilinx PCI LogiCORE license.
Very nice board considering the price, but I guess I wish they used
speed grade -6 instead of -5.
Although, I keep emphasizing that it is hard to meet timings
of 33MHz PCI, and I am sure other people will say something similar,
what I have noticed was that violation of up to 5ns doesn't seems to
matter that much if the objective is to just to get the PCI board to
"barely" work.
I tested my own PCI IP core with Insight Electronics Spartan-II PCI
development board, and the board worked fine at PCI running at 33MHz
with both Intel 430TX chipset and SiS 5598 chipset.
The user logic I attached to the PCI IP core was a very simple one
that responds only to I/O cycles, and not memory cycles because I can
access I/O ports through real or V86 mode, but I will have to do a lot
of software writing to access a memory-mapped device that is located
near the top of the 4GB memory space.
Of course, the PCI IP core supported configuration cycle, too.
The worst Tsu was I think around 10 or 11ns, and the worst Tval was
around 15.5ns, and I think it was TRDY#.
I do understand that a lot of people reading comp.fpga.arch will
criticize me for writing something like, "my design worked fine even
though I didn't meet the timings required by the specification," but
the board somehow worked.
I don't have the money to buy an oscilloscope or a logic analyzer, or
know someone who will let me use them, so I really don't know what is
going on the PCI bus.
The most accurate data I got was from post-place & route simulation I
did with ModelSim XE-Starter.
I have absolutely no intention to advocate violating timing
specification, and if someone were to sell a PCI card, that person has
to make sure that timings are met.
But I suppose for a student project (I am guessing), barely working
(not meeting timings) is probably acceptable since the student never
has enough time to complete the project.
So, my conclusion here will be that you may have to develop
your own PCI IP core which can take months, and it will be tough for a
synthesizable PCI IP core without using Floorplanner to meet 33MHz PCI
timings, but if your objective is to make it barely work somehow, then
violating 33MHz PCI timings may not be a big issue.
Regards,
Kevin Brace (don't respond to me directly, respond within the
newsgroup)
"Ras Sim" <simsek@rhrk.uni-kl.de> wrote in message news:<49a92f681fea693317ee5a82213a3519.32396@mygate.mailgate.org>...
> Hi folks!
> I'm a student and i need a free PCI-Core wich is written in vhdl.
> Where could I download it ?
>
> Greets
> Rasit
Article: 35617I wrote > "Falk Brunner" <Falk.Brunner@gmx.de> wrote > > > Again, does anyone have some pointers to ressources regarding DDR > > Xmission (not just Xilinx papers). I had a look at some JEDEC standards, > > but this is not that valueable. > > Try the Micron site and the Advanced Memory Systems (AMS.org????) site. > AMS is here: http://www.ami2.com/online_info.aspArticle: 35618
husby_d@yahoo.com (Don Husby) wrote in message news:<35802095.0110101232.6249a107@posting.google.com>...
> More wacky synthesis results from Synplicity:
>
> (Note that this sort of thing isn't specific to
> Synplicity. Leonardo does a lot of wacky things too.
> Sadly, Synplicity is probably the better tool.)
>
> You'd think a simple 56-bit counter would be no
> problem. The code below should synthesize to
> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
> Instead, Synplicity adds an extra 57 LUTs and an extra
> level of logic.
>
> module Cnt56(K, CE, R, Out);
> input K, CE, R;
> output [55:0] Out;
> reg [55:0] Q;
> assign Out= Q;
> always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
> // if (R) Q <= 0; // This doesn't work either
> // else if (CE) Q <= Q+1;
> endmodule
>
> Why? Instead of running the R signal directly to the
> reset pin of the flip flop, Synplicity merges it into
> the equations for Q and CE. So we get:
>
> module Cnt56(K, CE, R, Out);
> input K, CE, R;
> output [55:0] Out;
> reg [55:0] Q;
> assign Out= Q;
>
> wire [55:0] Q_plus_1 = Q+1;
> wire [55:0] Q_and_R = R ? Q_plus_1 : 0;
> wire CE_or_R = CE | R;
>
> always @(posedge K) if (CE_or_R) Q <= Q_and_R;
> endmodule
>
The tool does precisely what you ask for - it implements a synchronous
reset since R is not in the sensitivity list.
If you need to reset the counter asynchronously, you must use "an
always statement whose event list contains edge events representing
the clock and asynchronous control variables".
Try this.
module Cnt56(K, CE, R, Out);
input K, CE, R;
output [55:0] Out;
reg [55:0] Q;
assign Out= Q;
always @(posedge K or posedge R)
if (R) Q <= 0;
else if (CE) Q <= Q+1;
endmodule
I do not have Synplicity, but with Leonardo it works perfectly well.
And the global reset is another issue. A tool may recognize it or not,
depending on the code and the tool capabilities. So it may be either
the global (chip wide) reset, or just an asynchronous reset, which can
be assigned to an IO pin, or used locally.
Regards,
Vitaliy
Article: 35619In article <a03b733b.0110111857.60281841@posting.google.com>, vitaliyt@xillix.com wrote: >husby_d@yahoo.com (Don Husby) wrote in message news:<35802095.0110101232.6249a107@posting.google.com>... >> More wacky synthesis results from Synplicity: >> >> (Note that this sort of thing isn't specific to >> Synplicity. Leonardo does a lot of wacky things too. >> Sadly, Synplicity is probably the better tool.) >> >> You'd think a simple 56-bit counter would be no >> problem. The code below should synthesize to >> 1 logic level using 56 LUTs, 56 FFs and a carry chain. >> Instead, Synplicity adds an extra 57 LUTs and an extra >> level of logic. >> >> module Cnt56(K, CE, R, Out); >> input K, CE, R; >> output [55:0] Out; >> reg [55:0] Q; >> assign Out= Q; >> always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q; >> // if (R) Q <= 0; // This doesn't work either >> // else if (CE) Q <= Q+1; >> endmodule >> >> Why? Instead of running the R signal directly to the >> reset pin of the flip flop, Synplicity merges it into >> the equations for Q and CE. So we get: >> >> module Cnt56(K, CE, R, Out); >> input K, CE, R; >> output [55:0] Out; >> reg [55:0] Q; >> assign Out= Q; >> >> wire [55:0] Q_plus_1 = Q+1; >> wire [55:0] Q_and_R = R ? Q_plus_1 : 0; >> wire CE_or_R = CE | R; >> >> always @(posedge K) if (CE_or_R) Q <= Q_and_R; >> endmodule >> > >The tool does precisely what you ask for - it implements a synchronous >reset since R is not in the sensitivity list. >If you need to reset the counter asynchronously, you must use "an >always statement whose event list contains edge events representing >the clock and asynchronous control variables". > >Try this. > >module Cnt56(K, CE, R, Out); > input K, CE, R; > output [55:0] Out; > reg [55:0] Q; > assign Out= Q; > always @(posedge K or posedge R) > if (R) Q <= 0; > else if (CE) Q <= Q+1; >endmodule > >I do not have Synplicity, but with Leonardo it works perfectly well. >And the global reset is another issue. A tool may recognize it or not, >depending on the code and the tool capabilities. So it may be either >the global (chip wide) reset, or just an asynchronous reset, which can >be assigned to an IO pin, or used locally. > >Regards, >VitaliyArticle: 35620
On 11 Oct 2001 19:57:59 -0700, vitaliyt@xillix.com (Vitaliy Tkachenko) wrote: >The tool does precisely what you ask for - it implements a synchronous >reset since R is not in the sensitivity list. >If you need to reset the counter asynchronously, you must use "an >always statement whose event list contains edge events representing >the clock and asynchronous control variables". Apparently, more than 1 person is under the impression that I wanted an asynchronous reset. What I wanted (and what I got) was a synchronous reset. Unfortunately, the synchronous reset was implemented using 57 LUTs and an extra level of logic instead of simply routing the reset signal to the synchronous reset input of the flip flops. Sorry I didn't make this clear the first time.Article: 35621
Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs. What are the advantages & disadvantages of each of them from the Users perspective?Article: 35622
Xilinx has 4Kbit BlockRAMs in Virtex and Virtex-E, and 18Kbit BlockRAMs in Virtex-II. The advantage of either must be very applications-dependent. Obviously, the user can concatenate several small RAMs into a large one, but that wastes performance and area. Obviously, a large RAM appears wasteful when you need a little one, but Xilinx can always offer the 16-bit distributed RAMs that Altera does not have. I found good use for the larger, and especially wider BlockRAM ( 512 x 36, and dual-ported on top! ) for unconventional applications. Your mileage may vary... Peter Alfke Gautam wrote: > Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs. > What are the advantages & disadvantages of each of them from the Users > perspective?Article: 35623
One more thing: If you need more, but smaller RAMs, you can always make two fully independent single-port RAMs out of one dual-ported RAM ( Tie address MSB High in one port, Low in the other ) Pretty simple, but often overlooked. Peter Alfke =========================== Gautam wrote: > Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs. > What are the advantages & disadvantages of each of them from the Users > perspective?Article: 35624
hi, check whether your component entity declartion and entity you have placed in your top level match.check for signal type also. from your package declartion you can remove ieee.std_logic_signed.all can you post code for your component? regards bala
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