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
Symon <symon_brewer@hotmail.com> wrote: >On 3/25/2010 1:10 AM, Thomas Entner wrote: >> As I think, many FPGA-designers have also to deal with EMC, I hope >> someone can help me here. We have currently some discussions (and >> doubts) regarding EMC-topics. As many people have different opinions >> on this subject, and it is quite hard to objectively verify, I would >> like to ask for some comments about following: >> >> 1. Filtering of IC-supply-voltage >> While it is quite standard to filter e.g. the PLL-supply voltages of a >> FPGA, there are some suggestions to filter the supply-voltage of every >> IC (CPU, FPGA, memory, ...) on the PCB with a ferrite-bead + C. >> (Consequently, this also means that every IC has it's own Vdd-island >> in the power-plane.) Does this work? >> >> 2. Return-path on Vdd-plane >> It is pretty clear that a solid ground-plane is required for return- >> path of I/O-signals. Most people also agree, that a power-plane will >> also do this job. But is this only because of the bypass-caps? Or is >> the "native" return-current flowing on ground when the output-driver >> is sinking and on Vdd when the output-driver is sourcing (assuming a >> high-impedance destination), i.e. it would be perfect to have both >> planes close to the signal-line? >> >> 3. Shields of connectors, chassis ground >> Most PCBs have one or more connectors with shields (e.g. USB, RJ45, >> VGA, RS-232,...) Do you connect these directly to circuit-ground? Or >> with C and R in parallel? Or do you have some kind of "frame-ground"? >> Have you the mounting holes grounded to the chassis? All or just one? >Hi Thomas, > >1) Yes. That will keep noise from coupling between devices. >2) Only nutters have power planes. They use up valuable space in which >you could more profitably use a ground plane. OK if you have enough decoupling on every pin. >3) Bond it all together. Unless you have to have isolation from >dangerous voltages. I feel more comfortable to put a bead between the shield and the ground. Keeps HF current inside / breaks HF pickup loops when wiring equipment together. >If anyone wants to disagree with this advice, I want a specific, first >person example where what I suggest is wrong. I don't want to hear what >some 'guru' told you on a course you paid for. :-) > >Symsx. > > > -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146676
Symon <symon_brewer@hotmail.com> wrote: > On 3/25/2010 6:13 PM, Kolja Sulimma wrote: (snip) >> Well, how do you create a low inductance path to the next capacitor? >> You do not necessarily need a full plane, but making sure there is a >> low inductance path quickly gets very cumbersome. > You use copper pours and puddles around the IC to link its bypass > capacitors. >> A power plane is as good a reference for a signal as a ground plane >> and the PCB stack needs to be symmetric anyway. So what is the >> disadvantage of having a power plane as layer 2 when there is >> a gnd in layer N-2? > 1) The stack up does not need to be symmetrical wrt to planes and signal > layers. However, you should make the substrates symmetrical. I have made > several boards that aren't plane symmetrical. Talk to your PCB vendor. > (Some of these boards were about 12x8 inches and didn't warp.) > 2) When a signal trace passes from layer 1 to layer N-1, its reference > plane has now changed. If this signal has a fast rise time, you have to > use a bypass capacitor nearby, with its attendant inductance, and via > inductance. With two ground planes, a regular via is enough. As I understand it, that mostly isn't true. For a reasonably plane there is enough capacitance around to get the signal across from one to the other. > 3) You make an interesting point when you say that a power plane is as > good as a ground plane as a reference. This is true. The problem comes > that you now have two references in your system, and they will have some > small noise voltage between them. You can reduce this to a small amount > of noise with capacitors, but for each power plane, you have to do this. > With multiple ground planes, they are all bonded together with the > ground vias in your board. Note that a single wire has inductance, and a single plane has capacitance. Even without another plane nearby, the capacitance of a ground plane isn't so bad. With another plane nearby, though, it is somewhat higher. At the higher frequencies, it is the plane capacitance that you see. At lower, but still plenty high frequencies, the actual bypass capacitors become more important. >> Putting a GND plane there instead will waste more space with >> no gain (as you still need to route the power signals somewhere) >> and putting no plane in that layer will result in a bent board. > Indeed, you need to put the powers somewhere. I recommend routing them > all on a couple of dedicated layers away from signal traces. On an FPGA > with at least 1.2V, 1.8V, 2.5V and 3.3V rails, which of these are you > suggesting will be on a plane? All of them? > (Again, the bent board thing is a fallacy, I have found.) >> Also, adjacent power planes provide multi GHz decoupling that is next >> to impossible to achieve with soldered capacitors. > We've been here before. It has a small amount of capacitance, which > doesn't help you because the multi-GHz can't get up the vias and balls > into the dice. Think of it this way, the reason a soldered capacitor > doesn't give you multi-GHz is the fact that you have to connect to it. > Actually in the ceramic of the cap is multi-GHz. It's the same with > connecting your chips to a adjacent-plane-made capacitor. Pin inductance is significant, and there isn't anything you can do about that on the board. Getting a reasonably low impedance to the pin is the best you can do, and that is still worth doing. > Of course, what this arrangement does also provide is the possibility of > multi-GHz resonances in your power planes. Lovely. Using a ground plane > where ever a reference plane is needed makes the SI design very simple > indeed. There was a question on a different post about the relative importance of noise on the ground vs. power pins. -- glenArticle: 146677
On 3/25/2010 11:29 PM, glen herrmannsfeldt wrote: >> inductance. With two ground planes, a regular via is enough. > > As I understand it, that mostly isn't true. For a reasonably plane > there is enough capacitance around to get the signal across from > one to the other. > Enough? Care to fill in any numbers? :-) > > Note that a single wire has inductance, and a single plane has > capacitance. Even without another plane nearby, the capacitance > of a ground plane isn't so bad. With another plane nearby, though, > it is somewhat higher. At the higher frequencies, it is the plane > capacitance that you see. At lower, but still plenty high frequencies, > the actual bypass capacitors become more important. > A single plane, like one hand clapping, has a capacitance to the inside of a hollow infinite conducting sphere. As such, it is as much use here as a chocolate teapot. Everything has the same capacitance to the aether. The planet earth has a capacitance of nearly a millifarad. Perhaps I should connect my 3.3V supply to that? > > Pin inductance is significant, and there isn't anything you can do > about that on the board. Getting a reasonably low impedance to > the pin is the best you can do, and that is still worth doing. > No it isn't worth doing. I posted a spice cct showing that about a month ago. Please try it out yourself. >> Of course, what this arrangement does also provide is the possibility of >> multi-GHz resonances in your power planes. Lovely. Using a ground plane >> where ever a reference plane is needed makes the SI design very simple >> indeed. > > There was a question on a different post about the relative > importance of noise on the ground vs. power pins. > > -- glen Glen, I beg your pardon, but I wonder, do you design circuit boards for a living? I'd love to see one! :-) Cheers, Syms.Article: 146678
On 3/25/2010 8:26 PM, Thomas Entner wrote: > Thank you everyone for the comments, it is an very interesting > reading. I already got a lot of input for a new PCB-design, from > which we will do some variants to check which EMC-solution works best. > Looks like we need more variants than originally planned... > > Thomas Hi Thomas, Will you post back with the results of your testing? Thanks, Syms.Article: 146679
On Mar 17, 12:21=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Mar 16, 11:44=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > Weng Tianxiang wrote: > > > I want to buy books on =A0CMOS digital circuit designs. Any advice on > > > which is the best book on CMOS digital circuit design? > > > At least "Nanometer CMOS ICs, From Basics to ASICs" written by Harry > > Veendrick is quite nice overall book and is up to date with the > > technology. The only problem with the book is the price, which is > > quite high. > > > --Kim > > Hi Kim, > Thank you for your recommendation. > > The book contains materials of full procedures to make an ASIC in > nanometer CMOS. > > I just want CMOS logic circuit in nanometer in 32um technology, for > example, domino logic, time borrowing, how to expand an adder > operation into 15 levels and something like that. > > I have ordered two books on Internet: > > 1. Principles of CMOS VLSI Design (Hardcover), second edition, 1992 > > ~ Neil H. E. Weste (Author), Kamran Eshraghian (Author) > > $0.01 > + $3.99shipping > > 2. Logical Effort: Designing Fast CMOS Circuits (The Morgan Kaufmann > Series in Computer Architecture and Design) by Ivan Sutherland, Robert > F. Sproull, and David Harris (Paperback - Feb. 16, 1999) > Buy new: $69.95 $62.95 > > 7 new from $30.00 > 16 used from $24.25 > > I may buy another book "Principles of CMOS VLSI Design (Hardcover)", > third edition, 2010, written by =A0Neil H. E. Weste and David Harris > when I finish reading the second edition. > > Weng Hi, I have received both books: 1. Principles of CMOS VLSI Design (Hardcover), second edition, 1992 Neil H. E. Weste (Author), Kamran Eshraghian (Author) 2. Logical Effort: Designing Fast CMOS Circuits (The Morgan Kaufmann Series in Computer Architecture and Design) by Ivan Sutherland, Robert F. Sproull, and David Harris (Paperback - Feb. 16, 1999). After brief reviewing, The first one is really good so why it receives more than 3k references in Google search. I have no any knowledge about CMOS. Now after reading I may have a full picture of it. It is a background knowledge and I like it even though it was published in 1992. The second one is basically useless. The reason is the estimate of a logic speed and how they are generated in most efficient way are the topics of HDL compilers and it becomes other people's business, not a digital logic designer's business. WengArticle: 146680
Hi guys,
I'm a newbie to Hardware coming from a software background. I've done
a bit of reading but haven't got around to coding anything much.
Anyway, I had a question (which is probably basic) about how to code
datapath type problems. I'll try a fairly simple problem in the
design I'll be doing:
in C code:
uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
{
return (a*b + c*d)/(b + d)
}
Obviously not the best thing to be doing in hardware. I ran it
through the free c-to-verilog compiler online and it produced some
very convoluted verilog code (suprise, suprise!) and so I thought I
can do much better.
Verilog:
module calc(
input a[15:0];
input b[15:0];
input c[15:0];
input d[15:0];
output result[15:0];
input clk;
reg tmp0;
reg tmp1;
reg tmp2;
wire ab;
wire cd;
wire bd;
wire res;
assign ab = a * b;
assign cd = c * d;
assign bd = b + d;
assign res = (tmp0 + tmp1) / tmp2
always @ (posedge clk)
begin
tmp0 <= ab;
tmp1 <= cd;
tmp2 <= bd;
result <= res;
end
}
Okay so it needs reset added and some other things to handle overflow,
etc. Let's just assume that's not a problem (it's a problem with the
C code also - and I know how to solve it). My question is this: my
verilog implies a 2 clock cycle calculation. But there are other area/
speed possibilities: eg use on multiplier and pipeline the two
calculations to save on area but take more clock cyles. Also in order
to get a faster clock cycle it's possible for the multiples to be
calculated over several clock cycles (I don't want to write the
multiplier I was just going to let the FPGA tool put in whatever
multiplier they already have - I haven't looked at how to do that
yet ... but it's not the issue I'm trying to address here).
Mostly I want to know how does one synchronise the datapath with the
control path. Eg say these inputs are used on a different module also
and I want to know when the result is updated to use it with some
other calculation I did in parallel. How do I know how many clocks it
takes (and do I have to code or is it possible to be flexible to do
trade offs later?).
Also, do I add an enable input and a ready output to my module to
model the function call and return of C or how do I handle these
syncronisations?
Thanks in advance for any help,
Dave
Article: 146681On Mar 25, 7:29=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > 2) When a signal trace passes from layer 1 to layer N-1, its reference > > plane has now changed. If this signal has a fast rise time, you have to > > use a bypass capacitor nearby, with its attendant inductance, and via > > inductance. With two ground planes, a regular via is enough. > > As I understand it, that mostly isn't true. =A0For a reasonably plane > there is enough capacitance around to get the signal across from > one to the other. =A0 Not only no but hail no. The only way for the current to get from one side of the board to the other is through capacitors. The distributed capacitance within two very close planes as measured in units of picofarads per square inch is relatively miserable. There are exotic materials where an extremely thin prepreg with copper that's applied differently than normal so the "smooth" rolled sides face each other rather than the rough side. I don't know anyone that's used those materials. Move two planes many mils apart and the capacitance drops off. Have more than one plane between start and finish of the signal and you have multiple capacitors in series. That's a bad thing, right? Capacitors in series show significantly lower overall capacitance when compared to the individual caps. > Note that a single wire has inductance, and a single plane has > capacitance. =A0Even without another plane nearby, the capacitance > of a ground plane isn't so bad. I'm sincerely wondering where you get your levels of magnitude for reference. Can you provide a picofarad per square inch value for the capacitance of a plane to earth ground? I know fully about self inductance but never in my days of electromagnetics graduate work was the concept of self-capacitance of a plane considered in my admittedly fading recollection. Capacitance needs two bodies. I can only assume the other body is earth ground in your description. For EMI and for crosstalk, the loop formed by the currents - forward and return - determine how much signal is "shared."Article: 146682
On Thu, 25 Mar 2010 18:48:13 -0700 (PDT), David Wiltshire
<dw_56@hotmail.com> wrote:
>Hi guys,
>
>I'm a newbie to Hardware coming from a software background. I've done
>a bit of reading but haven't got around to coding anything much.
>Anyway, I had a question (which is probably basic) about how to code
>datapath type problems. I'll try a fairly simple problem in the
>design I'll be doing:
>
>in C code:
>
>uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
>{
> return (a*b + c*d)/(b + d)
>}
>
>Obviously not the best thing to be doing in hardware. I ran it
>through the free c-to-verilog compiler online and it produced some
>very convoluted verilog code (suprise, suprise!) and so I thought I
>can do much better.
>
>Verilog:
>
>module calc(
> input a[15:0];
> input b[15:0];
> input c[15:0];
> input d[15:0];
>
> output result[15:0];
>
> input clk;
>
> reg tmp0;
> reg tmp1;
> reg tmp2;
>
> wire ab;
> wire cd;
> wire bd;
>
> wire res;
You need to size these registers correctly. Probably
reg [31:0] ab; etc would be what you want.
>
> assign ab = a * b;
> assign cd = c * d;
> assign bd = b + d;
>
> assign res = (tmp0 + tmp1) / tmp2
You don't mention it in the rest of your post but you'll find that
this divide by tmp2 would give you the biggest headache. Multipliers
are easy. All synthesis tools know how to either infer them to use the
macros or implement them in the fabric. Dividers are difficult (to
optimize that it) especially when they have a non-constant
denominator.
--
Muzaffer Kal
DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com
Article: 146683Hello, A long time ago I have heard about VHDL-POSIX. however today, when I need it, the website is dead http://savannah.nongnu.org/projects/vhdl-posix/ and nothing can be downloaded. What has become of this project and his maintainers? Is there anything similar ? Is there an old archive where I can read the source code ? Should I rewrite all I need instead ? yg -- http://ygdes.com / http://yasep.orgArticle: 146684
> > > =A0assign res =3D (tmp0 + tmp1) / tmp2 > > You don't mention it in the rest of your post but you'll find that > this divide by tmp2 would give you the biggest headache. Multipliers > are easy. All synthesis tools know how to either infer them to use the > macros or implement them in the fabric. Dividers are difficult (to > optimize that it) especially when they have a non-constant > denominator. > Okay, the divider is the trickier of the two - I just looked and I see that now. Still FPGA synthesis software includes cores for dividers. Still my main question is about timing. The division is going to occur over multiple clock cycles. How does this impact my design (especially compared to other operations which happen in shorter periods of time) and how do I make sure that the result of this function is synchronised with other functions?Article: 146685
On Mar 26, 6:06=A0am, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > Is it possible to get a detailed report out of XST, listing the gates it > has optimized out of a design? XST is removing some gates that I > specifically put into a design, and I want to prevent this. I can use > the XST constraints file, but I'd like to see exactly what it is doing. > > Googling hasn't turned up much, yet. > > Thanks > -- > Jason Thibodeau Not that I'm experienced but whenever I've seen a similar question (missing logic) it's been optomised out because you haven't connected the output to anything. Try connecting it to a pin out (even if that's not where you want it eventually) and see if it turns up. DaveArticle: 146686
On Mar 25, 10:55=A0pm, whygee <y...@yg.yg> wrote: > Hello, > > A long time ago I have heard about VHDL-POSIX. > however today, when I need it, the website is deadhttp://savannah.nongnu.= org/projects/vhdl-posix/ > and nothing can be downloaded. > > What has become of this project and his maintainers? > Is there anything similar ? > Is there an old archive where I can read the source code ? > Should I rewrite all I need instead ? > > yg > --http://ygdes.com/http://yasep.org Try CVS and get a snapshot of the sources. You can look at the sources here: http://cvs.savannah.gnu.org/viewvc/?root=3Dvhdl-posix -- AmalArticle: 146687
Hi, Amal wrote: > Try CVS and get a snapshot of the sources. You can look at the > sources here: > > http://cvs.savannah.gnu.org/viewvc/?root=vhdl-posix thanks, Any news from the author ? Has anybody used, ported or modified this recently ? This may sound curious or stupid but I need exactly these functionalities today, but they are written for an old Modelsim and I use GHDL :-/ If I can avoid reintenting the wheel, I'll save a lot of time... regards, > -- Amal yg -- http://ygdes.com / http://yasep.orgArticle: 146688
John_H <newsgroup@johnhandwork.com> wrote: (snip) > I'm sincerely wondering where you get your levels of magnitude for > reference. Can you provide a picofarad per square inch value for the > capacitance of a plane to earth ground? I know fully about self > inductance but never in my days of electromagnetics graduate work was > the concept of self-capacitance of a plane considered in my admittedly > fading recollection. Capacitance needs two bodies. I can only assume > the other body is earth ground in your description. It comes out easily if you do electrodynamics in CGS (gaussian) units. The unit of capacitance is the centimeter and, without trying too hard, you find that it is the capacitance of a sphere of the specified radius. Concider a concentric sphere capacitor in the limit that the outer sphere radius goes to infinity. The conversion factor to SI units is 4*pi*e0, or about 1.1 pF/cm. As with inductance, you can also do it though potential energy. 0.5*C*V**2 is the energy in a capacitor, which is equal to the energy in the electric field integrated over all space. (For ordinary capacitors, most of the energy is inside.) 0.5*C*V**2=0.5*epsilon*the integral over all space of E**2*dv (E is electric field, v is volume). > For EMI and for crosstalk, the loop formed by the currents - forward > and return - determine how much signal is "shared." Yes, including the effect of any capacitors in the circuit. -- glenArticle: 146689
David Wiltshire <dw_56@hotmail.com> wrote:
> I'm a newbie to Hardware coming from a software background. I've done
> a bit of reading but haven't got around to coding anything much.
> Anyway, I had a question (which is probably basic) about how to code
> datapath type problems. I'll try a fairly simple problem in the
> design I'll be doing:
> in C code:
> uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
> {
> return (a*b + c*d)/(b + d)
> }
It is much easier if you don't try to think of it in
terms of software. Think in terms of wires and logic
blocks connected together.
> Obviously not the best thing to be doing in hardware. I ran it
> through the free c-to-verilog compiler online and it produced some
> very convoluted verilog code (suprise, suprise!) and so I thought I
> can do much better.
(snip)
> assign ab = a * b;
> assign cd = c * d;
> assign bd = b + d;
> assign res = (tmp0 + tmp1) / tmp2
> always @ (posedge clk)
> begin
> tmp0 <= ab;
> tmp1 <= cd;
> tmp2 <= bd;
> result <= res;
> end
(snip)
How did you decide where to put in the latch? (The result
of the always @() block?
> Okay so it needs reset added and some other things to handle overflow,
> etc. Let's just assume that's not a problem (it's a problem with the
> C code also - and I know how to solve it). My question is this: my
> verilog implies a 2 clock cycle calculation. But there are other area/
> speed possibilities: eg use on multiplier and pipeline the two
> calculations to save on area but take more clock cyles. Also in order
> to get a faster clock cycle it's possible for the multiples to be
> calculated over several clock cycles (I don't want to write the
> multiplier I was just going to let the FPGA tool put in whatever
> multiplier they already have - I haven't looked at how to do that
> yet ... but it's not the issue I'm trying to address here).
Verilog, and so synthesis tools, won't put in any registers
that you don't ask for. If you write a*b that implies a
combinatorial multiplier. That is, a block that will generate
the product with an appropriate delay after its input changes.
No clocks will be implied. If you want a pipelined multiplier,
you either write it yourself (in verilog) or use one from
a library or logic generating program.
> Mostly I want to know how does one synchronise the datapath with the
> control path. Eg say these inputs are used on a different module also
> and I want to know when the result is updated to use it with some
> other calculation I did in parallel. How do I know how many clocks it
> takes (and do I have to code or is it possible to be flexible to do
> trade offs later?).
Synthesis tools will normally generate multipliers, but they
normally don't generate dividers. A combinatorial divider
is big and slow, and rarely wanted, so tools don't generate one.
> Also, do I add an enable input and a ready output to my module to
> model the function call and return of C or how do I handle these
> syncronisations?
That is one reason why the C analogy isn't so good.
In C, you actually call the function, in which case it is
executed and generates the result. The verilog assign statement,
called continuous assign, does not require any execution.
It more closely models wires and gates connected together.
However, verilog normally does not include any delays in
evaluating logic, but real logic has delays. It is up
to you to design logic with the appropriate latches (for
pipelined designs) and delays. For appropriate synchronous
logic design, the tools will calculate a reasonably clock speed.
-- glen
Article: 146690On Mar 25, 6:41=A0pm, "Maurice Branson" <trauben...@arcor.de> wrote: > Thanks, Michael! > > I will have a look at the URL you postet. Anyway I want this project to b= e > one from which I learn a lot. So I am not interested in the 'least brain' > approach but to do as much as I can in VHDL and just use a chipset for th= e > physical link. First of all you should go to USB implementers forum USB-IF and download the specifications of USB 3.0 (which will include host/device/ hub specification). Than you have to read and read and read again to fully understand the USB 3.0. I hope you know that this won't be a project that you will finish in a month or two. I would estimate that one person would spend about 8 hours a day on USB 3.0 one could probably finish it in 12 months (but that might be too optimistic, since the development of USB 3.0 device takes about 6-9 months for a team of HDL developers :)) If you want to learn something first try using ready USB 2.0 chip and implement full hardware control of the chip without any CPU.Article: 146691
wojtek <wojtekpowiertowski@gmail.com> wrote >On Mar 25, 6:41 pm, "Maurice Branson" <trauben...@arcor.de> wrote: >> Thanks, Michael! >> >> I will have a look at the URL you postet. Anyway I want this project to be >> one from which I learn a lot. So I am not interested in the 'least brain' >> approach but to do as much as I can in VHDL and just use a chipset for the >> physical link. > >First of all you should go to USB implementers forum USB-IF and >download the specifications of USB 3.0 (which will include host/device/ >hub specification). Than you have to read and read and read again to >fully understand the USB 3.0. I hope you know that this won't be a >project that you will finish in a month or two. I would estimate that >one person would spend about 8 hours a day on USB 3.0 one could >probably finish it in 12 months (but that might be too optimistic, >since the development of USB 3.0 device takes about 6-9 months for a >team of HDL developers :)) If you want to learn something first try >using ready USB 2.0 chip and implement full hardware control of the >chip without any CPU. I would buy a USB chip. The protocol is a total mess and always has been. I don't know if FTDI do a '3 chip but their standard ones work really well.Article: 146692
Maurice > I will have a look at the URL you postet. Anyway I want this project to be > one from which I learn a lot. So I am not interested in the 'least brain' > approach but to do as much as I can in VHDL and just use a chipset for the > physical link. USB 3.0 requires that a device (peripheral) support the new "Super Speed" *and* at least one other speed (low, full or high). So, in many ways, you would be better doing a USB2.0 device and sticking on a suitable USB PHY for the physical interface. There aren't many USB 3.0 hosts around yet against which you could test your device either: lots of USB 2.0 stuff though! AndrewArticle: 146693
Hi, I'm making a uart that will run at the standard baud rates and have a bit of a query, My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock then derive all the baud clocks from it,,eg, -- 50mhz/ 1843200 = 27.1267 -- 13 bit acc = 4096 msb -- divided by 151 -- 4096/151 = 27.1258 -- close enough -- gives 1.843262MHz clock this is fine for TX but when it comes to RX where the accepted sample clk is 16x the baud rate I hit a few problems. I wanted to sample the incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and use the theory that if two samples match then RX bit is good, It's this generation of a 16x clock that is causing me problems, not easy to create for all baud rates. At the moment I'm sampling the RX at 50MHz and taking samples at three points, this scheme works but seems a bit inefficient due to having to have a bank of constants with the the various count values for different baud rates. Has anyone come across this problem ?Article: 146694
Hi every body; i am working on xilinx EDK with MicroBlaze soft core processor. i am using Virtex 5 ML506 platform studio and my EDK is EDK 9.2 on this processor i am downloading C code for Elliptic curve diffie-hellman key exchange and it is done but result is not displayed on the hyperterminal so is there any body who can help me how to fix my problem? but the connetion of the RS232_uart is working properly i have checked it with simple C code. the baud rate is all ok thank you in advance. kind regards weldat --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146695
On 26/03/2010 03:22, David Wiltshire wrote:
>>
>>> assign res = (tmp0 + tmp1) / tmp2
>>
>> You don't mention it in the rest of your post but you'll find that
>> this divide by tmp2 would give you the biggest headache. Multipliers
>> are easy. All synthesis tools know how to either infer them to use the
>> macros or implement them in the fabric. Dividers are difficult (to
>> optimize that it) especially when they have a non-constant
>> denominator.
>>
>
> Okay, the divider is the trickier of the two - I just looked and I see
> that now. Still FPGA synthesis software includes cores for dividers.
> Still my main question is about timing. The division is going to
> occur over multiple clock cycles. How does this impact my design
> (especially compared to other operations which happen in shorter
> periods of time) and how do I make sure that the result of this
> function is synchronised with other functions?
Hi David,
there are two (or two and a half?) answers
1. You do it manually. It's up to you to develop an architecture in
which all the timing "adds up". Typically people either create a
pipeline and a state machine, or a kind of "baby DSP" i.e. a more
general purpose system that has some kind of stored program control.
Essentially this is a large chunk of what hardware design actually is -
coming up with a good architecture to solve a particular problem, taking
into account the constraints of real hardware.
Of course as you say there's lots of IP you can use.
Regarding you question regarding timing, you can either arrange for
every piece of data to arrive at the correct clock edge using your skill
and judgement; or if it made sense for your application you could use a
handshaking system between blocks; or a FIFO to create an elastic buffer.
More architectural work I'm afraid :-(
2. You pay a lot of money for a behavioural synthesis tool (for instance
Mentor's Catapult C or Forte Cynthesizer - other tools may be available,
I don't intend that to be an exhaustive list). You then either press the
"go" button and hope for the best, or you spend time twiddling the knobs
on the tools until you get what you want.
2.5 Certain RTL synthesis tools do sometimes understand a so-called
implicit state machine style, where you make assignments in a single
process separated by waits for a clock edge. They then infer a state
machine and a datapath from the order of the assignments. (The divider
would still be a problem).
regards
Alan
--
Alan Fitch
Senior Consultant
Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services
Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com
------------------------------------------------------------------------
This message may contain personal views which are not the views of
Doulos, unless specifically stated.
Article: 146696"Andrew Jackson" <alj@nospam.com> wrote news:X_adnaUfiO556jHWnZ2dnUVZ8l2dnZ2d@eclipse.net.uk... > ways, you would be better doing a USB2.0 device and sticking on a suitable > USB PHY for the physical interface. There aren't many USB 3.0 hosts > around yet against which you could test your device either: lots Thanks, Andrew! Sounds resonable to me. So if I start with 2.0 is there a compatibility that I may "expand" my design to a 3.0 core or is it totally different? I learned from what I've read here and in the www that I need at least a separate PHY because that is something that I cannot to in the FPGA fabric. Are there any USB 3.0 PHYs already available? Found nothing. :-( KR MauricaArticle: 146697
Brad Smallridge wrote: > Why shouldn't Xilinx tell us when parts are available. > They are the mfg. They probably have a better idea. > Even an approximation would be better than nothing. > > What's the sales politics in saying you're going to have > a package but don't say when? I think this comes from the fact that many chip vendors stock their chips as wafers. And they package those according to the forecasts they receive. Same silicon fits to many different package types. It's much faster just to package the chips compared to the leadtime of silicon wafer trough the fab. --KimArticle: 146698
da_wils@hotmail.com wrote: > I'm making a uart that will run at the standard baud rates and have a > bit of a query, > My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock > then derive all the baud clocks from it,,eg, > -- 50mhz/ 1843200 = 27.1267 > -- 13 bit acc = 4096 msb > -- divided by 151 > -- 4096/151 = 27.1258 -- close enough > -- gives 1.843262MHz clock I believe that off by 1% is considered close enough. The ones that are usually a little off are 110 baud (for ASR33s) and 134.48 (for IBM 2741s). As you can see, getting exactly 134.48 isn't easy with any divider and normal crystal frequency. I believe tradition is to sample in the middle of the incoming bit time, but sampling more and combining them in some way doesn't sound bad. As well as I remember it, when you see the start bit then you wait 1/2 bit time (8 cycles of 16x), then check to be sure the start bit is still there. If not, then it is just noise. (Currently popular modems probably won't do that, but FSK modems, like the 103, can easily do that.) If the start bit is good, then accumulate bits every 16 clock cycles. The 16x clock gives you a 6% tolerance on where you see the start bit edge. That is the reason for the 16x clock. (Higher would be better, and I have known some that will do 64x.) An important part of asynchronous communication is that it resynchs on the start bit for each character. If the clock is a little off, the error accumulates over each character, but not between characters. -- glenArticle: 146699
When you want to run a serial flow of operations on hardware, maybe you should consider implementing a CPU and have it execute software? The CPU could be a specific one, where you hardcode the operations of your application (=assembler). Or it could be a "standard" one, allowing you to use a C compiler to create the necessary code. You could then attach those "hardware" things, that made you go for hardware in the first place, as peripherials to your CPU and make them available to the software side to be able to combine them in the desired ways. This pushes all timing and concurrency problems into the software, where it's easy to control and understand.
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