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 Clemens, one simple solution: add an RC-circuit to one of your FPGAs inputs. ( R VCC IO C IO GND ) Connect the IO to the Enable input of some cunning counter or LFSR, whatsoever, which is clocked as fast as possible. Make sure that the time constant of the RC-Circuit is significantly greater than the clock period. The (e.g.) counter should stop, when the input goes High. Then you can use it's output as your seed value. Due to variations in temperature, humidity etc. the seed value should be different on each powerup of the board. If you are very clever, you can use an LDR or NTC/PTC resistor or some other resistive or capacitive sensor in your circuit to increase the effect. I know there are drawbacks in effectiveness, but it's just a simple toy solution and better than nothing. Have a nice synthesis Eilert Clemens schrieb: > >> Don't do that. R(0) on the next clock will then be exactly >> the same as R(1) on this clock. Not very random-like. >> >> Consider using two separate LFSRs of different lengths to generate the >> two bits. > > Thanks Jonathan, I just saw this not very random like behaviour in the > simulator ;). So I am thinking of using two 16-bit LFSRs with different > seeds each providing one bit of information. > >> So, on an FPGA what do you mean by "on each run"? Do you want >> each build of the FPGA to have a different seed, or do you want the >> FPGA to choose a different seed each time it powers-up? > > A different seed for each power-up would have been nice. Its not in an > end product, I am just doing some "research" and it would be interesting > to evaluate the behaviour of my implementation with different seeds for > different runs. If the worst comes to the worst I have to sythesise the > design with a different hardcoded seeds each time... > > Cheers, > ClemensArticle: 132301
On May 21, 8:07=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > On May 20, 10:17=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > > > > > austin wrote: > > > Joseph, > > > > Imagine all those Altera customers who designed in the Stratix III GX:= > > > all dressed up, and nowhere to go. > > > Maybe Altera also shares roadmaps like you do to bigger customers, and > > those designers maybe do not exist... Imagine all those V4FX designers > > who wanted working fast tranceivers. > > > I would say all vendors offer surprises to customers who are using > > leading edge devices. > > > > Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because= > > > they are IDENTICAL to the FPGA > > > My opinion is that EasyPath is the worst of the two worlds. It has > > limitations in flexibility, and the possibilities with price are > > not that great because it is the same silicon. Better to have either > > the full flexibility which costs or then the lowest possible cost > > with no flexibility. > > > --Kim > > Let's not turn this into a marketing slugfest. > It does not take a genius to figure out why Altera was forced to > embark on such a risky gamble... > "We live in interesting times" > Peter Alfke- Hide quoted text - > > - Show quoted text - And So the fudd begings to flow :) Or should we talk about sour grapes.Article: 132302
Thank you for your input, we will try the debugging.Article: 132303
Hi All, When compiling a design I receive the following message: :Pack:1653 - At least one timing constraint is impossible to meet because component delays alone exceed the constraint. A physical timing constraint summary will appear in the map report. This summary will show a MINIMUM net delay for the paths. For more information about the Timing Analyzer, consult the Xilinx Timing Analyzer Reference manual. For more information on TRCE, consult the Xilinx Development System Reference Guide "TRACE" chapter. The problem however is that I receive no information WHICH SIGNAL PATH generates that problem, so I'm not able to redesign my core... The timing constraints are already the most liberal to be accepted by external hardware. How to identify the path generating the problem? I can not run the timing analyzer, because the map fails. -- TIA & regards, Wojtek ZabolotnyArticle: 132304
On 20 May, 03:03, jhal...@TheWorld.com (Joseph H Allen) wrote: > They've also released Hardcopy-IV, including serdes and PCI-e. =A0Why both= er > with ASICs... Cost - power - analog. JonArticle: 132305
"Wojciech Zabolotny" <wzab@ipebio15.ise.pw.edu.pl> wrote in message news:slrng37qjj.ab6.wzab@ipebio15.ise.pw.edu.pl... > Hi All, > > When compiling a design I receive the following message: > > :Pack:1653 - At least one timing constraint is impossible to meet because > component delays alone exceed the constraint. A physical timing > constraint > summary will appear in the map report. This summary will show a MINIMUM > net > delay for the paths. For more information about the Timing Analyzer, > consult > the Xilinx Timing Analyzer Reference manual. For more information on > TRCE, > consult the Xilinx Development System Reference Guide "TRACE" chapter. > > The problem however is that I receive no information WHICH SIGNAL PATH > generates that problem, so I'm not able to redesign my core... > The timing constraints are already the most liberal to be accepted by > external > hardware. > > How to identify the path generating the problem? > I can not run the timing analyzer, because the map fails. > -- > TIA & regards, > Wojtek Zabolotny Hi Wojtek, In the ISE GUI (I'm using 8.2 at the moment; I hope your version is similar), find the 'Processes' window. Expand the section 'Implement Design', then expand 'Map', then 'Generate Post-Map Static Timing'. If you double-click 'Analyze Post-Map Static Timing', it'll churn away and eventually open the timing analyser. You can then find what path is failing. The key insight is to run the timing analyser on the map results, before you enter the P&R phase. HTH, Syms.Article: 132306
> > How to identify the path generating the problem? > > I can not run the timing analyzer, because the map fails. > > -- > > TIA & regards, > > Wojtek Zabolotny > > Hi Wojtek, > In the ISE GUI (I'm using 8.2 at the moment; I hope your version is > similar), find the 'Processes' window. Expand the section 'Implement > Design', then expand 'Map', then 'Generate Post-Map Static Timing'. If you > double-click 'Analyze Post-Map Static Timing', it'll churn away and > eventually open the timing analyser. You can then find what path is failing. > The key insight is to run the timing analyser on the map results, before you > enter the P&R phase. > HTH, Syms. The problem is, that I can not 'Generate Post-Map Static Timing', because the map fails! -- WojtekArticle: 132307
On Wed, 21 May 2008 02:54:02 -0700 (PDT), wzab <wzab01@gmail.com> wrote: >> > How to identify the path generating the problem? >> > I can not run the timing analyzer, because the map fails. >> > -- >> > TIA & regards, >> > Wojtek Zabolotny >> >> Hi Wojtek, >> In the ISE GUI (I'm using 8.2 at the moment; I hope your version is >> similar), find the 'Processes' window. Expand the section 'Implement >> Design', then expand 'Map', then 'Generate Post-Map Static Timing'. If you >> double-click 'Analyze Post-Map Static Timing', it'll churn away and >> eventually open the timing analyser. You can then find what path is failing. >> The key insight is to run the timing analyser on the map results, before you >> enter the P&R phase. >> HTH, Syms. > >The problem is, that I can not 'Generate Post-Map Static Timing', >because the map fails! Relax the timing until it maps, then you can find the slowest paths (at PAR if necessary). Fix these and retry. Then tighten the timings a bit. Repeat until done. It's frustrating, I agree. Map should have completed, just to let you run the report. Alternatively, what did synthesis report as the longest paths? Did they exceed your timing constraints? It may be worth fixing those first. (However, synthesis may not see the longest path if you are using black box components) - BrianArticle: 132308
On 21 Mai, 08:07, Peter Alfke <al...@sbcglobal.net> wrote: > On May 20, 10:17 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > Let's not turn this into a marketing slugfest. > It does not take a genius to figure out why Altera was forced to > embark on such a risky gamble... > "We live in interesting times" > Peter Alfke waiting for Spartan-4 is boring.. not interesting :( Antti PS but times are interesting yesArticle: 132309
"wzab" <wzab01@gmail.com> wrote in message news:7572b54b-1e31-433c-8c08-cd96f69d8351@k37g2000hsf.googlegroups.com... >> > How to identify the path generating the problem? >> > I can not run the timing analyzer, because the map fails. >> > -- >> > TIA & regards, >> > Wojtek Zabolotny >> >> Hi Wojtek, >> In the ISE GUI (I'm using 8.2 at the moment; I hope your version is >> similar), find the 'Processes' window. Expand the section 'Implement >> Design', then expand 'Map', then 'Generate Post-Map Static Timing'. If >> you >> double-click 'Analyze Post-Map Static Timing', it'll churn away and >> eventually open the timing analyser. You can then find what path is >> failing. >> The key insight is to run the timing analyser on the map results, before >> you >> enter the P&R phase. >> HTH, Syms. > > The problem is, that I can not 'Generate Post-Map Static Timing', > because the map fails! > -- > Wojtek OK, soz that didn't help you, ISE 8.2 doesn't seem to behave like that, I've only experienced this problem when it does the timing stuff in P&R. Out of interest, what version of the tools are you using? It sounds like a big backwards step from what I'm used to! Maybe there's a switch to turn off timing driven mapping? Cheers, Syms. p.s. What Brian posted! :-)Article: 132310
On May 21, 1:19 am, vikram <vikram...@gmail.com> wrote:
> On May 19, 5:44 pm, morphiend <morphi...@gmail.com> wrote:
>
>
>
> > On May 19, 1:35 am, vikram <vikram...@gmail.com> wrote:> hello,
>
> > > I am trying to interface between my pc (windows) and a Xilinx
> > > Virtex2Pro board using ethernet. i am told i require Xilinx PLB
> > > Ethernet MAC ip core. i must admit i am very new to such work, forgive
> > > my blatantness.... i would like to know:
>
> > > 1) What exactly do i get in the Xilinx Ethernet MAC ip core? (design
> > > files etc?)
>
> > You get the unlocked CoreGen core. In other words, you could generate
> > the core from CoreGen and use it however. Or, you'll be able to use it
> > directly in EDK. Of course, since you're referring to the V2Pro,
> > you're also referring to the Softcore MAC. This provides a full MAC
> > capable of performing 10/100 communication. Starting with EDK 9.2, the
> > OPB version of the core has been released for 'free' (included w/ the
> > purchase of EDK 9.2).
>
> > > 2) Using XPS (EDK 9.1) and ISE 9.1, how do i integrate it into an
> > > existing project?
>
> > It will appear as an unlocked core in the High-Speed communications
> > category of the EDK core list in any of your projects.
>
> > > 3) the ethernet is just a part of the project.... i only need to
> > > transfer data between my pc and the board.... should the MAC be a part
> > > of the board?
>
> > Well, Ethernet is split into multiple parts. The first part is the PHY
> > or the physical communication. This provides the lowest layer to which
> > the data is transmitted. This device is responsible for conversion
> > from a Media-Independent Interface (R/S/G/MII) to the physical layer:
> > copper/fiber/etc. The next layer up is the MAC: Media Access Control.
> > This provides the conversion from your real data into a Media-
> > Independent Interface (R/S/G/MII). So unless you're going to build
> > your own MAC and design it to meet all of the IEEE specs for whatever
> > MII you use, then YES you need it.
>
> > > 4) do i have to use an embedded processor (microblaze/powerpc) to
> > > integrate the MAC?
>
> > No, but depending on what you're doing you may want to have processor
> > perform the work. It's possible to create devices that just take/put
> > streams with solely logic and state machines. But if you want to start
> > handling TCP traffic or anything higher-layer (HTTP/FTP) or more
> > complicated you will probably want a processor and software to handle
> > it. But that's my $0.02.
>
> > -- Mike
>
> dear Mike
>
> thanks for the prompt response. the board i'm using has an on-board
> PHY.>You get the unlocked CoreGen core. In other words, you could generate
>
> the core from CoreGen and use it.
>
> once i have the generated MAC core, do i just add it to my existing
> project to 'use' it?
> or, from EDK, do i add it as a peripheral ("import peripheral") to my
> existing project?
>
> thanks again
> vikram
If you have the core unlocked, it should show up as a core in the High-
Speed Communication 'folder' in the cores tree. In other words, there
isn't much you'd have to do to 'import' it into EDK. It should be
their auto-magically.
Article: 132311On 2008-05-21, fazulu deen <fazulu.vlsi@gmail.com> wrote: > As per Andreas: it is always advised that FOR loops are not to be > used in RTL coding Just to set the record straight: What I sad was that we recommend our students in _introductory_ courses to avoid for-loops. The reason is that we have seen too many cases of students who try to program in VHDL or Verilog instead of designing hardware in VHDL or Verilog. We believe that it is probably not a good idea to teach for-loops before a student has grasped the basic concepts of hardware design using RTL language. As I mentioned in an earlier posting, there is nothing magical about for loops, the synthesizer will simply unroll the loop. For-loops (especially in conjunction with generate) can be a great way to minimize the amount of typing. /ANdreasArticle: 132312
On May 20, 8:26=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> fazulu deen wrote:
> > hai,
>
> > I learned from the Xilinx manual that for,while do statements are
> > synthesized in XST..
>
> > I would like to know how these statements(for,while,do while) are
> > implemented as logic design(EDIF and constraints) in FPGA device?? .
>
> > Though FOR loop is synthesizable , it is always advised that FOR loops
> > are not to be used in RTL coding. This is because it consumes lot of
> > resources (like area etc)whether XST will not optimize it before
> > targetting to FPGA device???
>
> > As wait() is not supported for synthesis wat should i use instead of
> > wait()??
>
> > regards,
> > faz
>
> One key point with these loops is that the conditionals that define
> how much to loop are typically only supported for constants. =A0Trying
> to do a for loop with a vector controlling your max value will
> probably only bring synthesis errors. =A0Using parameters or other
> constant values allow you to use these loops without the synthesis
> complaints.
>
> - John_H
hai,
As per Andreas: it is always advised that FOR loops are not to be
used in RTL coding
for example:
for(int i=3D2; i>=3D0; i--) {
c+ =3D a[i]*b[i+1];
};
In this case it is probably a much better idea to write a small state
machine
for example:
case (state)
first:
begin
c+ =3D a[2]*b[3];
c+ =3D a[1]*b[2];
c+ =3D a[0]*b[1];
state=3Doutput;
end
=2E......
I would like to know the difference between number of clock
cycles,adders and multipliers required when "for" loop is used and
"state machine" is used??
Wat is the advantage i get interms of number of clocks,resources if i
have more number of states the above example is divided as 3 states
instead of 1 as follows.??
case (state)
first:
begin
c+ =3D a[2]*b[3];
state=3Dsecond;
end
second:
begin
c+ =3D a[1]*b[2];
state=3Dthird;
end
third:
begin
c+ =3D a[0]*b[1];
state=3Doutput;
end
regards.
faz
Article: 132313Hi I have an evaluation board with a target and a control FPGA. The control FPGA is connected to the target FPGA over 32-bit local bus and can write the data to a host PC over a RS232 interface. Both FPGAs are internally clocked with 24MHz. So I have to implement on the control FPGA a transmitter that gathers the 32 bits and sends them in 8 bit chunks to the host PC. I wonder if somebody has some helpful ressources how to implement such an simple interface. Also I have to implement a suitable divisor for the baudgenerator to generate 115200 Hz from 24MHz. Would be thankful for helpful comments and ressources ;) Dan!Article: 132314
Dan Arik wrote: > Hi > > I have an evaluation board with a target and a control FPGA. The control > FPGA is connected to the target FPGA over 32-bit local bus and can write > the data to a host PC over a RS232 interface. Both FPGAs are internally > clocked with 24MHz. So I have to implement on the control FPGA a > transmitter that gathers the 32 bits and sends them in 8 bit chunks to > the host PC. I wonder if somebody has some helpful ressources how to > implement such an simple interface. Also I have to implement a suitable > divisor for the baudgenerator to generate 115200 Hz from 24MHz. > > Would be thankful for helpful comments and ressources ;) > > Dan! There are a couple of UART cores available on OpenCores that you can take a look through. Other than that, I seem to recall that Ken Chapman's UART implementation that comes packaged with the PicoBlaze core works pretty nicely. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 132315
I caught the long thread here on the quadrature rotary encoder from 2 weeks ago. Like the OP in that thread, I am new to combinatorial logic and describing it with VHDL. The problem on the surface seems so enticingly simple. Peter's solution presented with the "high" speed clock strikes me as wasteful. (I'll gratefully accept your guidance and correction, of course.) The quadrature decoder itself seems reasonably well defined by a single D flipflop with clock enable. One encoder switch (call it q1) clocks the dff on its rising edge. Debouncing logic drives the clock-enable. The second encoder switch (q2) drives D, making Q the direction of rotation. Direction and some strobe can feed the direction and clock on an up/down counter. The "some strobe" part could be problematic. Is there no way to generate this without an external clock? If I drive the counter clock from the debounced q1, it arrives before direction is valid. (Maybe that's good enough and usable. I only want to get this into the starter kit, marvel at some moving LEDs, and then move on. At this point, I can live with a little backlash and some inaccuracy at direction changes.) It seems I can simply gate q1 with an inverted debounce signal, using a simple AND2 with one inverted input, to drive the counter strobe. Debouncing seems on the surface pretty simple also: ignore further changes on q1 until q2 changes sense. And this seems to be where I'm stuck. I want to sample q2 on the rising edge of q1, and compare q2 with its value with the old q2 value when debouncing started. Alternatively, I want to clock "something" on the next arriving rising _or_ falling edge of q2. XST doesn't like either one, and my head is likewise in a pretzel here. Isn't there any way to do this part without an external clock? (I left school 25 years. This is self assigned homework, and usenet and amazon.com are my only classrooms. Your help is really the only help I'll get.) Regards, Mike.Article: 132316
Mike, There is always a clock present (FPGA design can only be done in a synchronous system, synchronous means there is a clock, speed is unimportant, but today folks want performance, which usually means at least one ~50 MHz clock will be present somewhere). If you are not using a FPGA, well, then, have fun. AustinArticle: 132317
Jim Granville wrote: > That may have more to do with the implicit ELSE handling. > ie One State engine locks solid, the other will recover > in a few clocks (which means you may not notice, or have not > yet noticed the effects!) > > Even with input registering, you should cover ALL states, > (including the 'illegal' ones) in your state code. > That's pretty easy to do with binary coded states, but with one-hot, and enumerating the type, how do you even SPECIFY the illegal states, as those, by definition, would be the ones with two or more bits "hot"? > Can you clarify 'too frequently' ? > With a 25ns clock, a couple of IPs and 5 choices, lets > take a nice round 100ns IP sample rate. (10MHz) > The external signals, all two of them are from a mechanical system, and change slowly. Thanks, JonArticle: 132318
Jeff Cunningham wrote: > Jon Elson wrote: > >>> In addition to registering all inputs, you also should make sure that >>> the state machine is initialized with a synchronous reset after your >>> DLLs have locked. >> >> No DLLs, just a plain single clock. The state machine and all other >> hardware >> does initialize perfectly. > > > Just be aware that even without DLLs to worry about, the internal reset > is asynchronous and can cause problems if the state bits see it go away > on different clock pulses, i.e. it is another asynchronous input to your > state machine. I never had a problem with the reset/initial state, that has worked fine all the time. But, I'll keep this in mind! JonArticle: 132319
MikeWhy wrote:
> I caught the long thread here on the quadrature rotary encoder from 2
> weeks ago. Like the OP in that thread, I am new to combinatorial logic
> and describing it with VHDL.
Learn to snowplow before you ski in the trees.
Combinational logic is an advanced topic in my book.
Start with a synchronous process.
> The problem on the surface seems so enticingly simple. Peter's solution
> presented with the "high" speed clock strikes me as wasteful.
It isn't.
Flops are free on an FPGA.
...
> Alternatively,
> I want to clock "something" on the next arriving rising _or_ falling
> edge of q2. XST doesn't like either one, and my head is likewise in a
> pretzel here.
Ah, there's the rub.
Synchronous design requires much less thinking,
and can be proven to work with computer simulation
and static timing analysis.
-- Mike Treseler
Article: 132320MikeWhy wrote: > I caught the long thread here on the quadrature rotary encoder from 2 > weeks ago. Like the OP in that thread, I am new to combinatorial logic > and describing it with VHDL. > > The problem on the surface seems so enticingly simple. Peter's solution > presented with the "high" speed clock strikes me as wasteful. (I'll > gratefully accept your guidance and correction, of course.) > > The quadrature decoder itself seems reasonably well defined by a single > D flipflop with clock enable. One encoder switch (call it q1) clocks the > dff on its rising edge. Debouncing logic drives the clock-enable. The > second encoder switch (q2) drives D, making Q the direction of rotation. > Direction and some strobe can feed the direction and clock on an up/down > counter. I use a state machine that only allows transitions from one AB state to another adjacent state, ie. only allowing one input to change state at a time. If both A and B change at the same time, it is impossible to determine which direction the movement was. JonArticle: 132321
Antti wrote: > On 21 Mai, 08:07, Peter Alfke <al...@sbcglobal.net> wrote: > >>On May 20, 10:17 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: >> >> >>Let's not turn this into a marketing slugfest. >>It does not take a genius to figure out why Altera was forced to >>embark on such a risky gamble... >>"We live in interesting times" >>Peter Alfke > > > waiting for Spartan-4 is boring.. not interesting :( I'm left wondering whatever happened to Altera's MAX III devices ? ;) Seems to be 'missing in action' ? -jgArticle: 132322
MikeWhy wrote: > I caught the long thread here on the quadrature rotary encoder from 2 > weeks ago. Like the OP in that thread, I am new to combinatorial logic > and describing it with VHDL. ** Listens for the noise from Peter's foxhole ** ;) > > The problem on the surface seems so enticingly simple. Peter's solution > presented with the "high" speed clock strikes me as wasteful. It has a more than minimal register count, but in a FPGA that is hardly an important issue. > (I'll gratefully accept your guidance and correction, of course.) All the presented solutions used a higher speed clock. > > The quadrature decoder itself seems reasonably well defined by a single > D flipflop with clock enable. One encoder switch (call it q1) clocks the > dff on its rising edge. Debouncing logic drives the clock-enable. The > second encoder switch (q2) drives D, making Q the direction of rotation. > Direction and some strobe can feed the direction and clock on an up/down > counter. > > The "some strobe" part could be problematic. Is there no way to generate > this without an external clock? If I drive the counter clock from the > debounced q1, it arrives before direction is valid. You can use a delay-line, to get a later clock edge. (see below) > (Maybe that's good > enough and usable. I only want to get this into the starter kit, marvel > at some moving LEDs, and then move on. At this point, I can live with a > little backlash and some inaccuracy at direction changes.) It seems I > can simply gate q1 with an inverted debounce signal, using a simple AND2 > with one inverted input, to drive the counter strobe. > > Debouncing seems on the surface pretty simple also: ignore further > changes on q1 until q2 changes sense. And this seems to be where I'm > stuck. I want to sample q2 on the rising edge of q1, and compare q2 with > its value with the old q2 value when debouncing started. Alternatively, > I want to clock "something" on the next arriving rising _or_ falling > edge of q2. XST doesn't like either one, and my head is likewise in a > pretzel here. Isn't there any way to do this part without an external > clock? It is POSSIBLE to make a self-clocked Quadrature counter (and I have done it, in a CPLD), but it is NOT simple, and can use MORE logic than a clocked one. It is very much a niche-solution, for cases where you do not have any other clock domains, and want the lowest possible power. There is another 'hybrid' solution, which adds some 'change-sense' logic to the State-Follower-Faster-Clock design, and it enables the Clock,(or clock osc) UNTIL the States are locked again (latency varies with earlier posted examples), no more than a handful of clocks later. This will have very high sleep:clk ratios. This is (slightly) more logic than the simplest design, but will save a lot of power. It would be well suited to a CPLD with a 1 terminal Gated RC Osc, and low idle power/low emc design targets. Idle (but ready) state powers under 10uA are possible with this approach. It is also much simpler to design with today's tools :) -jgArticle: 132323
On Wed, 21 May 2008 17:23:27 +0100, Dan Arik wrote: > I have to implement on the control FPGA a >transmitter that gathers the 32 bits and sends them in 8 bit chunks to >the host PC. I'd recommend you do NOT try to send a 32-bit word as 4 bytes over a UART. Instead, find some way to represent the 32-bit word using plain text (printable ASCII characters in the range 0x21-0x7E). Plain ASCII hex is an obvious choice, but rather extravagant (at least 8 characters per 32 bits); if throughput on your serial port is not a big problem, plain ASCII hex is good because it's so easy to generate and debug. If you need better throughput, you can use btoa or uuencode tricks to put the 32 bits into 5 or 6 plain-text characters. Think, too, about how you can reliably indicate the boundaries of your "here's a word" messages. A newline character on the end of your 8-character hex word is an easy and reasonable choice, and again is very convenient for debug. >Also I have to implement a suitable >divisor for the baudgenerator to generate 115200 Hz from 24MHz. 24MHz/13 is almost exactly 16x115200Hz. Plenty close enough for a UART clock, anyway. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 132324
Dan Arik wrote: > Hi > > I have an evaluation board with a target and a control FPGA. The control > FPGA is connected to the target FPGA over 32-bit local bus and can write > the data to a host PC over a RS232 interface. Both FPGAs are internally > clocked with 24MHz. So I have to implement on the control FPGA a > transmitter that gathers the 32 bits and sends them in 8 bit chunks to > the host PC. I wonder if somebody has some helpful ressources how to > implement such an simple interface. Also I have to implement a suitable > divisor for the baudgenerator to generate 115200 Hz from 24MHz. > > Would be thankful for helpful comments and ressources ;) > > Dan! A sample implementation for a serial receiver/transmitter with explanations about the used methods can be found at the very recommendable site www.fpga4fun.com Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. Thom
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