need a cheap student edition FPGA

First, I am not a lawyer, and I don't know what I am talking about.


On 29 Oct 2005 18:02:03 -0700, "Weng Tianxiang" <wtx@umem.com> wrote:
Hi, Why are there two patents with same title?
Patents can have any title they like. Sometimes they are descriptive
of the patent contents, and sometimes they are deliberately poor to
make searches fail. Usually they are descriptive.

There are many reasons for apparently duplicated effort. You need
to study the claims section carefully to see how they differ.

I believe that patents can be described as "method patents" and
"means patents". Sometimes the claims are combined in one patent
and sometimes they are separate patents.

After filing a patent, the engineering continues. If additional
ideas are developed, or better implementations discovered, then
a follow on patent may be filed to cover the new material.


What are their major purposes?
To protect intellectual property.

A means patent covers the mechanisms or structures needed to
implement the patent. A methods patend covers how the means
are applied to achieve the goal of the patent. (I may be
totally screwed up on this).

For example: Altera patents:
6,859,065 Use of dangling partial lines for interfacing in a PLD
6,653,862 Use of dangling partial lines for interfacing in a PLD

In the latest patent, it contains the following statements:

This application is a continuation of U.S. patent application Ser. No.
10/140,911 filed on May 6, 2002, now U.S. Pat. No. 6,653,862, which
claims priority to U.S. Provisional Application Ser. No. 60/289,346,
filed May 6, 2001, and entitled "Use of Dangling Partial lines for
Interfacing in a PLD."
This may be an example of the "additional ideas". I have not looked
at the patents you reference.

Thank you.
Weng
Philip
 
Your first two steps are identical as far as logic is concerned because
you use the same resources and are only renaming the output using
assigns. Treat assigns as simply wires that will connect Temp to
Command and when the output is decalred as Command then the assign is
not required.

Having said that any time you declare an output and you actually want
it out of your FPGA then you have no choice but to use the resources
you have. If you are bringing several outputs out of the chip and not
all of them are required at the same time then you can mux it out -
apart from that you are out of luck.

BL
 
I have been looking at C like development tools and have seen a number
of products mature. I tried to get in touch with Celoxia but never got
any furthure than the UK representative saying he past my contact
information on to the sales representative at the US office.

Have you considered Impluse CoDeveloper? Getting a 30 day trial license
was very painless. The demo looks like it is the same as if you bought
the full version just limited to 30 days. It seems to be very able but
a work in progress. Since I have downloaded the demo there has been a
couple of updates but I might have caught them in the middle of a
release process. The tutorials seem to illustrate features of their
environment but the discussion could be more insightful. Their is also
a book entitled "Practical Fpga Programming In C" by David Pellerin.
I've ordered a copy of the book and I'm hoping that it will help me
understand how to take advantage of their libraries with larger
designs. On the small it seems like the VHDL code generated is very
readable and easy to understand.

I was wondering what kind of experiences other designers have had with
Impulse's CoDeveloper?

Derek
 
DerekSimmons@FrontierNet.net wrote:

Have you considered Impluse CoDeveloper? Getting a 30 day trial license
was very painless.
I don't know of a CAE tool that doesn't
provide a full-up 30 day trial.

It seems to be very able but
a work in progress.
Thanks for the tip.

On the small it seems like the VHDL code generated is very
readable and easy to understand.
Most readers of comp.lang.vhdl can already
write such code without a middle man.

I was wondering what kind of experiences other designers have had with
Impulse's CoDeveloper?
Why not try it out on a real design
and tell us how it goes.


-- Mike Treseler
 
"Weng Tianxiang" <wtx@umem.com> writes:
Why are there two patents with same title?
I haven't looked at those two patents, but it's common for this to happen. A patent
application will be split into two or more parts, because the patent examiners think
that there are independently patentable concepts involved.

I've seen one that was split into many pieces of which more than a dozen were actually
issued as patents, all with the same title.

If you want to know the difference between the two, you'll have to compare the claims.
 
I could be wrong, but it looks like the drastic change in utilization
you see -- that is, in slices and LUTs (not IOBs, which are obviously
because you're not mapping the registers to pins) -- is simply because
the synthesizer optimized the flip-flops out. If they're not used, i.e.
in this case not mapped to pins, then they're optimized away. So you're
getting a false positive in #3; your utilization in #'s 1 and 2 is
correct.

Julian
 
I used CoDeveloper for a Mandelbrot image generation project and had a
pretty good experience. Support from Impulse was outstanding.
I have never used any other C-to-HDL software, so I can't compare it to
others.
CoDeveloper can't compete with HDL which is hand written, and I don't
think it claims to. Its more for a software engineer who wants to use
PPC/Microblaze/Altera uP + FPGA fabric.
 
Why don't you write in english so that we could understand you ?
 
"Von Heler" <eck@forlivingstone.com> wrote in message
news:Xns971C6270A1224eckforlivingstonecom@194.117.143.53...
On 28 Nov 2005, Frank put down his happy meal and blurted:

When my DAC output is from 0-1V, and is fed into 10-bit AD9218 which
is set to binary mode, what binary value will I get when the input is
-10mV?








I'm lovin' it.

I am so hard doing this assignment for the year end bonus's sake. After the
money enters my purse,
I can BURP about all the nice food in the entire city.

I'm lovin' it. Kekekeke...................
 
You have a couple of things to straighten out here (I didn't check your
logic for you, I just looked at a few constructs).

The biggest mistake you've made is that you mixed your logic with your
test bench. Xilinx has no way of knowing which is which since they're
both written in verilog. What you need to do is put all of your logic
(the stuff that will go into the CPLD) in one file and then instantiate
that logic in your testbench.

I'll go through a couple of problems here:

* Delays are always ignored for synthesis. They shouldn't be needed in
your logic. If they are, it is probably flawed logic, or perhaps an
ugly hack to get around some other problem.
* Initial blocks are ignored for synthesis (usually, though this is not
necessarily the case). You should use either an asynchronous reset or
a synchronous reset instead.
* The following logic is bad since it is a combinational block that
does not have all inputs declared.

/* GENERATE SCK WHEN outClock HIGH */
/* SCK = CLOCK/8 */
always @(clk) begin
if (outClock == 1) begin
sck = !sck;
#4;
end else
sck = 1;
end

For this block, you must get rid of the delays and add sck to the
sensitivity list, but this logic will still not work. You can either
have two clock domains, one for sck and one for clk, or you can make a
state machine that outputs an enable bit for other logic. For example:

reg [2:0] dly_count;
reg enable_sck;

always @ (posedge clk or negedge rst)
begin
if(!rst)
dly_count <= 3'h0;
else
begin
dly_count <= dly_count + 1;
end
end

always @(dly_count)
begin
if(dly_count == 3'b111)
enable_sck = 1'b1;
else
enable_sck = 1'b0;
end

What this logic will do (assuming I didn't make a mistake, which is
possible; it's untested) is set enable_sck high 1 clock out of every 8.
What you can then do is for all logic that uses the sck, you enable it
with the enable_sck, so for example:

//shift register that shifts on "sck"

reg [3:0] sreg;
reg shift_out;

always @ (posedge clk or negedge rst)
begin
if(!rst)
sreg <= 4'h0;
else
begin
if(enable_sck)
{shift_out,sreg} <= {sreg[3:0],shift_in};
end
end

Another mistake is perhaps the repeat command. I'm not sure that it
can be synthesized. It might be able to be by some synthesizers (I'm
amazed by the strange stuff that design compiler can synthesize), but I
would still not recommend it. In the way that you used it though, I
would never expect it to work. You can't write serialized logic the
way you did since delays are not synthesized. All of that repeat(16)
block would happen in 0 time (theoretically).

There are a lot of flaws in your design (ignoring checking actual
logic). You probably should read the XST users guide from xilinx.
It's available for free on the web. It will tell you what kinds of
logic you can synthesize and give you a good idea of good design
practices.

CPLDs and FPGAs, while not exactly like ASICs, are very similar. They
at the very least require the same methodology. Remember that this is
a digital design and not an embedded system and that there isn't really
such a thing as a "delay" in rtl and that everything should happen
synchronous to a clock.

Perhaps you should also look through some examples at fpga4fun.com to
get a better idea of what can be done with FPGAs and CPLDs. If you
have any questions though on how something works or what might be the
best way of writing something (out of several possibilities that you
have written), please post back here at comp.arch.fpga. Folks are
pretty helpful when it comes to specific questions.

Good Luck,
Arlen
 
Reza -

The first thing you must understand about Verilog is that some of its
constructs are synthesizable, other are not. These latter constructs
such as 'while', 'repeat', 'wait', 'initial' are in the language purely
for
simulation. These constructs cannot be synthesized. So you need
to learn what constructs can be used for designing your CPLD and
which ones can only be used in the testbench.

Next, you need to separate the testbench code from the CPLD logic.
In the testbench, instantiate the actual design. When you want to
synthesize, only give XST the actual design to work on, not the design
and testbench.

Next, you need to understand about logic design, ie, how do flip flops
really work, how to do synchronous design for timing analysis, etc.

You should look at some examples of other peoples work. Try
Opencores.org.

Good luck!

John Providenza
 
Thanks for the excellent help. Though now I'm quite irritated at the
$80 verilog book that I bought - it didn't differentiate at all between
the constructs that are test-bench specific, and the ones that I could
use for the design. It also didn't indicate any problems with using
delays in the code.

And most all that code except the part labeled 'TEST CLOCK' is all
supposed to be functional logic to be implemented.

So it sounds like I'll have to re-write the whole thing. I'll look at
some of the sites you referred me to. I also dont mind buying another
book on the subject if you have any recommendations.

Thanks!
Reza

p.s. I'll be posting again soon
 
Reza -

I should have mentioned that Opencores.org has a SPI module.

I've never used it, but it may be educational to look at.

In terms of books, I've not seen any Verilog books that I thought were
worthwhile. I've given up looking.

John Providenza
 
The only verilog book that I use these days is the Thomas and Moorby
book. It's very expensive and it wouldn't be particularly useful to
you for synthesis purposes. It's really about the language itself
which was designed for simulation. Synthesis is a different ball game
entirely.

Here's some general advice about synthesis:

If you can't visualize the hardware being produced, you probably
shouldn't code it yet. Remember that behavioral models probably won't
work, and even if they do, they won't work well, or be even close to
optimal.

The best place to start for learning synthesis, is to make a simple
combinational circuit, followed by a complex one, followed by a simple
register, followed by a state machine.

A couple simple combinational circuits might be:
assign out = a & b; //and AND gate
assign out = s ? a : b; //a 2 to 1 MUX
assign out[3:0] = a[2:0] + b[2:0]; //a 3-bit adder

A complex combinational block uses an always statement for
combinational purposes:
reg out;
always @ (ina or inb or inc or ind)
begin
out = 1'b0;
if(ina) out = inb;
if(inc) out = ind;
end

A simple register (or flip-flop) is like this:
reg q;
always @(posedge clk)
q <= d;
or with reset:
reg q;
always @(posedge clk or negedge rst)
if(!rst)
q <= 1'b0;
else
q <= d;

I won't give an example state machine, but what I can tell you is that
in documents such as the XST user guide they explain very clearly how
to make them. Really all they are though is one set of flops, and two
blocks of combinational logic:
combinational logic takes outputs of flops and state machine inputs as
inputs and outputs flops next state
flops register that data
other combinational logic takes output of flops and optionally state
machine inputs as inputs and outputs needed signals.

With those basic constructs almost anything synthesizable is possible.
Other synthesizable constructs are for loops that have a finite number
of iterations (though, personally I've never used this).

It's worth noting that the following combinational constructs are not
synthesizable:
/ -- division is nearly impossible to do combinationally, unless it's a
divide by 2^n
<< and >> -- these are only synthesizable if the shift is by a constant
amount. These can be done non-constant in completely combinational
logic; this is called a barrel shifter; but it is not supported by
synthesizers.

Here is the XST User guide:
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0001_1.html

It has a lot of good information. I particularly recommend the HDL
Coding Techniques Section:
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0012_5.html#wp234748

Again, good luck. I wish you the best,
Arlen
 
Hi all,

I want to design a digital delta-sigma DAC. It includes a pulse density
modulated module and RC low-pass filter.

The pulse density modulated module is a Delta-Sigma type (one adder and
one substractor). But why use Delta-Sigma type (i.e. how to understand
it)? Is there any good tutorial on digital Delta-Sigma?

Best regards,
Davy
 
"Davy" <zhushenli@gmail.com> writes:

Hi all,

I want to design a digital delta-sigma DAC. It includes a pulse density
modulated module and RC low-pass filter.

The pulse density modulated module is a Delta-Sigma type (one adder and
one substractor). But why use Delta-Sigma type (i.e. how to understand
it)? Is there any good tutorial on digital Delta-Sigma?
Wikopedia has some good information. At least yesterday it did.
--
% Randy Yates % "How's life on earth?
%% Fuquay-Varina, NC % ... What is it worth?"
%%% 919-577-9882 % 'Mission (A World Record)',
%%%% <yates@ieee.org> % *A New World Record*, ELO
http://home.earthlink.net/~yatescr
 
Randy Yates wrote:
"Davy" <zhushenli@gmail.com> writes:


Hi all,

I want to design a digital delta-sigma DAC. It includes a pulse density
modulated module and RC low-pass filter.

The pulse density modulated module is a Delta-Sigma type (one adder and
one substractor). But why use Delta-Sigma type (i.e. how to understand
it)? Is there any good tutorial on digital Delta-Sigma?


Wikopedia has some good information. At least yesterday it did.
Hi Randy,

You mean "Wikipedia" - replace the 'o' with an 'i'.
http://wikipedia.org


--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536
Being a good example is hard. I'm trying to serve as a horrible
warning instead. - Brian Crane
 
In sci.electronics.basics Davy <zhushenli@gmail.com> wrote:
: Hi all,

: I want to design a digital delta-sigma DAC. It includes a pulse density
: modulated module and RC low-pass filter.

: The pulse density modulated module is a Delta-Sigma type (one adder and
: one substractor). But why use Delta-Sigma type (i.e. how to understand
: it)? Is there any good tutorial on digital Delta-Sigma?

: Best regards,
: Davy

Read, read, read!

In any A/D or D/A circuit there is a quantizer -- the part of the
circuit that actually does the conversion from analog to digital. The
error in quantization shows up as noise in the resulting signal. The
total power of this quantization noise only depends upon the number of
levels in the quantizer, for any type of data converter (This is often
stated as the distance between levels, which means pretty much the same
thing.)

In a nutshell, while most types of data converters result in
quantization noise with a white spectrum (i.e. spread evenly throughout
the signal band,) Delta-Sigma converters "shape" the noise, to move it out
of the band of interest. This is often combined with oversampling which
has at least two advantages -- to spread the quantization noise out over a
larger band (even without noise shaping,) and to be able to move the
quantization noise far away from the band of interest, such that it can be
subsequently filtered out relatively easily.

Delta-Sigma modulation allowed for parctical A/D and D/A
converters to be built that use as few as 2 levels (i.e. "1-bit
converters") and have acceptable performance for data conversion of
relatively low-bandwidth signals like audio (or slower) signals. The
reason why Delta-Sigma converters are usually used for low-bandwidth
signals is because the oversampling ratio must be relatively high
(around 100X) for good performance, which dictates how fast the system
clock needs to run.

Joe
 
"Davy" <zhushenli@gmail.com> skrev i en meddelelse
news:1137467765.105916.108520@g47g2000cwa.googlegroups.com...
Hi all,

I want to design a digital delta-sigma DAC. It includes a pulse density
modulated module and RC low-pass filter.

The pulse density modulated module is a Delta-Sigma type (one adder and
one substractor). But why use Delta-Sigma type (i.e. how to understand
it)? Is there any good tutorial on digital Delta-Sigma?
I would recommend books from the authors Richard Schreier, Gabor C. Temes,
Steven R. Norsworthy and James C. Candy. Specifically the following books
cover almost all subjects from end to other:

R. Schreier, G. Temes, "Understanding Delta-Sigma Data Converters", 2004
http://www.amazon.com/gp/product/0471465852/103-2515440-5710236
Very good introduction to the principles, with many examples. A more
hands-on approach than many other books on the subject.

R. Schreier, G. Temes, S. Norsworthy "Delta Sigma Data Converters: Theory,
Design and Simulation", 1996
http://www.amazon.com/gp/product/0780310454/103-2515440-5710236
Very detailed and in-depth coverage with good theoretical background on most
subjects.

James C. Candy, Gabor C. Temes, "Oversampling Delta-Sigma Data Converters:
Theory, Design and Simulation", 1991
http://www.amazon.com/gp/product/0879422858/103-2515440-5710236
A collection of important scientific papers that covers the full (almost)
history of the development of this particular field of science. Very good
supplement for the two other books.

I have read several other books on the subject, but none of them have the
accuracy of these books. I would recommend not reading them cronologically,
but start with the newest one, and then progress to the older books if you
have a need for more background info or explanation of the theories.

-Thomas
 

Welcome to EDABoard.com

Sponsor

Back
Top