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
Thanks for the suggestions Michael. The point is that when ISE runs out of disk space it does not, in my experience, say "no space available on device" or something like that. It usually says something like "internal error". --steve "Michael" <michael_laajanen@yahoo.com> wrote in message news:8qe1ohF3lmU1@mid.individual.net... > Dont top post on Usenet. http://www.caliburn.nl/topposting.html > > Then you should have a better control of your server I think and keep > track of usage per day or so. > > There are tools that can monitor diskuage and alert when you are reaching > a critical level.Article: 150626
On 26/01/2011 12:52, Nial Stewart wrote: >> With a sync reset, if it meets timing, it should run ok. > > > I have had it confirmed that if you generate a reset synchronously then use it > 'asynchronously' in the standard process template (VHDL) that Quartus knows it's > a synchronous signal and all timing analysis is correctly handled. > > > Nial. > > Rick is correct, where generic code loses its portability, and not all devices or manufacturers may have this property. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 150627
On 26/01/2011 14:09, Emanuele83 wrote: > On Jan 26, 8:45 am, Emanuele83<emanuele83katam...@googlemail.com> > wrote: >> On Jan 26, 6:44 am, rickman<gnu...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >>> On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote: >> >>>> Emanuele83<emanuele83katam...@googlemail.com> wrote: >>>>> Good day to everybody, >> >>>>> Chipscope core to debug my modifications, the design was no more able >>>>> to perform correct operations nor to communicate with some external >>>>> chips creating corrupted data. Even if ALL the constraints at 40MHz >> >>>> IMHO this is a problem with unconstrained paths. Did you constrain >>>> input to ff and ff to output paths? Did you constrain paths between >>>> unrelated clock domains? >> >>>>> Some info: >>>>> 1_I have no possibility to check if the FPGA HW is broken or not. X- >>>>> ray or what else. I just wait for a new board which should be backed >>>>> carefully >>>>> 2_I have no chances to perform post route simulations for the whole >>>>> project (I am in a hurry) and with my old design I did not do it >>>>> (SPARTAN 2) and everything was perfectly working (also without setting >>>>> any constraint over PERIOD or OFFSET) >>>>> 3_I have 3 boards, when I program them with the same bitstream they >>>>> behave sometimes differently. >> >>>> This may be due to FPGA variations. I'd get the constraints sorted out >>>> first. Perhaps you could buy a development board and verify your >>>> design on that so you have a proper reference. >> >>> That is one of the things I have always felt was lacking, a way to >>> verify timing constraints. I've talked to FPGA vendors and their >>> attitude is just that an engineer should be able to write the >>> constraints correctly, period. No need to verify! Boy, that goes >>> against everything I've ever learned about engineering. You can have >>> problems with ANY part of a design. Being able to verify all aspects >>> of your design is much better than "testing". Testing can prove the >>> existence of faults, but it can't prove the absence... at least not >>> without a LOT of effort and analysis. In fact, testing is a lot like >>> constraints, you have to do it "right" and how do you prove that you >>> have done the testing "right"? >> >>> Rick >> >> Holy words, fellow, holy words! :) We use more time to writing the >> correct test (that must be done carefully) than to design the logic... >> >> I am going to test the power supply section, but I've already tested >> yesterday that compiling the same code, setting the drive strength of >> I/Os to a safer value (from 6 to 2) the behaviour of the system is no >> more consistent. I left all the timing constraints unchanged, always >> met, @40Mhz speed, but it does not work.... > > > 1_ I checked the power supply of the board. I fixed some minor stuff, > and I checked the layout. My colleague has forgot to split the power > plan for VCCAUX and VCC_0 so I thought that maybe the noise introduced > by switching I/Os on the VCCAUX could create problems with the DCMs > that I was using. take a look to the clock architecture: > > http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/8738/1/dcm_arch.jpg > > this was the one at the very beginning (at 80MHz) and now I changed > using the same DCM structure but with 40MHz (output of first DCM is > not clk_2x anymore) and everything now works with 40Mhz. > The second DCM has the only purpose to deskew the RAM chips (which > work at 40MHz now) > > Thinking that the problem was on DCM's noisy power supply I just > removed the DCM and bypassed the 40 MHz clock input directly to the > ram output, the external feedback is no more used and the logic is > clocked directly with the external clock. > it seems better, but if I change the compiling settings (optimizing > for area and not for speed for example) the system does not work... > The design seems less affected from the settings modifications but it > is not yet stable, and the goal of 80Mhz is still far away :( > > 2_ I find sometimes this WARNING in the map log: > Pack:266 - The function generator inst_arbiter_core/hist_box_ch_0/ > state_m_1_FSM_Out21 failed to merge with F5 multiplexer > inst_arbiter_core/hist_box_ch_0/i_FSM_FFd2-In21_f5. There is a > conflict for the FXMUX. The design will exhibit suboptimal timing. > I am not able to link it to the abnormal behaviour yet, but i found no > explanation in the Xilinx website. Does somebody know something about > it? > I usually use some VARIABLES in my processes, also in the state > machine which gives the PACK:266 error. they are not SHARED VARIABLES > and are modified only synchronously, but sometimes i use them as a > trick to save some clock cycles of latency (implementing real > instantaneous assignments). Is a practice that should be avoided in a > good VHDL code? > > > Thanks, > Emanuele If the power supply is marginal in terms of noise, it may be worth fixing the location of the DCM to a site on a quieter side of the FPGA. It is something I've had to do when decoupling was not ideal, where different compilations gave very different results similar to your experience. Have you looked at the 80MHz output pin using a 'scope? Is it clean? When interfacing the logic from your "Rest of Logic" to the "Ext 40MHz chip", how are you qualifying which edge of the 80 MHz clock the data changes on? I don't see any issue with using variables, shared or otherwise. I would have thought synthesis would take out common logic where it feels it can. One consequence of using variables in the manner you describe would be more levels of logic, leading to a slower design. If timing constraints are set correctly, then this ought not be an issue. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 150628
On 01/27/2011 09:12 PM, KK6GM wrote: > Newb question: suppose I want to create a shift register that's > clocked from an external source (like an SPI slave device). My > impression (correct me if I'm confused) is that if the external clock > is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock > and a 50MHz fast clock), I can sync both clock and data to the fast > clock and proceed from there, using the fast clock along with an edge > detected signal for further processing. The fast clock is mapped to > low-skew clock lines which are designed for the purpose, so things are > good. > > But what if the clock is not slow WRT the fast clock? What if the > external clock is too fast to reliably sync with the fast clock? e.g. > a 20MHz clock and a 50MHz fast clock. In that case it seems that the > external clock needs to be used directly, but won't there be potential > clock skew problems using a regular input as a clock? I'd appreciate > insight on how such problems are dealt with, if indeed they are even > problems at all. That's why Xilinx provides multiple low-skew clock nets on their FPGAs. In some cases it is necessary to run significant amounts of logic from different clocks, and then have some synchronizing mechanism somewhere in the middle. That can be hard or easy, depending on a number of circumstances. JonArticle: 150629
> >When it happens that a design really needs some clock routed trough >ordinary routing ressources, the problems you mentioned apply. >So the designer has to make sure that the net stays as small as >possible, and tries to controll it with tight timing constraints. > This is where the ability the lock flops into place and hand route is handy. Shift registers on high skew clocks are always dicey because you don't have any next state logic to help ensure that you meet hold time requirements so you might get "shoot through". Some things that you can try: 1) Counter flow your clock. Route the clock to the very last flop in the chain and then from there go to the next to last until you get to the first flop. That way you are always sending data to a flop on an earlier clock and that delay helps meet hold time. 2) Split your clock in two. Create a clock and clock_n and double the number of flops in the chain. Alternate clocks on the chain with the rising one going to the input flop that then feeds a falling clock flop. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150630
On Jan 27, 7:42=A0am, Emanuele83 <emanuele83katam...@googlemail.com> wrote: > all the I/Os are constrained. > > the point is: > same VHDL code+same constrains --> changing synthesis/mapping/PAR options= --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes. > > > > > > >In general computers do what they are told not what you expect them to > do. > > Exactly what I do with my code that has been simulated and the algorithm = results correct. It is very unlikely that if you have constraints on the design (and it sounds like you have), that the behaviour changes from run to run, and that the reason is the implementation tool's fault. It sounds like an asynchronous/clock domain issue. Do you have more than one clock in the design? How are all crossings handled? Are any of the external inputs/internal signals async to the clock at all? As for process size - the tools themselves have no limitations in this regard - other posters were only pointing out that for the engineer to be able to keep a clear idea in his head, and to be able to quickly visually verify that a process is correct, it helps to keep the code split up into smaller more functional processes. It's not required, but it makes the engineers life at design time, and for any later modifications much easier. This is what was meant my maintainability. Splitting a process up does not necessarily add latency - in fact, it can help you discover and separate the more critical parts. In a way it is like doing a schematic, it helps to know logically how it should be separated in a schematic, and then code that. good luckArticle: 150631
On Jan 16, 4:36 pm, Mike Treseler <mtrese...@gmail.com> wrote: > On 1/15/2011 12:09 PM, rickman wrote: > > > This is starting to sound like VHDL...! I don't mind being explicit. > > It is just that in VHDL it can get rather confusing as to what you > > need to be explicit about or how exactly to be explicit. > > > I find it hard to believe that there are no good texts on this. > > It is true. > I found this one slightly useful:http://www.google.com/search?q=botros+isbn+1584508558 > > It's the only book of side by side vhdl|verilog examples in print. > But that is all it is -- simple synthesis examples and a short > explanation. No language reference or simulation examples. > But it's a quick way for a vhdl guy to get started > on verilog synthesis, and the price is right. > > -- Mike Treseler Why do you say this is the "only" text? I know of at least two others that cover both VHDL and Verilog. One is Ben Cohen's book, "Real Chip Design and Verification Using Verilog and VHDL". The other I have, Douglas J. Smith, "HDL Chip Design". The Smith book has side by side examples of both like you describe for the Botros book, but I can't say about the Cohen book since I haven't seen it. I will say this is the only affordable one of the three. The other two are $167 and $135! Thats just too rich for my blood. RickArticle: 150632
I've implemented a DSSS receiver in an FPGA. The code rate NCO is
controlled by an early/late detector. The carrier NCO is controlled by a
Costas Loop. I chose PI gain constants for the control loops by trial and
error but would like to do it more scientifically by analysing stability
using a Bode plot of open loop gain. I always do it this way for analogue
PLLs; but I'm new to z-domain stability analysis.
TimW - I bought your book; but, to be honest, found it quite heavy going.
Nevertheless, adapting some code from the accompanying CD, I came up with
this Scilab script:
kPD = 2^20;
kP = 2^(41-64);
kI = 2^(15-64);
kNCO = 10000;
G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
G.dt = 1e-3;
scf(0);
clf;
bode(G);
The resulting Bode plot never even passes through unity gain! So is the
system unconditionally stable? Here's a simplified version of the FPGA
code:
`define KP 41
`define KI 15
reg [63:0] phase, rate; // 64 places after the binary point
reg signed [31:0] err; // = Early - Late
always @ (posedge clk) // 10 MHz
if (millisecond) begin
phase <= phase + rate + (err << `KP);
rate <= rate + (err << `KI);
end else
phase <= phase + rate;
It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3
and kNCO = 10000.
Is the Bode plot correct?
TIA
Article: 150633On Sun, 30 Jan 2011 17:53:06 -0000, "Andrew Holme" <ah@nospam.com> wrote: >I've implemented a DSSS receiver in an FPGA. The code rate NCO is >controlled by an early/late detector. The carrier NCO is controlled by a >Costas Loop. I chose PI gain constants for the control loops by trial and >error but would like to do it more scientifically by analysing stability >using a Bode plot of open loop gain. I always do it this way for analogue >PLLs; but I'm new to z-domain stability analysis. > >TimW - I bought your book; but, to be honest, found it quite heavy going. >Nevertheless, adapting some code from the accompanying CD, I came up with >this Scilab script: > >kPD = 2^20; >kP = 2^(41-64); >kI = 2^(15-64); >kNCO = 10000; >G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1); >G.dt = 1e-3; >scf(0); >clf; >bode(G); > >The resulting Bode plot never even passes through unity gain! So is the >system unconditionally stable? Here's a simplified version of the FPGA >code: > >`define KP 41 >`define KI 15 > >reg [63:0] phase, rate; // 64 places after the binary point >reg signed [31:0] err; // = Early - Late > >always @ (posedge clk) // 10 MHz > if (millisecond) begin > phase <= phase + rate + (err << `KP); > rate <= rate + (err << `KI); > end else > phase <= phase + rate; > >It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3 >and kNCO = 10000. > >Is the Bode plot correct? > >TIA > Is 'err' quantized to two values, early or late bang-bang style, or is it some finer-grain time error signal? JohnArticle: 150634
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:3p9bk6tm0uqf4ol2kdbm95a3en7g8b0acn@4ax.com... > On Sun, 30 Jan 2011 17:53:06 -0000, "Andrew Holme" <ah@nospam.com> > wrote: > >>I've implemented a DSSS receiver in an FPGA. The code rate NCO is >>controlled by an early/late detector. The carrier NCO is controlled by a >>Costas Loop. I chose PI gain constants for the control loops by trial and >>error but would like to do it more scientifically by analysing stability >>using a Bode plot of open loop gain. I always do it this way for analogue >>PLLs; but I'm new to z-domain stability analysis. >> >>TimW - I bought your book; but, to be honest, found it quite heavy going. >>Nevertheless, adapting some code from the accompanying CD, I came up with >>this Scilab script: >> >>kPD = 2^20; >>kP = 2^(41-64); >>kI = 2^(15-64); >>kNCO = 10000; >>G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1); >>G.dt = 1e-3; >>scf(0); >>clf; >>bode(G); >> >>The resulting Bode plot never even passes through unity gain! So is the >>system unconditionally stable? Here's a simplified version of the FPGA >>code: >> >>`define KP 41 >>`define KI 15 >> >>reg [63:0] phase, rate; // 64 places after the binary point >>reg signed [31:0] err; // = Early - Late >> >>always @ (posedge clk) // 10 MHz >> if (millisecond) begin >> phase <= phase + rate + (err << `KP); >> rate <= rate + (err << `KI); >> end else >> phase <= phase + rate; >> >>It clocks at 10 MHz and applies corrections every millisecond; hence >>dt=1e-3 >>and kNCO = 10000. >> >>Is the Bode plot correct? >> >>TIA >> > > > Is 'err' quantized to two values, early or late bang-bang style, or is > it some finer-grain time error signal? > > John > err is fine-grained: approx +/- 2^20 Actually, kPD slope should be 2*(2^20) per chip.Article: 150635
On 01/30/2011 09:53 AM, Andrew Holme wrote: > I've implemented a DSSS receiver in an FPGA. The code rate NCO is > controlled by an early/late detector. The carrier NCO is controlled by a > Costas Loop. I chose PI gain constants for the control loops by trial and > error but would like to do it more scientifically by analysing stability > using a Bode plot of open loop gain. I always do it this way for analogue > PLLs; but I'm new to z-domain stability analysis. > > TimW - I bought your book; but, to be honest, found it quite heavy going. > Nevertheless, adapting some code from the accompanying CD, I came up with > this Scilab script: > > kPD = 2^20; > kP = 2^(41-64); > kI = 2^(15-64); > kNCO = 10000; > G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1); > G.dt = 1e-3; > scf(0); > clf; > bode(G); > > The resulting Bode plot never even passes through unity gain! So is the > system unconditionally stable? Here's a simplified version of the FPGA > code: There's several things wrong with this -- does the loop actually work? Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which should guarantee wild Fs/2 oscillations. kP / kI is 67 million some odd, which means your integrator doesn't start doing anything until Fs/67000000 or so -- that's a pretty low frequency for an integrator to kick in. As a minor point, you're including the subtraction in the phase comparator, meaning that your phase shift criterion is 0 rather than 180 -- that's not how most folks do it, but there's a significant enough minority that do that I can't quibble _too_ much. As another minor point, Scilab (and anything that uses polynomials for this sort of analysis) is vulnerable to numerical errors when the order of the system gets high. Using -->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1)); dodges this (note that I'm using my preferred sign convention). It's not the issue here. > > `define KP 41 > `define KI 15 > > reg [63:0] phase, rate; // 64 places after the binary point > reg signed [31:0] err; // = Early - Late > > always @ (posedge clk) // 10 MHz > if (millisecond) begin > phase<= phase + rate + (err<< `KP); > rate<= rate + (err<< `KI); > end else > phase<= phase + rate; > > It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3 > and kNCO = 10000. > > Is the Bode plot correct? I'm not going to pick through that Verilog code for a complete model unless you pay me, but I know it's not matching the transfer function that you give. Here's some points that I can pick out: * If KP were 0, then phase <= phase + rate + (err << 'KP) would give an effective kP of 1, or if you're viewing your variables as fractional, then kP of 2^-32. Not 2^-64. * You are only applying your proportional term, and updating your integrator, on the millisecond intervals. But you are applying your integrator state to the phase every NCO sampling interval. This gives your integrator an extra gain of 10MHz * 1ms. It would arguably be much better style (and it would certainly give you smoother operation) if you calculated a frequency increment command separately from your controller update. You may not want the slowness that comes with smoothness, and you may not want to carry the extra storage -- which is where the arguing comes in. So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in your model are already way too high. If things work, this makes me suspect that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?) If I make the factor of 10000 correction to kI I get an integrator zero at around 0.04Hz, which is not terribly unreasonable, if a bit slow. I'm still not getting a gain of 1 in the region of 90 degrees phase shift, but I'll leave that part to you. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150636
Impact reports something like "device not recognized" and then I point it to the .bit file. Reading ID / signature shows that all bits are zeros. Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change states. I have an old analog scope and the time period is very short (for me, human), but I can see that signals are valid (0 and 3V3, nothing strange happening). Can I make Impact talk to the fpga more often, so I can better see the signals? (If not, I could make a prog to toggle the port pins...) I've used the same JTAG programming board for Spartan 2, and it works. Spartan2, Spartan3A and parallel port JTAG boards were all done by me. I have the PROG pin HIGH, the rest are floating. Then I've connected M0-M2 and PUDC HIGH, but its the same. Any thoughts?Article: 150637
On Jan 30, 10:06=A0pm, aleksa <aleks...@gmail.com> wrote: > the rest are floating. i.e. CCLK, DIN, CS, INIT, all clocks. Power pins are connected :)Article: 150638
VCCAUX is at 3V3, and constraint is in the UCF, also.Article: 150639
On Jan 30, 1:06=A0pm, aleksa <aleks...@gmail.com> wrote: > Impact reports something like "device not recognized" and then I point > it to the .bit file. > Reading ID / signature shows that all bits are zeros. > > Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change > states. > I have an old analog scope and the time period is very short (for me, > human), > but I can see that signals are valid (0 and 3V3, nothing strange > happening). > > Can I make Impact talk to the fpga more often, so I can better see the > signals? > (If not, I could make a prog to toggle the port pins...) > > I've used the same JTAG programming board for Spartan 2, and it works. > Spartan2, Spartan3A and parallel port JTAG boards were all done by me. > > I have the PROG pin HIGH, the rest are floating. > Then I've connected M0-M2 and PUDC HIGH, but its the same. > > Any thoughts? Having the IDCODE reported as all zeros indicates that the JTAG is broken somewhere or the TAP controller is being held in reset. 1) You indicated the PROGRAM_B was high (was this measured?), but what about INIT_B? 2) Have you confirm that TCK is getting to the TCK pin of the Spartan-3A device? 3) Have you probed the TDO at the Spartan-3A device for any activity? Ed McGettigan -- Xilinx Inc.Article: 150640
"Tim Wescott" <tim@seemywebsite.com> wrote in message news:D8Wdnfpn6tJmUdjQnZ2dnUVZ_gKdnZ2d@web-ster.com... > On 01/30/2011 09:53 AM, Andrew Holme wrote: >> I've implemented a DSSS receiver in an FPGA. The code rate NCO is >> controlled by an early/late detector. The carrier NCO is controlled by a >> Costas Loop. I chose PI gain constants for the control loops by trial >> and >> error but would like to do it more scientifically by analysing stability >> using a Bode plot of open loop gain. I always do it this way for >> analogue >> PLLs; but I'm new to z-domain stability analysis. >> >> TimW - I bought your book; but, to be honest, found it quite heavy going. >> Nevertheless, adapting some code from the accompanying CD, I came up with >> this Scilab script: >> >> kPD = 2^20; >> kP = 2^(41-64); >> kI = 2^(15-64); >> kNCO = 10000; >> G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1); >> G.dt = 1e-3; >> scf(0); >> clf; >> bode(G); >> >> The resulting Bode plot never even passes through unity gain! So is the >> system unconditionally stable? Here's a simplified version of the FPGA >> code: > > There's several things wrong with this -- does the loop actually work? > > Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which should > guarantee wild Fs/2 oscillations. > > kP / kI is 67 million some odd, which means your integrator doesn't start > doing anything until Fs/67000000 or so -- that's a pretty low frequency > for an integrator to kick in. > > As a minor point, you're including the subtraction in the phase > comparator, meaning that your phase shift criterion is 0 rather than > 180 -- that's not how most folks do it, but there's a significant enough > minority that do that I can't quibble _too_ much. > > As another minor point, Scilab (and anything that uses polynomials for > this sort of analysis) is vulnerable to numerical errors when the order of > the system gets high. Using > > -->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1)); > > dodges this (note that I'm using my preferred sign convention). It's not > the issue here. > >> >> `define KP 41 >> `define KI 15 >> >> reg [63:0] phase, rate; // 64 places after the binary point >> reg signed [31:0] err; // = Early - Late >> >> always @ (posedge clk) // 10 MHz >> if (millisecond) begin >> phase<= phase + rate + (err<< `KP); >> rate<= rate + (err<< `KI); >> end else >> phase<= phase + rate; >> >> It clocks at 10 MHz and applies corrections every millisecond; hence >> dt=1e-3 >> and kNCO = 10000. >> >> Is the Bode plot correct? > > I'm not going to pick through that Verilog code for a complete model > unless you pay me, but I know it's not matching the transfer function that > you give. Here's some points that I can pick out: > > * If KP were 0, then phase <= phase + rate + (err << 'KP) would > give an effective kP of 1, or if you're viewing your variables > as fractional, then kP of 2^-32. Not 2^-64. > > * You are only applying your proportional term, and updating your > integrator, on the millisecond intervals. But you are applying > your integrator state to the phase every NCO sampling interval. > This gives your integrator an extra gain of 10MHz * 1ms. > > It would arguably be much better style (and it would certainly > give you smoother operation) if you calculated a frequency > increment command separately from your controller update. You > may not want the slowness that comes with smoothness, and you > may not want to carry the extra storage -- which is where the > arguing comes in. > > So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in your > model are already way too high. If things work, this makes me suspect > that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?) > > If I make the factor of 10000 correction to kI I get an integrator zero at > around 0.04Hz, which is not terribly unreasonable, if a bit slow. I'm > still not getting a gain of 1 in the region of 90 degrees phase shift, but > I'll leave that part to you. > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com > > Do you need to implement control loops in software? > "Applied Control Theory for Embedded Systems" was written for you. > See details at http://www.wescottdesign.com/actfes/actfes.html Tim, thank you. I had applied that kNCO=10000 multiplier to both kI and kP. It should only be applied to kI for exactly the reason you have pointed out. The following code is giving me a sensible looking Bode plot: kPD = 2^20; kP = 2^(41-64); kI = 10000 * 2^(18-64); G = -kPD * (kP + kI/(%z-1)) / (%z-1); G.dt = 1e-3; scf(0); clf; bode(G); I'm using `KI=18 in the latest FPGA. The rate was taking several seconds to settle. Thanks for the free consultancy :-) I will study the book.Article: 150641
On 01/30/2011 04:19 PM, Andrew Holme wrote: > "Tim Wescott"<tim@seemywebsite.com> wrote in message > news:D8Wdnfpn6tJmUdjQnZ2dnUVZ_gKdnZ2d@web-ster.com... >> On 01/30/2011 09:53 AM, Andrew Holme wrote: >>> I've implemented a DSSS receiver in an FPGA. The code rate NCO is >>> controlled by an early/late detector. The carrier NCO is controlled by a >>> Costas Loop. I chose PI gain constants for the control loops by trial >>> and >>> error but would like to do it more scientifically by analysing stability >>> using a Bode plot of open loop gain. I always do it this way for >>> analogue >>> PLLs; but I'm new to z-domain stability analysis. >>> >>> TimW - I bought your book; but, to be honest, found it quite heavy going. >>> Nevertheless, adapting some code from the accompanying CD, I came up with >>> this Scilab script: >>> >>> kPD = 2^20; >>> kP = 2^(41-64); >>> kI = 2^(15-64); >>> kNCO = 10000; >>> G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1); >>> G.dt = 1e-3; >>> scf(0); >>> clf; >>> bode(G); >>> >>> The resulting Bode plot never even passes through unity gain! So is the >>> system unconditionally stable? Here's a simplified version of the FPGA >>> code: >> >> There's several things wrong with this -- does the loop actually work? >> >> Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which should >> guarantee wild Fs/2 oscillations. >> >> kP / kI is 67 million some odd, which means your integrator doesn't start >> doing anything until Fs/67000000 or so -- that's a pretty low frequency >> for an integrator to kick in. >> >> As a minor point, you're including the subtraction in the phase >> comparator, meaning that your phase shift criterion is 0 rather than >> 180 -- that's not how most folks do it, but there's a significant enough >> minority that do that I can't quibble _too_ much. >> >> As another minor point, Scilab (and anything that uses polynomials for >> this sort of analysis) is vulnerable to numerical errors when the order of >> the system gets high. Using >> >> -->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1)); >> >> dodges this (note that I'm using my preferred sign convention). It's not >> the issue here. >> >>> >>> `define KP 41 >>> `define KI 15 >>> >>> reg [63:0] phase, rate; // 64 places after the binary point >>> reg signed [31:0] err; // = Early - Late >>> >>> always @ (posedge clk) // 10 MHz >>> if (millisecond) begin >>> phase<= phase + rate + (err<< `KP); >>> rate<= rate + (err<< `KI); >>> end else >>> phase<= phase + rate; >>> >>> It clocks at 10 MHz and applies corrections every millisecond; hence >>> dt=1e-3 >>> and kNCO = 10000. >>> >>> Is the Bode plot correct? >> >> I'm not going to pick through that Verilog code for a complete model >> unless you pay me, but I know it's not matching the transfer function that >> you give. Here's some points that I can pick out: >> >> * If KP were 0, then phase<= phase + rate + (err<< 'KP) would >> give an effective kP of 1, or if you're viewing your variables >> as fractional, then kP of 2^-32. Not 2^-64. >> >> * You are only applying your proportional term, and updating your >> integrator, on the millisecond intervals. But you are applying >> your integrator state to the phase every NCO sampling interval. >> This gives your integrator an extra gain of 10MHz * 1ms. >> >> It would arguably be much better style (and it would certainly >> give you smoother operation) if you calculated a frequency >> increment command separately from your controller update. You >> may not want the slowness that comes with smoothness, and you >> may not want to carry the extra storage -- which is where the >> arguing comes in. >> >> So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in your >> model are already way too high. If things work, this makes me suspect >> that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?) >> >> If I make the factor of 10000 correction to kI I get an integrator zero at >> around 0.04Hz, which is not terribly unreasonable, if a bit slow. I'm >> still not getting a gain of 1 in the region of 90 degrees phase shift, but >> I'll leave that part to you. >> >> -- >> >> Tim Wescott >> Wescott Design Services >> http://www.wescottdesign.com >> >> Do you need to implement control loops in software? >> "Applied Control Theory for Embedded Systems" was written for you. >> See details at http://www.wescottdesign.com/actfes/actfes.html > > > Tim, thank you. I had applied that kNCO=10000 multiplier to both kI and kP. > It should only be applied to kI for exactly the reason you have pointed out. > > The following code is giving me a sensible looking Bode plot: > > kPD = 2^20; > kP = 2^(41-64); > kI = 10000 * 2^(18-64); > G = -kPD * (kP + kI/(%z-1)) / (%z-1); > G.dt = 1e-3; > scf(0); > clf; > bode(G); > > I'm using `KI=18 in the latest FPGA. The rate was taking several seconds to > settle. > > Thanks for the free consultancy :-) I will study the book. The integrator shift of 15 certainly showed in the Bode plot as being insufficient for fast settling. Note that with all-digital systems like this you can often push your system much harder than you would if you have physical components -- you don't have such inconveniences as unknown dynamics or gains that change. On the other hand, you have to make sure that your model really does match reality!! -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150642
On Jan 30, 11:31=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Jan 30, 1:06=A0pm, aleksa <aleks...@gmail.com> wrote: > > > > > > > Impact reports something like "device not recognized" and then I point > > it to the .bit file. > > Reading ID / signature shows that all bits are zeros. > > > Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change > > states. > > I have an old analog scope and the time period is very short (for me, > > human), > > but I can see that signals are valid (0 and 3V3, nothing strange > > happening). > > > Can I make Impact talk to the fpga more often, so I can better see the > > signals? > > (If not, I could make a prog to toggle the port pins...) > > > I've used the same JTAG programming board for Spartan 2, and it works. > > Spartan2, Spartan3A and parallel port JTAG boards were all done by me. > > > I have the PROG pin HIGH, the rest are floating. > > Then I've connected M0-M2 and PUDC HIGH, but its the same. > > > Any thoughts? > > Having the IDCODE reported as all zeros indicates that the JTAG is > broken somewhere or the TAP controller is being held in reset. > > 1) You indicated the PROGRAM_B was high (was this measured?), but what > about INIT_B? > 2) Have you confirm that TCK is getting to the TCK pin of the > Spartan-3A device? > 3) Have you probed the TDO at the Spartan-3A device for any activity? > > Ed McGettigan > -- > Xilinx Inc. Yes, PROG is HIGH. INIT_B was floating. I've pulled it up now, but no change. TDO does show activity. I've made a prog to pulse (500 kHz) the TMS, TCK and TDI signals, and they all get to FPGA, nice and clean.Article: 150643
some tests I did: 1. started iMPACT. 2. double click on Boundary scan. 3. right click, Initialize Chain. I get blue text "Identify succeeded" The part is already shown as unknown. I'm asked "Do you want to cont. and assign conf. files?" YES "Do you have a BSDL or BIT file?" YES (xc3s50a.bsd) 4. Debug, Chain integrity test = OK. Everything else fails.Article: 150644
Is it possible to simply add the EDK (which includes the SDK) to ISE WebPack OR is it necessary to get the ISE Embedded suite please? Thanks, Rog.Article: 150645
On Jan 31, 4:46=A0am, aleksa <aleks...@gmail.com> wrote: > some tests I did: > > 1. started iMPACT. > 2. double click on Boundary scan. > 3. right click, Initialize Chain. > > I get blue text "Identify succeeded" > The part is already shown as unknown. > > I'm asked "Do you want to cont. and assign conf. files?" YES > "Do you have a BSDL or BIT file?" YES (xc3s50a.bsd) > > 4. Debug, Chain integrity test =3D OK. > > Everything else fails. What was the IDCODE reported by iMPACT? When you put the oscilloscope on the TDO output what voltage levels did you see? Is the TDO of the part connected to the TDO of the cable? Are there any other devices in the JTAG chain? Ed McGettigan -- Xilinx Inc.Article: 150646
On Jan 31, 6:43=A0am, "Roger" <rogerwil...@hotmail.com> wrote: > Is it possible to simply add the EDK (which includes the SDK) to ISE WebP= ack > OR is it necessary to get the ISE Embedded suite please? > > Thanks, > > Rog. If all of the devices that you need are in the WebPack then you can just add the EDK tools. Ed McGettigan -- Xilinx Inc.Article: 150647
On Jan 31, 4:25=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Jan 31, 4:46=A0am, aleksa <aleks...@gmail.com> wrote: > > > some tests I did: > > > 1. started iMPACT. > > 2. double click on Boundary scan. > > 3. right click, Initialize Chain. > > > I get blue text "Identify succeeded" > > The part is already shown as unknown. > > > I'm asked "Do you want to cont. and assign conf. files?" YES > > "Do you have a BSDL or BIT file?" YES (xc3s50a.bsd) > > > 4. Debug, Chain integrity test =3D OK. > > > Everything else fails. > > What was the IDCODE reported by iMPACT? IDCODE =3D all zeros > When you put the oscilloscope on the TDO output what voltage levels > did you see? 0 and 3.2V > Is the TDO of the part connected to the TDO of the cable? Yes, I've placed a JTAG gif here http://www60.zippyshare.com/v/18748688/file.html > Are there any other devices in the JTAG chain? NoArticle: 150648
>> I have had it confirmed that if you generate a reset synchronously then use it >> 'asynchronously' in the standard process template (VHDL) that Quartus knows it's >> a synchronous signal and all timing analysis is correctly handled. >> > Rick is correct, where generic code loses its portability, and not all devices or manufacturers > may have this property. Fair enough if the logic you're designing might be targeted at any manufacturers devices. I'm just confirming the case with the Altera tools that a synchronously generated reset that's implemented as an apparently asycnchronous reset is treated synchronously. Ie the reset trees are used instead of wasting a valuable logic input to implement the reset. Nial.Article: 150649
Hi everyone, I'm looking for someone that can develop an FPGA based multiUART with 32 UARTs for me. My software will run on this board: h**p://www.andahammer.com/mini35- sdk. The mini2440 ARM board has 40 pin system expansion bus connector that will connect to the multiuart PCB you develop. Each UART in the multiUART will connect to a gasoline dispenser using optoisolated 20mA, 30 mA, 45mA current loop. I will provide schematics for the TTL-current loop conversion. I was thinking the UARTs could be the 16750 from opencores.org. It's supposed to be stable and it works with standard Linux drivers. h**p:// opencores.org/project,uart16750 Check out the schematics of a mini2440 expansion card that Eric Brombaugh already developed. h**p://members.cox.net/ebrombaugh1/synth/mini_2440_fpga/index.html Regards Axel
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