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 Phillip, > Thanks for the reply. I incorporated the component into a synchronous > process and it works fine now. However, I still have a few questions > just so I can get a better understanding of what was going on. > >> The way you have written this code will make sure that Modelsim only >> 'schedules' the process if A_in or B_in changes. > > That was my intention. I wanted the output to change *only* when one > of the two inputs changed. I see what you mean that the 'internal > states' were not counted as inputs though. So, how would you go about > making this component so that it will change state only when the input > changes? VHDL was initially designed as a simulation laguage based on ADA using concurrent processes and the lot. Using the sensitivity list you could pick which set of events could trigger scheduling of one such process during simulation. The 'synthesizable subset' of VHDL, be it the 1987, 1993 or 200x version, has the requirement that a process by nature is sensitive to any signal or port to the right of an '<=', unless it's within a "clk'event or clk='whatever' block. This will cause a process(a,b) not only to be 'scheduled' when a or b changes, but whenever any input in any of the internal statement changes. This is inherent to the fact that within a process you are merely decribing a more or less complex set of combinatorial equations, possibly ending in a bunch of registers at the end (which are inferred by the clk'event stuff). So, at this point I don't see an easy way to do this, unless you want to use the a and b signals as true and inverted clocks to a set of toggle registers and use the relative state of these registers as your state vector. >> If you synthesize this with Quartus (or any synthesis tool for that >> matter) you will get warnings that state(1) and state(0) should also be >> on the sensitivity list. > > In fact, Quartus gives the following message: "Design > top_quadrature_decoder: Netlist extraction and synthesis were > successful. 0 errors, 0 warnings" I think you should get a warning that something else should be on the sensitivity list as well. I'll give it a try on monday and file an SR if I don't get one. >> Even though I hate using the /= operator on a std_logic. > > Is this just a personal preference? or is there a reason one should > avoid the /= operator? A bit only has values '0' and '1', so saying "if x /= '0'" basically means "if x = '1'", so no problem there. However, a std_logic has seven possible values, so saying "if x /= '0'" basically means "if x='1' or x='Z' or x='H' or x='L' or x='X' or x='U'". Most of these don't make sense during synthesis and ar happily ignored, but I've had two cases where such a comparison was made on a signal that was part of a tri-state bus somewhere upstream, and the 'Z' (or tri-state) case was taken into account as well, causing a lot of initialy inexplicable behavior. Best regards, BenArticle: 74076
Rick, I can not say how long, because that is proprietary information. I know exactly how long it takes to test the CLB, BRAM, DCM, PPC, MGT, etc. Exactly. Austin rickman wrote: > austin wrote: > >>Rick, >> >>Configuration of a test pattern can make efficient use of our partial >>reconfiguration capabilities. I can not say how many seconds an FPGA >>spends in the tester, but it is less that an ASIC does. There also may >>be much faster ways to configure that we can use, but do not offer to >>customers. > > > Austin, if you don't know how much time it takes to test your FPGAs, > then how can you possibly say it is faster than an ASIC that you also > don't know the test time for??? I think you and Peter are talking > through your hats on this one. Much like the other arguments that FPGAs > are better than ASICs that pretty much ignore the fact that an ASIC can > be done using several generations older technology to get the same > overall costs. Your 90nm chips may be very dense, but they are using > the most expensive equipment around and automatically have a 10:1 hit in > most areas of cost. > > > >>Why can we do 1,000's of BIST patterns faster? Well one obvious reason >>is that a BIST pattern in a FPGA can run at the speed of the FPGA, which >>is often 10X to 100X faster than the tester. It might have to run for >>1000 clocks to finish, and then go on to the next test, which might be >>different by the contents of a few LUTs. >> >>If you are really curious of how we perform this magic, you can research >>all of our BIST patents and think about what you would do if you faced >>such a problem. >> >>Again, Peter is right. > > > I am sure Peter is right about a lot of stuff. But you don't provide > any information that shows he is right about this. >Article: 74077
Rick, see below Austin rickman wrote: > austin wrote: > >>Rick, >> >>Bad hair day? > > > Austin, Peter sends me private emails asking me to ignore your > nonsense. I will discuss it with Peter. As well, I have no shortage of folks who email me directly or on this board to let me know if they do not like a posting. He tells me you are a valuable asset to this group because > you have significant knowledge. Untrue. I have only been at Xilinx for 6 years, before that I spent 26 years in the telecom business. What I know about ICs and FPGAs has been gained from 6 produt releases. There are many at Xilinx with many many more years, and products, under their belts than I. I consult them for my responses, as I by myself, am nothing. But your BS is enormous. No need to be insulting. This comment > is the sort of thing that is not welcome in the group, at least by me. > If you want to discuss the issues, then leave the crap at home. I find > you to be a very unprofessional representative for Xilinx and I have > even told my local sales people that. I have not heard this feedback. Let me know who you contacted. It is important to me that all feedback get back to the people who should hear it. I don't know if this ever makes > it back to your managers, but I sincerly hope that I never have to > depend on you for any sort of support. In fact, you personally are one > of the reasons that I keep looking at the solutions offered by Altera, > and have ended up filling at least one of the sockets on our boards with > an Altera part. I am sorry if I have offended you in any way. I have no idea what I have done. My managers are well aware of my postings, as well as what people say about me. If there is something you feel they should know, email me directly and I will give you their email addresses so you may reply in private to them. Or post it here. If you wish, I can be reached directly by this email address. I am always willing to listen to how I can improve.Article: 74078
MK, Unfortunately, I do not. My information was from word of mouth from IC designers that worked at Intel, but are no longer there. It counts every single FF added for capture, scan chain, as well as all test loopbacks, multiplexers, etc. that are added for any reason that is not purely functional. I know that there is not that much area added to the IBM 405PPC, and not that much added to the MGT, etc. but the Pentium is much more complex, and may require more logic for test reasons to get better coverage. If I find a reference, I will post it. As I said to Rick, I really don't know all that much, but I am a good listener. And when I listen to IC designers talk about what they did, and so forth, I do remember what they say. Austin mk wrote: > On Fri, 01 Oct 2004 07:54:13 -0700, Austin Lesea <austin@xilinx.com> > wrote: > >>30%+ of a Pentium IV is BIST logic > > > I find that very hard to believe. Do you have any references to back > up that claim ? >Article: 74079
Martin Schoeberl wrote: >>Martin- It makes sense that integrating ram replacing external memory > > would > >>reduce pin count etc, the confusing part of your message is realted to > > this > >>thread being NV memory oriented. Do you want your 128KB on chip memory >>truly for ram or for code storage? Does that relate to the NV aspect > > of the > >>discussion for those low density devices you mention? >>-cheers > > > It does not direct relate to the NV aspect, but Paul was talking about > the SRAM contained in an FPGA. So I throwed in my larger SRAM wish. This Code-Ram should also be able to be Wide path and split, so that multiple cores can be supported, with wide opcodes if desired. Given the relatively high Static Icc now of FPGAs, it would also make sense to look at Self-refresh DRAM - DRAM is much more die efficent. > For code memory I'm happy with larger serial Flash chips when I can access > them from the FPGA. Here the pin count is not so problematic and I know > Flash integration is problematic from the technology point. Serial 'Data Storage' Flash is getting better all the time, and could serve as code memory in some instances. 'Jumps outside the Cache' would be relatively costly, but the streaming speeds are getting quite good. -jgArticle: 74080
Antti Lukats wrote: > Hi > > I would like to quote Martin Schoeberl: "And a MB on an Altera FPGA, that's > the end of the world." > > Well the end of the world must then be TODAY? > MB is working in Cyclone FPGA, screenshots available: > > http://uclinux.openchip.org/forum/viewtopic.php?t=11 Impressive, Wonder when we will see NIOS-II on Spartan-3 ;) -jgArticle: 74081
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cjm4ke$p5$1@news.netpower.no>... > "Antti Lukats" <antti@case2000.com> wrote in message > news:cjjtgn$mp6$03$1@news.t-online.com... > > "Jon Beniston" <jon@beniston.com> wrote in message > > news:e87b9ce8.0410010514.6fa501a@posting.google.com... > > > > # Xilinx benefit if MicroBlaze is in the news > > > > > > > > # Such efforts expand usage of, and research in, MicroBlaze > > > > > > > > # It can be a usefull second opinion / benchmark > > > > > > > > # Xilinx will have trademark rights to MicroBlaze, so they can > > > > restrict use of the name. Other examples of this are 6805 uC and i2c > > > > instances. > > > > > > > > # The open source core is only a tiny portion of system development: > > > > you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of > > > > those will have Xilinx license restrictions for Xilinx FPGAs. > > > > > > Actully, the compiler & I believe the debugger are open source. This > > > means that people are very close to having everything for free. > > > > 1) The compiler and binutils are GPL GNU stuff - that is Xilinx *must* > > provide the source of the those GNU tools in source code form at no > charge, > > what they are doing, the gnu source of the tools is freely available from > > Xilinx. And due to the GPL licensing they can not limit the access to that > > source code. > > Xilinx don't have to provide the source free of charge. What they have to > do is provide an offer to those who have access to the binaries, offering > them the source code for no more than a reasonable distribution fee. They > have no obligation to make the source code available to anyone else, nor do > they have to make it free (as in beer), only free (as in speach). However, > if someone buys a MicroBlaze development kit including the compiler, etc., > then Xilinx must provide the source code to that someone, and they can then > pass it on freely if they want. What this boils down to is that Xilinx has > no obligations to make the tools easily available, but if someone posts the > tools on opencores then Xilinx cannot complain (except perhaps regarding > trademarks on the name). They do actually provide the source code for free. There is a link on their web site. Cheers, JonBArticle: 74082
Martin Schoeberl wrote: > > You can find a 6809 with VGA, UART and keyboard controller running on the > Starter Kit at: > http://members.optushome.com.au/jekent/Spartan3/index.html > > Martin Thanks! (so I guess similar 8-bit processors should be on its limits.) Here follows more newbie-questions. As the Spartan-3 Starter Kit comes with only sixty days evaluation version of "ISE Foundation", and not time-limited version of "ISE WebPACK", I listed their differences from http://www.xilinx.com/ise/devsys_feature_guide.pdf and realized that WebPACK is lacking at least these features that come with the Foundation: CORE Generator System Modular Design FPGA Editor with Probe SMARTModels for PowerPC and RocketIO. What are these, and how essential they are if I (eventually/immediately) want to do my own designs? Also, does WebPACK support both VHDL and Verilog fully? Anybody knows if there there plans to port it (WebPACK) to Linux or other Unix-systems, and when? (And similar question for Altera's Quartus-II software.) Yours, AnttiArticle: 74083
> 2) It is not of big news yet, but the new EDK software ide is based on > Open-Source Eclipse Platform as well, but Eclipse licensing is different so > using Xilinx Eclipse tools is possible not free, but as Eclipse itself is > free and Open-Source there are no limitations for 3rd parties to develop > Eclipse based IDE for the Open-Source M*Blaze No doubt their version of eclipse will be based on the standard C/C++ plugin with a few extras. It's already pretty easy to set eclipse up to target MicroBlaze / NIOS / any other GNU toolchain based processor. Cheers, JonArticle: 74084
Hi, whatisasics wrote: > Antti Lukats wrote: > >> http://uclinux.openchip.org/forum/viewtopic.php?t=4 >> >> here is proof :) >> >> the opensource version as available from opencores is not yet good >> enough to >> run uCLinux - well lets see if that will change, >> I think there is a wish to have an open-souce multi-vendor FPGA softcare >> capable to run uCLinux inside many people :) > > And this is what irks me...if you "need" a "free" FPGA cpu core, there > are already several to choose from (www.opencores.org.) One of them > even has a full GNU-tool chain. So what makes the Microblaze so > special? Is it because it has some industry recognition, better > performance/functionality, or is it simply because more people have > already used it, and want to continue use what they're familiar with? > > Maybe it's because Xilinx poured in a lot of R&D into Microblaze, > proved the design, and are committed to future support of it. > Enough customers haved used the design that people in the industry > collectively 'know' its strengths/weaknesses. I think the reasons our mb-uclinux project is a success, with high visibility and good commercial and academic penetration, are its openness, its community, and its independence. uClinux on Altera NIOS 1 seems to have gone almost no-where, I think partially because the rights to sell the development kit were bundled into Microtronix. The uClinux mailing list now sees a few individuals trying to scrape together the bits and pieces from that project, to get a free, public distribution. Evidence that Altera learned their lesson comes from the fact that uClinux support for NIOS 2 was announced the same day as the NIOS2 core was available, and AFAIK this time it is free. Good move. > Sorry I went off on a rant...I'm struggling to understand why > OpenRISC 1k, despite being 'proven' for more than a year, isn't really > showing up anywhere. There is/was a port for uClinux 2.0 kernel for OR1K - however I think system performance in generic FPGA fabric might have been an issue. Also, there is more to building a system than justing having a processor and a compiler, you need tools to interconnect system componebts and so on - the Xilinx EDK and Altera equivalent. Without the tools, free or not there hurdle is too high. > I suppose the upside is that old engineering saying: "copying is the > highest form of flattery." :) Indeed - has anyone reverse engineered NIOS yet? ;-) Regards, JohnArticle: 74085
Hi I am working with a xilinx EMAC core on a virtex II FPGA. I have successfully (at least I think) placed the EMAC core on the board and able to compile all cores and able to synthesize the design. I am also able to run some sample code on the board. Now I am working with EMAC and xilinx low level drivers. In my drivers I am calling functions from Xilnx EMAC drivers (loopback, selftest). I am able to successfully call some functions for EMAC for ex. setMac Address and initialize device but the selftest functions for emac always fails. I am not sure if its the hardware or broken drivers. Any ideas or advice will be greatly appreciated. thank Mike K. SUNY FarmingdaleArticle: 74086
Followup to: <cjev60$2cnv$1@biggoron.nerim.net> By author: "Daniel" <df@yahoo.com> In newsgroup: comp.arch.fpga > > Why not a reimplementation of software? Is it more difficult to develop a > version for a FPGA solution (if the publisher can do it) than to programme > the FPGA in order to adjusted it to the soft? > Doing a sequential algorithm in an FPGA is bound to be much slower than one on a hardwired CPU. The FPGA will win if you can exploit the parallellism inherent in the hardware solution. -hpaArticle: 74087
Hi folks, Antti Lukats wrote: > the M*Blaze/uCLinux has already received first donation offers, but more > donations are welcome of course, specially in form of FPGA development > hardware. I would like to point out that this has nothing to do with the Microblaze uClinux project that is run out of The University of Queensland. We are neither soliciting nor accepting donations for this work. The Microblaze uClinux project home page: http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Regards, JohnArticle: 74088
>Doing a sequential algorithm in an FPGA is bound to be much slower >than one on a hardwired CPU. Why? Is that comment true in general, or just for OCR problems? I'd expect there are some sequential problems that would be much faster in a FPGA. Suppose we assume the clock on the CPU is N times as fast as the FPGA and the CPU. Then any problem that takes more than N cycles on the CPU will be faster on the FPGA if the FPGA only takes 1 cycle. How about something like computing a CRC? Better would be doing a CRC type calculation while searching for a pattern. I think the Fire codes use something like that for error correction. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 74089
Mike,
Neither CORDIC nor the software approximations are all that appropriate
for hardware (FPGA) implementation. The first question is how accurate do
you need the log? A quick and dirty Log will get you to about 1/4 dB
using a very small LUT and barrel shift. Here's the secret:
You've got some number Y which has a big dynamic range (say it's floating
point, for example). Y can be broken into Y=(2^b)*a where a is a
normalized value such that 1.0<=a<2.0. Then Log(Y)= bLog(2)+Log(a). Use
a normalizing barrel shift to shift the unsigned mantissa all the way to
the left so that the MSB is a '1', counting the number of bits shifted.
The number of bits shifted is related to the exponent b by a simple
subtraction. Log(2) is a constant multiply of the exponent. The exponent
gets you to 6dB alone. Now since the mantissa is normalized, you can use
the MSBs to address a look up table to get the part of the log due to the
fraction. The MSB is always a '1', so it does not need to be used in
forming the address. If you use the next 4 MSBs to address a 16 entry
table you get better than a half dB accuracy, and it only takes a 4 input
LUT per bit to do. Oh, one more thing. If you choose the log base as 2,
then you simply concatenate the exponent bits (no multiplication) to the
output of the mantissa LUT. If you then need a different base, you can
multiply that complete log by a constant equal to 1/Log(2) in the desired
base.
Floating point input to the Log is actually nearly ideal, because the
mantissa is already normalized and the exponent already separated, so you
can do the log directly.
Computing exp(x) is similar except the operations are accomplished in
reverse (it is easiest to do in base 2): First, convert to a log base of
two by multiplying by the appropriate constant. Next separate the integer
and fraction parts (this is jsut a fixed selection of the bits in the
log). The fraction part address a look up table containing the antilog of
the fraction (you can get by using jsut a few MSBs once again, and you'll
want to add on an implied 1 so that the fraction is between 1.0 and 2.0).
Then shift the value read from the LUT by the number of bits indicated by
the integer part of the Log value.
If you need higher precision than what you get with a reasonably sized
LUT, you can iterate on this method or use one of several algorithms. In
most cases, you do not need the extra precision.
Mike Delaney wrote:
> snipped, basically he needs log and exp in floating point
--
--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: 74090
Oh yeah, I forgot to mention this. Of course the CORDIC is fixed point. CORDIC
is an inherently fixed point algorithm. It makes absolutely no sense to attempt
CORDIC as floating point. If you need to use CORDIC for floats, then you should
first normalize your I and Q inputs so that the larger is left justified and
they share a common exponent, Then you perform the CORDIC rotation on the
normalized mantissa pair as a fixed point operation, passing the common exponent
around the CORDIC. At the CORDIC output, you can renormalize the I and Q and
marry those individually with the common exponent. It doesn't make sense to do
the insides of CORDIC in floating point because it is a shift and add
operation. Each iteration requires the mantissa for either I or Q to be
denormalized so that they have a common exponent so that they can be summed.
Further, each elemental rotation does not alter the magnitude of the vector
(other than a small fixed gain), so each stage in the CORDIC rotation has the
same common exponent.
The CORDIC Log is somewhat awkward in that it involves some rather hardware
intesive set up to get the (a-1)/(a+1) term from the log argurment, a. There
are better algorithms (for example, I developed a precision log algorithm
similar to CORDIC that I have not published yet, but have used in a design where
I needed to compute a Log with an accuracy of 0.005dB ).
Kevin Neilson wrote:
--
--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: 74091"iceman" <static123ph@yahoo.com> wrote in message news:62011d8f.0410030504.40932424@posting.google.com... > ei anyone can help me with the algorithm on how to control a > servomotor... cause we are gonna use it on our thesis... by the it's > called "FPGA based intravenous infusion monitoring and control system" > > can anyone help us out on how to control a servomotor...will be using > the servomotor to clamp the tube of an I.V.(intravenous) tube... the > flow of the algorithm will bw this... first a personnel will input how > many dosage a patient gets and then the servomotor will clamp the I.V. > tube so that the desired dosage is achive... by the way will be using > optical sensors to monitor the drops of the I.V. fluid i will be > placed at the outside of the drip chamber... > > but we have a problem what if the drip of the fluid change how will > the servomotor adjust it so that the dosage will be maintained...will > use a feedback but how are we gonna implement it on FPGA.. > > got any suggestion on the algorithm... or any sites that can help us > solve this problem you did not specify what type of servo you need to control, if that R/C servo then that can be easily connected to FPGA there are some free ip cores for that. BUT controlling R/C servo and doing some algorithm is way simpler faster and cheaper when implemented using some small microcontroller not an FPGA - so unless there are other reasons to use FPGA then microcontroller based design would be better choice anttiArticle: 74092
The best solution is to use a phase accumulator (aka Direct Digital Synthesis). All
that is is a fancy name for an accumulator that adds a fixed increment value to itself
on every clock cycle. The MSB of the accumulator is the clock output, and the output
frequency is related to the master clock frequency by:
fo = fc*n/(2^k)
where:
fo = output frquency
fc = master clock frequency
n = increment value (integer)
k = number of bits in accumulator.
For example, you have a 200 MHz master clock, and you need the output to be 400 Hz.
Lets say we use an 32 bit accumulator, so n = 400/200M * (2^32) = 8589.9, which rounded
is 8590. Plugging that back in, you have an output frequency of 400.003 Hz. The
number of bits in the accumulator sets the resolution of the frequency setting you can
have. The output will have a maximum jitter of +/- 1/2 clock period of the master
clock.
The circuit is just an accumulator that always adds the constant n to itself. This
works by taking advantage modulo arithmetic. Basically , you keep accumulating the
fractional part and throwing away the integer part of the accumulated sum. Each time
the sum crosses over to the next integer, the integer part is dropped.
Rakesh Sharma wrote:
> Hi,
>
> I wish to generate a frequency of approx 400 Hz using Xilinx
> Spartan II(200 MHz)and send the 1 bit signal to a speaker output and
> hope to hear some noise.
> My VHDL code, tested on PeakVHDL simulator does generate the
> waveform and is pasted at the far bottom. The problem is that the code
> does not compile on Xilinx because "WAIT for 2.5 ns" is not supported
> on Xilinx Spartan II for a process. What would be the simplest way out
> to generate 400 approx Hz on a Xilinx 200MHz device? I have used
> 200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of
> STD_LOGIC_VECTOR)
>
> Another thing which has confused me is: If I wish to write an
> entity(below) for Spartan II, does the programmer worry about
> generating the signal for "clk" input? Or simply connect it to the
> correct pin of FPGA and I should get the signal of 200MHz?
>
> ENTITY some_entity IS
> PORT (clk : IN BIT);
> END some_entity;
>
> For my code tested on PeakVHDL, I have generated the 200MHz signal
> using a test bed(music_tester) and then modified it to 400Hz.
>
> I apologise if the question is basic.
>
> Thanks in advance
>
> ENTITY music_tester IS
> PORT (clk : OUT STD_LOGIC; freq : IN STD_LOGIC);
> END music_tester;
>
> ARCHITECTURE behavioral OF music_tester IS
> BEGIN
> process
> BEGIN
> clk <= '1';
> -- 200MHz is 5ns cycle
> WAIT FOR 2.5 ns;
> clk <= '0';
> WAIT FOR 2.5 ns;
> END process;
> END behavioral;
>
> ENTITY music1 IS
> PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
> END music1;
>
> ARCHITECTURE music1_structure OF music1 IS
> BEGIN
>
> PROCESS(clk)
> VARIABLE counter : STD_LOGIC_VECTOR(18 DOWNTO 0) :=
> conv_std_logic_vector(0, 19);
> VARIABLE Aint : INTEGER RANGE 0 TO 524287 := 0; -- 19 bits
>
> BEGIN
> IF RISING_EDGE(clk) THEN
> counter := conv_std_logic_vector(Aint, 19);
> Aint := Aint + 1;
> -- Divide 200 Mhz/(2*2*2...19
> times)
> -- MSB has approx 382Hz
> pinout <= counter(18);
> END IF;
> END process;
> END music1_structure;
>
> ENTITY testbench IS
> END testbench;
>
> ARCHITECTURE structure OF testbench IS
> COMPONENT music_tester PORT (clk : OUT STD_LOGIC; freq : IN
> STD_LOGIC); END COMPONENT;
> COMPONENT music1 PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
> END COMPONENT;
> SIGNAL a, b :STD_LOGIC;
> BEGIN
> tester: music_tester PORT MAP(a, b);
> UUT: music1 PORT MAP(a, b);
> END structure;
--
--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: 74093
Depends on your design and what you are willing to settle for. Technically
speaking, all you really need to do is provide a way of clearing stuff in your
design tht is inside hardware loops. For example, a state machine or an IIR
filter have a 'loop' that needs to be broken in order to bring the hardware to a
known state. In many cases, it is perfectly acceptable to clear only key points
in the design, and sometimes even require the reset be asserted for some minimum
number of clock cycles to achieve a known state. Yes, the easy methodology is
to reset every flip-flop, but it is not necessary and can cost you dearly in
terms of both gates and reset signal fan out (and therefore delay).
Dave wrote:
> Ok I understand...but isn't it better to have a reset for all our flip flop?
> If something goes wrong - or when I press the reset button...- the
> controller can always reset everything to zero before we start again...
>
> Thanks,
> David
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:415DAEA4.AAFC9B99@andraka.com...
> > The SRL16 does not have a reset pin on it...ie, you can't clear its
> > contents in one clock cycle. Your code has a reset in it that clears the
> > whole shift register, which means it cannot be implemented using an SRL16
> > primitive (which costs only one LUT+FF instead of 9). If you can
> > eliminate the reset on this shift register, then you get a more compact
> > implementation. Your code would look like this:
> >
> > always @ (posedge mclk or negedge resetb)
> > begin
> > if (sclkRise == 1) begin
> > datain[63:1] <= datain[62:0];
> > datain[0] <= sdata;
> > end
> > if (lrclkRise == 1) begin
> > leftdata <= datain[63:40];
> > rightdata <= datain[31:8];
> > end
> >
> > end
> >
> > David wrote:
> >
> > > Hi,
> > > I'm getting an HDL ADVISOR message when I synthesize this code.
> > > Basically, it is a big shift register that shift-in data on each
> > > rising edge of mclk if srclkRise is high, and outputs its data on the
> > > rising edge of mclk if lrclkRise is high. I don't quite understand the
> > > advice here. Can anybody help?
> > > Thanks,
> > > David
> > >
> > > --ADVICE
> > > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> > > signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> > > Removing the set/reset logic would take advantage of SRL16 (and
> > > derived) primitives and reduce this to 1 logic cells (1 slices).
> > > Evaluate if the set/reset can be removed for this simple shift
> > > register. The majority of simple pipeline structures do not need to be
> > > set/reset operationally.
> > >
> > > --CODE
> > > always @ (posedge mclk or negedge resetb)
> > > begin
> > > if (~resetb) begin
> > > datain <= 0;
> > > leftdata <= 0;
> > > rightdata <= 0;
> > > end
> > > else begin
> > > if (sclkRise == 1) begin
> > > datain[63:1] <= datain[62:0];
> > > datain[0] <= sdata;
> > > end
> > > if (lrclkRise == 1) begin
> > > leftdata <= datain[63:40];
> > > rightdata <= datain[31:8];
> > > end
> > > end
> > > end
> >
> > --
> > --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: 74094austin wrote: > Configuration of a test pattern can make efficient use of our partial > reconfiguration capabilities. I can not say how many seconds an FPGA > spends in the tester, but it is less that an ASIC does. There also may > be much faster ways to configure that we can use, but do not offer to > customers. How long it takes to run the tests is one thing, how long to design the tests is another. For a small volume ASIC the design (human) time could be long amortized over the chips produced. -- glenArticle: 74095
Glen, One potential advantage we have is that we have been doing this for 20 years, and testing the interconnect, FFs and LUTs doesn't change that much from generation to generation. Same could be said for an ASIC cell that has been used for the last few generations, too (as long as it hasn't changed much). The overall ASIC functional test vectors are often quite complex. That leaves time to get clever with paterns. Austin glen herrmannsfeldt wrote: > austin wrote: > >> Configuration of a test pattern can make efficient use of our partial >> reconfiguration capabilities. I can not say how many seconds an FPGA >> spends in the tester, but it is less that an ASIC does. There also >> may be much faster ways to configure that we can use, but do not offer >> to customers. > > > How long it takes to run the tests is one thing, how long to > design the tests is another. For a small volume ASIC the > design (human) time could be long amortized over the chips > produced. > > -- glen >Article: 74096
maxfoo <maxfoo@punkassSPAM.com> wrote in message news:<uhlal0l0dqdsess20ijlh2a4i4jh1h4346@4ax.com>... > Have you looked at the development boards at www.digilent.com > > Xilinx only, but the lowest priced ones I've seen anywhere on the web... I believe I've looked at those before... the dimensions of the boards there don't seem to be listed on the website, but from what I can tell they appear to be too large, unfortunately. -DarienArticle: 74097
Dear all, I am working on the Xilinx ML300 prototying board. I have a Linux image that needs to be uploaded to the DDR memroy. I tried for a few days and was unable to figure out how this can be done. Can any one kindly give me some hints? Even if you may not have the board, can you share your experience on how usually this is done? Thanks a lot! Best regards, Jingzhao PS: I do know that the data for the on-chip BRAM is initialized through the bitstream generated using the DATA2BRAM program.Article: 74098
Howdy all- I'm doing some archive work and I am attempting to ressurect an old version of Logical Devices CUPL Total Designer/WIN V4.7A... would/could anyone who might have the install disks or install file set lurking around help me out? I need three files from or an image of distribution disk #12--- Fit1500.EX_ Espresso.EX_ Flexfit.EX_ Help would be greatly appreciated. Many thanks Regards, RobertArticle: 74099
Antti, Antti Lukats wrote: > the M*Blaze/uCLinux has already received first donation offers, but more > donations are welcome of course, specially in form of FPGA development > hardware. > PS I am not the author of the open-source M*Blaze, neither is the M*Blaze > IP-Core downloadable from openchip, the primary download location for the > M*Blaze IP-Core is the opencores website, project name aeMB. You are also not the author of a single line of source code in the microblaze-uclinux project. I would appreciate it if you did not make comments that could be misunderstood as representing me or any other contributor to that project. There is no such thing as M*Blaze. The author of aeMB has wisely avoided any direct reference to Microblaze. If the Leon core had been called SP*RC, it would have lasted about 10 minutes before Sun jumped on it. Please let the people who do the work, speak for themselves. Thanks, John
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